sistema de detecÇÃo de queda e monitoramento da...

UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ

CAMPUS DE FOZ DO IGUAÇU

PROGRAMA DE PÓS-GRADUAÇÃO EMENGENHARIA ELÉTRICA E COMPUTAÇÃO

DISSERTAÇÃO DE MESTRADO

SISTEMA DE DETECÇÃO DE QUEDA EMONITORAMENTO DA FREQUÊNCIA CARDÍACA

UTILIZANDO ESP8266 E PROTOCOLO MQTT

ALANNA VANZELLA

FOZ DO IGUAÇU2018

Alanna Vanzella

Sistema de Detecção de Queda e Monitoramento daFrequência Cardíaca Utilizando ESP8266 e Protocolo MQTT

Dissertação de Mestrado apresentada ao Programa dePós-Graduação em Engenharia Elétrica e Computa-ção como parte dos requisitos para obtenção do tí-tulo de Mestre em Engenharia Elétrica e Computa-ção. Área de concentração: Sistemas Dinâmicos eEnergéticos.

Orientador: Adriana Tokuhashi KauatiCo-orientador: Renato Bobsin Machado

Foz do Iguaçu2018

Resumo

Segundo o IBGE há um continuado crescimento no número de arranjos unipessoais. As causasmais impactantes para isso são a queda da fecundidade e envelhecimento da população. O au-mento de pessoas que moram sozinhas traz o problema da falta de ajuda para solicitar socorromédico em casos de emergência. Problema este, agravado com o fato da população brasileiraestar passando por um processo de envelhecimento. Uma solução para isso são sistemas demonitoramento de pessoas. Porém, o desenvolvimento de um sistema de monitoramento não setrata de uma tarefa trivial, pois envolve diversas fontes de dados diferentes. Além disso, é ne-cessário transformar os dados em informações para posterior apresentação e, por fim, forneceruma forma para gerenciamento de toda a solução. A proposta deste trabalho é apresentar umaarquitetura simples e economicamente acessível para um sistema de detecção de quedas e mo-nitoramento da frequência cardíaca. O objetivo é construir uma aplicação voltada para pessoasque precisam ser monitoradas por parentes ou um responsável, sem a interferência de empresas,hospitais, clínicas, etc. O sistema proposto visa atuar como uma segurança extra para pessoasque moram sozinhas, idosas ou não. Para guiar o desenvolvimento deste trabalho e solucionaralguns dos problemas citados, empregou-se o conceito e soluções presentes em aplicações deInternet das Coisas. Utilizou-se um acelerômetro para detectar quedas e um sensor para mo-nitoramento dos sinais elétricos do coração. Esses dois sensores foram conectados ao móduloWi-Fi ESP8266, sendo este o responsável por pré-processar os dados, gerar alertas e enviá-losutilizando o protocolo de comunicação MQTT para o broker. Um sistema web é a interfacepara a gestão das informações e apresenta os alertas detectados de todos os sensores conectadosaos ESP8266. Por fim, uma aplicação móvel permite a visualização dos alertas detectados dousuário autenticado, assim como dos usuários pelos quais ele é responsável. De acordo com ostestes de desempenho realizados na aplicação web e broker, verificou-se que é possível o enviode 1.500 alertas simultâneos sem apresentar falhas. A placa ESP8266 se mostrou adequada paraeste trabalho apresentando uma autonomia de bateria de aproximadamente 8 dias sem desligaro equipamento. O algoritmo de detecção de quedas também se mostrou eficaz, com 93% deacurácia.

Palavras-chave: Internet das Coisas, monitoramento da saúde, testes de desempenho, consumode energia.

v

Abstract

According to the IBGE there is a continuous increase in the number of single-person arrange-ments. The main causes for this, are decline in fertility and aging of population. With the in-crease in the number of people living alone comes the problem of who will help in emergenciescase. This problem become more alarmant by the fact that brazilian population is undergoing anaging process. One solution to this is people monitoring systems. However, the development ofa monitoring system is not a trivial task because it involves several different data sources. Be-sides that, it is necessary to transform data into information for later presentation and providea way to manage the entire solution. The idea of this work is to present a simple architectureand economically accessible system for fall detection and heart rate monitoring. The goal is todevelop a solution to people who need to be monitored by relatives or a responsible one, withoutinterference of companies, hospitals, clinics, etc. The proposed system aims to be as an extrasecurity for people who live alone, elderly or not. In order to solve some of the problems men-tioned above, this work was guided by the concept and solutions present in Internet of Things(IoT). It was used an accelerometer to detect falls and a sensor to monitor heart’s electricalsignals. These two sensors were connected to Wi-Fi module, ESP8266, which is responsiblefor preprocessing data, generating alerts and sending them to broker with MQTT communica-tion protocol. A web system is the interface for information management and presents detectedalerts of all sensors connected to ESP8266. Finally, a mobile application allows to view detec-ted alerts of authenticated user as well as the users for whom he is responsible. According to theperformance tests in web application and broker, it was verified that it is possible to send 1500simultaneous alerts without failures. The ESP8266 board proved suitable presenting a batterylife of almost 8 days without disconnecting the equipment. The fall detection algorithm wasalso effective, with 93% accuracy.

Keywords: Internet of Things, health monitoring, performance tests, energy consumption.

vi

Agradecimentos

Aqui vão os meus agradecimentos a todos que contribuíram, de maneira direta ou indireta,ostensiva ou não, explícita ou implícita, formal ou informal, para que este trabalho pudesse terchegado ao seu fim a contento.

Assim, agradeço à Profa Kauati e ao Profo Renato por me guiarem e possibilitarem arealização desse trabalho.

Agradeço também à meus pais, Valéria e Pedro, por dedicarem suas vidas a família esempre reforçarem a importância do estudo em nossas vidas.

Ao Parque Tecnológico Itaipu (PTI) por apoiar seus colaboradores a se qualificarem e aomeu gestor, Rodrigo, por permitir que parte do tempo de trabalho fosse dedicado aos estudos.

Por fim, agradeço ao meu marido, Dario, por ter me dado toda a estrutura necessária, nãome permitindo cair nunca.

vii

Sumário

Lista de Figuras xii

Lista de Quadros xiii

Lista de Tabelas xv

Lista de Símbolos xvii

1 Introdução 1

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Descrição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Internet das Coisas 7

2.1 Considerações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Potencial Comercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Arquitetura IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Elementos IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Identificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.2 Sensores/Atuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.3 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.4 Processamento de dados . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.5 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.6 Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 Padrões para IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ix

x

2.6.1 Protocolos de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6.2 Tecnologias de comunicação . . . . . . . . . . . . . . . . . . . . . . . 16

2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Detecção de Quedas 19


3.2 Algoritmos e Técnicas para Detecção de Queda . . . . . . . . . . . . . . . . . 20

3.2.1 Classificação dos Movimentos Humanos . . . . . . . . . . . . . . . . 20

3.2.2 Sistema para Detecção de Quedas . . . . . . . . . . . . . . . . . . . . 21

3.2.3 Determinação de Limiares Simples para Parâmetros Baseados em Ace-lerômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.4 Avaliação de Algoritmos de Detecção de Quedas Baseados em LimiaresUtilizando Acelerômetro . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Métodos para Avaliação de Algoritmos de Detecção de Queda . . . . . . . . . 24


4 Cálculo da Frequência Cardíaca 27


4.2 Funcionamento do Coração e o Eletrocardiograma . . . . . . . . . . . . . . . . 27

4.3 Detecção de QRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Algoritmo de Pan & Tompkins . . . . . . . . . . . . . . . . . . . . . . 30

4.3.2 Algoritmo de HC Chen e SW Chen . . . . . . . . . . . . . . . . . . . 32


5 Tecnologias 35


5.2 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3 DigitalOcean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4 Apache JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.5 JSON Web Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

xi


6 Materiais e Métodos 41


6.2 Funcionalidades do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3 Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4.3 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.4.4 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.4.5 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.4.6 Aplicação Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.5 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.6 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.7 Testes e experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.7.1 Experimentos de Detecção de queda . . . . . . . . . . . . . . . . . . . 57

6.7.2 Testes de Consumo de energia . . . . . . . . . . . . . . . . . . . . . . 58

6.7.3 Teste de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . 59


7 Resultados e Discussão 61


7.2 Sistema de Monitoramento do Corpo Humano (SMCH) . . . . . . . . . . . . . 61

7.2.1 Resultados dos testes de desempenho . . . . . . . . . . . . . . . . . . 63

7.3 Resultados do algoritmo de detecção de quedas . . . . . . . . . . . . . . . . . 66

7.4 Resultados do Consumo de Energia . . . . . . . . . . . . . . . . . . . . . . . 68

7.5 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


xii

8 Conclusão e Trabalhos Futuros 73

Referências Bibliográficas 75

A Arquivo Security.java 81

B Arquivo nginx.conf 83

C Arquivo default.conf 85

D Método FCMPlugin.onNotification - Ionic 87

E Método FCMPlugin.getToken - Ionic 89

F Parecer do comitê de ética da Unioeste 91

G Arquivo de configuração mosquitto.conf 97

Lista de Figuras

2.1 Investimento em aplicações de IoT por ano até 2025 (em trilhões). . . . . . . . 9

2.2 Arquitetura do MQTT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Derivações periféricas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 Diagrama de casos de uso do sistema. . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Passos necessários para enviar um novo alerta. . . . . . . . . . . . . . . . . . . 43

6.3 Passos necessários para inserir um novo dispositivo no sistema. . . . . . . . . . 44

6.4 Arquitetura proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.5 Esquemático da conexão do sensor GY-89 com o ESP8266 . . . . . . . . . . . 54

6.6 Esquemático da conexão do sensor AD8232 com o ESP8266 . . . . . . . . . . 54

6.7 Algoritmo implementado para detecção de quedas. . . . . . . . . . . . . . . . 57

7.1 Aplicação web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2 Aplicação mobile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.3 Telas para cadastrar, remover, editar e buscar usuários. . . . . . . . . . . . . . 63

7.4 Telas para cadastrar, remover, editar e buscar dispositivos. . . . . . . . . . . . . 64

7.5 Tela que ilustra uma nova notificação recebida. . . . . . . . . . . . . . . . . . 64

7.6 Comparação do tempo máximo de execução de acordo com a qualidade de ser-viço e número de mensagens simultâneas. . . . . . . . . . . . . . . . . . . . . 67

7.7 Solução final para detecção de queda. . . . . . . . . . . . . . . . . . . . . . . 67

7.8 Solução real do hardware para detecção do sinal de ECG. . . . . . . . . . . . . 68

xiii

Lista de Quadros

6.1 Docker Compose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2 Configuração do MQTT no Spring. . . . . . . . . . . . . . . . . . . . . . . . . 49

6.3 URI para requisição para o FCM. . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.4 Requisição para o FCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5 Dockerfile do Nginx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.6 Configuração com o broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.7 Conexão com o broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.8 Envio de alertas para o broker. . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C.1 Configurações das aplicações web. . . . . . . . . . . . . . . . . . . . . . . . . 85

xv

Lista de Tabelas

6.1 Hardwares adquiridos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1 Resultado do teste de desempenho do protocolo MQTT. . . . . . . . . . . . . . 65

7.2 Resultados das simulações de quedas . . . . . . . . . . . . . . . . . . . . . . . 67

7.3 Resultados do consumo de energia . . . . . . . . . . . . . . . . . . . . . . . . 68

xvii

Lista de Símbolos

AMQP Advanced Message Queuing ProtocolAMS Área de Magnitude do SinalAPI Application Programming InterfaceBA Componente devido a movimento corporalBLE Bluetooth Low EnergyCEP Comitê de Ética em Pesquisa com Seres HumanosCoAP Constrained Application ProtocolCSS Cascading Style SheetsDNS Domain Name SystemDTLS Datagram Transport Layer SecurityECG EletrocardiogramaEEG eletroencefalogramaEMG EletromiografiaEPC Electronic Product CodeEs EspecificidadeFCM Firebase Cloud MessagingFN Falso NegativoFP Falso PositivoGA Componente devido à gravidadeHTTP Hypertext Transfer ProtocolIBGE Instituto Brasileiro de Geografia e EstatísticaIETF Internet Engineering Task ForceINTO Instituto Nacional de Traumatologia e OrtopediaIoT Internet of ThingsJWT JSON Web TokenMQTT Message Queue Telemetry TransportNAV Nó atrioventricularNSA Nó sinusal ou sinoatrialPC Personal ComputerRDF Resource Description FrameworkREST Representational State TransferRFID Radio-Frequency IdentificationSa Soma total da aceleração

xix

xx

SBC Electronic Product CodeSDK Software Development KitSe SensibilidadeSh Soma da aceleração no plano horizontalSMCH Sistema de Monitoramento do Corpo HumanoSO Sistemas OperacionaisSSL Secure Socket LayerTCP Transmission Control ProtocolTic Tempo em que o corpo bateu no chãoTLS Transport Layer SecurityTrs Tempo em que o corpo iniciou o repousoUDP User Datagram ProtocolUMTS Mobile Telecommunication SystemUNIOESTE Universidade Estadual do Oeste do ParanáURI Uniform Resource IdentifierVMS Vetor de Magnitude do SinalVN Verdadeiro NegativoVP Verdadeiro PositivoWOL Ontology Web LanguageVmax Velocidade máxima até o corpo bater no chãoV SD Vetor de soma dinâmicaV Smaxmin Vetor de soma das diferenças entre máximos e mínimosV STOT Vetor de soma total da aceleraçãoZ2 Aceleração vertical

Capítulo 1

Introdução

Desenvolver novas tecnologias para a área da saúde está entre os 14 grandes desafios paraa engenharia no século XXI (Pandey et al., 2012). Aplicações nessa área têm como tarefas:aquisição de dados, gestão das informações e utilização de conhecimento biomédico, partindoda utilização individual de sensores que enviam os sinais vitais e/ou ambientais para um sistemaremoto, permitindo uma maior eficiência em cuidados médicos e identificação de emergências(Pandey et al., 2012).

Segundo o Instituto Brasileiro de Geografia e Estatística (IBGE) “doenças cardiovascu-lares são a principal causa de morte no Brasil” (IBGE, 2016a). Em 2013, 4,2% (6,1 milhões)de pessoas com idade igual ou superior a 18 anos tiveram algum diagnóstico médico de algumadoença cardíaca (IBGE, 2016a). Outra pesquisa relevante foi a análise das condições de vidada população brasileira feito pelo IBGE em 2013, onde identificou-se um continuado cresci-mento da proporção de pessoas que moram sozinhas (arranjos unipessoais), passando de 9,3%em 2002 para 13,2% em 2012, ou seja, um aumento de 42,4% (IBGE, 2016b). Os fatores maisrelevantes responsáveis por esse crescimento são a queda da fecundidade e o envelhecimentoda população (IBGE, 2016b).

O fato da população brasileira estar passando por um processo de envelhecimento tornaainda mais alarmante a estatística levantada pelo Instituto Nacional de Traumatologia e Orto-pedia (INTO), onde concluiu-se que “de 30% a 60% da população com mais de 65 anos caianualmente e, dessas quedas, de 40% a 60% levam a algum tipo de lesão” (INTO, 2016).

Essas estatísticas mostram a importância de um sistema para monitorar a saúde das pes-soas, permitindo que, não somente hospitais, mas também parentes ou responsáveis sejam aler-tados em caso de emergência.

O desenvolvimento de um sistema de monitoramento não é uma tarefa trivial, pois envolvea utilização de diversas tecnologias e em várias camadas de abstração. Nesse cenário é interes-sante apropriar-se do conceito de Internet das Coisas (IoT do inglês Internet of Things), ondediversos dispositivos são conectados e possibilitados de se comunicarem entre si. AplicaçõesIoT são capazes de adicionar “inteligência” em qualquer ambiente, objeto, eletrodoméstico, etc.

1

2

Sendo assim, utilizando das tecnologias envolvidas nas aplicações IoT, é possível o desenvol-vimento de sistemas inovadores na área da saúde, dentre eles, sistemas para monitoramento dasaúde.

Os elementos básicos para a construção de aplicações IoT são: identificação; sensores/a-tuadores; comunicação; processamento de dados; serviços e semântica (Al-Fuqaha et al., 2015).A identificação se refere a um objeto ter uma identificação única dentro da rede, podendo serutilizado o Protocolo da Internet versão 6 ou 4 (IPv6 ou IPv4 do inglês Internet Protocol v6 ouv4) para essa tarefa. Os sensores são os responsáveis por coletar os dados e enviá-los para umabase de dados. Alguns sensores que podem ser utilizados para coletar informações importantesdo corpo humano são:

• Sensor para monitoramento dos sinais elétricos do coração, utilizado para obter o ECG(eletrocardiograma), a partir do qual se pode calcular a frequência cardíaca;

• Sensor para monitoramento do funcionamento do músculo, utilizado para obter o sinal deEMG (eletromiografia);

• Sensor para monitoramento das atividades cerebrais, capaz de obter o sinal de EEG (ele-troencefalograma);

• Sensor que mede a pressão sanguínea;

• Sensor para monitorar a respiração;

• Sensores de movimento.

Para realizar a comunicação entre os dispositivos, existem os protocolos de aplicação ecomunicação (Santos et al., 2016). Dentre os protocolos de aplicação, destacam-se o Cons-trained Application Protocol (CoAP) e Message Queue Telemetry Transport (MQTT), pois sãoideais para dispositivos com baixo poder de processamento e que necessitam de baixo consumode energia (Santos et al., 2016). Quanto aos protocolos de comunicação, os padrões ZigBee eBluetooth Low Energy (BLE) são interessantes para aplicações IoT, principalmente por poupa-rem energia dos dispositivos (Santos et al., 2016). O Wi-Fi é um padrão amplamente utilizadonas residências, comércios, hospitais, etc., porém o consumo de energia é alto, tornando-o ina-dequado para esse tipo de aplicação (Santos et al., 2016). Mas existem dispositivos criados pararesolver esse problema, como por exemplo o ESP8266, viabilizando a utilização do Wi-Fi emaplicações IoT.

Através dos protocolos de aplicação e comunicação é possível enviar os dados dos sen-sores para um servidor na nuvem. Na nuvem esses dados são armazenados, permitindo queaplicações clientes tenham acesso às informações históricas sempre que desejarem.

3

As unidades de processamento (por exemplo, microcontroladores e microprocessadores)e aplicações de software representam o “cérebro” e a capacidade computacional da IoT (Al-Fuqaha et al., 2015). Diversos hardwares foram desenvolvidos para suportar aplicações IoT,como por exemplo Arduino, UDOO, Intel Galileo, Raspberry PI, BeagleBone, entre outros.

Uma aplicação IoT deve disponibilizar uma gama de serviços. Dentre eles destacam-seos serviços que permitam a identificação única de cada objeto; serviços que coletam e tratammedições sensoriais brutas; serviços que tomam decisões e atuam de acordo com os dadoscoletados; e serviços de colaboração e inteligência, que devem estar disponíveis em qualquermomento que eles forem necessários, assim como para qualquer um e em qualquer lugar (Al-Fuqaha et al., 2015).

Por fim, a semântica, no contexto de IoT, se refere a habilidade de extrair conhecimentode diferentes dispositivos para fornecer os serviços solicitados (Al-Fuqaha et al., 2015).

Existem, na literatura, diversos trabalhos que abordam IoT e healthcare, utilizando diver-sas tecnologias. Dentre esses trabalhos, Yang, Xie, Mäntysalo, Zhou, Pang, Xu, Kao-Walter,Chen & Zheng (2014) desenvolveram um sistema de monitoramento da saúde em residências.O sistema foi desenvolvido em 3 blocos: os sensores, capazes de coletar sinais biomédicos;uma caixa médica, que armazena os remédios prescritos, além de receber os dados dos sensorese enviá-los para um servidor através da internet; e um servidor, responsável por disponibilizaras informações históricas, em tempo real, para aplicações clientes.

Yang, Ge, Li, Rao & Shen (2014) desenvolveram um sistema para monitoramento depessoas em cadeira de rodas. Esse sistema é composto pelos seguintes componentes: sensores;um conversor de ZigBee para Bluetooth; um smartphone; e um servidor. O conversor é utilizadocomo um gateway para fazer a comunicação dos sensores com o smartphone, para que este envieos dados para o servidor através da internet.

Rasid et al. (2014) e Jara et al. (2013) utilizam o protocolo 6LoWPAN, onde cada pacientee seus sensores são considerados nós. Cada paciente envia os dados para um gateway, sendoeste o responsável por distribuir os dados, podendo ser de acesso local ou envio dos dados paraa nuvem. O protocolo IPv6 Over Low Power Wireless Personal Area Networks (6LoWPAN)é utilizado para pequenas distâncias, por este motivo, Shahamabadi et al. (2013) propõe umasolução para melhorar a questão de mobilidade utilizando 6LoWPAN.

O baixo consumo de energia é um desafio importante em aplicações IoT, a fim de contri-buir para a resolução deste problema, Kiran et al. (2014) propõe uma técnica de amostragemesparsa inteligente, e seu uso juntamente com uma transmissão inteligente, diminui a geração eenvio de dados.

A proposta desse trabalho é apresentar uma arquitetura mais simples e acessível economi-camente que as encontradas na literatura, além de desenvolver um sistema que permita o acessonão apenas para empresas, hospitais e clínicas, mas também para ambientes familiares, sem

4

depender de terceiros. Nessa arquitetura, os sensores que obtém informações do paciente seconectam com um módulo Wi-Fi, que é responsável por pré-processar os dados, detectar aler-tas e enviá-los para o servidor. A comunicação entre o módulo Wi-Fi e o servidor é realizadautilizando o protocolo MQTT. Um sistema web realiza a configuração inicial dos sensores, paraentão receber os alertas e disponibilizá-los para visualização. O sistema web também é res-ponsável pela autenticação e gestão das informações de todos os pacientes cadastrados. Porúltimo, uma aplicação mobile apresenta os alertas da pessoa autenticada e da pessoa pela qual éresponsável, além de receber notificação quando um novo alerta ocorrer.

A solução proposta, por meio do presente trabalho, visa atuar como uma segurança extrapara pessoas que moram sozinhas, idosas ou não.

1.1 Objetivos

O objetivo desse trabalho é desenvolver e validar um sistema de monitoramento de ECGe de queda, voltado para pessoas que precisam ser monitoradas por um parente ou responsável.Os objetivos específicos são:

• Criar uma arquitetura simplificada, possibilitando o acesso para ambientes familiares,sem depender de terceiros;

• Comunicar um ECG e um acelerômetro com o ESP8266 (módulo Wi-Fi), pré-processaros valores e gerar alertas de queda e de frequência cardíaca elevada;

• Estudar e implementar o protocolo MQTT, permitindo que o ESP8266 envie os dadospara um servidor;

• Desenvolver um sistema web que permita a configuração e gestão das informações;

• Desenvolver uma aplicação mobile que permita a visualização dos alertas detectados dopaciente autenticado ou do paciente do responsável autenticado;

• Realizar testes de consumo do ESP8266 e desempenho do protocolo MQTT, analisandoprincipalmente, perda de pacotes e velocidade de envio.

1.2 Descrição do Problema

Diante dos dados estatísticos levantados e previamente citados, identificou-se nichos ondehá a necessidade de um sistema de monitoramento da saúde. Pessoas com problemas cardio-vasculares, idosos e pessoas que moram sozinhas, não possuem um meio simples e eficiente

5

de serem monitoradas e receberem o atendimento médico, quando necessário, o mais rápidopossível.

Uma solução de monitoramento da saúde vestível, o menos intrusiva possível, poderia sercapaz de detectar situações de emergência. O ideal seria o envio de alertas diretamente para hos-pitais, os quais enviariam um transporte para realizar o atendimento. Porém, o desenvolvimentode uma aplicação de monitoramento envolvendo as atividades de hospitais é muito complexo,pois o sistema não deve ter falsos positivos (alertas de emergências falsos). Um falso positivoiria trazer transtornos e gastos desnecessários, fazendo com que o sistema caia em descrédito.

Outra possibilidade seria a utilização de empresas especializadas em envio de atendimentode emergência. Porém o custo de uma empresa desse tipo é muito alto, o que acarretaria em umcusto mais elevado para a utilização pelo usuário final.

É possível a criação de um sistema mais simples e acessível. Existem no mercado diversosdispositivos vestíveis, capazes de coletar sinais vitais e de movimento. Dentre esses dispositivosestão:

• Cinta para monitoramento de frequência cardíaca: essas cintas são capazes de realizar aleitura da frequência cardíaca, e enviar para algum outro dispositivo (normalmente umsmartphone) utilizando tecnologias de comunicação sem fio;

• Pulseiras inteligentes: são capazes de coletar diversos dados, entre os quais: frequênciacardíaca; localização; temperatura corporal; número de passos dados; etc. Assim comoas cintas, essas pulseiras enviam os dados para um smartphone, normalmente utilizandoo Bluetooth;

• Smartphones: os próprios celulares já coletam diversos dados que poderiam ser utilizadospara detectar emergências. Por exemplo, pode-se utilizar o acelerômetro para detectarquedas.

Todos os dispositivos citados possuem diversos modelos de variadas marcas, e preçostambém diversificados. Porém, para se obter todas as funcionalidades desejadas, pode ser ne-cessária a compra de mais de um dispositivo, podendo atingir um valor elevado para a soluçãofinal.

Com o objetivo de obter um produto mais acessível economicamente, é necessário umdispositivo e sistemas mais simples. Nesse trabalho foi avaliado o módulo Wi-Fi ESP8266,sendo este um microprocessador de baixo custo, e ao utilizá-lo, elimina-se a necessidade deelementos intermediários para envio dos sinais biomédicos para um servidor. O ESP8266 possuiuma capacidade computacional limitada, além disso, o consumo de energia deve ser otimizado.Para enviar as mensagens do ESP8266 para um servidor, deve-se utilizar um protocolo de enviode mensagens apropriado para suas limitações, o MQTT.

6

Neste trabalho foi desenvolvido um sistema de monitoramento sem o envolvimento dehospitais ou clínicas. O sistema foi concebido para o uso doméstico. Deste modo, os pacientesserão monitorados por familiares ou pessoas de confiança. Em caso de emergência, o sistemaemite um alerta para o responsável pelo paciente e para o próprio paciente. Se o alerta emitidofor um falso positivo, o próprio paciente pode informar o responsável que não se trata de umalerta.

Para alcançar o objetivo deste trabalho, esta dissertação está organizada da seguinte forma:

• No capítulo 2 é apresentada a fundamentação teórica de Internet das Coisas, onde sãoidentificados desafios, potencial comercial, arquitetura de desenvolvimento e algumastecnologias necessárias para o desenvolvimento de aplicações IoT;

• No capítulo 3 é feito um estudo bibliográfico sobre detecção de quedas, pois será neces-sário estudar e implementar um algoritmo para detecção de quedas;

• No capítulo 4 é feito um estudo bibliográfico sobre o cálculo de frequência cardíaca atra-vés do eletrocardiograma, pois será necessário estudar e implementar um algoritmo parao cálculo da frequência cardíaca;

• No capítulo 5 são apresentadas as principais tecnologias de mercado utilizadas neste tra-balho. Neste capítulo contém conceitos que foram julgados necessários um detalhamento.As demais ferramentas necessárias para o desenvolvimento do trabalho são citadas nocapítulo 6, porém sem aprofundado detalhamento por se tratarem de ferramentas ampla-mente utilizadas e consolidadas no mercado;

• No capítulo 6 são apresentadas as funcionalidades e arquitetura do sistema proposta edesenvolvida neste trabalho. Assim como as tecnologias, hardware, algoritmos, cenáriose métodos experimentais utilizados para o desenvolvimento deste trabalho;

• No capítulo 7 são apresentados os resultados obtidos neste trabalho, assim como discus-sões relevantes;

• Por fim, o capítulo 8 contém a conclusão do trabalho e um levantamento de trabalhosfuturos.

Capítulo 2

Internet das Coisas

Neste capítulo é apresentada a fundamentação teórica de Internet das Coisas. Primeira-mente são identificados os desafios e o potencial comercial de aplicações IoT. Em seguida sãoapresentadas arquitetura de desenvolvimento e algumas tecnologias envolvidas e necessáriaspara o desenvolvimento de aplicações IoT.

2.1 Considerações Iniciais

O número de dispositivos conectados de algum modo, enviando informações e se co-municando, está aumentando cada vez mais. Atualmente existem diversos dispositivos com“inteligência” embutida, entre eles eletrodomésticos, relógios e principalmente os celulares. Oaumento significativo desses dispositivos criou a IoT. Esse cenário vem possibilitando diversasaplicações inovadoras, como por exemplo, a transformação de casas em ambientes inteligentes,sendo possível monitorar umidade, temperatura, fechaduras, interruptores, etc., tudo isso deforma remota e simples para o usuário. Outra aplicação importante é na saúde, pois utilizandoIoT é viável reduzir custos de hospitais, fornecer um atendimento de emergência mais eficaz,além de trazer mais conforto para pacientes, permitindo que os mesmos fiquem em suas resi-dências. Tudo isso é possível fazendo uso de sensores e dispositivos capazes de compartilharinformações através da Internet.

2.2 Desafios

Muitos desafios estão presentes no desenvolvimento de uma aplicação IoT. Dentre elesdestacam-se (Al-Fuqaha et al., 2015):

• A enorme quantidade de dispositivos conectados na Internet. Segundo van der Meulen(2015), estima-se que em 2020 o número de dispositivos conectados à internet passe de

7

8

20 bilhões. Esse número torna necessário um espaço grande de endereçamento, como porexemplo, o IPv6.

• Segurança e privacidade são outros requisitos importantes, pois esses dispositivos coletame enviam para a Internet informações privadas, como por exemplo informações médicas.Outro problema é que muitas vezes, além de apenas coletar informações, essas aplicaçõesatuam sobre dispositivos físicos, como por exemplo, um sistema capaz de abrir janelas re-sidenciais remotamente. Nesses casos, é ainda mais crucial um cuidado com a segurança,a fim de não permitir invasores.

• Deve-se garantir o envio de dados com alta qualidade e de maneira eficiente. Aplicaçõesde gestão e monitoramento, por exemplo, exigem informações confiáveis e em tempohábil.

• A maioria das aplicações IoT enviam os dados para usuários móveis, sendo necessário ga-rantir que o usuário receba a informação desejada mesmo quando estiver em movimento.

• Garantir a performance é um grande desafio pelo fato de que depende do desempenho dediversas tecnologias, sendo necessário avaliar velocidade de processamento, comunica-ção, tipo de dispositivo, entre outras métricas.

• A grande quantidade de dispositivos interfere também na capacidade de gestão dos mes-mos. Deve-se garantir uma forma facilitada de instalá-los, configurá-los, manipulá-los eapagá-los.

• Deve ser possível adicionar novos dispositivos, serviços e funcionalidades sem afetar oque já existe. Essa pode vir a ser uma tarefa complicada, já que aplicações nessa áreaenvolvem a utilização de hardwares e protocolos de comunicação diversificados.

• Normalmente os dispositivos utilizados em IoT são de capacidades limitadas, princi-palmente pelo fato de serem fisicamente pequenos e possuírem energia limitada (Houet al., 2016).

Dependendo da aplicação, alguns desses desafios se destacam. Por exemplo, uma apli-cação onde a visualização dos dados em tempo real é de extrema importância, então a dispo-nibilidade e confiabilidade terão que ser tratadas com cuidado. Segundo Hou et al. (2016) nasaplicações voltadas para cuidados médicos, a quantidade de usuários é considerada pequena, osdispositivos possuem um baixo consumo de energia e alto custo de manutenção. Além disso,nessas aplicações, a confiabilidade, segurança e privacidade são muito importantes.

9

2.3 Potencial Comercial

Mesmo diante de tantos desafios, aplicações em IoT estão em alta, sendo uma área demuito interesse e com grande chances de crescimento. A Gartner Inc. realizou uma análise,em 2015, sobre o impacto de IoT para as empresas. Foram analisados dois aspectos: númerode dispositivos conectados à internet instalados e o quanto foi/será gasto com essa tecnologia.Estima-se que em 2020 o número de dispositivos conectados à internet passará de 20 milhões(van der Meulen, 2015). Além disso, estima-se que será gasto mais de 3 bilhões de dólares comesta tecnologia em 2020.

Segundo Manyika et al. (2013), estima-se um investimento em Internet das Coisas entreU$2,7 e U$6,2 trilhões por ano até 2025. Das aplicações analisadas, as mais relevantes são asligadas à saúde e a manufatura. As aplicações relacionadas à saúde podem vir a ter um impactoeconômico de U$1,1 a U$2,5 trilhões por ano até 2025. O gráfico circular 2.1 apresenta os dadoslevantados pela McKinsey Global Institute. Pode-se analisar que as aplicações relacionadas àassistência médica representam cerca de 40% do valor total investido em IoT.

Figura 2.1: Investimento em aplicações de IoT por ano até 2025 (em trilhões).

Diante dos dados estatísticos levantados, percebe-se grande interesse no desenvolvimentode aplicações IoT na área da saúde. Nas sessões a seguir serão apresentadas arquiteturas, ele-mentos e tecnologias que viabilizam o desenvolvimento dessas aplicações.

10

2.4 Arquitetura IoT

Pelo fato da necessidade de lidar com uma grande quantidade de dispositivos e, alémdisso, os mesmos serem heterogêneos, a arquitetura é uma questão muito importante quandoo assunto é IoT. Segundo Al-Fuqaha et al. (2015), existem diversas arquiteturas propostas, po-rém a literatura ainda não convergiu para uma arquitetura de referência. Dentre os modelospropostos, existe a arquitetura dividida em 5 camadas (Khan et al., 2012):

1. Camada de objetos: Nessa camada estão os objetos físicos e os sensores responsáveispor coletar informações específicas desses objetos, como por exemplo umidade, tempe-ratura, frequência cardíaca, movimento, etc. Essa camada digitaliza e disponibiliza asinformações para a camada de rede.

2. Camada de rede: Essa camada é responsável por transmitir as informações obtidas dacamada de objetos, de forma segura, para a camada de gerenciamento de serviços. Atransmissão pode ocorrer por meio de cabos ou sem fio, algumas tecnologias presentesnessa camada são 3G, Radio-Frequency IDentification (RFID), Wi-Fi, Bluetooth, ZigBee,Universal Mobile Telecommunication System (UMTS), infravermelho, etc.

3. Camada de gerenciamento de serviços: Uma aplicação IoT utiliza dispositivos heterogê-neos, onde cada um implementa um tipo de serviço. Cada dispositivo se comunica apenascom dispositivos que implementam o mesmo tipo de serviço. Portanto, essa camada é res-ponsável por gerenciar a comunicação entre esses dispositivos. Ela também tem acessoao banco de dados, onde são armazenadas as informações recebidas da camada de rede.Além disso, essa camada processa as informações recebidas e toma decisões automáticasbaseadas nos resultados.

4. Camada de aplicação: Fornece um gerenciamento global da aplicação com base nas infor-mações processadas na camada de gerenciamento de serviços. Essa camada deve forneceros serviços solicitados pelo usuário, como por exemplo frequência cardíaca e pressão arte-rial (Al-Fuqaha et al., 2015). Alguns exemplos de aplicações de IoT são saúde inteligente,casa inteligente, cidade inteligente, transporte inteligente, etc.

5. Camada de negócio: Essa camada gerencia todo o sistema IoT, incluindo as aplicações eos serviços. Aqui são gerados gráficos, modelos de negócio, etc. baseados nas informa-ções recebidas da camada de aplicação. Através dos resultados gerados nessa camada, épossível determinar ações futuras e estratégias de negócio.

11

2.5 Elementos IoT

Diversas tecnologias estão envolvidas no desenvolvimento de IoT. Essas tecnologias sãocombinadas a fim de se complementarem e viabilizar a integração dos objetos do mundo físicono mundo virtual (Santos et al., 2016). Segundo Al-Fuqaha et al. (2015), são necessários 6elementos para criar aplicações IoT: identificação, sensores/atuadores, comunicação, processa-mento, serviços e semântica.

2.5.1 Identificação

Os métodos de identificação são utilizados para fornecer uma identidade clara e única paracada objeto dentro da rede. Existem formas de nomear objetos, como por exemplo, o Electro-nic Product Code (EPC), e existem métodos para endereçá-los dentro da rede de comunicação(Al-Fuqaha et al., 2015). Para endereçamento, existem o IPv6 e IPv4, sendo o 6LoWPAN ummecanismo mais indicado para redes sem fio com pouca energia, pois comprime os cabeça-lhos do IPv6 (Al-Fuqaha et al., 2015). É importante salientar a diferença entre fornecer um IDpara um objeto e endereçá-lo, pois o primeiro não se trata de uma identificação global, comopor exemplo, chamar de “ECG1” um determinado eletrocardiograma. Já os métodos de en-dereçamento atribuem uma forma de identificação única e global para os objetos (Al-Fuqahaet al., 2015).

2.5.2 Sensores/Atuadores

São os elementos da IoT responsáveis por interagir com os objetos dentro da rede. Ossensores IoT podem ser sensores inteligentes ou sensores vestíveis (Al-Fuqaha et al., 2015).Os atuadores são capazes de realizar alguma ação em campo, como por exemplo, uma tomadainteligente com um atuador permite ser desligada remotamente.

Tipicamente, em produtos IoT utilizam-se Single Board Computers (SBC) integrados comos sensores juntamente com funcionalidades TCP/IP e de segurança (Al-Fuqaha et al., 2015).Alguns exemplos de SBC são Raspberry PI, BeagleBone Green, UDOO Neo, entre outros.

2.5.3 Comunicação

As tecnologias de comunicação IoT têm como finalidade conectar diversos objetos he-terogêneos a fim de fornecer serviços específicos (Al-Fuqaha et al., 2015). Normalmente osdispositivos IoT devem operar com baixa potência por meios de comunicação com ruídos eperdas (Al-Fuqaha et al., 2015). Alguns exemplos de protocolos de comunicação são Wi-Fi,Bluetooth, IEEE 802.15.4, Z-wave e LTE-Advanced.

12

2.5.4 Processamento de dados

As unidades de processamento (por exemplo, microcontroladores e microprocessadores),e aplicações de softwares, representam o “cérebro” e a capacidade computacional da IoT (Al-Fuqaha et al., 2015). Existem diversos hardwares no mercado que viabilizam o desenvolvi-mento de aplicações IoT, como por exemplo Arduino, UDOO, Intel Galileo, Raspberry PI,BeagleBone, entre outros.

Além disso, várias plataformas de software são utilizadas para fornecer funcionalidadesIoT. Dentre essas plataformas existem os Sistemas Operacionais (SOs), contendo os específi-cos para aplicações em tempo real como por exemplo, o Contiki RTOS, além dos SOs leves,projetados para o ambiente IoT, como o TinyOS, LiteOS e Riot OS (Al-Fuqaha et al., 2015).Por último, existem as plataformas na nuvem, que fornecem facilidades para os objetos envia-rem seus dados, possibilitam que um grande volume de dados seja processado em tempo real edisponibilizam o conhecimento extraído para os usuários finais (Al-Fuqaha et al., 2015).

2.5.5 Serviços

Segundo Al-Fuqaha et al. (2015), os serviços podem ser categorizados em quatro clas-ses: Serviços de Identificação, Serviços de Agregação de Dados, Serviços de Colaboração eInteligência e Serviços de Ubiquidade. Os serviços de identificação são muito importantes,pois todas as aplicações que trazem as informações do mundo real para o virtual precisam deuma forma de identificar unicamente cada objeto. Os serviços de agregação de dados coletame tratam medições sensoriais brutas que precisam ser processadas e enviadas para a aplicaçãoIoT. Serviços de colaboração e inteligência atuam sobre os serviços de agregação de dados.Esses serviços tomam decisões e reagem de acordo com os dados coletados. Os serviços deubiquidade disponibilizam serviços de colaboração e inteligência em qualquer momento queeles forem necessários, assim como para qualquer um e em qualquer lugar.

2.5.6 Semântica

Semântica, no contexto de IoT, se refere à habilidade de extrair conhecimento de diferen-tes dispositivos para fornecer os serviços solicitados (Al-Fuqaha et al., 2015). Tecnologias deWeb Semântica são utilizadas a fim de acrescentar significado aos dados, permitindo comunica-ção de máquina com máquina e interações entre objetos. Alguns exemplos dessas tecnologiassão Resource Description Framework (RDF) e Ontology Web Language (OWL) (Al-Fuqahaet al., 2015).

13

2.6 Padrões para IoT

Existem diversos padrões, ou protocolos, desenvolvidos a fim de facilitar e simplificar odesenvolvimento de aplicações IoT. Al-Fuqaha et al. (2015) classifica os protocolos em quatrocategorias: de aplicação, descoberta de serviços, de infraestrutura e outros protocolos influentes.Porém não é necessário ter todos esse protocolos em conjunto para desenvolver uma aplicaçãoIoT.

2.6.1 Protocolos de Aplicação

O protocolo HyperText Transfer Protocol (HTTP) é amplamente conhecido e utilizado emaplicações web para acessar informações na internet. Esse protocolo faz uso da estratégia re-quisição/resposta sobre o paradigma cliente/servidor (Santos et al., 2016). Apesar de ser muitoconhecido, o protocolo HTTP foi criado para redes compostas por computadores pessoais (PCsdo inglês Personal Computers). Os dispositivos utilizados em aplicações IoT não possuem omesmo poder computacional de um PC, sendo eles limitados com relação a processamento,memória e consumo de energia. Essas restrições tornam o protocolo HTTP inadequado paraaplicações IoT. Existem diversos protocolos que podem ser utilizados para resolver esse pro-blema, tendo como destaque o CoAP e MQTT, que serão descritos a seguir.

Constrained Application Protocol (CoAP)

O CoAP é definido e mantido pelo Internet Engineering Task Force (IETF) (CoAP, 2018).O CoAP funciona de forma similar ao HTTP e define um protocolo de transferência de da-dos baseado no REpresentational State Transfer (REST) (Santos et al., 2016). REST per-mite uma comunicação entre cliente e servidor utilizando Uniform Resource Identifiers (URIs)como substantivos e os métodos HTTP GET, POST, PUT e DELETE como verbos (Al-Fuqahaet al., 2015). Um diferencial do CoAP é o fato de utilizar, por padrão, o protocolo User Data-gram Protocol (UDP) e não o Transmission Control Protocol (TCP), tornando-o mais adequadopara aplicações IoT (Al-Fuqaha et al., 2015). Além disso, o CoAP altera algumas funcionali-dades do HTTP a fim de atender as necessidades de IoT, como o baixo consumo de energia e apresença de perdas e ruídos nos meios de comunicação (Al-Fuqaha et al., 2015).

O CoAP é dividido em duas subcamadas e assim permite que dispositivos com baixapotência e de pouco poder computacional e de comunicação possam interagir utilizando REST(Al-Fuqaha et al., 2015). A primeira é a subcamada de mensagem, sendo responsável por detec-tar mensagens duplicadas e fornecer comunicação confiável sobre a camada de transporte UDP.A segunda é a subcamada de requisição/resposta, que manipula as comunicações REST (Al-Fuqaha et al., 2015). O CoAP utiliza quatro tipos de mensagens: confirmable, non-confirmable,reset e acknowledgement.

14

Algumas funcionalidades importantes que o CoAP fornece são (Al-Fuqaha et al., 2015):

• Observações de recursos: monitorar alterações de recursos através do mecanismo de pu-blish/subscribe. Assim é possível se inscrever para receber novos dados sempre que elesforem publicados.

• Interação com HTTP: O fato dos dois utilizarem arquitetura REST facilita a interaçãoentre CoAP e HTTP.

• Segurança: o protocolo proposto para assegurar as transações CoAP é o Datagram Trans-port Layer Security (DTLS), o qual garante integridade e confidencialidade nas trocas demensagens (Karagiannis et al., 2015). DTLS roda em cima do UDP e é análogo ao Trans-port Layer Security (TLS) para TCP (Karagiannis et al., 2015). Porém, esse protocolo desegurança traz algumas desvantagens para o CoAP. Primeiramente, o DTLS não suportamulticast, sendo esta uma característica importante do CoAP e para IoT (Karagianniset al., 2015). Outra questão é o fato de requerer pacotes adicionais, que aumentam o trá-fego de rede, recursos computacionais e diminuem o tempo de vida dos dispositivos pelofato de consumir mais energia (Karagiannis et al., 2015).

Message Queue Telemetry Transport (MQTT)

O MQTT é um protocolo simples e leve de envio de mensagens do tipo publish/subscribe.É uma forma de comunicação ideal para aplicações onde minimizar a largura de banda e oconsumo de energia é de suma importância (MQTT, 2018).

Os clientes podem ser publishers e/ou subscribers. Quando atua como publisher, o clienteenvia dados para o broker em um tópico específico (Patel et al., 2015). Já o cliente que atuacomo subscriber se inscreve para receber os dados de um ou mais tópicos (Patel et al., 2015).

O principal componente do protocolo MQTT é o broker, responsável por concentrar edistribuir as informações publicadas. Quando houver uma nova publicação em algum tópico, obroker distribui a mesma para os clientes que se inscreveram nesse tópico (Patel et al., 2015). Afigura 2.2 apresenta a arquitetura do protocolo, onde o ECG, EMG e EEG publicam seus dadosnovos para um broker na fila “health”. Dois clientes se inscrevem previamente para receber osdados da fila “health”. O broker envia os novos dados para todos os clientes inscritos na fila.

Utilizando essa estrutura, é possível trocar um sensor, ou qualquer outro publisher, semafetar o funcionamento da solução como um todo. Os subscribers apenas receberão as men-sagens quando o novo equipamento estiver instalado e configurado como um publisher. Noinverso isso também ocorre, pois a adição de um novo subscriber é transparente para os de-mais clientes, bastando o broker ter conhecimento e iniciar o envio de publicações para estesubscriber (Hunkeler et al., 2008).

Segundo Hunkeler et al. (2008), o MQTT dá suporte a três níveis de qualidade de serviço.

15

Figura 2.2: Arquitetura do MQTT.

A escolha entre os níveis vai depender da aplicação. No nível 0 as mensagens são enviadasuma única vez para o destino, não sendo possível definir formas de retransmissão. No nível 1as mensagens são retransmitidas até garantir a entrega da mensagem. O ponto positivo do nível1 é que há a garantia de entrega, porém o destino pode receber duas vezes a mesma mensagempor causa da técnica de retransmissão. Já no nível 2 obtém-se a garantia de entrega, além deassegurar que a mensagem é recebida apenas uma vez. Para garantir a segurança, o broker deverequerer autenticação via usuário e senha. Além disso, a comunicação entre clientes e brokerdeve ser protegida utilizando os protocolos TLS ou Secure Socket Layer (SSL) (Karagianniset al., 2015).

Karagiannis et al. (2015) apresentam uma breve comparação entre MQTT e CoAP, ondeconclui que o fato de CoAP rodar em cima do UDP e não do TCP, o torna mais leve. Entretanto,como o UDP não possui mecanismos de retransmissão, a perda de pacotes é mais provável aoutilizar CoAP. Thangavel et al. (2014) comparou a performance do MQTT e do CoAP emtermos de atrasos em transmissão e uso de banda. Os resultados experimentais mostraram queas mensagens MQTT possuem menor atraso que as mensagens CoAP quando as taxas de perdade pacotes são baixas, porém, possuem maior atraso quando as taxas de perda são maiores.Além disso, os experimentos revelaram que no envio de mensagens pequenas e com taxa deperda igual ou inferior a 25%, o CoAP gera tráfego adicional menor que o MQTT. Isso ocorrepelo fato do MQTT garantir a confiabilidade da mensagem.

Advanced Message Queuing Protocol (AMQP)

O AMQT é um protocolo utilizado em ambientes orientados a mensagens (Al-Fuqahaet al., 2015). Nesse protocolo a comunicação é manipulada através de dois componentes prin-cipais: exchanges e queues. As exchanges distribuem as cópias das mensagens para as queuesapropriadas, onde podem ser armazenadas para então serem enviadas para os clientes. Nessemodelo, o AMQP também suporta a estratégia de comunicação publish/subscribe.

16

Cada protocolo pode ter um bom desempenho em cenários e ambientes específicos. Se oconsumo de bateria não for um problema, pode-se simplesmente implementar serviços RESTe interagir com a internet utilizando o tão conhecido HTTP (Karagiannis et al., 2015). Paracenários onde o consumo de energia deve ser baixo e o poder computacional é limitado, osprotocolos MQTT e CoAP se destacam (Karagiannis et al., 2015). Além disso, o MQTT sesobressai quando a aplicação requer atualização massiva de um mesmo valor (Karagiannis et al.,2015).

2.6.2 Tecnologias de comunicação

Nessa subseção serão descritas as principais tecnologias de comunicação utilizados emIoT (Santos et al., 2016).

Ethernet

O padrão Ethernet (IEEE 802.3) está presente nas redes cabeadas. É um padrão simples,de fácil manutenção e baixo custo. Atualmente existem dois tipos de cabos: par trançado, quepode atingir taxas de até 1 Gbps, limitados a 100 m; e fibra óptica que alcança taxas de 10 Gbps,limitado a 2000 m. Esse padrão é sugerido para dispositivos fixos, sem mobilidade. Por estarazão não é muito adequado para aplicações IoT.

Wi-Fi

O padrão Wi-Fi (IEEE 802.11) se trata de uma solução de comunicação sem fio, sendoesta amplamente conhecida e utilizada, estando presente nas residências, pontos turísticos, hos-pitais, espaços comerciais, etc. Esse padrão define um conjunto de padrões de transmissão ecodificação e permite uma taxa de comunicação de até 600 Mbps ou 1300 Mbps na versão IEEE802.11ac.

O Wi-Fi não possui preocupação com consumo de energia, por isso não é muito utilizadoem aplicações IoT. Porém, sua popularidade e alcance de conexão são suas grandes vantagense, por essas razões, existem hardwares que visam a aplicabilidade do Wi-Fi em IoT, como porexemplo o ESP8266.

ZigBee

O padrão ZigBee é baseado na especificação do protocolo IEEE 802.15.4 para a camadade enlace e é mantido pela ZigBee Alliance. Essa tecnologia pode alcançar uma taxa máximade 250 kbps, bem inferior ao padrão Wi-Fi. As principais características do ZigBee são a baixa

17

vazão e consumo de energia reduzido. Para maximizar o consumo de energia, o ZigBee permiteque os dispositivos entrem em modo sleep quando não estão em uso. A utilização do ZigBee emIoT depende de um gateway, a fim de permitir a comunicação entre os dispositivos que utilizamZigBee e os que não utilizam.

Bluetooth Low Energy (BLE)

O Bluetooth é atualmente mantido pela Bluetooth Special Interest Group. Trata-se de umaalternativa de tecnologia de comunicação sem fio utilizando transmissão de radiofrequênciapara envio de dados. Os dispositivos podem se comunicar de forma simples, bastando estarempróximos. O BLE, diferentemente das versões anteriores, foi desenvolvido se preocupandocom o baixo consumo de energia. Atualmente está na versão 5.0 e permite o envio de umvolume de dados em curtos espaços de tempo através de conexão de rádio de longo alcance(Bluetooth, 2016). Já as versões anteriores estabeleciam uma conexão sem fio de curto alcancee contínua, sendo muito interessante para transmissão de áudio, por exemplo (Bluetooth, 2016).

2.7 Considerações Finais

Neste capítulo foram apresentados os desafios, potencial comercial, arquitetura e tecno-logias envolvendo aplicações IoT.

O desenvolvimento de aplicações IoT possui diversos desafios, dentre os quais destacam-se a grande quantidade de dispositivos conectados, o baixo poder de processamento e energialimitada desses dispositivos e a segurança das informações.

Mesmo diante de grandes desafios, aplicações IoT estão em alta e estima-se um investi-mento de U$2,5 trilhões até 2025 em aplicações IoT voltadas a área da saúde.

Arquiteturas e tecnologias focadas em aplicações IoT ainda não estão consolidadas eexistem diversas opções. Neste capítulo foi apresentada uma arquitetura de 5 camadas e os6 elementos essenciais para a criação de aplicações IoT. Por fim, foram descritas diversas tec-nologias existentes para realizar a comunicação entre dispositivos e dispositivos, assim comoentre dispositivos e servidor.

Capítulo 3

Detecção de Quedas

Neste capítulo é feito um estudo bibliográfico sobre detecção de quedas de pessoas idosas,a fim de identificar sensores e algoritmos que possam ser utilizados neste trabalho.


Segundo Mubashir et al. (2013) queda é a maior causa de lesões fatais, especialmentepara pessoas idosas. Além disso, as consequências de uma queda são altamente dependentes dotempo de resposta e resgate (Mubashir et al., 2013). Segundo o Instituto Nacional de Traumato-logia e Ortopedia (2015) “de 30% a 60% da população com mais de 65 anos cai anualmente e,dessas quedas, de 40% a 60% levam a algum tipo de lesão”. O crescimento da população idosaincentiva o estudo e o desenvolvimento de sistemas para monitoramento da saúde, incluindoa detecção de quedas. A finalidade desses sistemas é de agilizar o atendimento médico e aomesmo tempo diminuir gastos.

As técnicas para detecção de quedas devem considerar diferentes cenários, podendo aqueda ser de diferentes origens: andando ou de pé, em cima de suportes (escadas, banquetas,etc.), dormindo ou deitado na cama e sentando na cadeira (Mubashir et al., 2013). Porém, outrasatividades também podem se confundir com quedas, como por exemplo, um rápido movimentopara baixo. Sendo assim, o grande desafio para as técnicas de detecção de quedas é ignorar osfalsos positivos.

Mubashir et al. (2013) categoriza essas técnicas em três diferentes classes: baseadas emdispositivos vestíveis, baseadas em sensores de ambiente e baseadas em câmeras. As técni-cas baseadas em dispositivos vestíveis podem utilizar sensores para detecção de postura ou demovimento. Os sensores de ambiente podem ser de detecção de presença ou de postura. E astécnicas baseadas em câmeras podem ser divididas em três classes: alteração de forma, inativi-dade e movimento 3D da cabeça.

Para esse trabalho houve o foco no estudo das técnicas baseadas em dispositivos vestí-

19

20

veis. Na literatura existem diversos estudos sobre o uso de acelerômetros para detectar quedas,analisando o uso de diferentes algoritmos e localizações dos sensores.

3.2 Algoritmos e Técnicas para Detecção de Queda

Nas sessões a seguir são apresentadas técnicas e algoritmos encontradas na literatura paradetectar quedas.

3.2.1 Classificação dos Movimentos Humanos

Karantonis et al. (2006) desenvolveu um algoritmo para classificação de movimentos hu-manos utilizando um acelerômetro triaxial localizado na cintura.

O sinal do acelerômetro é amostrado à uma taxa de 45 Hz, e, para classificar os movi-mentos, utiliza-se uma janela de 1 segundo de dados. Primeiramente aplica-se um filtro demediana com n = 3 para remover ruídos. Posteriormente são extraídos os componentes devidosà gravidade e movimento corporal. Para isso, aplica-se um filtro passa-baixa utilizando o filtroelíptico de resposta infinita ao impulso de terceira ordem, com frequência de corte (Fc) de 0,25Hz. A resposta do filtro passa-baixa sobre o sinal filtrado pela mediana é o componente devidoà gravidade (GA). Para obter o componente devido ao movimento corporal (BA), é necessáriosubtrair o sinal original do componente GA.

O componente BA é utilizado para distinguir atividade de repouso, pois nesse caso, nãoé necessário o efeito da gravidade. Já o componente GA provê informações sobre o ângulo deinclinação, possibilitando identificar a orientação postural da pessoa.

Para diferenciar atividade de repouso, calcula-se a área de magnitude do sinal normalizado(AMS), definido em 3.1. Onde x(t), y(t) e z(t) são os componentes BA dos eixos x, y e z. Ointervalo de tempo utilizado é 1 segundo.

AMS = 1/t(∫ t

0|x(t)|dt+

∫ t

0|y(t)|dt+

∫ t

0|z(t)|dt) (3.1)

Para calcular a orientação postural, utiliza-se apenas o componente GA para obter o ân-gulo de inclinação. Esse valor é calculado de acordo com o ângulo entre o eixo z positivo e ovetor gravitacional g, utilizando a relação 3.2.

Φ = arccos(z) (3.2)

Se essa relação for (Karantonis et al., 2006):

21

• Maior que 20o: a pessoa está em pé;

• Entre 20o e 60o: a pessoa está sentada;

• Entre 60o e 120o: a pessoa está deitada.

Por fim, para detectar a queda, calcula-se a magnitude do vetor do sinal (VMS) de acordocom a equação 3.3, onde xi, yi e zi são as amostras dos eixos x, y e z de índice i da componenteBA. Quando o limiar de 1, 8g for ultrapassado, caracteriza-se como uma possível queda.

VMS[i] =√

(x2i + y2i + z2i ) (3.3)

Karantonis et al. (2006) realizou três experimentos envolvendo a detecção de quedas, sãoeles:

• Inicialmente em pé, a pessoa cai de uma maneira não especificada. Foi então simuladauma recuperação realizando alguma atividade dentro dos próximos 60 segundos.

• Inicialmente em pé, a pessoa cai de uma maneira não especificada. Nenhuma atividade érealizada nos próximos 60 segundos.

• Inicialmente em pé, a pessoa cai enquanto está sentando em uma cadeira.

Nos dois primeiros a acurácia foi de 100%, tendo 15 quedas detectadas corretamente e 0incorretamente. No terceiro experimento a acurácia foi de 86,7%, tendo 13 quedas detectadascorretamente e 2 incorretamente.

3.2.2 Sistema para Detecção de Quedas

Wang et al. (2008) desenvolveu um sistema para detecção de quedas de pessoas idosasutilizando um acelerômetro triaxial localizado acima da orelha. A taxa de amostragem utilizadafoi de 200 Hz. O sensor é posicionado de tal forma que o eixo x aponta para frente, o eixo ypara a vertical e o eixo z para a lateral.

Quatro critérios para a detecção de quedas foram propostos, são eles:

1. Soma total da aceleração (Sa): calculado conforme a equação 3.3. Se a soma total daaceleração ultrapassar 6G (seis vezes a gravidade), identifica-se uma queda.

2. Soma da aceleração no plano horizontal (Sh): calculado conforme a equação 3.4, onde xie zi são as amostras dos eixos x e z de índice i. A fim de distinguir atividades comuns dodia-a-dia, utiliza-se um limiar de 2G.

Sh[i] =√

(x2i + z2i ) (3.4)

22

3. Tempo em que o corpo bateu no chão (Tic) e tempo em que o corpo iniciou o repouso(Trs): quando o valor de Sh ultrapassa o valor de 2G, então o tempo dessa amostra é oTic. Em seguida analisam-se as próximas amostras com relação ao valor Sa. Quandohouver 60 amostras seguidas com uma variação menor que 0,13 G então o último tempoé o Trs.

4. Velocidade máxima: a velocidade máxima é calculada de acordo com a equação 3.5, ondeTrs é o tempo em que o corpo esteve em repouso e Tic é o tempo exato em que o corpose encontrou com o chão. Esse último critério ajuda a diferenciar ainda mais atividadesdo dia-a-dia de uma queda real. O valor de limiar para esse critério é de 2 m/s.

Vmax =∫ T ic

Trs[Sa(t)− 1]dt|max (3.5)

Segundo os experimentos criados por Wang et al. (2008), a combinação dos critériosSa > 6G e Vmax > 2m/s obteve uma acurácia de 100%.

3.2.3 Determinação de Limiares Simples para Parâmetros Baseados emAcelerômetro

Kangas et al. (2007) avalia o desempenho de diferentes parâmetros para detecção de que-das utilizando os acelerômetros em lugares distintos: cabeça, cintura e pulso.

Os dados coletados foram amostrados a uma taxa de 50 Hz, e aplicou-se um filtro demediana com uma janela de 3 amostras a fim de remover ruídos. Em seguida utiliza-se umfiltro passa-baixa, ou passa-alta, (com frequência de corte de 0,25 Hz) com um filtro digital deButterworth de segunda ordem. O sinal filtrado pelo filtro passa-baixa é utilizado para análisede postura. O sinal filtrado pelo filtro passa-alta é utilizado para análise de movimento. Após aaplicação dos filtros, os seguintes parâmetros são extraídos:

1. Vetor de soma total da aceleração (V STOT ): calculado conforme a equação 3.3. O sinalutilizado nesse cálculo ainda não passou pelo filtro passa-baixa nem passa-alta.

2. Vetor de soma dinâmica (V SD): calculado utilizando a equação 3.3. Porém, o sinalutilizado é o resultado do filtro passa-alta.

3. Vetor de soma das diferenças entre máximos e mínimos (V Smaxmin): primeiramentecalcula-se a diferença entre os valores máximo e mínimo de cada eixo em um intervalode tempo de 0,6 segundos. Após obter os valores dos três eixos, utiliza-se a equação 3.3.

4. Aceleração vertical (Z2): calculada conforme a equação 3.6, onde G é a componentegravitacional com valor 1 g.

23

Z2 = (V S2TOT − V S2

D −G2)/2G (3.6)

Para o acelerômetro localizado na cintura, além dos parâmetros citados, avalia-se a pos-tura nos próximos 2 segundos. Para detectar a postura após o impacto, utiliza-se o sinal após ofiltro passa-baixa (Karantonis et al., 2006). Kangas et al. (2007) realizou experimentos a fim deencontrar valores ótimos para os limiares em cada parâmetro. Para cada posição do acelerôme-tro (cabeça, pulso e cintura) esses limiares são alterados.

Kangas et al. (2007) conclui que a cabeça e a cintura são locais relevantes para a detecçãode quedas utilizando acelerômetro, parâmetros simples e detecção de postura. Porém, o pulsonão se mostrou um local ideal nessas circunstâncias.

3.2.4 Avaliação de Algoritmos de Detecção de Quedas Baseados em Limi-ares Utilizando Acelerômetro

Bourke et al. (2007) utilizou dois acelerômetros, um localizado na coxa e outro no tronco.Para os experimentos, foram analisados 10 jovens entre 21 e 29 anos. Os indivíduos realizaram8 tipos de queda e repetiu cada uma 3 vezes. As quedas simuladas foram: quedas para frente,para trás, quedas para a direita e para à esquerda. Todas realizadas para os dois casos: com asduas pernas retas e com as pernas flexionadas.

Como não é viável simular quedas com idosos, foram analisados 10 idosos (entre 70 e 83anos) em suas atividades diárias. Cada atividade foi realizada 3 vezes em cada indivíduo. Asatividades foram:

1. Sentar e levantar de uma poltrona;

2. Sentar e levantar de uma cadeira de cozinha;

3. Sentar e levantar do assento da privada;

4. Sentar e levantar de um assento mais baixo;

5. Entrar e sair de um assento de carro;

6. Sentar e levantar da cama;

7. Deitar e levantar da cama;

8. Andar 10 metros.

24

Nesse experimento foi aplicado no sinal um filtro passa-baixa de Butterworth de segundaordem, com uma frequência de corte de 250 Hz. Após filtrar o sinal, utilizou-se a equação 3.3para calcular a aceleração total. Bourke et al. (2007) definiu limites superiores e inferiores paracada uma das localizações dos acelerômetros. Bourke et al. (2007) obteve uma especificidadede 100% utilizando o limite superior para o acelerômetro localizado na cintura. Concluindo,assim, que um algoritmo simples e um acelerômetro localizado na cintura já traz bons resultadospara a detecção de quedas.

3.3 Métodos para Avaliação de Algoritmos de Detecção deQueda

Percebe-se que na literatura cada autor criou seus próprios casos de teste, ficando difí-cil comparar os resultados. A fim de solucionar esse problema, Noury et al. (2007) apresentacenários e uma forma generalizada de avaliação dos algoritmos de detecção de quedas desen-volvidos. Segundo Noury et al. (2007) existem 4 casos possíveis:

• Verdadeiro positivo (VP): a queda ocorre e o dispositivo a detectou;

• Falso positivo (FP): o dispositivo acusa uma queda, mas ela, de fato, não ocorreu;

• Verdadeiro negativo (VN): uma atividade diária ocorre, e o dispositivo, de fato, não de-tecta uma queda;

• Falso negativo (FN): uma queda ocorre, mas o dispositivo não a detecta.

Para avaliar essas 4 situações, 2 critérios são propostos: sensibilidade (3.7) e especifici-dade (3.8). Sensibilidade é a capacidade de detectar a queda e especificidade é a capacidade dedetectar apenas quando de fato é uma queda.

Sensibilidade = V P/(V P + FN) (3.7)

Especificidade = V N/(V N + FP ) (3.8)

Os cenários de testes para a avaliação de um dispositivo de detecção de queda devemconsiderar tanto as quedas quanto as atividades diárias. O seguintes cenários de testes foramcriados por Noury et al. (2007):

• Queda para trás finalizando sentado: deve ser acusado uma queda

• Queda para trás finalizando deitado: deve ser acusado uma queda

25

• Queda para trás finalizando em posição lateral: deve ser acusado uma queda

• Queda para trás porém se recuperando: não deve ser acusado uma queda

• Queda para frente finalizando de joelhos: deve ser acusado uma queda

• Queda para frente se protegendo com os braços para frente: deve ser acusado uma queda

• Queda para frente finalizando deitado: deve ser acusado uma queda

• Queda para frente rotacionando e finalizando para o lado direito: deve ser acusado umaqueda

• Queda para frente rotacionando e finalizando para o lado esquerdo: deve ser acusado umaqueda

• Queda para frente porém se recuperando: não deve ser acusado uma queda

• Queda lateral para a direita finalizando deitado: deve ser acusado uma queda

• Queda lateral para a direita porém se recuperando: não deve ser acusado uma queda

• Queda lateral para a esquerda finalizando deitado: deve ser acusado uma queda

• Queda lateral para a esquerda porém se recuperando: não deve ser acusado uma queda

• Escorregar contra a parede e finalizar sentado: não deve ser acusado uma queda

• Sentar em uma cadeira e então levantar (considerar a altura da cadeira): não deve seracusado uma queda

• Deitar na cama e levantar-se: não deve ser acusado uma queda

• Andar poucos metros: não deve ser acusado uma queda

• Se abaixar, pegar algo no chão e então levantar-se: não deve ser acusado uma queda

• Tossir ou espirrar: não deve ser acusado uma queda

Segundo Noury et al. (2007) cada cenário pode ser realizado no máximo 3 vezes por cadapessoa. Existem 20 cenários, sendo assim, resultaria em 60 testes por pessoa. Uma quantidadede 10 pessoas já seriam 600 dados, o que já é suficiente para realizar análises estatísticas (Nouryet al., 2007). Deve-se levar em consideração uma boa distribuição com relação ao sexo daspessoas (feminino e masculino) e a idade. As quedas não podem ser simuladas com pessoasidosas, porém as atividades diárias sim.


Neste capítulo foram apresentados os algoritmos e técnicas existentes na literatura paradetectar quedas utilizando acelerômetros.

26

De acordo com os trabalhos estudados, verificou-se que a utilização de um acelerômetroposicionado na cintura ou na cabeça e o cálculo de parâmetros simples são suficientes para adetecção de queda.

O fato de cada trabalho realizar testes e experimentos diferentes, dificulta a comparaçãoentre algoritmos. A fim de resolver esse problema, Noury et al. (2007) apresenta métodos ecenários ideais para avaliar esses algoritmos.

Capítulo 4

Cálculo da Frequência Cardíaca

Neste capítulo é feito um estudo bibliográfico sobre o cálculo de frequência cardíacaatravés do eletrocardiograma. Primeiramente é descrito o funcionamento do coração, assimcomo técnicas para adquirir o eletrocardiograma. Posteriormente são apresentados algoritmospara detecção de QRS.


Segundo o Instituto Brasileiro de Geografia e Estatística (IBGE) “doenças cardiovascula-res são a principal causa de morte no Brasil” (IBGE, 2016a). Em 2013, 4,2% (6,1 milhões) depessoas com idade igual ou superior a 18 anos tiveram algum diagnóstico médico de alguma do-ença cardíaca (IBGE, 2016a). A análise do eletrocardiograma provê informações importantes erelevantes sobre o estado do coração, sendo possível, inclusive, diagnosticar doenças cardíacas(Álvarez et al., 2013).

4.2 Funcionamento do Coração e o Eletrocardiograma

O bombeamento de sangue realizado pelo coração é responsável por distribuir o sanguenecessário pelo corpo inteiro. Isso é feito através de pulsos de corrente elétrica que ocasionama contração dos músculos do coração. Ao passar pelo órgão, o sinal elétrico faz com quediferentes partes do coração respondem cada qual no seu tempo, dependendo das característicasdas fibras musculares e nervosas (Machado, 2016).

A capacidade do coração bater só é possível devido às características das células presentesno coração, sendo essas (Machado, 2016):

• Excitabilidade: capacidade de responder a um impulso elétrico;

• Contratibilidade: resposta de contração muscular para o estímulo elétrico;

27

28

• Condutibilidade: capacidade de conduzir o estímulo elétrico para uma célula adjacente;

• Automaticidade: capacidade de gerar estímulos elétricos automaticamente.

As células adjacentes se influenciam mutuamente gerando o processo de despolarizaçãoe repolarização onde ocorre a variação do potencial interno de positivo para negativo, e voltaao potencial positivo. Isso gera um pulso elétrico que se espalha pelo coração seguindo umcaminho, iniciando no nó sinusal ou sinoatrial (NSA), seguindo para os feixes internodais, nóatrioventricular (NAV) e por fim o sistema His-Purkinje (Machado, 2016). O sinal elétrico docoração passa pelos seguintes passos (Machado, 2016):

• O impulso elétrico surge no NSA e se propaga pelos feixes internodais. Isso desencadeiauma onda de despolarização que se propaga a partir dos átrios e é representada no ECGcomo a onda P;

• O NSA se conecta ao NAV através dos feixes internodais. O NAV atrasa o impulso paradar tempo suficiente para o enchimento ventricular;

• O impulso elétrico é conduzido para os ventrículos através do feixe de His que por suavez envia o sinal para os ventrículos esquerdo e direito;

• O sinal elétrico gerado que se propaga do NAV para o sistema de His-Purkinje é o respon-sável pela geração do complexo chamado QRS, normalmente utilizado para a determina-ção da frequência cardíaca. O QRS representa, graficamente, a chamada despolarizaçãoventricular que ocorre antes da contração dos ventrículos.

Para se obter o sinal cardíaco, existem maneiras invasivas e não invasivas, sendo quenesta última, utilizam-se eletrodos na superfície do corpo em posições padronizadas para obtero ECG que reflete a atividade elétrica do coração (Álvarez et al., 2013). Cada contração docoração produz um impulso elétrico que é coletado por eletrodos posicionados na pele (Álvarezet al., 2013). A batida do coração produz uma série de ondas cuja morfologia varia ao longodo tempo (Álvarez et al., 2013). Qualquer modificação na forma e/ou padrão do ECG constituiuma arritmia cardíaca, sendo estas indicativas de anomalias funcionais do coração (Schlindweinet al., 1987).

Uma das maneiras de capturar o sinal do ECG é através das 6 derivações periféricas quesão capturadas posicionando um eletrodo em cada braço e outro na perna (Dubin, 1976). Esseseletrodos formam um triângulo chamado de triângulo de Einthoven (Dubin, 1976). A figura 4.1ilustra essas derivações (DI, DII e DIII), sendo que cada par de eletrodos (um positivo e outronegativo) formam uma derivação (Dubin, 1976).

As outras 3 derivações periféricas são as aumentadas, ilustradas por aVD, aVE e aVPna figura 4.1 (Dubin, 1976). As derivações aumentadas utilizam um eletrodo como positivo eo restante como negativo (Dubin, 1976). Sendo assim, a derivação aVD utiliza o eletrodo do

29

braço direito como positivo e o restante como negativo, a aVE o braço esquerdo como positivoe a aVP o pé esquerdo como positivo (Dubin, 1976).

Cada derivação periférica registra um ângulo diferente, de modo que cada uma delas(DI, DII, DIII, aVD, aVE e aVP) representa uma visão diferente da mesma atividade cardíaca(Dubin, 1976).

Figura 4.1: Derivações periféricas.

4.3 Detecção de QRS

Na análise do ECG, a correta detecção dos batimentos cardíacos é de suma importância,pois através dos batimentos são extraídas informações para a análise, além disso, o cálculoda frequência cardíaca é feito com base nesses dados (Álvarez et al., 2013). A energia dosbatimentos cardíacos está localizada principalmente no complexo QRS, portanto, um detectorde QRS preciso é essencial (Álvarez et al., 2013). A detecção de QRS é difícil, porque amorfologia da batida varia ao longo do tempo além de existirem diferentes fontes de ruído(Álvarez et al., 2013). A maioria dos algoritmos de detecção do QRS possui duas etapas: pré-processamento e decisão (Álvarez et al., 2013). Na etapa de pré-processamento são aplicadasdiferentes técnicas a fim de atenuar as ondas P e T, bem como o ruído (Álvarez et al., 2013).Dentre essas técnicas, encontram-se filtragem linear ou não linear e suavização. Na etapa dedecisão são definidos os limites que serão aplicados a fim de determinar se trata-se de um QRS(Álvarez et al., 2013).

Segundo Álvarez et al. (2013) nos últimos 30 anos foram propostos vários algoritmospara detecção de QRS, dentre eles estão:

• N. Arzeno 2008 (Arzeno et al., 2008). Testado com a base de dados MIT-BIH (Moody& Mark, 2001). Sensitividade: 99,68%. Predição positiva: 99,63%.

30

• J. Martinez 2004 (Martíinez et al., 2004). Testado com as bases de dados MIT-BIH, QT(Physionet, 2018b), ST-T (Taddei et al., 1992) e CSE (Physionet, 2018a). Sensitividade:99,66%. Predição positiva: 99,56%.

• B. Abibullaev 2011 (Abibullaev & Seo, 2011). Testado com a base de dados MIT-BIH.Sensitividade: 97,2%. Predição positiva: 98,52%.

• J. Pan 1985 (Pan & Tompkins, 1985). Testado com a base de dados MIT-BIH. Sensitivi-dade: 99,3%.

• P. Hamilton 1986 (Hamilton & Tompkins, 1986). Testado com a base de dados MIT-BIH.Sensitividade: 99,69%. Predição positiva: 99,77%.

• A. Martinez 2010 (Martínez et al., 2010). Testado com as bases de dados MIT-BIH, QT,ST-T e TWA (Moody, 2008). Sensitividade: 99,81%. Predição positiva: 99,89%.

A fim de avaliar e comparar esses algoritmos, Álvarez et al. (2013) implementou 3 e testoucada um em uma mesma base de dados (MIT-BIH). Os algoritmos selecionados foram Pan &Tompkins (Pan & Tompkins, 1985), Hamilton & Tompkins (Hamilton & Tompkins, 1986) e umalgoritmo baseado na transformação fasorial (Martínez et al., 2010). De acordo com Álvarezet al. (2013) o algoritmo com melhor performance dentre eles é o de Pan & Tompkins comsensitividade de 99,79% e capacidade de predição positiva de 99,84%.

4.3.1 Algoritmo de Pan & Tompkins

Este algoritmo é baseado na análise digital da inclinação, amplitude e comprimento dosinal (Pan & Tompkins, 1985). Está dividido em três etapas de processamento: filtro lineardigital, transformação não linear e regras de decisão (Pan & Tompkins, 1985).

Após aplicar os filtros no sinal, o passo seguinte é o algoritmo de decisão responsável pordetectar o complexo QRS. Pan & Tompkins utiliza dois grupos de limites, um deles é aplicadono sinal derivado e o outro é aplicado no sinal que sofreu a integração por janela deslizante.Com isso melhora-se a confiabilidade da detecção pelo fato de utilizar duas formas de onda.Esses limites são alterados conforme o ruído e picos detectados pelo algoritmo. Essa abordagemreduz o número de falsos positivos causados por tipos de ruído que imitam as características docomplexo QRS.

O algoritmo utiliza uma técnica de limites duplos, a fim de detectar batidas do coraçãoperdidas e reduzir falsos positivos. Para isso existem dois níveis de limites (em cada grupo),um é metade do outro. Se não for encontrado um complexo QRS no intervalo de tempo cor-respondente a 166% do intervalo R-R médio atual, o pico máximo detectado é considerado umpossível complexo QRS, e o menor dos dois limites é aplicado.

Ao detectar um complexo QRS, deve-se aguardar 200 ms para detectar o próximo. Comonão é possível que um segundo QRS ocorra em menos tempo, isso previne um falso positivo.

31

Os limites aplicados nos dois sinais: após a integração e após a diferenciação são:

SPICOA = 0, 125 ∗ PICO + 0, 875 ∗ SPICO (Se PICO é o pico do sinal) (4.1)

SPICOB = 0, 25 ∗ PICO + 0, 75 ∗ SPICO (Se PICO é o pico do sinal) (4.2)

RPICO = 0, 125 ∗ PICO + 0, 875 ∗RPICO (Se PICO é o pico do ruído) (4.3)

LIMITEA = RPICO + 0, 25 ∗ (SPICO −RPICO) (4.4)

LIMITEB = 0, 5 ∗ LIMITEA (4.5)

Onde, PICO é o valor do pico que está sendo avaliado, SPICO é um pico que já foi de-finido como um QRS,RPICO é qualquer pico que não foi categorizado como QRS. Um pico édefinido como SPICO se ultrapassar o LIMITEA se for a primeira análise ou o LIMITEB

se uma pesquisa foi necessária para encontrar um QRS faltante. O valor de SPICO pode serdefinido através das equações 4.1 se o limite ultrapassado for 4.4 e 4.2 se o limite ultrapassadofor 4.5.

Quando se trata de batidas de coração irregulares, os limites são reduzidos pela metade afim de aumentar a sensibilidade e evitar perder batidas.

Para ser detectado como um complexo QRS, o pico deve ser reconhecido como um com-plexo nas duas formas de onda.

O algoritmo armazena duas médias de intervalo R-R, a primeira é a média dos últimos8 intervalos R-R conforme equação 4.6, onde RRn é o intervalo mais recente. A segunda é amédia dos 8 intervalos R-R que se mantiveram dentro dos limites mínimo e máximo definidosnas equações 4.7 e 4.8, respectivamente, onde, RR_MEDIA2 é calculada conforme a equação4.6. A razão disso é fazer com que o algoritmo se adapte e altere ao identificar batidas decoração irregulares.

RR_MEDIA = 0.125 ∗ (RRn−7 +RRn−6 + ...+RRn) (4.6)

RR_LIMITE_MINIMO = 92% ∗RR_MEDIA2 (4.7)

RR_LIMITE_MAXIMO = 166% ∗RR_MEDIA2 (4.8)

Se nenhum complexo QRS é encontrado durante o intervalo de 166% ∗ RR_MEDIA2,então o maior pico entreRR_LIMITE_MINIMO eRR_LIMITE_MAXIMO é selecio-nado como possível candidato, passando a utilizar o limite definido na equação 4.5 na detecção.

Se cada um dos 8 intervalos R-R mais recentes forem iguais aos que ficaram dentro doslimites RR_LIMITE_MINIMO e RR_LIMITE_MAXIMO, então considera-se uma

32

batida de coração regular.

Por fim, se um intervalo R-R é menor que 360 ms, deve-se avaliar se o atual complexoQRS foi corretamente identificado ou se trata-se de uma onde T. Se a maior inclinação destecomplexo for maior ou igual à metade da maior inclinação do complexo QRS anterior, então adetecção está correta, caso contrário é identificado como uma onda T.

4.3.2 Algoritmo de HC Chen e SW Chen

Esse algoritmo é uma simplificação do algoritmo de Pan & Tompkins. Segundo os testesrealizados com a base de dados MIT-BIH, esse algoritmo possui uma capacidade de prediçãopositiva de 99,5% (Chen & Chen, 2003).

O algoritmo é formado por três etapas: um filtro passa alta linear, um filtro passa baixa nãolinear e a etapa de decisão. O objetivo do filtro passa alta é acentuar o complexo QRS e suprimiras ondas indesejadas de ECG, como as ondas P ou T. O filtro passa alta utilizado resultou naequação 4.9, onde y[n] é o ponto de saída, x[n] é o ponto de entrada e M é o tamanho o filtro,avaliado como ideal os valores 5 ou 7.

y[n] = x[n− M + 1

2]− 1

M

M−1∑m=0

x[n−m] (4.9)

O filtro passa baixa não linear é composto por uma elevação ao quadrado de cada pontoseguido de uma integração por janela deslizante. Esse filtro intensifica informações sobre ainclinação e o comprimento do complexo QRS. Empiricamente utiliza-se uma janela de 30amostras para uma taxa de amostragem de 200 amostras/s.

Por fim, na etapa de tomada de decisão utiliza-se um threshold adaptativo, conformeequação 4.10, onde PICO é o máximo local sendo analisado. O α é o “fator de esquecimento”,restrito à números fracionários positivos, ou seja, 0 ≤ α ≤ 1. γ é um fator de ponderação paradeterminar a contribuição do PICO para o ajuste do threshold. Empiricamente, γ pode assumiro valor de 0,15 ou 0,2. Se o máximo local ultrapassar o threshold, então o mesmo é categorizadocomo um complexo QRS e deve-se atualizar o valor do threshold.

threshold = α ∗ γ ∗ PICO + (1− α) ∗ threshold (4.10)

Chen & Chen (2003) alcançou uma capacidade de predição positiva de 99,5% utilizandoos seguintes parâmetros: M = 5, α = 0, 05 e γ = 0, 15.

33


Neste capítulo foi descrito o funcionamento do coração, técnicas para aquisição do sinaldo eletrocardiograma e algoritmos para detecção do QRS.

O algoritmo de Pan & Tompkins é um dos algoritmos com maior capacidade de prediçãopositiva existentes na literatura, 99,84% segundo o estudo de Álvarez et al. (2013). Porém,Chen & Chen (2003) desenvolveu uma versão simplificada deste algoritmo e alcançou umacapacidade de predição positiva de 99,5%.

Capítulo 5

Tecnologias

Neste capítulo são apresentadas as principais tecnologias presentes no mercado, e queforam utilizadas neste trabalho. Primeiramente é apresentada a ferramenta de criação de con-tainers a qual facilita a migração do ambiente de desenvolvimento para o ambiente de testes.Para disponibilizar o ambiente de testes, utilizou os serviços de Infraestrutura como Serviçoda DigitalOcean. Para realizar os testes de desempenho, utilizou-se a ferramenta JMeter. Porfim, com o intuito de proteger a API, utilizou-se o JSON Web Token (JWT) para autenticação eautorização.


As ferramentas apresentadas neste capítulo envolvem conceitos que foram julgados ne-cessários um detalhamento. As demais tecnologias envolvidas neste trabalho serão citadas nocapítulo 6, como por exemplo, frameworks para desenvolvimento de API e aplicações Javas-cripts. Porém, estas são ferramentas amplamente utilizadas e que não terão seu funcionamentodetalhado neste trabalho.

5.2 Docker

O Docker é um software open source, e trata-se de uma tecnologia de containerizaçãoque permite a criação e o uso de containers Linux como se fossem máquinas virtuais modulares(Redhat, 2018a). Um container Linux é um conjunto de processos que são isolados do resto dosistema, oferecendo maior flexibilidade, permitindo criar, implantar, copiar e migrá-los de umambiente para outro (Redhat, 2018a). A grande diferença entre virtualização e o uso de con-tainers é que na virtualização criam-se vários sistemas operacionais simultâneos em um únicosistema hospedeiro, e já os containers compartilham o mesmo Sistema Operacional e isolamapenas os processos referentes ao aplicativo em questão, ganhando mais leveza e otimizandorecursos (Redhat, 2018b).

35

36

O Docker, assim como todas as ferramentas de containers, fornece um modelo de implan-tação com base em imagem, onde estão presentes todos os arquivos necessários para a execuçãode um aplicativo, incluindo suas dependências (Redhat, 2018a). O modelo de imagem torna ocontainer portátil e o mesmo se mantém durante a etapa de desenvolvimento, teste e produ-ção (Redhat, 2018b). Além disso, as imagens podem ser versionadas, facilitando o controle deversão da aplicação.

Segundo Redhat (2018a), as vantagens dos containers Docker são:

• Modularidade: torna possível desativar uma parte do aplicativo sem interrompê-lo comoum todo. Isso é muito interessante e essencial para uma arquitetura baseada em micros-serviços. Além disso, é possível compartilhar serviços entre várias aplicações.

• Camadas e controle de versão de imagens: cada imagem Docker é composta por diversascamadas. Cria-se um nova camada sempre que há alterações na imagem. O Docker fazuso desse técnica para agilizar a criação de containers, além de melhorar a velocidade,tamanho e a eficiência destes. Sempre que é realizada uma nova alteração, é gerado umregistro de alteração, o que fornece controle de versão sobre as imagens do container.

• Reversão: o fato de serem criadas camadas para cada alteração, facilita a reversão quandodesejado.

• Implantação rápida: os containers podem ser facilmente migrados, facilitando e agili-zando a implantação.

Uma ferramenta muito interessante de se utilizar junto ao Docker é o Docker Compose1,sendo esta uma ferramenta para definir e rodar aplicações com múltiplos containers Docker.Com o Compose, basta configurar um arquivo YAML com todos os serviços da aplicação paracriar e iniciar todos eles com um único comando.

5.3 DigitalOcean

DigitalOcean2 é uma empresa que fornece diversas soluções, que visam simplificar acomputação em nuvem. Dentre estas, destaca-se o recurso de Infraestrutura como Serviço (IaaSdo inglês Infrastructure as a Service). IaaS é a entrega de hardware (servidor, armazenamentoe rede) e software associado (tecnologia de virtualização de sistemas operacionais e sistema dearquivos), como um serviço (Bhardwaj et al., 2010). Um provedor de IaaS fornece recursos sobdemanda, ou seja, paga-se apenas pelo recurso realmente necessário para a sua aplicação e esserecurso pode ser facilmente escalado quando desejado.

1<https://docs.docker.com/compose/overview/>2<https://www.digitalocean.com/>

37

A DigitalOcean fornece as Droplets (máquinas virtuais), sendo possível selecionar qual-quer uma das seguintes distribuições: Ubuntu, FreeBSB, Fedora, Debian, CentOS. As quanti-dades de memórias, CPUs e tamanho de disco são selecionadas de acordo com a necessidade.

5.4 Apache JMeter

Os testes em sistemas são essenciais para garantir a qualidade dos mesmos, contribuindopara identificar erros e pontos de melhorias. Dentre os diversos testes que podem ser realizadosem um sistema, encontra-se o teste de desempenho. Este teste é responsável por determinara capacidade de resposta, confiabilidade, taxa de transferência, interoperabilidade e escalabi-lidade considerando uma determinada carga de trabalho. Além disso, é uma ferramenta deidentificação de gargalos e pontos únicos de falha na aplicação (Erinle, 2013).

Os testes de desempenho são essenciais para estimar os recursos da aplicação antes mesmoda publicação. Também ajudam a identificar problemas com antecedência e auxiliam em toma-das de decisões importantes e estratégicas (Erinle, 2013).

O teste de desempenho normalmente é composto por um conjunto de testes automatiza-dos, pois através destes, é possível simular e repetir diversas condições de carga, podendo sernormal, de pico ou excepcionais (Erinle, 2013). Muitas vezes, os testes de desempenho são rea-lizados em um ambiente controlado e em conjunto com o teste de estresse. O teste de estresse éutilizado para determinar a capacidade da aplicação de manter um certo nível de eficácia quandoestá sob condições desfavoráveis (Erinle, 2013).

Segundo Erinle (2013), as seguintes atividades são necessárias na realização de testes dedesempenho:

• Identificar o ambiente de teste: é necessário familiarizar-se com os ambientes de testefísico e em produção. Deve-se conhecer o hardware, o software e as configurações derede.

• Identificar os critérios de aceitação: deve-se identificar qual é o desempenho aceitávelquando a aplicação estiver sob uma determinada carga. É necessário mensurar as restri-ções de tempo, taxa de transferência e utilização de recursos, sendo estes os aspectos-chave do teste de desempenho.

• Planejar e projetar testes: sempre que houver, deve-se conhecer o padrão de uso daaplicação para criar cenários de uso realistas.

• Preparar o ambiente de teste: deve-se configurar o ambiente de teste, as ferramentase recursos necessários para conduzir os cenários planejados. O ambiente de teste é uminstrumento para monitorar os recursos e auxiliar na análise dos resultados.

38

• Registrar o plano de teste: os cenários de testes planejados devem ser registrados atravésde uma ferramenta. Existem diversas ferramentas disponíveis para esse propósito, dentreelas destaca-se o JMeter, sendo esta uma ferramenta livre e com uma grande base deusuários.

• Executar os testes: primeiramente deve-se executar os planos de testes sob uma cargaleve a fim de verificar a exatidão dos scripts de teste e dos resultados de saída.

• Analisar os resultados, criar o relatório e executar o reteste: nessa etapa deve-se ana-lisar os resultados e identificar pontos de melhorias. As melhorias podem estar relaciona-das ao sistema, banco de dados ou aplicação. Melhorias no sistema estão relacionadas àsalterações de infraestrutura, como por exemplo aumentar a memória disponível. Melho-rias no banco de dados podem levar à análise das operações de entrada e saída, introduçãode índices adicionais, entre outras ações que visam otimizar o uso do banco de dados. Asalterações relacionadas ao aplicativo podem implicar em refatoração a fim de reduzir oconsumo de memória e o acesso ao disco rígido, por exemplo. Após finalizar a primeiraanálise, onde foram identificados e resolvidos os gargalos do sistema como um todo, ostestes devem ser executados novamente e comparados com as execuções anteriores. Éindicado que as alterações sejam feitas uma de cada vez, a fim de verificar se a alteraçãoteve efeito positivo ou negativo nos resultados.

O Apache JMeter3 é uma ferramenta para planejamento e execução de testes de desem-penho. Trata-se e uma aplicação desktop open source que existe desde 1998 tornando-a umaferramenta madura, robusta e confiável (Erinle, 2013). Erinle (2013) lista algumas das princi-pais funcionalidades do JMeter:

• Possibilidade de testar a performance de diferentes servidores, incluindo web (HTTP eHTTPS), SOAP, banco de dados, LDAP, entre outros.

• Portabilidade para diversos sistemas operacionais.

• Estrutura multithreading que permite amostragem simultânea através de várias threads.

• Interface gráfica do usuário.

• Servidor de gravação de proxy HTTP.

• Cache e análise offline/repetição dos resultados.

• Exibição em tempo real dos resultados enquanto os testes estão sendo executados.

Com o JMeter é possível simular o acesso simultâneo de vários usuários (Erinle, 2013),permitindo verificar a quantidade limite de usuários simultâneos, identificar pontos de melho-rias, gargalos, etc (Erinle, 2013). Entretanto, o número de usuários simulados é limitado àespecificação da máquina em que está executando os testes (Erinle, 2013).

3<https://jmeter.apache.org/>

39

5.5 JSON Web Token

O padrão JSON Web Token (JWT) define uma forma segura de transmitir mensagens,utilizando um token no formato de um objeto JSON (JWT, 2018). O JWT é compacto porquealém de leve, pode ser enviado através da URL, como parâmetro no corpo de uma requisiçãoPOST ou no cabeçalho da requisição HTTP (JWT, 2018). Além disso, o JWT é self-contained,ou seja, possui toda informação necessária para autenticar um usuário, excluindo a necessidadede fazer mais que uma única consulta na base de dados (JWT, 2018).

O JWT é estruturado por três partes separadas por ponto: cabeçalho, corpo e assinatura(JWT, 2018). O cabeçalho é formado pelo algoritmo de hash utilizado, como por exemplo,HMAC SHA256 ou RSA e o tipo do token, que é JWT (JWT, 2018). Sendo assim, gera-se um JSON equivalente ao exemplo abaixo que posteriormente é codificado em Base64Url(JWT, 2018).

1 {2 " a l g " : " HS256 " ,3 " t y p " : "JWT"4 }

No corpo do JWT estão algumas informações sobre o usuário, além de outros dadosimportantes, como tempo de expiração. O corpo também é um JSON, que posteriormente écodificado em Base64Url (JWT, 2018).

Por fim, a assinatura garante que a mensagem não foi alterada no caminho e verifica seo remetente do JWT é quem diz ser (JWT, 2018). Para criar a assinatura utiliza-se o algoritmode hash, definido no cabeçalho passando o cabeçalho e corpo previamente codificados e umsegredo “s”, como por exemplo (JWT, 2018):

HMACSHA256( base64Ur lEncode ( c a b e c a l h o ) + " . " + base64Ur lEncode ( co rpo ) , s )


As tecnologias apresentadas neste capítulo facilitaram e agilizaram desde a etapa de de-senvolvimento até a etapa de testes e validações.

Capítulo 6

Materiais e Métodos

Neste capítulo são apresentadas as funcionalidades do sistema, a arquitetura do sistema,assim como as tecnologias, hardware, algoritmos, cenários e métodos experimentais utilizadospara o desenvolvimento de cada componente da arquitetura proposta.


A solução desenvolvida é composta por hardware e software. O hardware abrange osESP8266 conectados aos sensores AD8232 (sensor para detecção do sinal do ECG) e GY-89(acelerômetro). A finalidade do hardware é obter as informações do paciente, pré-processar osdados, detectar alertas e enviá-los para o servidor, utilizando os protocolos Wi-Fi e MQTT.

O software abrange, principalmente, as aplicações clientes web (AngularJS) e móvel (Io-nic), a API (SpringBoot), o banco de dados (PostgreSQL) e o MQTT broker. Porém, em umambiente de produção, se faz necessária a utilização de um proxy. A aplicação web, em con-junto com a API, realiza a configuração inicial dos sensores, para então receber os alertas edisponibilizá-los para visualização. A aplicação móvel, também em conjunto com a API, apre-senta os alertas da pessoa autenticada e da pessoa pela qual é responsável, além de recebernotificação quando um novo alerta ocorrer, sendo que, para acessar os recursos disponibiliza-dos pela API, é necessário passar pelo processo de autenticação.

6.2 Funcionalidades do Sistema

O diagrama de casos de uso ilustrado na figura 6.1 apresenta as funcionalidades do sistemadesenvolvido neste trabalho. O administrador do sistema tem acesso as seguintes funcionalida-des:

• Manter usuários: cadastrar, editar, remover e buscar usuários. Todos os pacientes assim

41

42

Figura 6.1: Diagrama de casos de uso do sistema.

como os responsáveis pelos pacientes devem ser cadastrados como usuários.

• Associar um responsável: após cadastrar o paciente e o responsável, o administrador dosistema pode realizar a associação entre os dois.

• Manter dispositivos: cadastrar, editar, remover e buscar dispositivos. Cada paciente temum ou mais dispositivos, sendo estes os responsáveis por enviar alertas para o sistema.

• Associar o usuário ao dispositivo: após cadastrar o dispositivo no sistema, o administradorpode associar o paciente ao dispositivo. Essa configuração é necessária pois o dispositivoapenas envia alertas e não existe nenhuma identificação do usuário no alerta.

• Reconhecer alertas: após resolver o alerta, o administrador pode reconhecer este alerta.Ao reconhecer um alerta, o mesmo não estará mais disponível para visualização.

• Visualizar alertas: o administrador do sistema pode visualizar todos os alertas ocorridos,de todos os pacientes.

O usuário comum (pacientes e responsáveis) tem acesso as seguintes funcionalidades:

43

• Visualizar alertas: o usuário comum pode visualizar seus alertas assim como do pacientepelo qual é responsável. Esses alertas podem ser visualizados no sistema web ou naaplicação móvel. Sempre que um alerta novo é enviado pelo dispositivo, a API envia umanotificação para os smartphones do paciente e do responsável.

• Reconhecer alertas: após resolver o alerta, o usuário comum pode reconhecer este alerta.O usuário comum só pode reconhecer os alertas dele ou do paciente pelo qual é respon-sável.

O hardware, ou dispositivo, tem a finalidade de gerar alertas e enviá-los para o servidor.Para enviar alertas, o dispositivo deve realizar os passos definidos no diagrama de atividadesilustrado na figura 6.2. Cada hardware está associado à um paciente no sistema. Para inserir umnovo dispositivo é necessário realizar os passos definidos no diagrama de atividades ilustradona figura 6.3.

Figura 6.2: Passos necessários para enviar um novo alerta.

44

Figura 6.3: Passos necessários para inserir um novo dispositivo no sistema.

6.3 Arquitetura Proposta

A arquitetura da solução proposta é ilustrada na figura 6.4. A comunicação entre ossensores e a API se da pelo protocolo MQTT. Para isso, são necessários a criação de tópicos.

45

Através desses tópicos os sensores irão enviar dados e a API, previamente inscrita em cadatópico, irá receber os dados.

Os sensores se conectam à um ESP8266, que implementa o protocolo MQTT para se co-municar e enviar alertas para o broker. A API REST é responsável por se inscrever nos tópicosque virão os alertas, armazená-los e enviá-los como notificação para os dispositivos móveis.Além disso, a API REST fornece todas as rotinas para o gerenciamento das informações neces-sárias para o funcionamento da aplicação, como por exemplo, salvar, deletar, buscar e removerusuários, dispositivos e alertas. Por fim, os clientes (aplicação móvel e web) consomem osrecursos disponibilizados pela API REST através do protocolo de comunicação HTTP.

A aplicação web abrange as seguintes funcionalidades:

• Cadastrar, remover, editar e buscar usuários;

• Cadastrar, remover, editar e buscar dispositivos (ESP8266);

• Atrelar os dispositivos aos seus respectivos usuários;

• Atrelar um usuário a um cuidador;

• Visualizar e verificar alertas de todos os usuários cadastrados;

• Reconhecer um alerta após resolvido.

A aplicação móvel contempla as seguintes funcionalidades:

• O usuário deve poder visualizar seus próprios alertas;

• O usuário deve poder visualizar os alertas do usuário por quem é responsável;

• O usuário deve receber uma notificação quando um alerta sobre o usuário por quem éresponsável ocorre;

• O usuário deve poder reconhecer um alerta após resolvido.

A fim de facilitar o desenvolvimento e a implantação da aplicação, utilizou-se o Docker,descrito na seção 5.2.

Nas próximas seções os componentes de software e hardware da arquitetura serão de-talhados. Além dos componentes, são descritas as diversas tecnologias utilizadas na soluçãoproposta. Deste modo, são especificados como foram configurados os containers Docker, oMQTT broker, a autenticação na API e o proxy, além de explicar como são enviadas as notifi-cações para a aplicação móvel. Por fim, são detalhadas as conexões de hardwares realizadas eas configurações utilizadas nos mesmos.

46

Figura 6.4: Arquitetura proposta

6.4 Software

Nesta seção são discriminadas todas as tecnologias de softwares utilizadas neste trabalho.

6.4.1 Docker

O Docker, descrito na seção 5.2, foi utilizado para auxiliar e facilitar no momento de fazerupload da aplicação para o ambiente de produção. O arquivo “docker-compose.yaml”, geradonesse trabalho foi o apresentado no quadro 6.1.

1 v e r s i o n : ’2 ’2 s e r v i c e s :3 db :4 image : p o s t g r e s5 r e s t a r t : a lways6 p o r t s :7 − 5432:54328 e n v i r o n m e n t :9 − POSTGRES_PASSWORD= s e n h a _ p o s t g r e s

10 − POSTGRES_USER= u s u a r i o _ p o s t g r e s

47

11 − POSTGRES_DB=smch12 volumes :13 − / d a t a / smch / p o s t g r e s : / v a r / l i b / p o s t g r e s q l / d a t a14 mqt t :15 image : e c l i p s e−m o s q u i t t o16 r e s t a r t : a lways17 p o r t s :18 − 1883:188319 volumes :20 − ~ / smch / m o s q u i t t o . con f : / m o s q u i t t o / c o n f i g / m o s q u i t t o . con f21 web :22 image : smch−web23 r e s t a r t : a lways24

25 a p i :26 image : smch−a p i27 r e s t a r t : a lways28 l i n k s :29 − db30 − mqt t31 e n v i r o n m e n t :32 − APP_DB_HOST=db33 − APP_DB_USERNAME= u s u a r i o _ p o s t g r e s34 − APP_DB_PASSWORD= s e n h a _ p o s t g r e s35 − APP_ENV= p r o d u c t i o n36 − MQTT_HOST= mqt t37 proxy :38 image : smch−proxy39 r e s t a r t : a lways40 depends_on :41 − web42 − a p i43 p o r t s :44 − 80 :80

Quadro 6.1: Docker Compose.

O container “proxy” é responsável por redirecionar as chamadas vindas do browser, naporta 80, para o container “web”, assim como redirecionar as requisições feitas pelo container“web”, que iniciam com “/api” para o container “api” na porta 8080. Percebe-se, nas linhas28 a 30, que a API é dependente dos containers “mqtt” e “db”, onde no primeiro encontra-seo MQTT broker Mosquitto e no segundo o banco de dados relacional PostgreSQL, utilizadosnesse trabalho.

Para subir o container com o banco de dados utilizou-se a imagem “postgres”1 disponi-bilizada no repositório oficial do Docker. Algo importante a se notar neste container é a linha

1<https://hub.docker.com/_/postgres/>

48

12, onde definem-se os volumes. Os volumes no Docker são utilizados quando há a neces-sidade de salvar dados presentes no container, independente do que aconteça com o mesmo.Assim, funciona como um backup e faz isso mantendo uma cópia do que se deseja do containerna máquina hospedeira. Para subir o container com o MQTT broker Mosquitto utilizou-se aimagem “eclipse-mosquitto”2 disponibilizada no repositório oficial do Docker. Como foi ne-cessário alterar a configuração padrão do Mosquitto, adicionou-se um volume para o arquivode configuração (linha 20). O arquivo de configuração mosquitto.conf utilizado nesse trabalhoencontra-se no apêndice G.

Todas as outras imagens foram criadas neste trabalho e serão apresentadas nas sessões aseguir.

6.4.2 API

Uma Application Programming Interface (API) expõe um conjunto de dados e funções,que facilitam a comunicação entre diferentes programas (Massé, 2011). REST significa Repre-sentational State Transfer, sendo este um termo criado por Roy Fielding em sua dissertaçãopara descrever um estilo arquitetural da web (Fielding, 2000). Sendo assim, uma API REST éuma interface que disponibiliza serviços web respeitando o padrão REST (Massé, 2011). UmaAPI REST utiliza URIs para endereçar recursos. Uma URI possui o seguinte formato:

p r o t o c o l o _ c o m u n i c a c a o : / / e n d e r e c o _ s e r v i d o r : p o r t a / caminho / r e c u r s o ? p1 = 1 & . . .

Neste formato “protocolo_comunicacao” é o protocolo de comunicação utilizado, paraesse trabalho é o HTTP; o “endereco_servidor” é o endereço do servidor, podendo ser um Do-main Name System (DNS), como por exemplo “google.com”; a “porta” padrão utilizada peloprotocolo HTTP é a 80, não sendo necessário especificá-la. Após a porta deve-se identificaro caminho para o recurso, como por exemplo “/usuario/1”, que significa o usuário de identifi-cação 1. A partir da “?” são definidos os parâmetros necessários, como por exemplo “/usua-rios?genero=feminino”, que significa buscar todos os usuários filtrando por gênero feminino.

Dentro da API desenvolvida neste trabalho existe uma gama de tecnologias diferentes,as quais são necessárias para atender todas as funcionalidades desejadas. A principal delas éo Spring Boot 3, sendo este um projeto da Spring que visa facilitar a criação, configuração epublicação de APIs.

Para realizar as configurações necessárias, com relação ao protocolo MQTT, utilizou-seo cliente Eclipse Paho 4 com o qual é possível criar um consumer no Spring (Spring, 2018).Nesse trabalho a configuração foi feita no arquivo “MqttConfig.java” e o handler foi definidono arquivo “DataHandler.java” conforme apresentado do quadro 6.2.

2<https://hub.docker.com/_/eclipse-mosquitto/>3<https://projects.spring.io/spring-boot/>4<https://www.eclipse.org/paho/>

49

1 @Conf igu ra t i on2 p u b l i c c l a s s Mqt tConf ig {3 @Value ( " \ ${ app . mqt t . u r l } " )4 p r i v a t e S t r i n g mqt tHos t ;5

6 @Bean7 p u b l i c MessageChannel m q t t I n p u t C h a n n e l ( ) {8 r e t u r n new D i r e c t C h a n n e l ( ) ;9 }

10

11 @Bean12 p u b l i c MessageProducer inbound ( ) {13 Mqt tPahoMessageDr ivenChanne lAdap te r a d a p t e r =14 new Mqt tPahoMessageDr ivenChanne lAdap te r ( " smch−web " ,

m q t t C l i e n t F a c t o r y ( ) , " + /FALL" , " + /FREQUENCY" ) ;15 a d a p t e r . s e t C o m p l e t i o n T i m e o u t ( 5 0 0 0 ) ;16 a d a p t e r . s e t C o n v e r t e r ( new D e f a u l t P a h o M e s s a g e C o n v e r t e r ( ) ) ;17 a d a p t e r . s e t Qo s ( 2 ) ;18 a d a p t e r . s e t O u t p u t C h a n n e l ( m q t t I n p u t C h a n n e l ( ) ) ;19 r e t u r n a d a p t e r ;20 }21

22 @Bean23 p u b l i c M q t t P a h o C l i e n t F a c t o r y m q t t C l i e n t F a c t o r y ( ) {24 D e f a u l t M q t t P a h o C l i e n t F a c t o r y f a c t o r y = new

D e f a u l t M q t t P a h o C l i e n t F a c t o r y ( ) ;25 Mqt tConnec tOp t ions o p t i o n s = new Mqt tConnec tOp t ions ( ) ;26 o p t i o n s . s e t M a x I n f l i g h t ( 6 5 0 0 0 ) ;27 o p t i o n s . s e t S e r v e r U R I s ( new S t r i n g [ ] { mqt tHos t } ) ;28 o p t i o n s . s e t C l e a n S e s s i o n ( f a l s e ) ;29 f a c t o r y . s e t C o n n e c t i o n O p t i o n s ( o p t i o n s ) ;30 r e t u r n f a c t o r y ;31 }32

33 @Bean34 @Autowired35 @ S e r v i c e A c t i v a t o r ( i n p u t C h a n n e l = " m q t t I n p u t C h a n n e l " )36 p u b l i c MessageHandler h a n d l e r ( Da taHand le r d a t a H a n d l e r ) {37 r e t u r n d a t a H a n d l e r ;38 }39 }40

41 p u b l i c c l a s s Da taHand le r imp lemen t s MessageHandler {42

43 @Override44 p u b l i c vo id hand leMessage ( Message <?> message ) th row s M e s s a g i n g E x c e p t i o n

{45 / / Execu tado sempre que uma mensagem nova vem do b r o k e r

50

46 }47 }

Quadro 6.2: Configuração do MQTT no Spring.

Na linha 13 foram definidas as filas onde a aplicação se inscreveu. Na linha 17 aplica-sea qualidade de serviço de nível 2, ou seja, existe garantia de que a mensagem seja entregue eainda garanta que a entrega ocorra uma única vez. Porém, a qualidade de serviço utilizada pelopublisher prevalece sob a do consumer.

Nas linhas 26 e 28 estão duas configurações importantes quando utiliza-se qualidade deserviço maior que 0. A primeira define o número de mensagens que poderão ser armazenadasenquanto o cliente não termina de processá-las. A segunda define se o cliente e o servidordevem lembrar o estado do cliente em todas as reconexões.

Na linha 37 está definido o handler, ou seja, o que fazer quando chegar uma mensagemnova. Quando isso acontecer, a API deve fazer duas ações: salvar o alerta no banco de dadose enviar uma notificação para o smartphone do cuidador do paciente. A solução que permite oenvio de mensagens entre plataformas é o Firebase Cloud Messaging (FCM) 5, possibilitandoo envio de notificações para uma aplicação cliente, seja este Android, iOS, Javascript, C++ ouUnity. A descrição de como deve ser feita a configuração na aplicação cliente está descrita naseção 6.4.6.

Para enviar notificações utilizando FCM, primeiramente deve-se criar um projeto no Fi-rebase Console. Após criar o projeto, deve-se criar um aplicativo. Para este trabalho, criou-seum aplicativo Android.

Na etapa de criação do aplicativo Android, é necessário informar o nome do pacote e napróxima etapa já será disponibilizado o google-services.json para baixar e adicionar no projetoAndroid.

Ao finalizar a criação do aplicativo, é gerada uma chave do servidor. Essa chave é utilizadapara a API enviar a notificação. Para encaminhar mensagens do servidor para aplicativos clientepor meio do FCM, o servidor deve realizar uma requisição HTTP utilizando o método POSTpara a URI definida no quadro 6.3. Deste modo, a requisição utilizada neste trabalho foi aapresentada no quadro 6.4.

h t t p s : / / fcm . g o o g l e a p i s . com / fcm / send

Quadro 6.3: URI para requisição para o FCM.

1 POST / fcm / send HTTP / 1 . 12 Host : fcm . g o o g l e a p i s . com3 A u t h o r i z a t i o n : key= + c h a v e _ d o _ s e r v i d o r4 Conten t−Type : a p p l i c a t i o n / j s o n5 {

5<https://firebase.google.com/docs/cloud-messaging/?hl=pt-br>

51

6 " n o t i f i c a t i o n " : {7 " t i t l e " : " A l e r t a " ,8 " body " : " V e r i f i q u e se e s t a tudo bem com seu p a c i e n t e "9 } ,

10 " r e g i s t r a t i o n _ i d s " : [ " f c m _ t o k e n _ c u i d a d o r " ]11 }

Quadro 6.4: Requisição para o FCM.

Na linha 10, o “fcm_token_cuidador” é o token que cada usuário do sistema possui. Essetoken é enviado para a API sempre que o usuário se autentica no aplicativo mobile.

6.4.3 Autenticação

Para realizar a autenticação no sistema, utilizou-se o padrão JWT, descrito na seção 5.5.Para utilizar o JWT em uma aplicação Spring, deve-se adicionar as dependências do JWT eSpring Security no pom.xml. Neste trabalho utilizou-se a versão 0.7.0 do artefato “jjwt” e 1.5.3do “spring-boot-starter-security”.

A configuração da autenticação foi adicionada no arquivo Security.java e está apresentadano apêndice A. Todos as classes utilizadas na função iniciada na linha 48 foram criadas dentrodo pacote “unioeste.smch.auth”.

6.4.4 Aplicação Web

A aplicação web foi desenvolvida utilizando o framework JavaScript AngularJS6 na ver-são 1.5.3. AngularJS é uma ferramenta desenvolvida pela Google e sua primeira versão foilançada em 2012 (W3Schools, 2018). Com este framework é possível criar aplicações webdinâmicas utilizando JavaScript e a linguagem de marcação de hipertexto (HTML - do inglêsHyperText Markup Language) para a geração dos templates (AngularJS, 2018).

Além do AngularJS, utilizou-se o Bower 7 e o Gulp 8. O primeiro consiste de ferramentapara administração das dependências para a web. O Bower gerencia componentes que contêmHTML, Cascading Style Sheets (CSS), JavaScript, fontes e arquivos de imagem. O Gulp é umaferramenta que permite automatizar tarefas. Alguns exemplos são minificar o Javascript e CSS,além de tarefas que servem e compilam a aplicação web.

6https://angularjs.org/7<https://bower.io/>8<https://gulpjs.com/>

52

6.4.5 Proxy

O proxy foi construído utilizando o nginx, o qual consiste em um servidor web e proxyreverso de alta performance (Reese, 2008). Foi criado por Igor Sysoev da empresa Rambler(Reese, 2008). O nginx fornece todas as funcionalidades desejadas para um servidor web,dentre elas (Reese, 2008): servir arquivos estáticos; suporte para SSL e TLS; hosts virtuais;proxy reverso; balanceamento de carga; reescrita de URL.

Para configurar o nginx são necessários dois arquivos, um com as configurações globais eoutro com as configurações da aplicação web que deseja-se hospedar. No arquivo “nginx.conf”presente no apêndice B estão as configurações globais utilizadas nesse trabalho. Ressalta-se alinha 21, onde são incluídos os arquivos de configuração de cada aplicação web.

O arquivo “default.conf” deste trabalho é apresentado no apêndice C, onde considera-seuma arquitetura em containers como descrito na seção 5.2.

Por fim, para gerar a imagem Docker do proxy, criou-se o arquivo “Dockerfile” com oconteúdo apresentado no quadro 6.5. Na primeira linha, define-se a criação da imagem uti-lizando, como base, a última versão da imagem do nginx disponível no repositório oficial doDocker. Os dois arquivos de configuração são copiados para suas respectivas pastas dentro daimagem (linhas 2 e 3).

1 FROM nginx : l a t e s t2 COPY v h o s t s / d e f a u l t . con f / e t c / ng inx / con f . d / d e f a u l t . con f3 COPY nginx . con f / e t c / ng inx / ng inx . con f

Quadro 6.5: Dockerfile do Nginx.

6.4.6 Aplicação Android

A aplicação Android foi desenvolvida utilizando o framework Ionic versão 1. Esse fra-mework permite a criação de aplicativos para diversas plataformas através de um código único.Esse código é desenvolvido em JavaScript e a versão 1 do Ionic faz uso do framework Angu-larJS. Isso agilizou muito o desenvolvimento, pois o mesmo código feito para a aplicação webfoi reutilizado na aplicação móvel, bastando pequenos ajustes.

Para receber notificações do servidor através do FCM, utilizou-se o plugin do Cordova9

para FCM. O arquivo baixado do Firebase console, “google-services.json”, citado na seção6.4.2, deve ser adicionado no diretório raiz do projeto Ionic. Para permitir o recebimento denotificações, deve-se adicionar o comportamento esperado quando uma notificação nova chega.Isso foi feito no arquivo “app.js” dentro da função “run”, conforme apresentado no apêndice D.

O token gerado pelo Kit de Desenvolvimento de Software (SDK do inglês Software De-

9https://cordova.apache.org/

53

velopment Kit) do FCM, para a instância do aplicativo cliente, é enviado para a API sempreque o usuário se autentica na aplicação. O apêndice E apresenta o código responsável por esseenvio.

6.5 Hardware

A tabela 6.1 apresenta os componentes de hardwares adquiridos e utilizados neste traba-lho. O módulo Wi-Fi utilizado foi o ESP8266 Thing da Sparkfun10, o qual possui um custo,considerando uma placa para desenvolvimento, de aproximadamente U$15,00. O ESP8266 éresponsável por pré-processar os dados, detectar a queda ou alerta de frequência cardíaca, assimcomo por enviar esses alertas para o MQTT broker. Foi utilizado o mesmo ESP8266 na detec-ção de queda e cálculo da frequência cardíaca, porém não ao mesmo tempo. Primeiramenterealizou-se os testes de detecção de quedas e consumo de energia na formação ESP8266 + GY-89. Posteriormente foi carregado o código para obter o ECG e calcular a frequência cardíaca,para então avaliar o consumo de energia na formação ESP8266 + AD8232.

Para realizar a detecção de quedas utilizou-se a placa GY-89, a qual já possui um giros-cópio, acelerômetro, magnetômetro e altímetro. O custo aproximado é de U$8,00.

Para monitorar a frequência cardíaca foi utilizada a placa AD8232, que funciona comoum amplificador operacional para ajudar a obter um sinal de ECG mais claro. O AD8232 foiprojetado para extrair, amplificar e filtrar pequenos sinais biopotenciais em condições ruidosas,como por exemplo quando posicionam-se eletrodos (Sparkfun, 2017). A AD8232 possui umcusto aproximado de U$15,00. Para esse trabalho, além do sinal de ECG ser adquirido, édetectado o complexo QRS para cálculo da frequência cardíaca.

Tabela 6.1: Hardwares adquiridos.

Modelo Descrição Marca PreçoESP8266 Thing -Dev Board

Módulo Wi-Fi Sparkfun U$15,95

GY-89 Giroscópio, Ace-lerômetro, Bússola eAltímetro

diymore Worldchips U$7,52

AD8232 Monitor de frequênciacardíaca

Deek-Robot U$10,30

Foram utilizadas duas baterias de lítio-íon com tensão de 3,7 V e potência de 8,51 Wh.Para calcular a capacidade da bateria basta dividir a tensão pela potência, ou seja, cada bateriapossui uma capacidade de 2300 mA/h, totalizando 4600 mA/h para a solução.

10<https://www.sparkfun.com/>

54

Os sensores foram conectados com o mesmo ESP8266 em momentos diferentes. A figura6.5 apresenta o diagrama esquemático da conexão do sensor GY-89 com o ESP8266. A figura6.6 apresenta o diagrama esquemático da conexão do sensor AD8232 com o ESP8266.

Figura 6.5: Esquemático da conexão do sensor GY-89 com o ESP8266

Figura 6.6: Esquemático da conexão do sensor AD8232 com o ESP8266

Para enviar alertas para o MQTT broker, utilizou-se a biblioteca PubSubClient11. Essabiblioteca fornece um cliente Arduino que facilita a publicação de mensagens para um servidorutilizando o protocolo MQTT.

Para publicar os alertas desejados, foi necessário, inicialmente, configurar o broker utili-zado. O código de configuração está apresentado no quadro 6.6, onde “BROKER_MQTT” e“BROKER_PORT” são, respectivamente, o IP e a porta do broker. Após configurar o broker,deve-se realizar a conexão com o mesmo (conforme apresentado do quadro 6.7).

Por fim, para enviar os alertas, foi utilizada a função definida no quadro 6.8, onde “TO-PIC_PUBLISH” é o tópico para o qual será publicado o alerta. Os tópicos definidos nessetrabalho são: serialNumber/FALL para queda; serialNumber/FREQUENCY para frequênciacardíaca. O “serialNumber” deve ser um identificador único do ESP8266 e cada ESP8266 deveser atrelado a um usuário.

1 vo id initMQTT ( vo id )2 {3 MQTT. s e t S e r v e r (BROKER_MQTT, BROKER_PORT) ;

11https://github.com/knolleary/pubsubclient

55

4 }

Quadro 6.6: Configuração com o broker.

1 vo id connectMQTT ( vo id )2 {3 w h i l e ( !MQTT. c o n n e c t e d ( ) )4 {5 S e r i a l . p r i n t l n ( " Tentando se c o n e c t a r ao Broker MQTT: " + S t r i n g (

BROKER_MQTT) ) ;6 i f (MQTT. c o n n e c t ( ID_MQTT) )7 {8 S e r i a l . p r i n t l n ( " Conec tado " ) ;9 }

10 e l s e11 {12 S e r i a l . p r i n t l n ( " F a l h a ao R e c o n e c t a r " ) ;13 S e r i a l . p r i n t l n ( " Tentando se r e c o n e c t a r em 2 segundos " ) ;14 d e l a y ( 2 0 0 0 ) ;15 }16 }17 }

Quadro 6.7: Conexão com o broker.

1 vo id sendValuesToMQTT ( )2 {3 w h i l e ( !MQTT. p u b l i s h ( TOPIC_PUBLISH , 1 ) ) {4 }5 S e r i a l . p r i n t l n ( " L e i t u r a e n v i a d a " ) ;6

7 }

Quadro 6.8: Envio de alertas para o broker.

6.6 Algoritmos

O sinal do acelerômetro foi amostrado à 50 Hz. O pré-processamento dos dados, assimcomo o algoritmo de detecção de quedas, foram adaptados do trabalho de Karantonis et al.(2006) que está descrito na seção 3.2.1. As alterações realizadas foram:

• Foi utilizado um filtro passa-baixa Butterworth de segunda ordem, e não o filtro elípticode resposta infinita ao impulso de terceira ordem. Essa alteração foi realizada a fim dediminuir a complexidade de implementação. O filtro está definido na equação 6.1, ondey[n] é a amostra na posição n do sinal de saída do filtro e x[n] é a amostra na posição ndo sinal de entrada;

56

• O cálculo de orientação postural foi realizado com o eixo x, pois o mesmo foi posicionadopara baixo, contra a gravidade;

• O valor de threshold da área de magnitude do sinal normalizado (AMS) foi definidoempiricamente (após realizar alguns testes) em 0,2, pois o mesmo não estava claramentedefinido no algoritmo original;

• O valor de threshold do vetor de magnitude do sinal (VMS) foi definido empiricamente(após realizar alguns testes) em 2 a fim de diminuir erros quando a pessoa está correndo;

• Como não há interesse, neste trabalho, em avaliar a postura do paciente quando não hárisco de queda, o algoritmo foi simplificado. Sendo assim verifica-se a postura apenasquando há suspeita de queda.

y[n] = (x[n−2]+(2∗x[n−1])+x[n])+(−0.9565436765∗y[n−2])+(1.9555782403∗y[n−1])

(6.1)

Criou-se um alerta apenas para identificar se o paciente caiu e está impossibilitado dese movimentar para pedir ajuda, como por exemplo em caso de desmaio. O algoritmo desen-volvido é ilustrado na figura 6.7. Após a aplicação dos filtros, calcula-se o AMS, conformeequação 3.1, para verificar se o paciente está em repouso ou em movimento. O usuário está emmovimento se o valor de AMS ultrapassar o limiar de 0,2. Se for detectado um movimento,calcula-se o valor VMS, conforme equação 3.3, para detectar uma possível queda. Considera-se uma possível queda se o valor de VMS ultrapassar o limiar de 2. Com os testes realizados,verificou-se que apenas o VMS não é suficiente para detectar uma queda, pois um movimentode corrida atinge já ultrapassa o limiar de 2. Sendo assim, após identificar uma possível queda, éverificada a orientação postural do paciente conforme equação 3.2. Como o intuito é enviar umalerta apenas se o paciente não conseguir se recuperar, então a orientação postural é verificadaapós o intervalo de tempo de 10 segundos. Se o cálculo da orientação postural indicar que opaciente está deitado, então é enviado um alerta de queda para o MQTT broker.

O algoritmo utilizado para calcular a frequência cardíaca foi o criado por Chen & Chen(2003), o qual é descrito na seção 4.3.2. No GitHub12 encontra-se esse algoritmo implementadonas linguagens C, Java e Arduino. Pelo fato de não haver alterações no algoritmo, não foinecessário realizar testes a fim de validar o mesmo. Além disso, o foco deste trabalho é analisara capacidade de processamento e consumo de energia do ESP8266.

12<https://github.com/blakeMilner/real_time_QRS_detection>

57

Figura 6.7: Algoritmo implementado para detecção de quedas.

6.7 Testes e experimentos

Neste trabalho foram realizadas três categorias de experimentos: experimentos de detec-ção de queda, para avaliar se o algoritmo implementado está se comportando como o esperado;experimentos de consumo de energia do ESP8266; e experimentos para testes de desempenhodo MQTT.

6.7.1 Experimentos de Detecção de queda

Os experimentos de detecção de queda foram realizados com 8 pessoas com idades entre25 e 34 anos. No apêndice F encontra-se o parecer do Comitê de Ética em Pesquisa comSeres Humanos (CEP) da Universidade Estadual do Oeste do Paraná (UNIOESTE), aprovandoa realização dos experimentos deste trabalho.

Os casos de testes utilizados são os descritos por Noury et al. (2007) e apresentados naseção 3.3. Neste trabalho o primeiro cenário (queda para trás e finalizar sentado) foi modifi-cado para a resposta negativa. Essa alteração foi realizada tendo em vista que o objetivo destetrabalho é detectar uma queda seguida de desmaio ou incapacitação.

A avaliação também foi realizada conforme sugere Noury et al. (2007). Deste modo,deve-se calcular a sensitividade conforme equação 3.7, e a especificidade conforme a equação3.8. Para auxiliar na comparação com outros trabalhos disponíveis na literatura, optou-se porcalcular, também, a acurácia, sendo esta obtida através da equação 6.2.

58

Acuracia = (V P + V N)/TOTAL (6.2)

6.7.2 Testes de Consumo de energia

O ESP8266 fornece três modos de configuração para poupar energia: modem-sleep, light-sleep, deep-sleep (Espressif, 2018). No modo modem-sleep, o circuito Wi-Fi é desligadoquando não há transmissão de dados e a Unidade Central de Processamento (CPU - do in-glês Central Process Unit) permanece ativa, permitindo o processamento de informações locais(Espressif, 2018). No modo light-sleep, o circuito Wi-Fi é desligado e a CPU entra em modosuspenso, não sendo possível processar informações locais (Espressif, 2018). Por fim, no mododeep-sleep o circuito Wi-Fi e a CPU também são desligados, o que permite economizar aindamais energia (Espressif, 2018).

Para este trabalho, os modos light-sleep e deep-sleep não são ideais, pois não é possí-vel interromper o processamento. A partir deste contexto, os seguintes experimentos foramdelineados para avaliar o consumo de energia do ESP8266:

1. Intensidade de corrente demandada processando a detecção de queda/cálculo da frequên-cia cardíaca, sem manter conexão com o Wi-Fi e o MQTT broker;

2. Intensidade de corrente demandada processando a detecção de queda/cálculo da frequên-cia cardíaca, mantendo a conexão com o Wi-Fi e MQTT broker.

Segundo Espressif (2018), o ESP8266 entra no modo modem-sleep automaticamente apósficar um intervalo de tempo sem transmitir dados. Porém, para facilitar a realização dos experi-mentos propostos neste trabalho, forçou-se o ESP8266 a entrar neste modo.

Para estes experimentos deve-se medir a média da corrente até a estabilização. Importanteressaltar que não calculou-se o consumo durante o envio de alertas para o servidor, pelo fato domesmo ser irrisório. Neste sentido insta definir que o envio de dados demora poucos segundospara finalizar e em um universo de 24 horas, não afeta de maneira considerável o consumo dabateria. Por exemplo, se a corrente durante o envio tiver um pico de 80 mA e o tempo de enviofor de 60 segundos (superestimando a corrente e o tempo de envio), então o valor de correntedemandada seria de 1,3 mA. Se a corrente média (sem considerar o envio) for de 20 mA, oconsumo em 1 dia seria de 480 mA. Caso ocorra 1 alerta por dia, seria acrescentado o consumode envio, eliminando a corrente média que já está embutida no consumo diário ([80 - 20] / 60 =1 mA), no consumo diário (480 mA), totalizando 481 mA. Retornando esse valor para correnteinstantânea, obtêm-se 20,04 mA. Deste modo, a autonomia sem considerar nenhum envio nodia é de 161 horas (6,7 dias) e considerando 1 alerta por dia é de 160,68 horas (6,69 dias).

59

O cálculo de autonomia da bateria é realizado conforme a equação 6.3 (Eletronics, 2018).O fator de 0,7 faz concessões para fatores externos que podem afetar a duração da bateria(Eletronics, 2018).

Autonomia =Capacidadedabateria(mAh)

Consumo(mA)∗ 0, 70 (6.3)

6.7.3 Teste de Desempenho

Os experimentos relativos a desempenho, nesse trabalho, são focados no protocolo MQTT.Sendo assim, foram simulados diversos envios simultâneos para o broker, com o intuito de ava-liar como o servidor se comporta, tanto em relação ao broker quanto a API que recebe os dados.Para realizar esses testes utilizou-se a ferramenta JMeter (versão 4.0), descrita na seção 5.4. OJMeter por si só não suporta o protocolo MQTT, de modo que foi necessário adicionar o pluginmqtt-jmeter13 na versão 1.0.

Os experimentos foram realizados com um computador pessoal que possui processadorIntel core i7 6700, memória de 16 GB e distribuição Linux Mint 18.1 x64. A rede cabeadadispõe da velocidade de transferência de dados de 108 Mb/s para download e 300 Mb/s paraupload.

A aplicação testada foi inserida em uma Droplet da DigitalOcean com as seguintes con-figurações: 1 CPU Intel Xeon E5-2650 v4, memória de 2 GB, 50 GB de espaço em disco edistribuição CentOS 7.5 x64.

Os cenários experimentais são apresentados a seguir, sendo que cada cenário foi realizadopara as qualidades de serviço 0, 1 e 2 do MQTT.

• 100 envios simultâneos para qualquer fila. Repetir 5 vezes (valor empiricamente definidopara obter-se uma média);

• 500 envios simultâneos para qualquer fila. Repetir 5 vezes;

• 1.000 envios simultâneos para qualquer fila. Repetir 5 vezes;






• Acima de 10.000 threads o PC utilizado para realizar os testes apresenta erro de falta dememória.

13<https://github.com/emqtt/mqtt-jmeter>

60


Neste capítulo foram detalhados os materiais e métodos utilizados neste trabalho. Primei-ramente apresentou-se o sistema como um todo, definindo suas funcionalidades e especificida-des. Posteriormente detalhou-se os componentes desenvolvidos, as ferramentas e algoritmosutilizados e por fim os testes e experimentos definidos. No próximo capítulo serão apresentadosos resultados obtidos e discussões relevantes sobre o trabalho.

Capítulo 7

Resultados e Discussão

Neste capítulo estão descritos os resultados obtidos nesse trabalho. Primeiramente é apre-sentado o Sistema de Monitoramento do Corpo Humano (SMCH), onde estão implementadostodos os componentes da arquitetura proposta. Posteriormente estão os resultados dos testes deperformance sob a API e o MQTT broker. Por fim estão discriminados os testes de detecção dequedas e os resultados de consumo de energia do ESP8266.


A fim de validar o sistema de monitoramento do corpo humano, foram testados dois mo-nitoramentos: detecção de queda e frequência cardíaca. O algoritmo para cálculo da frequênciacardíaca utilizado neste trabalho não foi testado, sendo este utilizado apenas para avaliar oESP8266. Construir dois hardwares foi essencial para verificar a capacidade de processamentodo ESP8266 e comparar o consumo de energia do mesmo. Já o algoritmo de detecção de queda,pelo fato de não haver algoritmos consolidados na literatura, foi devidamente testado.

O teste de performance do sistema teve como foco avaliar a quantidade de informaçõesque o MQTT broker e a API desenvolvida suportam processar.

7.2 Sistema de Monitoramento do Corpo Humano (SMCH)

Os componentes da arquitetura proposta foram todos desenvolvidos. A figura 7.1 ilustra aaplicação web, com a qual é possível realizar as configurações necessárias e visualizar os alertasde todos os usuários cadastrados. A figura 7.2 ilustra a aplicação mobile, com a qual é possívelvisualizar os alertas do paciente (tanto do usuário autenticado, quanto do paciente pelo qual éresponsável). Além disso, no aplicativo mobile, o usuário é notificado quando um alerta ocorrer.

Os requisitos funcionais descritos no capítulo 6, referentes à aplicação web, foram todosdesenvolvidos. A título ilustrativo, na figura 7.3 apresentam-se as telas que permitem cadastrar,

61

62

Figura 7.1: Aplicação web.

Figura 7.2: Aplicação mobile.

63

remover, editar e buscar usuários. Para atrelar um cuidador ao usuário, basta informá-lo nocadastro do usuário. Já na figura 7.4 ilustra-se a tela que permite cadastrar, remover, editar ebuscar dispositivos. Para atrelar um dispositivo a um usuário, basta informá-lo no cadastro dodispositivo. Por fim, para reconhecer um alerta, basta clicar no botão sob o alerta em questão,ilustrado na figura 7.1.

Figura 7.3: Telas para cadastrar, remover, editar e buscar usuários.

Todas as funcionalidades descritas no capítulo 6 referentes à aplicação mobile foram de-senvolvidas. A figura 7.2 ilustra a tela que permite visualizar os próprios alertas e os alertas dousuário por quem é responsável. A figura 7.5 ilustra uma notificação de alerta recebida. Porfim, para reconhecer um alerta, basta clicar no botão à direita no alerta em questão, ilustrado nafigura 7.2.

7.2.1 Resultados dos testes de desempenho

As atividades definidas na seção 5.4 foram executadas, passo a passo, sendo que na ati-vidade “Projetar e planejar”, apenas focou-se em identificar quantos alertas simultâneos a APIsuporta receber (os cenários estão descritos na seção 6.7.3). Isso se deu pelo fato de ser umaaplicação nova e poder ser implantada em diversos cenários diferentes. Deste modo, não foi

64

Figura 7.4: Telas para cadastrar, remover, editar e buscar dispositivos.

Figura 7.5: Tela que ilustra uma nova notificação recebida.

possível definir o padrão de uso da aplicação e identificar cenários de uso realistas.

Os ambientes de testes físico e em produção estão identificados na seção 6.7.3. O critério

65

de aceitação definido é que todo alerta enviado pelo hardware deve ser processado e armazenadono servidor.

O ambiente de testes físico foi preparado de modo que apenas a interface gráfica do JMetere um terminal estivesse aberto. Esse cuidado existe para consumir a menor quantidade possívelde recurso da máquina.

A tabela 7.1 apresenta os resultados obtidos de acordo com os cenários de testes planeja-dos. Na primeira coluna está discriminada a qualidade de serviço testada. Na segunda colunadefine-se o cenário (número de mensagens enviadas simultaneamente) e a média do número demensagens que a API de fato recebeu e processou (armazenou como alerta). Na terceira colunaestá a média do tempo mínimo e máximo de envio. Por fim, a quarta coluna apresenta a mé-dia das porcentagens de erros no envio. As médias são de acordo com as 5 execuções de cadacenário, conforme definido na seção 6.7.3.

Tabela 7.1: Resultado do teste de desempenho do protocolo MQTT.

Qualidade de Serviço No de Mensagens envi-adas / processadas

Tempo min. (ms) /Tempo máx. (ms)

Erro (%)

0

100 / 100 0 / 1,4 0500 / 500 0 / 1 01.000 / 1.000 0 / 10,4 01.500 / 1.500 0 / 10,2 02.000 / 2.000 0 / 20 04.000 / 4.000 0 / 33,8 08.000 / 8.000 0 / 48 010.000 / 9.989,6 0 / 66,4 0,104

1

100 / 100 223,8 / 353,8 0500 / 500 223,6 / 251,6 01.000 / 1.000 223,6 / 260,6 01.500 / 1.500 223,2 / 401,6 02.000 / 1.994,2 223 / 291,2 0,294.000 / 3.968,8 223,5 / 1.307,4 0,788.000 / 7.989,6 223,5 / 3.488,6 0,1310.000 / 10.000 223,4 / 4.060,8 0

2

100 / 100 448,2 / 485 0500 / 500 446,8 / 703,4 01.000 / 1.000 446,8 / 1.712,2 01.500 / 1.500 443,8 / 1.821,4 02.000 / 2.000 447,6 / 1.398,6 04.000 / 3.996 449,5 / 2.869,8 0,18.000 / 7.989,8 448 / 4.404,6 0,127510.000 / 9.999,6 448,75 / 6.437,4 0,004

Esses resultados não foram obtidos na primeira execução, pois identificaram-se pontos de

66

falha. As alterações realizadas na API foram:

• Criar uma thread para cada mensagem recebida do broker a fim de paralelizar o proces-samento dos alertas na API;

• Incrementar o valor da propriedade “MaxInflight” do Eclipse Paho para 65.000 (o padrãoé 10) a fim de armazenar uma maior quantidade de dados no broker e diminuindo a perda;

• Alterar o valor da propriedade “CleanSession” do Eclipse Paho para falso (o padrão éverdadeiro) a fim de armazenar o estado da conexão entre cliente e servidor em caso dereconexão.

As alterações realizadas no broker foram através do arquivo “mosquitto.conf” e estãodefinidas a seguir:

• Definir a configuração “persistence” para verdadeiro (o padrão é falso). Essa configura-ção define que as mensagens devem ser armazenadas em disco caso necessário, evitandoperdas quando o fluxo de mensagens for muito alto;

• Definir a configuração “max_inflight_messages” para 0 (o padrão é 20). Essa configura-ção define o número de mensagens que podem estar em processo de transmissão simulta-neamente. O valor 0 indica o número máximo possível.

O gráfico 7.6 compara o tempo máximo de envio das mensagens, de acordo com a qua-lidade de serviço selecionada e o número de mensagens simultâneas enviadas. Conclui-se quequanto maior a qualidade de serviço, mais tempo demora para finalizar o envio. Isso se dá pelofato de serem necessárias confirmações nas qualidade de serviço 1 e 2. No caso específico da 2são necessárias mais mensagens de confirmação, pois garante a entrega apenas uma vez. Paraeste trabalho, a qualidade de serviço 1 já atende, pois não há problema se um mesmo alerta forenviado mais de uma vez.

7.3 Resultados do algoritmo de detecção de quedas

O ESP8266 e a placa GY-89 foram conectados conforme ilustrado na figura 6.5. Na figura7.7a encontra-se a solução real do hardware para detecção de queda. Esta solução foi dispostaem uma cinta (figura 7.7b) e posicionada na cintura de cada voluntário.

O algoritmo de detecção de quedas, descrito na seção 6.6, foi implementado e carregadono ESP8266. Os cenários de testes realizados estão definidos na seção 6.7.1 e na tabela 7.2são apresentados os resultados alcançados com as simulações de quedas. De acordo com asequações 3.7, 3.8 e 6.2 a sensibilidade do algoritmo é de 90%, a especificidade é de 95% e aacurácia é de 93%.

67

Figura 7.6: Comparação do tempo máximo de execução de acordo com a qualidade de serviçoe número de mensagens simultâneas.

(a) Solução real do hardware para detecção dequeda.

(b) Cinta utilizada para dispor o hardware de detec-ção de queda.

Figura 7.7: Solução final para detecção de queda.

Tabela 7.2: Resultados das simulações de quedas

Casos realizados Casos detectadosVerdadeiros Positivos (VP) 216 194

Verdadeiros Negativos (VN) 264 252Falsos Negativos (FN) 0 22Falsos Positivos (FP) 0 12

68

7.4 Resultados do Consumo de Energia

O consumo de energia foi avaliado tanto com o ESP8266 conectado à placa GY-89, quantocom o ESP8266 conectado à placa AD8232. O ESP8266 e a placa AD8232 foram conectadosconforme ilustrado na figura 6.6 e o código para o cálculo da frequência cardíaca, apresentadona seção 6.6, foi carregado. Na figura 7.8 encontra-se a solução real do hardware para detecçãodo sinal de ECG.

Figura 7.8: Solução real do hardware para detecção do sinal de ECG.

Para cada formação de hardware realizaram-se os cenários definidos na seção 6.7.2. Osresultados obtidos foram os mesmos para as duas formações e estão apresentados na tabela 7.3.De acordo com os resultados é possível concluir que o ideal é a implementação de acordo com oexperimento 1, onde o Wi-Fi permanece desligado e a conexão só ocorre quando for necessárioenviar um alerta para o servidor.

Segundo Espressif (2018) o ESP8266 consome uma corrente de 15 mA quando está nomodo modem-sleep. Porém, foi utilizado neste trabalho uma placa de desenvolvimento, a qualpossui periféricos e outros componentes embutidos. Além disso, existe o acréscimo do consumodo sensor (GY-89 ou AD8232) que foi conectado ao ESP8266. Por esses motivos, a soluçãodesenvolvida consome mais energia do que o que consta na documentação do chip ESP8266.

Tabela 7.3: Resultados do consumo de energia

Experimento Corrente Autonomia (horas) Autonomia (dias)1 20 mA 107,1 6,72 73 mA 38,8 1,8

69

7.5 Discussões

Neste trabalho foi desenvolvido uma solução monitorar pessoas com problemas cardio-vasculares, idosos e pessoas que moram sozinhas. O foco foi um sistema para uso doméstico eeconomicamente acessível, a fim de possibilitar que o maior número de pessoas possíveis tenhaacesso a um sistema de monitoramento.

Como resultado, foi construído um dispositivo de aproximadamente U$20,00, para detec-ção de queda e outro, de aproximadamente U$30,00, para detecção do sinal de ECG. Não foilevantado o custo da bateria utilizada neste trabalho, porém é possível adquirir uma de 2.500mA/h por aproximadamente U$8,001 na China. Além da bateria, é necessário acrescentar ocusto do circuito para permitir o carregamento da mesma, além de uma caixa de proteção para odispositivo. Porém, o ESP8266 adquirido e testado neste trabalho é um próprio para desenvol-vimento, de modo que é possível utilizar, na solução final, um módulo com um custo inferior(aproximadamente U$8,002).

Para manter a plataforma no ambiente de produção utilizado neste trabalho, conformedefinido na seção 6.7.3, tem um custo de U$10,00 por mês. Porém, é possível manter em umservidor local, não sendo obrigatório o uso de uma Infraestrutura como Serviço.

Ainda assim, a solução de hardware proposta neste trabalho é muito vantajosa, pois osusuários podem adquirir apenas os dispositivos específicos para monitorar o desejado e utilizar amesma plataforma de software. Além de que, a plataforma estando disponível, qualquer pessoapoderia confeccionar o hardware, conforme desejado, e solicitar autorização para utilizar aplataforma de monitoramento.

A solução de hardware, mesmo sendo simples e economicamente acessível, se mostroueficiente. Os testes de detecção de queda obtiveram uma sensibilidade de 90%, especificidade de95% e acurácia de 93%. Comparando os resultados obtidos com relação à detecção de quedas,Kangas et al. (2007) obteve uma sensibilidade de 100% utilizando uma acelerômetro na cinturae analisando a postura após a queda. Porém, realizou-se apenas 45 casos de testes utilizandodois voluntários. Karantonis et al. (2006) obteve uma acurácia de 95,6% na detecção de quedas,sendo este o trabalho utilizado como base para o algoritmo. Wang et al. (2008) obteve umaespecificidade e sensibilidade de 100% ao utilizar 4 critérios para detecção de quedas: soma-vetor de todos os eixos (Sa); soma-vetor do plano horizontal (Sh); estampa de tempo da quedado corpo já em repouso (Trs); estampa de tempo do contato inicial do corpo com o chão (Tic);e integração inversa da velocidade de referência (Vmax). Porém, o acelerômetro é posicionadona cabeça, diferentemente deste trabalho onde o acelerômetro é posicionado na cintura. Bourkeet al. (2007) obteve uma especificidade de 100% utilizando um acelerômetro no tronco.

Não foram realizados testes sobre o algoritmo utilizado para calcular a frequência car-

1https://best.aliexpress.com/2https://www.sparkfun.com/products/13678

70

díaca. Isso se deu pelo fato de que não foram feitas alterações no algoritmo original. Alémdisso, o foco deste trabalho foi analisar a capacidade de processamento e consumo de ener-gia do ESP8266. Deste modo, verificou-se que o ESP8266 é capaz de processar o cálculo dafrequência cardíaca e enviar alertas quando desejado.

Neste trabalho utilizou-se o conceito e as tecnologias envolvidas em aplicações IoT, poiscomo levantado na seção 2, mais especificamente no gráfico representado na figura 2.1, estima-se um investimento de aproximadamente U$2,5 trilhões por ano, até 2025, em aplicações IoTfocadas em assistência médica. Sendo assim, pode haver o interesse comercial em manter edistribuir a plataforma de monitoramento proposta neste trabalho.

Além disso, a arquitetura de aplicações IoT permite que a plataforma seja expansível.Deste modo, é possível incrementar o número de dispositivos facilmente, podendo acrescentaroutras monitorações, como por exemplo pressão sanguínea. Também é possível incrementar onúmero de clientes, como por exemplo, uma aplicação para um hospital. Basta o novo clientese inscrever nos tópicos definidos que o mesmo irá receber os alertas.

Essa expansão é apenas limitada pelo desempenho do broker, conforme apresentado naseção 7.2.1. Identifica-se, como ideal, que a plataforma seja utilizada em um nível de abrangên-cia, onde seja improvável receber mais de 1.500 alertas ao mesmo tempo.

As tecnologias utilizadas neste trabalho foram escolhidas em conjunto e se complemen-tam. Dentre as opções de comunicação sem fio destacam-se Wi-Fi, Zigbee e BLE. O protocoloZigbee exige um gateway para que os dados gerados pelos equipamentos que se comunicamatravés desta tecnologia, sejam enviados para um servidor web. Sendo assim, o gateway deveser capaz de enviar os dados através do protocolo Wi-Fi ou Ethernet. Um equipamento comessa finalidade tem um custo aproximado de U$140,00 3 e cada residência deveria possuir umdeste. Um modulo Bluetooth tem um custo aproximado de U$20,00 4 e acrescenta a dificuldadee necessidade de um dispositivo intermediário. Os dados gerados pelos dispositivos Bluetoothdeverão passar por um dispositivo intermediário (como por exemplo um smartphone) para entãoserem enviados para o servidor web. Diante deste cenário, o uso do ESP8266, que possui umcusto aproximado de U$16,00 5, é o ideal pelo fato de ser economicamente acessível e não sernecessário nenhum equipamento intermediário para enviar os dados para o servidor web pois jáutiliza o protocolo de comunicação Wi-Fi.

O protocolo MQTT foi selecionado pela sua simplicidade e eficiência. Existem outrosprotocolos similares e com a mesma finalidade, porém o MQTT é um protocolo simples e,diferentemente do CoAP, utiliza o protocolo TCP que garante a entrega de pacotes, ao contráriodo UDP.

O Docker foi utilizado neste trabalho apenas para facilitar a implantação do ambiente de

3https://www.amazon.com/Networking-Modules-Gateway-ZigBee-Ethernet/dp/B00R3RETSM4https://www.sparkfun.com/products/148395https://www.sparkfun.com/products/13711

71

testes.

Os frameworks Spring Boot e AngularJS foram utilizados pelo fato da autora já possuirexperiência com estas tecnologias. Já o framework Ionic v1 foi utilizado pelo fato de utili-zar AngularJS para a implementação do código. Deste modo foi possível reutilizar o códigodesenvolvido em AngularJS na aplicação móvel.

A ferramenta de testes JMeter foi selecionada pelo fato da autora ter uma prévia experi-ência com a ferramenta.

Para realizar a detecção de quedas, este trabalho utilizou como base o algoritmo de Ka-rantonis et al. (2006). Isso se deu pois, diante dos trabalhos estudados, este foi o que mais seadequou às necessidades deste trabalho, como por exemplo o uso de um único acelerômetro eposicionado em um local possível de se utilizar durante o dia (cintura). Além disso, foi possívelreplicar as partes de interesse do algoritmo.

Para calcular a frequência cardíaca, foi utilizado o algoritmo criado com Chen & Chen(2003) por ser simples e alcançar bom resultados estatísticos.


Neste capítulo foram apresentados os resultados obtidos neste trabalho assim como dis-cussões relevantes. No próximo capítulo será feito uma conclusão do trabalho, sumarizando ospontos principais e citando trabalhos futuros.

Capítulo 8

Conclusão e Trabalhos Futuros

A plataforma desenvolvida neste trabalho alcançou uma boa performance, especifica-mente dentro dos requisitos estabelecidos, sendo possível enviar até 10.000 alertas simultâneos,utilizando a qualidade de serviço 1 do protocolo MQTT, sem apresentar erros. O maior erroidentificado nos testes de desempenho foi de 0,78%, no envio de 4.000 alertas simultâneos(aproximadamente 31 alertas), na configuração de qualidade de serviço 1. Nos cenários comaté 1.500 mensagens simultâneas, não houve falha em nenhum tipo de envio. Deste modo,identifica-se como ideal que a plataforma seja utilizada em um nível de abrangência, onde sejaimprovável receber mais de 1.500 alertas ao mesmo tempo.

O hardware desenvolvido caracteriza um protótipo com a finalidade de validar o uso deequipamentos economicamente acessíveis. Mesmo selecionando equipamentos de custo baixo,os resultados foram amplamente satisfatórios.

Os resultados obtidos para detecção de quedas foram: 90% de sensibilidade, 95% deespecificidade e 93% de acurácia. Comparando com os resultados da literatura, a detecçãode quedas desenvolvida neste trabalho obteve resultados inferiores. Porém, os experimentosrealizados são diferentes e em alguns casos o acelerômetro é posicionado em locais inadequadospara este trabalho (a cabeça por exemplo).

O algoritmo desenvolvido neste trabalho não obteve os mesmos resultados do trabalhoutilizado como base, o qual obteve uma acurácia de 95,6%. Uma explicação é que pelo fatodo hardware ser um protótipo e não ter sido devidamente protegido, fez com que ocorressemproblemas físicos, ocasionando desligamento temporário do dispositivo.

Com relação ao consumo de energia, para as duas formações de hardwares obteve-se umaautonomia de aproximadamente 6 dias, sendo este um consumo viável.

O ESP8266 atende a necessidade de baixo consumo desde que utilize o Wi-Fi apenasquando necessário, além de ser economicamente acessível e de fácil implantação, bastando opaciente possuir internet Wi-Fi em sua residência. A solução foi pensada para funcionar apenasna residência do paciente, pois se acontecer algum acidente em um ambiente externo, o mesmopode ser socorrido por outras pessoas.

73

74

O protocolo MQTT é de simples configuração e atendeu perfeitamente a resolução doproblema abordado neste trabalho. Neste sentido, foi necessário apenas um foco nas alteraçõesrealizadas no arquivo de configuração do broker para garantir a performance alcançada.

O desenvolvimento deste trabalho permitiu identificar diversos estudos futuros, dentreeles melhorias no hardware, como por exemplo o desenvolvimento de uma caixa de proteçãoe realizar soldas para o equipamento ser mais robusto e confiável. Outro trabalho consiste emestudar uma bateria que não agregue muito valor econômico na solução e que seja de fácilrecarga. Também merece atenção adicionar segurança no protocolo MQTT, pois o mesmopermite uma autenticação por usuário e senha. Outra funcionalidade pertinente consiste empermitir o envio de informações em tempo real para a plataforma e apresentar essas informaçõesem gráficos, a fim de auxiliar em futuros estudos. Por fim, incrementar a arquitetura a fim depermitir escalonamento na aplicação.

Referências Bibliográficas

Abibullaev, B. & Seo, H. D. (2011). A New QRS Detection Method Using Wavelets andArtificial Neural Networks, Journal of Medical Systems 35(4): 683—-691.

Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M. & Ayyash, M. (2015). Internet ofthings: A survey on enabling technologies, protocols, and applications, IEEE Communi-cations Surveys Tutorials 17(4): 2347–2376.

Álvarez, R. A., Penín, A. J. M. & Sobrino, X. A. V. (2013). A Comparison of Three QRSDetection Algorithms Over a Public Database, Procedia Technology 9: 1159–1165.Disponível em: http://linkinghub.elsevier.com/retrieve/pii/S2212017313002831

AngularJS, G. (2018). What is angularjs? Acesso em: 23 de mai. 2018.Disponível em: https://docs.angularjs.org/guide/introduction

Arzeno, N. M., Deng, Z. D. & Poon, C. S. (2008). Analysis of first-derivative based QRSdetection algorithms, IEEE Transactions on Biomedical Engineering 55(2): 478–484.

Bhardwaj, S., Jain, L. & Jain, S. (2010). Cloud Computing : a Study of Infrastructure As aService ( Iaas ), International Journal of Engineering 2(1): 60–63.Disponível em: http://ijeit.org/index_files/vol2no1/CLOUD COMPUTING A STUDYOF.pdf

Bluetooth (2016). Bluetooth core specification. Acesso em: 05 de abr. 2017.Disponível em: https://www.bluetooth.com/specifications/bluetooth-core-specification

Bourke, A. K., O’Brien, J. V. & Lyons, G. M. (2007). Evaluation of a threshold-based tri-axialaccelerometer fall detection algorithm, Gait and Posture 26(2): 194–199.

Chen, H. & Chen, S. (2003). A moving average based filtering system with its application toreal-time QRS detection, Computers in Cardiology, 2003 pp. 585–588.Disponível em: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1291223

CoAP (2018). Coap web page. Acesso em: 22 de mai. 2018.Disponível em: http://coap.technology/

Dubin, D. M. D. (1976). Interpretacão Rápida do ECG, 3 edn, Cover Publishing Company.

Eletronics, D. (2018). Battery life calculator. Acesso em: 13 de mar. 2018.Disponível em: https://www.digikey.com/en/resources/conversion-calculators/conversion-calculator-battery-life

Erinle, B. (2013). Performance Testing with JMeter 2.9, Packt Publishing Ltd.

75

76

Espressif (2018). Esp8266 low power solutions. Acesso em: 23 de jul. 2018.Disponível em: https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf

Fielding, R. T. (2000). Architectural styles and the design of network-based software architec-tures. Acesso em: 23 de mai. 2018.Disponível em: http://www.ics.uci.edu/ fielding/pubs/dissertation/top.htm.

Hamilton, P. S. & Tompkins, W. J. (1986). Quantitative Investigation of QRS Detection RulesUsing the MIT/BIH Arrhythmia Database, IEEE Transactions on Biomedical EngineeringBME-33(12): 1157–1165.Disponível em: http://ieeexplore.ieee.org/document/4122227/

Hou, L., Zhao, S., Xiong, X., Zheng, K., Chatzimisios, P., Hossain, M. S. & Xiang, W. (2016).Internet of Things Cloud: Architecture and Implementation, IEEE Communications Ma-gazine 54(12): 32–39.

Hunkeler, U., Truong, H. L. & Stanford-Clark, A. (2008). Mqtt-s—a publish/subscribe proto-col for wireless sensor networks, Communication systems software and middleware andworkshops, 2008. comsware 2008. 3rd international conference on, IEEE, pp. 791–798.

IBGE (2016a). Pesquisa nacional de saúde. Acesso em: 16 de jun. 2016.Disponível em: http://biblioteca.ibge.gov.br/visualizacao/livros/liv91110.pdf

IBGE (2016b). Síntese de indicadores sociais. uma análise das condições de vida da populaçãobrasileira. Acesso em: 16 de jun. 2016.Disponível em: http://biblioteca.ibge.gov.br/visualizacao/livros/liv66777.pdf

INTO (2016). Lançada a campanha do into contra as quedas. Acesso em: 16 de jun. 2016.Disponível em: https://www.into.saude.gov.br/noticiasAtuais.aspx?id=471

Jara, A. J., Zamora-Izquierdo, M. A. & Skarmeta, A. F. (2013). Interconnection framework formhealth and remote monitoring based on the internet of things, IEEE Journal on SelectedAreas in Communications 31(9): 47–65.

JWT (2018). Introduction to json web tokens. Acesso em: 23 de mai. 2018.Disponível em: https://jwt.io/introduction/

Kangas, M., Konttila, A., Winblad, I. & Jämsä, T. (2007). Determination of simple thresholdsfor accelerometry-based parameters for fall detection, Annual International Conference ofthe IEEE Engineering in Medicine and Biology - Proceedings pp. 1367–1370.

Karagiannis, V., Chatzimisios, P., Vazquez-Gallego, F. & Alonso-Zarate, J. (2015). A surveyon application layer protocols for the internet of things, Transaction on IoT and CloudComputing 3(1): 11–17.

Karantonis, D. M., Narayanan, M. R., Mathie, M., Lovell, N. H. & Celler, B. G. (2006). Im-plementation of a real-time human movement classifier using a triaxial accelerometer forambulatory monitoring, IEEE Transactions on Information Technology in Biomedicine10(1): 156–167.

77

Khan, R., Khan, S. U., Zaheer, R. & Khan, S. (2012). Future internet: the internet of things ar-chitecture, possible applications and key challenges, Frontiers of Information Technology(FIT), 2012 10th International Conference on, IEEE, pp. 257–260.

Kiran, M. P. R. S., Rajalakshmi, P. & Acharyya, A. (2014). Context predictor based sparsesensing technique and smart transmission architecture for iot enabled remote health moni-toring applications, 2014 36th Annual International Conference of the IEEE Engineeringin Medicine and Biology Society, pp. 4151–4154.

Machado, F. M. (2016). Sob Demanda De Sinais Biomédicos Usando Internet Das Coisas ,Computação Móvel E Armazenamento Em Nuvem, Dissertação .

Manyika, J., Chui, M., Bughin, J., Dobbs, R., Bisson, P. & Marrs, A. (2013). Disruptivetechnologies: Advances that will transform life, business, and the global economy.Acesso em: 05 de abr. 2017.Disponível em: http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/disruptive-technologies

Martíinez, J. P., Almeida, R., Olmos, S., Rocha, A. P. & Laguna, P. (2004). A wavelet-basedECG delineator: evaluation on standard databases, IEEE Transactions on Biomedical En-gineering 51(4): 570–581.

Martínez, A., Alcaraz, R. & Rieta, J. (2010). Application of the phasor transform for automaticdelineation of single-lead ECG fiducial points, Physiological Measurement 31(11): 1467.

Massé, M. (2011). Rest API Design Role Book, 1 edn, OReilly Media.

Moody, G. B. (2008). The physionet / computers in cardiology challenge 2008: T-wave Alter-nans, Computers in Cardiology 35: 505–508.

Moody, G. B. & Mark, R. G. (2001). The impact of the MIT-BIH arrhythmia database, IEEEEngineering in Medicine and Biology Magazine 20(3): 45–50.

MQTT (2018). Mqtt web page. Acesso em: 22 de mai. 2018.Disponível em: http://mqtt.org/

Mubashir, M., Shao, L. & Seed, L. (2013). A survey on fall detection: Principles and approa-ches, Neurocomputing 100: 144–152.Disponível em: http://dx.doi.org/10.1016/j.neucom.2011.09.037

Noury, N., Fleury, a., Rumeau, P., a.K. Bourke, Laighin, G., Rialle, V. & Lundy, J. (2007).Fall detection - Principles and Methods, 2007 29th Annual International Conference ofthe IEEE Engineering in Medicine and Biology Society pp. 1663–1666.

Pan, J. & Tompkins, W. J. (1985). A Real-Time QRS Detection Algorithm, IEEE Transactionson Biomedical Engineering BME-32(3): 230–236.Disponível em: http://ieeexplore.ieee.org/document/4122029/

Pandey, S., Voorsluys, W., Niu, S., Khandoker, A. & Buyy, R. (2012). An autonomic cloudenvironment for hosting ecg data analysis services, Future Generation Computer Systems28(1): 147–154.

78

Patel, K. K., Patoliya, J. & Patel, H. (2015). Low cost home automation with esp8266 andlightweight protocol mqtt, Transactions on Engineering and Sciences 3(6): 14–50 19.

Physionet (2018a). Other databases of physiologic signals. Acesso em: 16 de mai. 2018.Disponível em: https://www.physionet.org/physiobank/other.shtml

Physionet (2018b). The qt database. Acesso em: 16 de mai. 2018.Disponível em: https://www.physionet.org/physiobank/database/qtdb/doc/node3.html

Rasid, M. F. A., Musa, W. M. W., Kadir, N. A. A., Noor, A. M., Touati, F., Mehmood, W., Khriji,L., Al-Busaidi, A. & Mnaouer, A. B. (2014). Embedded gateway services for internetof things applications in ubiquitous healthcare, 2014 2nd International Conference onInformation and Communication Technology (ICoICT), pp. 145–148.

Redhat (2018a). O que é docker? Acesso em: 22 de mai. 2018.Disponível em: https://www.redhat.com/pt-br/topics/containers/what-is-docker

Redhat (2018b). O que é um container linux? Acesso em: 22 de mai. 2018.Disponível em: https://www.redhat.com/pt-br/topics/containers/whats-a-linux-container

Reese, W. (2008). Nginx: the High-Performance Web Server and Reverse Proxy, Linux Journal2008(2).

Santos, B. P., Silva, L. A. M., Celes, C. S. F. S., Neto, J. B. B., Peres, B. S., Vieira, M. A. M.,Vieira, L. F. M., Goussevskaia, O. N. & Loureiro, A. A. F. (2016). Internet das coisas:da teoria à prática, XXXIV Simpósio Brasileiro de Redes de Computadores e SistemasDistribuídos 1: 1–50.

Schlindwein, F., Pereira, W. & Lima, C. (1987). Algoritmo Para Detecção e Delimitação deComplexos QRS Em Duas Derivações de ECG, Research on Biomedical Engineering4(2): 5–23.

Shahamabadi, M. S., Ali, B. B. M., Varahram, P. & Jara, A. J. (2013). A network mobilitysolution based on 6lowpan hospital wireless sensor network (nemo-hwsn), 2013 SeventhInternational Conference on Innovative Mobile and Internet Services in Ubiquitous Com-puting, pp. 433–438.

Sparkfun (2017). Sparkfun single lead heart rate monitor - ad8232. Acesso em: 28 de abr. 2017.Disponível em: https://www.sparkfun.com/products/12650

Spring (2018). Spring integration reference manual -mqtt support. Acesso em: 22 de mai. 2018.Disponível em: https://docs.spring.io/spring-integration/reference/html/mqtt.html

Taddei, A., Distante, G., Emdin, M., Pisani, P., Moody, G., Zeelenberg, C. & Marchesi, C.(1992). The European ST-T Database: standard for evaluating systems for the analysisof ST-T changes in ambulatory electrocardiography, European Heart Journal 13: 1164–1172.

Thangavel, D., Ma, X., Valera, A., Tan, H. X. & Tan, C. K. Y. (2014). Performance evaluationof mqtt and coap via a common middleware, 2014 IEEE Ninth International Conferenceon Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), pp. 1–6.

79

van der Meulen, R. (2015). Gartner says 6.4 billion connected "things"will be in use in 2016,up 30 percent from 2015. Acesso em: 05 de abr. 2017.Disponível em: http://www.gartner.com/newsroom/id/3165317

W3Schools (2018). Angularjs tutorial. Acesso em: 23 de mai. 2018.Disponível em: https://www.w3schools.com/angular/

Wang, C. C., Chiang, C. Y., Lin, P. Y., Chou, Y. C., Kuo, I. T., Huang, C. N. & Chan, C. T.(2008). Development of a fall detecting system for the elderly residents, 2nd InternationalConference on Bioinformatics and Biomedical Engineering, iCBBE 2008 pp. 1359–1362.

Yang, G., Xie, L., Mäntysalo, M., Zhou, X., Pang, Z., Xu, L. D., Kao-Walter, S., Chen, Q.& Zheng, L. R. (2014). A health-iot platform based on the integration of intelligentpackaging, unobtrusive bio-sensor, and intelligent medicine box, IEEE Transactions onIndustrial Informatics 10(4): 2180–2191.

Yang, L., Ge, Y., Li, W., Rao, W. & Shen, W. (2014). A home mobile healthcare systemfor wheelchair users, Proceedings of the 2014 IEEE 18th International Conference onComputer Supported Cooperative Work in Design (CSCWD), pp. 609–614.

Apêndice A

Arquivo Security.java

Arquivo de configuração da autenticação da API.

1 @Autowired2 p u b l i c S e c u r i t y (3 Objec tMapper ob jec tMapper , U s e r D e t a i l s S e r v i c e u s e r D e t a i l s S e r v i c e ,

J w t U t i l j w t U t i l ) {4 t h i s . o b j e c t M a p p e r = o b j e c t M a p p e r ;5 t h i s . u s e r D e t a i l s S e r v i c e = u s e r D e t a i l s S e r v i c e ;6 t h i s . j w t U t i l = j w t U t i l ;7 }8

9 @Override10 p r o t e c t e d vo id c o n f i g u r e ( A u t h e n t i c a t i o n M a n a g e r B u i l d e r a u t h ) t h ro ws

E x c e p t i o n {11 a u t h12 . u s e r D e t a i l s S e r v i c e ( u s e r D e t a i l s S e r v i c e )13 . passwordEncoder ( passwordEncoder ( ) ) ;14

15 }16 @Override17 p r o t e c t e d vo id c o n f i g u r e ( H t t p S e c u r i t y h t t p ) t h ro ws E x c e p t i o n {18 / / @fo rma t t e r : o f f19 h t t p20 . formLogin ( ) . d i s a b l e ( )21 . a n t M a t c h e r ( " / a p i /∗∗ " ) . a u t h o r i z e R e q u e s t s ( )22 . a n t M a t c h e r s ( POST , " / a p i / l o g i n " ) . p e r m i t A l l ( )23 . anyReques t ( ) . a u t h e n t i c a t e d ( )24 . and ( )25 . c s r f ( ) . d i s a b l e ( )26 . h e a d e r s ( )27 . f r a m e O p t i o n s ( ) . d i s a b l e ( )28 . and ( )29 . s e ss ionManagement ( )30 . s e s s i o n C r e a t i o n P o l i c y ( STATELESS )31 . and ( )

81

82

32 . a d d F i l t e r B e f o r e ( j w t A u t h e n t i c a t i o n F i l t e r ( ) ,U s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r . c l a s s )

33 . a d d F i l t e r B e f o r e ( u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r ( ) ,J w t A u t h e n t i c a t i o n F i l t e r . c l a s s ) ;

34 / / @fo rma t t e r : on35 }36

37 @Bean38 p u b l i c PasswordEncoder passwordEncoder ( ) {39 r e t u r n new BCryptPasswordEncoder ( ) ;40 }41

42 @Bean43 p u b l i c F i l t e r j w t A u t h e n t i c a t i o n F i l t e r ( ) {44 r e t u r n new J w t A u t h e n t i c a t i o n F i l t e r ( j w t U t i l , u s e r D e t a i l s S e r v i c e ) ;45 }46

47 @Bean48 p u b l i c F i l t e r u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r ( ) t h row s E x c e p t i o n {49 U s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r

u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r = newU s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r ( ) ;

50 u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r . s e t A u t h e n t i c a t i o n S u c c e s s H a n d l e r (new J w t A u t h e n t i c a t i o n S u c c e s s H a n d l e r ( j w t U t i l , o b j e c t M a p p e r ) ) ;

51 u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r . s e t A u t h e n t i c a t i o n F a i l u r e H a n d l e r (new J w t A u t h e n t i c a t i o n F a i l u r e H a n d l e r ( ) ) ;

52 u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r . s e t A u t h e n t i c a t i o n M a n a g e r (a u t h e n t i c a t i o n M a n a g e r ( ) ) ;

53 u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r . s e t F i l t e r P r o c e s s e s U r l ( " / a p i / l o g i n ") ;

54 r e t u r n u s e r n a m e P a s s w o r d A u t h e n t i c a t i o n F i l t e r ;55 }

Apêndice B

Arquivo nginx.conf

Arquivo de configurações globais do nginx.

1 u s e r ng inx ;2 w o r k e r _ p r o c e s s e s 1 ;3 p i d / v a r / run / ng inx . p i d ;4

5 e v e n t s {6 w o r k e r _ c o n n e c t i o n s 1024 ;7 }8

9 h t t p {10 i n c l u d e / e t c / ng inx / mime . t y p e s ;11 d e f a u l t _ t y p e a p p l i c a t i o n / o c t e t−s t r e a m ;12

13 l o g _ f o r m a t main ’ $ r e m o t e _ a d d r − $ r e m o t e _ u s e r [ $ t i m e _ l o c a l ] " $ r e q u e s t "’

14 ’ $ s t a t u s $ b o d y _ b y t e s _ s e n t " $ h t t p _ r e f e r e r " ’15 ’ " $ h t t p _ u s e r _ a g e n t " " $ h t t p _ x _ f o r w a r d e d _ f o r " ’ ;16

17 a c c e s s _ l o g / v a r / l o g / ng inx / a c c e s s . l o g main ;18 s e n d f i l e on ;19 k e e p a l i v e _ t i m e o u t 6 5 ;20 c l i e n t _ m a x _ b o d y _ s i z e 10M;21 i n c l u d e / e t c / ng inx / con f . d / ∗ . con f ;22 }

83

Apêndice C

Arquivo default.conf

Arquivo de configurações do nginx da aplicação web que deseja-se hospedar.

1 s e r v e r {2 l i s t e n 8 0 ;3 se rve r_name l o c a l h o s t ;4 p r o x y _ p a s s _ h e a d e r S e r v e r ;5

6 l o c a t i o n / {7 p r o x y _ s e t _ h e a d e r Host $ h o s t ;8 p r o x y _ s e t _ h e a d e r X−Real−IP $ r e m o t e _ a d d r ;9 p r o x y _ p a s s h t t p : / / web ;

10 }11

12 l o c a t i o n ~ ^ / a p i {13 p r o x y _ s e t _ h e a d e r Host $ h o s t ;14 p r o x y _ s e t _ h e a d e r X−Real−IP $ r e m o t e _ a d d r ;15 p r o x y _ p a s s h t t p : / / a p i : 8 0 8 0 ;16 }17 }

Quadro C.1: Configurações das aplicações web.

85

Apêndice D

Método FCMPlugin.onNotification - Ionic

Implementação do comportamento desejado ao receber uma notificação na aplicação mó-vel.

1 v a r smchMobile = a n g u l a r . module ( ’ smchMobile ’ , [ ] )2 . run ( f u n c t i o n ( . . . ) {3 FCMPlugin . o n N o t i f i c a t i o n (4 f u n c t i o n ( d a t a ) {5 i f ( d a t a . wasTapped ) {6 / / A d i c i o n a r acao quando a n o t i f i c a c a o f o r p r e s s i o n a d a p e l o

u s u a r i o7 } e l s e {8 / / A d i c i o n a r acao quando a n o t i f i c a c a o nao f o r p r e s s i o n a d a p e l o

u s u a r i o9 }

10 } ,11 f u n c t i o n ( msg ) {12 / / C a l l b a c k i n d i c a n d o que o e v e n t o de o n N o t i f i c a t i o n f o i

r e g i s t r a d o com s u c e s s o .13 } ,14 f u n c t i o n ( e r r ) {15 / / C a l l b a c k i n d i c a n d o que houve um e r r o ao r e g i s t r a r o e v e n t o

de o n N o t i f i c a t i o n .16 }17 ) ;18 } ) ;

87

Apêndice E

Método FCMPlugin.getToken - Ionic

Implementação para o envio do token FCM da aplicação móvel para a API.

1 FCMPlugin . ge tToken (2 f u n c t i o n ( t o k e n ) {3 u s e r . fcmToken = t o k e n ;4 U s e r S e r v i c e . u p d a t e ( u s e r ) . t h e n ( f u n c t i o n ( u s e r ) {5 c o n s o l e . l o g ( ’ t o k e n armazenado ’ ) ;6 } ) ;7 } ,8 f u n c t i o n ( e r r ) {9 a l e r t ( ’ e r r o ao p e g a r token ’ ) ;

10 }11 ) ;

89

Apêndice F

Parecer do comitê de ética da Unioeste

91

UNIOESTE - CENTRO DECIÊNCIAS BIOLÓGICAS E DASAÚDE DA UNIVERSIDADE

PARECER CONSUBSTANCIADO DO CEP

Pesquisador:

Título da Pesquisa:

Instituição Proponente:

Versão:

CAAE:

Sistema de Monitoramento da Saúde Utilizando Wi-Fi e o Protocolo MQTT

Alanna Vanzella

UNIVERSIDADE ESTADUAL DO OESTE DO PARANA

2

83142718.5.0000.0107

Área Temática:

DADOS DO PROJETO DE PESQUISA

Número do Parecer: 2.588.608

DADOS DO PARECER

A presente pesquisa visa apresentar e desenvolver uma arquitetura para um sistema de monitoramento da

saúde. O foco é que a solução seja economicamente acessível, assim como eliminar burocracias para que

de fato qualquer pessoa possa se beneficiar da solução.A fim de validar a arquitetura proposta na presente

pesquisa, serão monitorados os sinais de ECG e de detecção de quedas. Para avaliar a solução de

monitoramento de sinais do ECG serão utilizadas bases de dados públicas. Para testar solução de detecção

de quedas, foram definidos 20 cenários de avaliação, contendo 15 quedas em um colchão inflável e 5

atividades do dia a dia. As simulações devem ser realizadas por no máximo 10 pessoas entre 20 e 35 anos.

Cada cenário deve ser repetido no máximo 3 vezes. Para algoritmos de detecção de quedas, 4 casos são

possíveis:- Verdadeiro positivo (VP): a queda ocorre e o dispositivo a detectou;- Falso positivo (FP): o

dispositivo acusa uma queda, mas ela de fato não ocorreu;- Verdadeiro negativo (VN): uma atividade diária

ocorre, e o dispositivo de fato não detecta uma queda;- Falso negativo (FP): uma queda ocorre, mas o

dispositivo não a detecta. Para avaliar essas 4 situações, são propostos 2 critérios: sensibilidade e

especificidade.

Apresentação do Projeto:

Objetivo principal:

• Desenvolver e validar um sistema de monitoramento de ECG e de queda, voltado para pessoas

Objetivo da Pesquisa:

Financiamento PróprioPatrocinador Principal:

85.819-110

(45)3220-3272 E-mail: [email protected]

Endereço:Bairro: CEP:

Telefone:

UNIVERSITARIAUNIVERSITARIO

UF: Município:PR CASCAVEL

Página 01 de 04


Continuação do Parecer: 2.588.608

que

precisam ser monitoradas por um parente ou responsável;

Objetivos específicos:

• Criar uma arquitetura simplificada, possibilitando o acesso para ambientes familiares, sem depender de

terceiros;

• Comunicar um ECG e um acelerômetro com o ESP8266 (módulo Wi-Fi) e preprocessar os valores;

• Estudar e implementar o protocolo MQTT, permitindo que o ESP8266 envie os dados para um servidor;

• Desenvolver um sistema web que permita a configuração dos dispositivos e apresenta os alertas

detectados de todos os sensores conectados aos ESP8266;

• Desenvolver uma aplicação mobile que permita a visualização dos alertas detectados do paciente

autenticado ou do paciente do responsável autenticado;

• Estudar e desenvolver uma forma de autenticação, de forma a proteger as informações trafegadas entre

os sistemas;

• Realizar testes de consumo do ESP8266.

Os riscos, assim como os benefícios, estão adequadamente descritos.

Riscos:

As simulações de quedas apresentam alguns riscos, sendo eles:

• Queda fora do colchão inflável: podendo ocasionar lesão;

• Colchão inflável estourar: podendo ocasionar lesão;

• Bater no chão através do colchão inflável: podendo ocasionar lesão.

Benefícios:

• Contribuir para o desenvolvimento da solução de monitoramento de sinais vitais.

Avaliação dos Riscos e Benefícios:

Pesquisa de extrema relevância para a área de Engenharias e Ciências da Saúde.

Comentários e Considerações sobre a Pesquisa:

Todos os termos de apresentação obrigatória estão anexados e adequadamente preenchidos.

Considerações sobre os Termos de apresentação obrigatória:

85.819-110



Telefone:



Página 02 de 04



Projeto considerado adequado do ponto de vista ético envolvendo seres humanos de acordo com as

exigências da Resolução 466 de 2012.

Conclusões ou Pendências e Lista de Inadequações:

Este parecer foi elaborado baseado nos documentos abaixo relacionados:

Tipo Documento Arquivo Postagem Autor Situação

Informações Básicasdo Projeto

PB_INFORMAÇÕES_BÁSICAS_DO_PROJETO_1072300.pdf

13/03/201812:53:36

Aceito

Outros carta_resposta.pdf 13/03/201812:53:05

Alanna Vanzella Aceito

Declaração deInstituição eInfraestrutura

ciencia_instituicao2_modificado.pdf 13/03/201811:24:17


Declaração deInstituição eInfraestrutura

ciencia_instituicao_modificado.pdf 13/03/201811:24:05


TCLE / Termos deAssentimento /Justificativa deAusência

tcle_modificado.pdf 13/03/201811:23:29


Folha de Rosto folhaDeRosto_modificado.pdf 13/03/201811:21:22


Projeto Detalhado /BrochuraInvestigador

projeto.pdf 12/02/201818:52:52


Outros declaracao_coleta_nao_iniciada.pdf 09/02/201817:00:18


Declaração dePesquisadores

uso_de_dados2.pdf 09/02/201816:54:23


Declaração dePesquisadores

uso_de_dados.pdf 09/02/201816:54:16


Situação do Parecer:Aprovado

Necessita Apreciação da CONEP:Não

85.819-110



Telefone:



Página 03 de 04



CASCAVEL, 09 de Abril de 2018

Dartel Ferrari de Lima(Coordenador)

Assinado por:

85.819-110



Telefone:



Página 04 de 04

Apêndice G

Arquivo de configuração mosquitto.conf

# =================================================================# C o n f i g u r a c o e s do m o s q u i t t o# =================================================================

# Numero maximo de mensagens a rmazenadas por c l i e n t e quando# u t i l i z a d o q u a l i d a d e de s e r v i c o 1 e 2 .# Padrao = 2 0 . Quando c o n f i g u r a d o em 0 , u t i l i z a −se o v a l o r maximo# Quando c o n f i g u r a d o em 1 , g a r a n t e a ordem de e n t r e g a .m a x _ i n f l i g h t _ m e s s a g e s 0

# Numero maximo de mensagens a serem m a n t i d a s em uma f i l a quando# u t i l i z a d o q u a l i d a d e de s e r v i c o 1 e 2 .# Padrao = 1 0 0 .max_queued_messages 7200

# Armazena as mensagens em d i s c o ( v e r d a d e i r o / f a l s e ) .p e r s i s t e n c e t r u e

97

sistema de detecÇÃo de queda e monitoramento da...

Documents