SML: Uma solução para prevenção da morte súbita infantil. Thiago Fonseca de Souza CENTRO DE INFORMÁTICA UNIVERSIDADE FEDERAL DA PARAÍBA

SML:

Uma solu¸

c˜

ao para preven¸

c˜

ao da morte s´

ubita infantil

Thiago Fonseca de Souza

CENTRO DE INFORM ´ATICA

UNIVERSIDADE FEDERAL DA PARA´IBA

Thiago Fonseca de Souza

SML

Monografia apresentada ao curso Ciˆencia da Computa¸c˜ao do Centro de Inform´atica, da Universidade Federal da Para´ıba, como requisito para a obten¸c˜ao do grau de Bacharel em Ciˆencia da Computa¸c˜ao Orientador: Fernando Menezes Matos

Ficha Catalográfica elaborada por Rogério Ferreira Marques CRB15/690

S719s Souza, Thiago Fonseca de.

SML / Thiago Fonseca de Souza. – João Pessoa, 2017. 41p. : il.

Monografia (Bacharelado em Ciência da Computação) – Universidade Federal da Paraíba - UFPB.

Orientadora: Profº. Dr. Fernando Menezes Matos.

1. Computação. 2. Sistemas embarcados. 3. Síndrome da morte súbita do lactente. I. Título.

DEDICAT ´

ORIA

Dedico este trabalho aos meus pais, Marcus e Adriene e aos meus falecidos av´os, Benjamin e Odaisa.

AGRADECIMENTOS

Agrade¸co primeiramente `a Deus, que tem me sustentado em todos os momentos, me dando for¸cas para n˜ao desistir.

Agrade¸co `a minha fam´ılia por todo apoio e carinho, pelo incetivo e por darem condi¸c˜oes para que eu pudesse progredir.

Agrade¸co `a meu orientador Prof. Dr. Fernando Menezes Matos por ter me aceitado como orientando e pela paciˆencia durante esse per´ıodo.

Agrade¸co aos meus amigos pelo suporte nos momentos dif´ıceis e por compartilhar os momentos alegres.

RESUMO

S´ındrome da morte s´ubita do lactente (SMSL), ´e a principal causa de morte para crian¸cas com idade entre 1 mˆes e 1 ano nos pa´ıses desenvolvidos. Ocorre em situa¸c˜oes em que um bebˆe aparentemente saud´avel morre sem causa aparente. Embora a causa da SMSL ainda seja desconhecida, os pesquisadores est˜ao se concentrando nos padr˜oes de sono infantil, respira¸c˜ao e excita¸c˜ao do sono. Por essa raz˜ao, os pais desenvolvem o h´abito de observar constantemente seus rec´em-nascidos, a fim de verificar a ocorrˆencia de qualquer irregularidade aparente no sono. A fim de auxiliar os pais na tarefa de cuidar dos seus filhos, esse trabalho prop˜oe um sistema embarcado de monitoramento dos sinais vitais dos bebˆes, bem como sua posi¸c˜ao no ber¸co, a fim de fornecer aos pais informa¸c˜oes e alertas acerca da sa´ude da crian¸ca em rela¸c˜ao aos parˆametros associados com a SMSL, especialmente n´ıvel de oxigˆenio no sangue e variabilidade da frequˆencia card´ıaca, que s˜ao fortes indicadores para um diagn´ostico r´apido de asfixia. Foram simuladas e testadas cada uma das situa¸c˜oes que representam perigo `a crian¸ca e, como resultado, o sistema mostrou-se bastante eficiente quanto `a precis˜ao no ato de detec¸c˜ao e alerta de alguma anormalidade.

Palavras-chave: Sistemas embarcados, S´ındrome da morte s´ubita do lactente, Asfixia, SpO2, Frequˆencia card´ıaca.

ABSTRACT

Sudden Infant Death Syndrome (SIDS) is the leading cause of death for children aged 1 month to 1 year in developed countries. It occurs in situations where a seemingly healthy baby dies for no apparent reason. Although the cause of SIDS is still unknown, researchers are focusing on patterns of infant sleep, breathing, and sleep arousal. For this reason, parents develop the habit of constantly observing their newborns in order to verify the occurrence of any apparent irregularity in sleep. In order to assist parents in caring for their children, this work proposes an embedded system for monitoring the vital signs of babies as well as their position in the crib in order to provide parents with information and warnings about Of the baby’s health in relation to the parameters associated with SIDS. Especially blood oxygen level and heart rate variability, which are strong indicators for a rapid diagnosis of asphyxia. Each of the situations that represent a danger to the child was simulated and tested, and as a result, the system proved to be very efficient in the detection and alertness of some abnormality.

Key-words: Embedded systems, Sudden infant death syndrome, Asphyxia, SpO2, Heart rate.

LISTA DE FIGURAS

1 Gr´afico de mortes infantis com causas aparentemente desconhecidas [9] . . 18

2 Triple risk model para SMSL[11] . . . 20

3 Diagrama de um sistema embarcado . . . 21

4 Diagrama de casos de uso . . . 26

5 Diagrama de Blocos . . . 30

6 Diagrama de classes . . . 31

7 Diagrama de sequˆencia . . . 32

8 Configura¸c˜ao do ambiente de testes . . . 35

9 Interface do simulador . . . 36

10 Log para o teste da posi¸c˜ao do bebˆe . . . 37

11 Log para o teste da satura¸c˜ao de oxigˆenio do bebˆe abaixo de 95% . . . 37

12 Log para o teste da satura¸c˜ao de oxigˆenio do bebˆe abaixo de 90% . . . 38

13 Log para o teste da frequˆencia card´ıaca com 80bpm por 30 segundos . . . . 38

LISTA DE TABELAS

1 Requisitos funcionais . . . 25

2 Requisitos n˜ao funcionais . . . 25

3 L´ogica dos sinais de alerta . . . 33

LISTA DE ABREVIATURAS

LUMO – Laborat´orio de computa¸c˜ao M´ovel e Ub´ıqua UML – Unified Modeling Language

SMSL – S´ındrome da Morte S´ubita do Lactente FSR – Force Sensitive Resistor

Sum´

ario

1 INTRODUC¸ ˜AO 15

1.1 Motiva¸c˜ao . . . 15

1.2 Objetivo . . . 16

1.3 Estrutura da monografia . . . 16

2 REVIS ˜AO DA LITERATURA E CONCEITOS GERAIS 17 2.1 Revis˜ao da literatura . . . 17

2.2 Conceitos B´asicos . . . 18

2.2.1 S´ındrome da morte subita do lactente . . . 18

2.2.2 Sistemas embarcados . . . 20

2.2.3 UML . . . 22

3 SISTEMA DE MONITORAMENTO DO LACTENTE 23 3.1 Metodologia . . . 23 3.2 Modelagem . . . 23 3.2.1 Requisitos . . . 24 3.2.2 Casos de uso . . . 24 3.2.3 Diagrama de Blocos . . . 30 3.2.4 Diagrama de Classes . . . 30

3.2.5 Diagrama de Sequˆencia . . . 31

3.3 L´ogica dos Alertas . . . 32

4 IMPLEMENTAC¸ ˜AO E TESTES 34 4.1 Prototipa¸c˜ao e ambiente de teste . . . 34

4.2 Cen´ario de teste e resultados . . . 36

5 CONCLUS ˜OES E TRABALHOS FUTUROS 40

REFERˆENCIAS 40

1

INTRODUC

¸ ˜

AO

A s´ındrome da morte s´ubita do lactente (SMSL), conhecida popularmente como morte do ber¸co, ´e definida como a morte imprevis´ıvel de um bebˆe com menos de um ano aparentemente saud´avel e com uma causa de morte aparentemente obscura, intrigando os especialistas e pais de rec´em-nascidos.

Objeto de estudo nas ´ultimas d´ecadas devido ao crescimento dos recursos m´edicos, bem como o surgimento de estat´ısticas concretas a respeito de uma das maiores causadoras de morte em crian¸cas entre 1 mˆes e 1 ano de idade [4] , as reais causas da s´ındrome ainda continuam sendo pouco conhecidas. Entretanto, pesquisadores afirmam estar no caminho certo ao concentrar seus estudos em fatores pertinentes ao sono e desenvolvimento do bebˆe, o que pode ser comprovado com a diminui¸c˜ao de casos relacionados `a s´ındrome devido a campanhas globais de conscientiza¸c˜ao voltada aos pais das crian¸cas sobre os riscos referentes ao modo em que eles colocam seus filhos para dormir.

Estabelecer uma solu¸c˜ao vi´avel como preven¸c˜ao da s´ındrome ´e necess´ario para que seja poss´ıvel, al´em de reduzir a taxa de mortalidade infantil, trazer tranquilidade aos pais, principalmente para os inexperientes. Neste aspecto, a tecnologia se torna uma im-portante aliada na busca por essa solu¸c˜ao, pois fornece diversas ferramentas de aux´ılio na detec¸c˜ao dos sinais vitais, como a satura¸c˜ao e frequˆencia card´ıaca, apontados pelos pesquisadores como os envolvidos diretamente na causa da morte s´ubita infantil[5], como tamb´em disponibiliza diversas formas de comunica¸c˜ao, capazes de alertar pais e autori-dades m´edicas a respeito das condi¸c˜oes de sa´ude dos filhos enquanto dormem. Dentre as poss´ıveis tecnologias, os sistemas embarcados aparecem como uma ´otima solu¸c˜ao de-vido a sua praticidade em “isolar” um determinado conjunto de tarefas e direcion´a-las na atua¸c˜ao de algum problema particular. Sua capacidade de processamento abre novas fronteiras na cria¸c˜ao de sistemas mais robustos e eficientes, capazes de serem inseridos em qualquer ambiente.

O maior desafio para desenvolver essa solu¸c˜ao ´e realizar a integra¸c˜ao entre um hardware que possa coletar os dados e o software respons´avel pelo processamento des-ses dados, al´em de definir quais condi¸c˜oes s˜ao realmente importantes e que devem ser exploradas a fim de atingir o objetivo de alertar poss´ıveis situa¸c˜oes de risco.

1.1 Motiva¸c˜ao

Para os pais, a sa´ude de seu rec´em-nascido ´e de extrema importˆancia, por isso todo zelo torna-se necess´ario. Portanto, ´e comum que eles monitorarem o sono de seus bebˆes por meio de visitas frequentes ao quarto da crian¸ca ou, at´e mesmo, para aqueles com maior poder aquisitivo, optam pelas bab´as eletrˆonicas. Por´em, nenhumas dessas solu¸c˜oes

amenizam a apreens˜ao dos pais. O quanto seria ´util um sistema que pudesse informar, em tempo real, informa¸c˜oes vitais de seu bebˆe e que alertas sejam gerados caso ocorra qualquer sinal de problema, trazendo seguran¸ca e devolvendo as noites de sono perdidas durante as visitas de rotina.

1.2 Objetivo

O objetivo desse trabalho ´e propor e criar um prot´otipo de um sistema embar-cado de monitoramento do sono de um rec´em-nascido com a finalidade de preven¸c˜ao da s´ındrome de morte s´ubita do lactente por meio de alertas gerados aos respons´aveis do bebˆe causados por alguma anormalidade detectada pelo sistema.

O sistema ser´a capaz de enviar distintos alertas a diferentes respons´aveis de acordo com o grau de urgˆencia da situa¸c˜ao. Ele tamb´em ser´a capaz de disparar alertas sonoros com objetivo de acordar a crian¸ca. Para garantir a sua confiabilidade, ´e necess´ario desen-volver um simulador que possa suprir o sistema com dados que possam imitar condi¸c˜oes encontradas em ambientes reais, simulando diferentes situa¸c˜oes de risco e analisando se o sistema toma as decis˜oes corretamente.

1.3 Estrutura da monografia

Esta monografia est´a dividida da seguinte maneira: no Cap´ıtulo 2 ´e feita a apre-senta¸c˜ao dos conceitos chaves utilizados para o desenvolvimento do sistema. No Cap´ıtulo 3 ´e apresentado o modelo de especifica¸c˜ao do sistema e seu funcionamento. No Cap´ıtulo 4 s˜ao discutidas a apresenta¸c˜ao, cen´arios de testes e seus resultados. Finalmente, no Cap´ıtulo 5 ´e feita a conclus˜ao do trabalho.

2

REVIS ˜

AO DA LITERATURA E CONCEITOS GERAIS

2.1 Revis˜ao da literatura

A sa´ude do rec´em-nascido ´e de extrema importˆancia, ainda mais quando problemas como a s´ındrome da morte s´ubita afligem os pais. Devido `a seriedade deste problema algumas empresas desenvolveram solu¸c˜oes com objetivo de trazer tranquilidade para os pais dos rec´em-nascidos.

O Owlet Smart Sock [1] ´e uma solu¸c˜ao que utiliza a tecnologia de oximetria de pulso para “alertar se seu bebˆe para de respirar”. O produto consiste em uma meia inteligente que verifica a frequˆencia card´ıaca e o n´ıvel de oxigena¸c˜ao do sangue do bebˆe enquanto ele dorme. Essas informa¸c˜oes s˜ao enviadas via bluetooth para uma esta¸c˜ao base localizada no quarto dos pais, que por sua vez envia os dados em tempo para um aplicativo m´ovel. A esta¸c˜ao base tamb´em funciona como um dispositivo de alerta, gerando sinais luminosos e alertas sonoros caso os n´ıveis coletados sejam mais altos ou inferiores aos n´ıveis predefinidos. No aplicativo m´ovel os pais tˆem acesso a an´alises do sono do bebˆe e tamb´em podem visualizar o hist´orico dos dados coletados pela meia.

Outra solu¸c˜ao ´e o Snuza Pico [2], um dispositivo que monitora a respira¸c˜R ao do

bebˆe enquanto ele dorme. Al´em disso, ele ´e capaz de monitorar a frequˆencia card´ıaca, a temperatura da pele e alertar caso a crian¸ca caia de alguma altura. Conectado na fralda do rec´em-nascido, ele se baseia no movimento que a respira¸c˜ao provoca na barriga do mesmo. Caso o dispositivo n˜ao detecte nenhuma respira¸c˜ao por 15 segundos, ele vibrar´a na tentativa de acordar o bebˆe. Caso a tentativa tenha surtido efeito, o sistema retorna para fun¸c˜ao de monitoramento. Se a vibra¸c˜ao n˜ao surtir efeito depois de 5 segundos o dispositivo dispara um alerta sonoro. Os pais podem ter acesso `as informa¸c˜oes de temperatura e frequˆencia card´ıaca por meio de um aplicativo m´ovel que se comunica via bluetooth com o dispositivo.

O Angelcare Ac1100 [3] ´e uma bab´a eletrˆonica que transmite imagens e possui microfone e alto-falante para os pais escutarem a crian¸ca. Al´em disso, o sistema conta com um sensor de movimento (com n´ıveis de ajuste de sensibilidade) que ´e posicionado debaixo do colch˜ao do rec´em-nascido e detecta at´e mesmo a mais suave respira¸c˜ao da crian¸ca. Um alarme ´e disparado com o objetivo de tentar acordar a crian¸ca caso o sensor n˜ao detecte movimento por 20 segundos.

As solu¸c˜oes apresentadas, apesar de serem produtos comercializados, n˜ao disp˜oem de todas as ferramentas que auxiliam na preven¸c˜ao da s´ındrome, como por exemplo, algum meio de descobrir se o bebˆe est´a dormindo com barriga para baixo. Fator diretamente ligado ao surgimento da s´ındrome [4].

2.2 Conceitos B´asicos

2.2.1 S´ındrome da morte subita do lactente

A s´ındrome de morte s´ubita do lactente, ou SMSL, ´e definida como “a morte s´ubita de uma crian¸ca com menos de um ano de idade, que permanece inexplic´avel ap´os uma investiga¸c˜ao minuciosa, incluindo a realiza¸c˜ao de uma aut´opsia completa, o exame do local da morte e a revis˜ao do hist´orico cl´ınico” [6]. N˜ao ´e tratada como uma doen¸ca espec´ıfica, mas, sim um diagn´ostico que os m´edicos d˜ao quando um bebˆe saud´avel morre durante o sono e sem nenhuma raz˜ao aparente. Seu diagnostico ´e feito pela exclus˜ao de outras poss´ıveis causas atrav´es de um exame p´os-´obito, com a necropsia devendo ser feita por algum patologista pedi´atrico e seguindo o protocolo recomendado pela SIDS International [7]. Apesar dos reais motivos que causam a SMSL sejam desconhecidos, ao longo dos anos, pesquisadores est˜ao se concentrando nos padr˜oes de sono infantil, respira¸c˜ao e excita¸c˜ao do sono como principais fatores causadores.

Em pa´ıses desenvolvidos, como os Estados Unidos, onde a SMSL ´e a maior causa de mortalidade infantil e onde, aproximadamente 1.600 rec´em-nascidos morreram em decorrˆencia da s´ındrome apenas em 2015 [8], j´a ´e unanime a ideia de que deitar o rec´ em-nascido de bru¸cos triplica o risco de SMSL. A American Academy Pediatrics (AAP) encabe¸caram diversas campanhas a partir de 1992 com o objetivo de conscientizar os pais para que eles posicionassem os bebˆes de barriga para cima (posi¸c˜ao supina) na hora de dormir, pois as crian¸cas que dormem com barriga voltada para baixo podem ter mais dificuldade em respirar do que aquelas posicionadas adequadamente com a barriga para cima [4]. Com apenas esse cuidado simples, pesquisas informam que o n´umero de ´obitos relacionados `a s´ındrome diminuiu em mais de 50% [9] desde que tais campanhas entraram em vigor, como mostra a Figura 1.

Figura 1: Gr´afico de mortes infantis com causas aparentemente desconhecidas [9]

Diversos problemas podem ser relacionados com a posi¸c˜ao em que o lactente dorme e que s˜ao capazes de disparar a s´ındrome, como por exemplo: (i) asfixia por compress˜ao das vias a´ereas ou inala¸c˜ao excessiva do g´as carbˆonico exalado na posi¸c˜ao com a face do bebˆe para baixo; (ii) hipertermia, que ´e o aumento da temperatura corporal causada pela compress˜ao da face contra o travesseiro ou colch˜ao, causada pelo fato que a face da crian¸ca ´

e considerada uma grande fonte de dissipa¸c˜ao de calor, e portanto, uma vez obstru´ıda, a temperatura corporal ´e elevada.

Segundo especialistas, as mortes causadas pela s´ındrome da morte s´ubita ocorrem com maior frequˆencia no inverno embora o frio n˜ao esteja relacionado aos casos, o que pode ser explicado pelo fato de justamente nessa esta¸c˜ao do ano em que os pais costumam agasalhar mais seus filhos. O uso excessivo de agasalhos e cobertores no combate a esse frio acaba expondo os bebˆes a um risco maior, pois aumentam a temperatura corporal no momento em que o mecanismo para regular rapidamente a temperatura do bebˆe n˜ao est´a totalmente desenvolvido. Nesta situa¸c˜ao, o estresse causado pelo aumento da temperatura leva a diminui¸c˜ao da frequˆencia card´ıaca e inibi¸c˜ao letal do centro respirat´orio.

Al´em disso, dormir em superf´ıcies excessivamente macias ou rodeada por almofadas configura um risco pelo fato que bebˆes mais novos n˜ao possuem autonomia sobre seus movimentos. Caso algum dos itens citados anteriormente cubram seu nariz ou boca, eles n˜ao conseguem livrar-se sozinhos.N˜ao obstante, o compartilhamento da cama entre pais e rec´em-nascidos n˜ao ´e aconselh´avel uma vez que pode criar superf´ıcies irregulares que podem impedir a respira¸c˜ao normal da crian¸ca.

Para organizar o conhecimento atual sobre as origens da SMSL, foi proposto o ”triple risk model ”[10]. Este modelo, que ´e considerado multifatorial (Figura 2), prop˜oe que a SMSL ocorre quando trˆes fatores coincidem: a crian¸ca ´e vulner´avel, est´a no per´ıodo de desenvolvimento cr´ıtico no controle homeost´atico e h´a um estressor ex´ogeno. Acredita-se que a determina¸c˜ao final da SMSL envolva um controle autonˆomico cardiorrespirat´orio imaturo, juntamente com uma falha na capacidade de resposta `a excita¸c˜ao do sono.

Em rela¸c˜ao `as crian¸cas vulner´aveis, v´arios estudos indicam que as v´ıtimas de SMSL apresentam anormalidades na fun¸c˜ao neurol´ogica [12], controle autˆonomo [13], organiza¸c˜ao do estado de sono e fun¸c˜ao respirat´oria [5]. A exposi¸c˜ao pr´e-natal `a fuma¸ca de cigarros tamb´em aumenta a vulnerabilidade a SMSL, uma vez que se sugere que o ta-bagismo possa alterar o controle autonˆomico. O baixo peso ao nascer e a prematuridade est˜ao associados ao tabagismo dos pais e s˜ao tamb´em fatores de risco que podem afetar o controle cardiovascular em bebˆes.

O per´ıodo de desenvolvimento cr´ıtico corresponde aos primeiros 6 meses ap´os o nascimento [14], quando ocorrem importantes mudan¸cas fisiol´ogicas e matura¸c˜ao r´apida do c´erebro, sistema cardiorrespirat´orio e organiza¸c˜ao do estado de sono. Mais de 90% das

Figura 2: Triple risk model para SMSL[11]

mortes por SMSL ocorrem nesse per´ıodo, com um pico de incidˆencia ocorrendo entre 2 e 4 meses de idade.

O terceiro fator, o que pode ser convenientemente gerenciado pelos pais, desem-penha um papel crucial no caso de SMSL. Estressores ex´ogenos, como priva¸c˜ao de sono, posi¸c˜ao de sono propensa, cobertura de cabe¸ca, superaquecimento e infec¸c˜oes s˜ao extre-mamente perigosos quando sobrepostos com bebˆes vulner´aveis durante um per´ıodo de desenvolvimento cr´ıtico.

2.2.2 Sistemas embarcados

Um sistema embarcado ´e descrito como uma combina¸c˜ao entre hardware e software projetado para execu¸c˜ao de uma funcionalidade espec´ıfica [15]. Em outras palavras, inserir capacidade computacional dentro de um circuito integrado com o objetivo de criar um sistema completo e independente que atua sobre algum problema em particular.

A presen¸ca de sistemas embarcados tem crescido bastante nos ´ultimos anos, com aplica¸c˜oes variando de ´areas industriais at´e entretenimento, sendo considerados indis-pens´aveis nos dias atuais. Dados mostram que esse tipo de sistema j´a ´e considerado o maior uso da computa¸c˜ao no mundo, ultrapassando o n´umero de PCs, notebooks e outros computadores de prop´osito geral. Algumas de suas caracter´ısticas envolvem:

• Baixo consumo de energia: por serem considerados sistemas de opera¸c˜oes especificas seu custo de energia pode ser otimizado.

• Sistemas port´ateis: possuem tamanho e peso reduzidos. 20

• Baixo custo de produ¸c˜ao: processadores utilizados nesses sistemas podem custar menos de 1 d´olar.

O uso de sistemas embarcados pode ser dividido em quatro tipos de aplica¸c˜oes, podendo ser [16]:

• Prop´osito geral: costumam possuir maior intera¸c˜ao entre o sistema e usu´ario, como por exemplo: os televisores digitais, videogames, caixas eletrˆonicos, PDAs.

• Sistemas de controle: fornecem pouca intera¸c˜ao com o usu´ario, entretanto possuem maior robustez e geralmente s˜ao compostas por diversos sensores, como por exemplo, controle veicular e reator nuclear.

• Processamento de sinais: envolvem uma quantidade enorme de dados que necessitam ser processados em pouco espa¸co de tempo, por exemplo, radares, aparelhos dvd, reprodutores de som.

• Comunica¸c˜ao: respons´aveis pela distribui¸c˜ao de informa¸c˜ao, como sistemas de in-ternet e telefonia.

O funcionamento de um sistema embarcado pode ser pensado como um conjunto de entradas coletadas por sensores dispostos em um ambiente. Ap´os a coleta, essas entradas s˜ao enviadas ao n´ucleo respons´avel por todo o processamento e ent˜ao a partir dai s˜ao definidas quais tarefas ser˜ao executadas. A Figura 3 ilustra este modelo.

Figura 3: Diagrama de um sistema embarcado

Sensores s˜ao dispositivos que detectam eventos ou altera¸c˜oes no ambiente, gerando sinais el´etricos anal´ogicos que s˜ao convertidos para dados digitais e processados pela CPU do sistema. Ap´os esse processo os dados obtidos poder˜ao ser utilizados para realiza¸c˜ao

de algumas tarefas. Tais tarefas podem ser executadas por algum atuador no ambiente. Para isso, o sistema deve converter novamente esses dados digitais para anal´ogicos para que o atuador possa interpretar qual fun¸c˜ao desempenhar´a.

2.2.3 UML

UML ´e uma sigla para a express˜ao Unified Modeling Language, que em sua tradu¸c˜ao livre significa Linguagem de Modelagem Unificada. Na realidade que vivemos hoje, ´e not´avel a dependˆencia dos softwares, tanto no ˆambito profissional quanto no pessoal e tal linguagem tem se tornado quase que indispens´avel na elabora¸c˜ao de projetos de software. Conhecida como uma linguagem que une uma s´erie de pr´aticas e pode ajudar na documenta¸c˜ao e modelagem durante o processo de desenvolvimento de software, ela permite fazer um “esbo¸co” do seu sistema para garantir uma melhor clareza ao longo do processo de constru¸c˜ao do projeto. Seu objetivo ´e aprimorar as etapas que envolvem o desenvolvimento do projeto, consequentemente, aumentado a produtividade e qualidade do produto desenvolvido.

As descri¸c˜oes das funcionalidades do sistema s˜ao conhecidas como os requisitos, po-dendo ser os requisitos funcionais e n˜ao funcionais. Os requisitos funcionais indicam quais servi¸cos o sistema deve fornecer, determinam modos de agir para um conjunto de entra-das, como ele deve se comportar em determinadas situa¸c˜oes. Os requisitos n˜ao funcionais levantam qualidades do produto, como desempenho, confiabilidade e usabilidade. Eles delimitam as quest˜oes referentes `as restri¸c˜oes das fun¸c˜oes disponibilizadas pelo sistema.

Os elementos UML s˜ao na maioria representa¸c˜oes gr´aficas e que s˜ao usados para criar diagramas que representam cada parte do sistema. Os principais diagramas s˜ao [17]: O diagrama de casos de uso demonstra o que o sistema realiza no ponto de vista dos atores participantes no processo. Ele explica as funcionalidades prim´arias do sistema e tem o intuito de auxiliar na comunica¸c˜ao entre clientes e analistas. Tal diagrama n˜ao tem n˜ao foca na parte t´ecnica do sistema, mas ´e uma parte te´orica de grande importˆancia. O diagrama de sequˆencia nos mostra o que ocorre nos objetos participantes e como os objetos se comunicam enviando mensagens uns aos outros durante a execu¸c˜ao de uma a¸c˜ao. Na estrutura de um diagrama de sequˆencia podemos visualizar exatamente a ordem e os momentos em que essas mensagens s˜ao enviadas para os objetos.

O diagrama de classes ´e fundamental e o mais utilizado, ele tem como objetivo principal representar os objetos no sistema e como eles se relacionam. Esse diagrama descreve a estrutura est´atica do sistema, pois mostram as classes com compostas por seus m´etodos e atributos, assim como qual classe faz parte de outra classe ou quais classes se relacionam entre si.

3

SISTEMA DE MONITORAMENTO DO LACTENTE

O Sistema de Monitoramento do Lactente ´e uma solu¸c˜ao integrada de hardware e software desenvolvida em parceria com o aluno Emerson Braga. O objetivo deste trabalho ´

e o desenvolvimento do software que executa em um sistema embarcado. Entretando, o SML tamb´em ´e composto por um aplicativo m´ovel e um sistema web desenvolvido pelo aluno Emerson Braga.

Neste cap´ıtulo ser´a apresentado o m´etodo utilizado para o desenvolvimento do sistema, como foi feita a sua modelagem e uma descri¸c˜ao de como foi feita a sua l´ogica de alertas.

3.1 Metodologia

Para uma melhor elabora¸c˜ao do projeto a metodologia se deu a partir de uma pesquisa bibliogr´afica em artigos m´edicos a respeito da s´ındrome da morte s´ubita do lactente, com o objetivo de entender os principais fatores que favorecem o surgimento da s´ındrome. Al´em disso, uma entrevista foi realizada com uma m´edica pediatra especialista nessa causa de morte. Foram discutidos o que a medicina tem feito para prevenir tal acontecimento e quais seriam as poss´ıveis solu¸c˜oes para o problema.

Com o entendimento do problema a partir do levantamento bibliogr´afico e com o auxilio da especialista, a especifica¸c˜ao do sistema foi iniciada e uma ideia de como o sistema a ser desenvolvido deveria se comportar foi definida. Foi feita uma pesquisa de produtos dispon´ıveis no mercado para uma familiariza¸c˜ao do que j´a havia sido desenvol-vido e quais funcionalidades apresentavam. Por fim, se seguiu com a modelagem e cria¸c˜ao de um prot´otipo para o sistema. Testes foram feitos com a finalidade de avaliar suas funcionalidades.

3.2 Modelagem

O SML tem como objetivo a preven¸c˜ao da morte s´ubita do lactente. Seu funci-onamento se d´a a partir do uso de dois sensores (ox´ımetro e Force Sensitive Sensor ) e um alto-falante conectados a uma placa Intel Galileo Gen 2. O ox´ımetro abastece oR

sistema com dados referentes `a satura¸c˜ao de oxigˆenio e frequˆencia card´ıaca. Podendo ser colocado em qualquer parte translucida do corpo do rec´em-nascido, como o dado da m˜ao ou do p´e. O Force Sensitive Sensor ´e colocado na parte do peito da roupa da crian¸ca e ´e utilizado para detectar (por meio da press˜ao exercida sobre ele) a posi¸c˜ao em que o bebˆe est´a deitado.

O sistema pode conectar-se com qualquer aplicativo ou sistema que aceite cha-madas remotas, enviando os dados dos sinais vitais da crian¸ca para que os pais possam

acompanha-los em tempo real. Alertas s˜ao gerados e enviados para o aplicativo ao de-tectar alguma mudan¸ca nos parˆametros monitorados pelos sensores, que s˜ao satura¸c˜ao de oxigˆenio, frequˆencia card´ıaca e posi¸c˜ao pronada do bebˆe. Em situa¸c˜oes mais cr´ıticas, o sistema dispara um alerta sonoro como uma tentativa de acordar o lactente, al´em de conectar-se com servi¸cos providos por autoridades de sa´ude com a finalidade de buscar um atendimento r´apido. O sistema tamb´em permite o armazenamento de informa¸c˜oes sobre a crian¸ca e os respons´aveis para que sejam identificados mais facilmente pelos servi¸cos de urgˆencia. ´E importante ressaltar que o foco no trabalho ´e na proposta do sistema embarcado. Desta forma, ´e assumido que existir´a um aplicativo e/ou sistema de sa´ude j´a dispon´ıvel para acesso aos dados.

3.2.1 Requisitos

Alguns requisitos foram levantados com o intuito de definir os objetivos e restri¸c˜oes que limitam o escopo do sistema. Na Tabela 1 s˜ao apresentados os requisitos funcionais que expressam as funcionalidades esperadas, seja atrav´es de comandos de usu´arios ou pela ocorrˆencia de eventos internos e externos. Na Tabela 2 pode-se encontrar os requisitos n˜ao funcionais que apresentam as qualidades desejadas de desempenho e restri¸c˜oes de projeto.

3.2.2 Casos de uso

O diagrama de casos de uso representado na Figura 4 mostra todas as fun¸c˜oes que o sistema precisa desempenhar, destacando a atua¸c˜ao de cada ator em cada uma dessas fun¸c˜oes. Os casos de uso tamb´em ser˜ao descritos de maneira textual com a inten¸c˜ao de explica-los com mais clareza.

Tabela 1: Requisitos funcionais Requisitos Descri¸c˜ao

RF001 O sistema deve ser capaz de receber dados de frequˆencia card´ıaca e concentra¸c˜ao de oxigˆenio do ox´ımetro, al´em dos dados do sensor de press˜ao.

RF002 O sistema deve armazenar em um intervalo de tempo definido, valores m´ınimo, m´edio e m´aximo de frequˆencia card´ıaca e concentra¸c˜ao de oxigˆenio.

RF003 O sistema deve ser capaz de monitorar em tempo real os dados de frequˆencia card´ıaca e concentra¸c˜ao de oxigˆenio do ox´ımetro.

RF004 O sistema deve transmitir alerta para aplicativo m´ovel. RF005 O sistema deve transmitir alerta para autoridades de sa´ude.

RF006 O sistema deve ser capaz de alertar mudan¸cas no n´ıvel de SpO2 que estejam fora dos padr˜oes.

RF007 O sistema deve ser capaz de alertar mudan¸cas na frequˆencia card´ıaca que estejam fora dos padr˜oes.

RF008 O sistema deve ser capaz de alertar mudan¸cas na posi¸c˜ao do bebˆe. RF009 O sistema deve permitir o cadastro dos dados do rec´em-nascido. RF010 O sistema deve permitir a edi¸c˜ao dos dados do rec´em-nascido. RF011 O sistema deve permitir o cadastro dos dados do respons´avel. RF012 O sistema deve permitir a edi¸c˜ao dos dados do respons´avel. RF013 O sistema dever´a fornecer relat´orio dos dados armazenados.

RF014 O sistema deve ser capaz de interromper, remotamente, o alerta sonoro.

Tabela 2: Requisitos n˜ao funcionais Requisitos Descri¸c˜ao

RNF001 O sistema deve transmitir dados em tempo real.

RNF002 O sistema deve ser compat´ıvel com ox´ımetros que utilizam o padr˜ao IEEE 11073-10404 Pulse Oximeter Specialization Standard.

Figura 4: Diagrama de casos de uso

UC01 – Monitora dados

• Descri¸c˜ao do UC: Este caso de uso descreve como o sistema monitora, a cada se-gundo, os dados coletados pelos sensores.

• Atores: Bebˆe

• Requisitos: RF001, RF003 • Prioridade: Alta

• Pr´e-condi¸c˜oes

1. Os sensores do sistema devem estar conectados ao bebˆe. • Fluxo principal

1. O sistema recebe valores referentes `a satura¸c˜ao de oxigˆenio e frequˆencia card´ıaca do bebˆe.

2. O sistema recebe valores referentes a posi¸c˜ao do bebˆe.

UC02 – Cadastra dados

• Descri¸c˜ao do UC: Este caso de uso descreve como o usu´ario deve agir para cadastrar os dados por meio de um aplicativo m´ovel.

• Atores: Pai

• Requisitos: RF009, RF011 • Prioridade – M´edia

• Pr´e-condi¸c˜oes

1. O pai precisa estar conectado ao sistema por meio de um dispositivo m´ovel. • Fluxo principal

1. O pai insere as informa¸c˜oes de cadastro no dispositivo m´ovel. 2. O pai finaliza o cadastro.

3. O dispositivo m´ovel envia os dados do cadastro para o sistema.

UC03 – Alerta n´ıvel de oxigˆenio

• Descri¸c˜ao do UC: Este caso de uso descreve como o sistema alerta quando a taxa de satura¸c˜ao de oxigˆenio est´a abaixo do normal.

• Atores: Sistema

• Requisitos: RF001, RF003, RF004, RF005, RF006 • Prioridade: Alta

• Pr´e-condi¸c˜oes

1. O sistema precisa estar conectado com o dispositivo m´ovel. • Fluxo principal

1. Sistema verifica se os valores dos dados coletados (UC01) referentes a satura¸c˜ao de oxigˆenio s˜ao inferiores a 95% (Fluxo Alternativo A - Valores coletados sˆao inferiores a 90%).

2. Alerta ´e enviado para o pai. • Fluxo Alternativo

Fluxo Alternativo A - Valores coletados sˆao inferiores a 90%. 1. Alerta ´e enviado para autoridade de sa´ude.

2. Alerta de som ´e disparado.

3. Retorna ao passo 2 do fluxo principal.

UC04 – Alerta n´ıvel de frequˆencia card´ıaca

• Descri¸c˜ao do UC: Este caso de uso descreve como o sistema alerta quando frequˆencia card´ıaca est´a abaixo de 80bpm por um determinado per´ıodo de tempo.

• Atores: Sistema

• Requisitos: RF001, RF003, RF004, RF005, RF007 • Prioridade: Alta

• Pr´e-condi¸c˜oes

1. O sistema precisa estar conectado com o dispositivo m´ovel. • Fluxo principal

1. Sistema verifica se os valores dos dados coletados (UC01) referentes `a frequˆencia card´ıaca s˜ao inferiores a 80bpm.

2. Sistema verifica se os valores dos dados coletados persistem abaixo de 80bpm por 30 segundos ou mais (Fluxo Alternativo A - Valores coletados persistem abaixo de 80bpm por 60 segundos ou mais).

3. Alerta ´e enviado para o pai. • Fluxo Alternativo

Fluxo Alternativo A - Valores coletados persistem abaixo de 80bpm por 60 segundos ou mais.

1. Alerta ´e enviado para autoridade de sa´ude. 2. Alerta de som ´e disparado.

3. Retorna ao passo 3 do fluxo principal.

UC05 – Alerta posi¸c˜ao pronada

• Descri¸c˜ao do UC: Este caso de uso descreve como o sistema alerta quando o bebˆe est´a deitado com a barriga para baixo.

• Atores: Sistema

• Requisitos: RF004, RF003, RF008 • Prioridade: Alta

• Pr´e-condi¸c˜oes

1. O sistema deve possuir os dados referentes `a posi¸c˜ao atual do bebˆe. 2. O sistema precisa estar conectado com o dispositivo m´ovel.

• Fluxo principal

1. Sistema verifica se o valor referente a posi¸c˜ao atual do bebˆe indica que ele se encontra em posi¸c˜ao prona.

2. Alerta ´e enviado para o pai.

UC06 – Gera relat´orio

• Descri¸c˜ao do UC: Este caso de uso descreve como o sistema envia um relat´orio requisitado pelo aplicativo m´ovel.

• Atores: Sistema, Pai • Requisitos: RF002, RF013 • Prioridade: Baixa

• Pr´e-condi¸c˜oes

1. O sistema deve possuir um banco de dados contendo dados coletados. 2. O pai precisa estar conectado ao sistema por meio de um dispositivo m´ovel. • Fluxo principal

1. Aplicativo m´ovel requisita do sistema um relat´orio de dados coletados em de-terminado per´ıodo de tempo.

2. Sistema acessa o banco de dados. 3. Sistema gera relat´orio.

4. Relat´orio ´e enviado ao pai.

3.2.3 Diagrama de Blocos

Embora n˜ao fa¸ca parte do conjunto de diagramas da UML, ele ´e bastante utilizado para especificar sistemas embarcados, pois da uma vis˜ao geral de como o sistema ´e divi-dido. A Figura 5 mostra o diagrama de blocos relativo ao software e hardware do projeto. Sensor Manager ´e respons´avel por conectar e receber dados com os sensores (ox´ımetro e FSR) e envia-los para o Business Manager. O Business Manager interpreta os dados e os passa para o Persistence Manager armazena-los em um banco de dados. O Business Manager processa a l´ogica que enviar´a os alertas atrav´es do Connection Manager para um aplicativo m´ovel ou autoridade de sa´ude. Al´em disso, ele comanda o sinal de alerta sonoro atrav´es de uma interface de som.

Figura 5: Diagrama de Blocos

3.2.4 Diagrama de Classes

O diagrama de classes apresentado na Figura 6 representa uma vis˜ao geral das classes envolvidas na ferramenta e como elas se relacionam. A classe DataManager tem a fun¸c˜ao de estabelecer uma conex˜ao com o aplicativo m´ovel. A classe DataSender ´e respons´avel pelo o envio os dados para o aplicativo m´ovel. O papel da classe RulesHandler ´

e identificar qual alerta ser´a executado. A classe DataRetriever ´e respons´avel por receber e tratar os dados coletados dos sensores. A classe DataBaseManager tem a finalidade de armazenar e consultar dados tratados em um banco de dados. A classe EchoService ´e respons´avel pelas opera¸c˜oes de requisi¸c˜ao de relat´orio e gera¸c˜ao de alertas para os servi¸cos disponibilizados pelas autoridades de sa´ude.

Figura 6: Diagrama de classes

3.2.5 Diagrama de Sequˆencia

O diagrama de sequˆencia apresentado na Figura 7 tem como objetivo demonstrar como ocorre o fluxo para gera¸c˜ao de um alerta. O DataRetriever envia os dados coletados pelos sensores para o RuleHandler, que identifica qual alerta (cr´ıtico ou n˜ao cr´ıtico) deve ser emitido caso ocorra situa¸c˜oes onde determinados limites de oxigena¸c˜ao ou batimentos card´ıacos sejam ultrapassados, ent˜ao alertas s˜ao disparados pelo DataSender para um aplicativo ou autoridade de sa´ude.

Figura 7: Diagrama de sequˆencia

3.3 L´ogica dos Alertas

Como o objetivo principal desse sistema ´e reportar anormalidades referentes aos sinais vitais do rec´em-nascido e que podem indicar um principio da SMSL, ´e necess´ario identificar em quais situa¸c˜oes se faz necess´ario um alerta e definir quais a¸c˜oes dever˜ao ser tomadas a partir dessa situa¸c˜ao.

Primeiro foram definidos os atores externos os quais s˜ao os alvos desses alertas. Como primeiro alvo o sistema deve informar aos pais da crian¸ca por meio de aplicativo m´ovel. Outra a¸c˜ao importante que o sistema deve tomar ´e notificar o Servi¸co de Sa´ude ou algum m´edico respons´avel, caso algum n´ıvel cr´ıtico seja atingido e seja necess´ario um r´apido atendimento especializado.

O primeiro alerta refere-se `a posi¸c˜ao do bebˆe no ber¸co. Esse alerta deve ser acio-nado quando a crian¸ca esta com a barriga voltada para baixo e n˜ao na posi¸c˜ao indicada pelos especialistas [4]. Como esse alerta ´e considerado n˜ao critico por n˜ao trazer s´erios riscos `a sa´ude do lactente, o sistema apenas deve enviar uma notifica¸c˜ao ao aplicativo m´ovel dos pais para que a crian¸ca seja reposicionada corretamente.

Como j´a foi apresentado na se¸c˜ao 2.1, outro importante fator de risco diz respeito ao n´ıvel de satura¸c˜ao de oxigˆenio no sangue, pois pode indicar diretamente o in´ıcio da hip´oxia e a falta de oxigena¸c˜ao tecidual. Dever˜ao existir dois tipos de alertas referentes a esse fator de risco, sendo que o primeiro deve ocorrer quando esse n´ıvel estiver abaixo de 95%, o que gera um alerta aos pais da crian¸ca como um sinal de alguma situa¸c˜ao que exige aten¸c˜ao. O segundo tipo de alerta deve ocorrer quando o n´ıvel de oxigena¸c˜ao alcan¸car valores abaixo de 90%, o que sugere uma poss´ıvel asfixia. Por ser um n´ıvel

alarmante, o sistema deve alertar n˜ao somente aos pais, mas tamb´em deve gerar o alerta para autoridades m´edicas.

Considerando que a frequˆencia card´ıaca normal para lactentes com menos de 1 ano pode variar entre 120 a 160 bpm [18], alertas sobre este parˆametro tamb´em devem ser con-templados. Tipicamente, quando os bebˆes est˜ao sofrendo asfixia, sua frequˆencia card´ıaca diminui, e o risco surge quando eles n˜ao tˆem uma resposta ativa a essa condi¸c˜ao [4]. A excita¸c˜ao do sono ´e o foco aqui, pois ´e desej´avel que os bebˆes demonstrem uma rea¸c˜ao `a asfixia e n˜ao apenas continuem sofrendo com ela, sendo considerada uma resposta essen-cial a um evento potenessen-cialmente fatal, como apneia prolongada ou hipotens˜ao. Portanto, tamb´em dever˜ao existir dois tipos de alertas para essa condi¸c˜ao: o primeiro deve ocorrer quando a frequˆencia card´ıaca estiver abaixo de 80 bpm por um per´ıodo de 30 segundos. Como o tempo ´e considerado relativamente curto, o sistema deve alertar somente aos pais do lactente. O segundo deve ocorrer quando a frequˆencia card´ıaca estiver abaixo de 80 bpm por um per´ıodo de 1 minuto, um tempo considerado suficiente para gerar um alerta n˜ao somente aos pais, mas tamb´em para as autoridades m´edicas.

Pelos motivos citados a respeito da rea¸c˜ao do bebˆe `a asfixia, deve ser inclu´ıdo um alerta sonoro quando os parˆametros sugerirem que a crian¸ca est´a em estado critico [19], pois tais sinais sonoros provocam uma rea¸c˜ao que estimula os centros respirat´orios e a frequˆencia card´ıaca, aumentando a ventila¸c˜ao pulmonar e consequentemente o n´ıvel de oxigˆenio no sangue [20].A Tabela 3 sumariza os alertas mencionados.

Tabela 3: L´ogica dos sinais de alerta

Alertas Condi¸c˜oes Alertar App Alertar autoridade de sa´ude

Disparar alerta sonoro 1 Bebˆe deitado de bru¸cos Sim N˜ao N˜ao 2 SpO2 <95% Sim N˜ao N˜ao

3 SpO2 <90% Sim Sim Sim

4 Frequˆencia card´ıaca <80bpm

por 30 segundos Sim N˜ao N˜ao 5 Frequˆencia card´ıaca <80bpm

por 60 segundos Sim Sim Sim

4

IMPLEMENTAC

¸ ˜

AO E TESTES

4.1 Prototipa¸c˜ao e ambiente de teste

Um prot´otipo do SML foi desenvolvido tendo como base a especifica¸c˜ao apresen-tadaa anteriormente. Este prot´otipo foi desenvolvido em Java utilizando o paradigma orientado a objetos. Para a persistˆencia dos dados coletados, foi escolhido o uso do SQ-Lite, um banco de dados tratado como referˆencia em sistemas embarcados devido `a sua simplicidade de administra¸c˜ao, implementa¸c˜ao e manuten¸c˜ao.

Como forma de comunica¸c˜ao entre o SML e entidade externas, foram utilizadas as tecnologias de socket e web service. Os sinais vitais do bebˆe em tempo real s˜ao enviados via socket para o aplicativo m´ovel utilizando protocolo UDP. Tal modelo foi escolhido pelo fato que a perda de pacotes ´e toler´avel nesta aplica¸c˜ao, uma vez que s˜ao enviados 1 pacote por segundo e a perda de alguns deles n˜ao interfere de maneira cr´ıtica na sua funcionalidade. Por outro lado, o web service ´e utilizado para consulta de relat´orios do hist´orico de dados e altera¸c˜oes de configura¸c˜ao. O uso de web service tamb´em foi escolhido para a transmiss˜ao dos alertas entre o sistema e as autoridades de sa´ude.

O hardware central do sistema embarcado ´e a placa Intel Galileo Gen 2, a qual ´eR

respons´avel pela coleta das informa¸c˜oes medidas pelos sensores, pela execu¸c˜ao das l´ogicas de neg´ocio definidas e pela comunica¸c˜ao com o aplicativo m´ovel e outros servi¸cos de sa´ude. Como um dos objetivos ´e obter a posi¸c˜ao da crian¸ca, foi pensado em algum sensor que pudesse ser facilmente inserido na vestimenta do rec´em-nascido. A op¸c˜ao escolhida foi o FSR 402, um resistor sens´ıvel `a for¸ca que funciona medindo a press˜ao aplicada em sua superf´ıcie atrav´es de sua varia¸c˜ao de resistˆencia, atuando como uma esp´ecie de “bot˜ao” que ativa quando o peso da crian¸ca exerce uma determinada press˜ao sobre o mesmo. Devido a seu tamanho pequeno e pouqu´ıssima espessura, ele se mostrou ideal para aplica¸c˜ao. Outro sensor considerado indispens´avel ´e o ox´ımetro, pelo qual ´e poss´ıvel obter a satura¸c˜ao de oxigˆenio e a frequˆencia card´ıaca. Neste caso, o sistema ´e compat´ıvel com qualquer ox´ımetro que disponibilize seus dados no modelo do IEEE 11073-10404 Pulse Oximeter Specialization Standdard [21]. Para os alertas sonoros foi utilizada uma placa de som USB gen´erica para habilitar a conex˜ao com um alto-falante, devido ao fato da placa Galileo n˜ao oferece entrada p2. O ambiente de testes foi configurado como ilustra a Figura 8.

Figura 8: Configura¸c˜ao do ambiente de testes

A placa est´a conectada com roteador via cabo Ethernet. O sensor FSR est´a conec-tado por fios jumpers em um protoboard que por sua vez est´a conectada com a placa. A caixa de som ´e outro dispositivo ligado `a placa. Sua conex˜ao se da por meio de um cabo p2 conectado a uma placa de som inserida na placa.

´

E importante ressaltar que devido `as restri¸c˜oes de pre¸co e disponibilidade no mer-cado, n˜ao foi poss´ıvel adquirir um ox´ımetro real. Desta forma, foi desenvolvido em python um simulador capaz de gerar dados com base no modelo IEEE 11073-10404 [21], um con-junto de padr˜oes que abordam a interoperabilidade de dispositivos pessoais de sa´ude. Este simulador ´e executado no computador (conectado na mesma rede do roteador via Wi-Fi) simulando os sinais vitais da crian¸ca e enviado para a placa. Al´em disso, o computador tamb´em foi utilizado para receber os dados destinados `as autoridades de sa´ude e aplicativo m´ovel, pois o objetivo desse projeto n˜ao foi desenvolvˆe-los.

4.2 Cen´ario de teste e resultados

A cria¸c˜ao de um cen´ario real de testes se tornou algo imposs´ıvel devido ao fato de ser invi´avel implantar o sistema em um ber¸co juntamente com um bebˆe humano, pois para que cada fun¸c˜ao da ferramenta fosse testada, seria necess´ario submeter o rec´ em-nascido a situa¸c˜oes de extremo risco. Diante desse fato, o simulador desenvolvido foi utilizado para controlar parˆametros de oxigena¸c˜ao e frequˆencia card´ıaca a fim de induzir valores capazes de disparar alertas (definidos na Se¸c˜ao 3.1). Por padr˜ao, o simulador inicia com um valor predeterminado para cada parˆametro (frequˆencia card´ıaca inicia com 120 e satura¸c˜ao de oxigˆenio inicia com 97%) e uma probabilidade de mudan¸ca para cada um deles dentro de um intervalo definido. Como n˜ao seria uma boa ideia esperar que qualquer um dos parˆametros aumentasse ou diminu´ısse de acordo com as probabilidades estabelecidas, foi implementado algumas fun¸c˜oes que alterassem os valores dos parˆametros instantaneamente para um valor de risco que possa disparar algum dos alertas. A interface do simulador ´e representada na Figura 9. O bot˜ao Start permite iniciar o simulador, o bot˜ao alert SpO2 reduz o n´ıvel de satura¸c˜ao do oxigˆenio para um valor entre 91% e 94% se pressionado uma vez e reduz esse n´ıvel para menos que 90% se pressionado duas vezes. J´a o bot˜ao alert hRate permite que o n´ıvel de frequˆencia card´ıaca caia para abaixo de 80bpm. O bot˜ao Reset retorna aos valores iniciais.

Figura 9: Interface do simulador

Foram realizados 4 testes, alterando os parˆametros do simulador com o objetivo de atingir cada um dos alertas representados na Tabela 3, al´em de mais um teste simulando o peso de um bebˆe sob o sensor FSR. O objetivo desses experimentos foi de observar a altera¸c˜ao dos parˆametros respons´aveis por informar o alerta relacionado a cada teste e alertar os pais por meio de um alerta para o aplicativo m´ovel. Para isso s˜ao apresentados os logs referentes a cada teste nas figuras 10, 11, 12, 13, 14. O quadrado vermelho marca exatamente o ponto em que o aplicativo recebe o alerta. Podemos tamb´em visualizar quais

s˜ao os valores dos parˆametros em cada tempo e o momento em que eles s˜ao alterados. Como primeiro teste, foi colocado um peso de 5kg em cima do sensor (reproduzindo o peso de um rec´em-nascido) com o objetivo de simular uma eventual situa¸c˜ao em que o bebˆe possa ter mudado a sua posi¸c˜ao e no momento se encontre com a barriga para baixo. Para o segundo teste, o simulador passou a ser usado como fornecedor dos sinais vitais a serem analisados. A taxa de satura¸c˜ao de oxigˆenio no sangue foi reduzida a 93%, valor considerado abaixo dos 95% especificados como limite para gera¸c˜ao de um sinal de alerta e que representa um poss´ıvel indicativo de asfixia. Para o terceiro teste, a taxa de satura¸c˜ao de oxigˆenio no sangue foi reduzida mais um pouco, chegando a 88%, uma situa¸c˜ao apontada como cr´ıtica e considerada um sinal claro de asfixia.

Figura 10: Log para o teste da posi¸c˜ao do bebˆe

Figura 11: Log para o teste da satura¸c˜ao de oxigˆenio do bebˆe abaixo de 95% 37

Figura 12: Log para o teste da satura¸c˜ao de oxigˆenio do bebˆe abaixo de 90%

Terminado os testes com as altera¸c˜oes na varia¸c˜ao da taxa de satura¸c˜ao, foram realizados os testes referentes `a frequˆencia card´ıaca. Para o quarto teste, esse sinal vital foi reduzido para 80bpm e mantido esse valor por cerca de 30 segundos. Por fim, o quinto e ´ultimo teste, o valor da frequˆencia card´ıaca foi reduzido para o mesmos 80bpm do teste anterior. Por´em, esse valor foi mantido por mais tempo, aproximadamente 60 segundos.

Na Figura 13, o log foi adaptado para imprimir os dados com o tempo de 5 em 5 segundos, enquanto que na Figura 14 o log foi adaptado para imprimir os dados com o tempo de 10 em 10 segundos. Tudo se deve ao fato que em ambos os testes foi necessario esperar o tempo estabelicido antes da gera¸c˜ao do alerta e se tornaria invi´avel demostra-lo sem adapta¸c˜ao devido ao seu extenso tamanho.

Figura 13: Log para o teste da frequˆencia card´ıaca com 80bpm por 30 segundos

Figura 14: Log para o teste da frequˆencia card´ıaca com 80bpm por 60 segundos

Um outro teste foi realizado com o objetivo de calcular o tempo gasto entre a gera¸c˜ao do alerta na placa e o tempo que a resposta chega ao seu destino. Esse teste utilizou o mesmo padr˜ao do teste anterior, foram feitos 5 testes com os mesmos par˜ametros e restri¸c˜oes. Na Tabela 4 est˜ao demostrados os tempos de resposta para alerta.

Tabela 4: Comparativo entre os tempos de resposta para cada teste Testes Aplicativo Autoridade de sa´ude Alerta sonoro

1 1,29s -

-2 1,01s -

-3 0,86s 2,15s 1,50s

4 31,44s -

-5 61.73s 63,23s 62,01s

Como podemos ver, o tempo entre a altera¸c˜ao para algum parˆametro de risco e a resposta foi na m´edia de 1 segundo para alertas enviados ao aplicativo e m´edia de 2 segundos para alertas destinados a autoridade de sa´ude. Isso pode ser explicado pelo tipo diferente de comunica¸c˜ao escolhida, enquanto os alertas enviados para o aplicativo eram enviados pela mesma rede via socket os alertas enviados para a autoridade de sa´ude levaram um caminho mais “longo”, pois o web service passa por um servidor antes de chegar ao local. O elevado tempo de resposta nos testes 4 e 5 s˜ao explicados pelo fato que est˜ao somados os tempo de espera previsto para os alertas (30 segundos para o teste 4 e 60 segundos para o teste 5). Com isso, ´e poss´ıvel verificar que o sistema atende aos requisitos de alertar com eficiˆencia e rapidez os diversos riscos associados a S´ındrome da Morte S´ubita do Lactente..

5

CONCLUS ˜

OES E TRABALHOS FUTUROS

Embora existam diversas medidas que possam impedir a ocorrˆencia da SMSL, a proposta de mais uma solu¸c˜ao n˜ao pode ser rejeitada. Levando isso em conta, uma extensa pesquisa de literatura m´edica, junto com a ajuda de um pediatra, possibilitou o desenvolvimento de um sistema computacional para lidar com uma quest˜ao t˜ao delicada. Os testes realizados mostraram a efic´acia do sistema no monitoramento dos sinais vitais do bebˆe em tempo real e no envio de alertas que tanto podem ser visualizados em aplicativos quanto em sistemas de autoridades de sa´ude.

Algumas das limita¸c˜oes do trabalho recaem nas tecnologias de comunica¸c˜ao, como por exemplo o uso via socket para a transmiss˜ao de dados entre o aplicativo e o sistema, uma vez que se torna necess´ario que o dispositivo m´ovel e a ferramenta estejam conecta-dos em uma mesma rede. Outra dificuldade ´e a necessidade que a autoridade de sa´ude disponibilize um web service para que o sistema possa se comunicar diretamente com eles. Como trabalhos futuros pretende-se adicionar novas funcionalidades ao sistema, como por exemplo, sensores capazes de medir a temperatura corporal da crian¸ca. Melhorar sua comunica¸c˜ao com dispositivos que possam se conectar a ela, bem como expandir o uso, tornando-o capaz de detectar problemas que v˜ao al´em das causas ligados a SMSL.

REFERˆ

ENCIAS

[1] Owlet. Dispon´ıvel em:<http://www.owletcare.com/smart-sock-2/>. Acesso em: 04 de jun. de 2017.

[2] Snuza. Dispon´ıvel em:<http://www.snuza.com/baby-monitors/movement-monitors/snuza-pico/>. Cesso em: 04 de jun. de 2017.

[3] AngelCare. Dispon´ıvel em:<http://www.angelcare.com.br/ac1100.html>. Acesso em: 04 de jun. de 2017.

[4] Moon, Rachel Y, Rosemary SC Horne, and Fern R. Hauck. “Sudden infant death syndrome”. The Lancet, v. 370, n. 9598, p. 1578-1587, nov., 2007.

[5] ] Kahn A, Groswasser J, Rebuffat E, Sottiaux M, Blum D, Foerster M, et al. Sleep and cardiorespiratory characteristics of infant victims of sudden death: a prospective case–control study. Sleep, v. 15, n. 4, p. 87-92, ago., 1992.

[6] Willinger M, James LS, Catz C. Defining the sudden infant death syndrome (SIDS): deliberations of an expert panel convened by the National Institute of Child Health and Human Development. Pediatr Pathol, v. 11, n. 5, p. 677-684, set./out., 1991. [7] Krous HF. Instruction and reference manual for the international standardized au-topsy protocol for sudden unexpected infant death. Journal of Sudden Infant death and Infant Mortality v.1 , p. 203-246, 1996.

[8] Sudden Unexpected Infant Death and Sudden Infant Death Syndrome. Dispon´ıvel em:<https://www.cdc.gov/sids/AboutSUIDandSIDS.htm>. Acesso em: 20 de mai. 2017.

[9] Sudden Unexpected Infant Death and Sudden Infant Death Syndrome. Dispon´ıvel em:<https://www.cdc.gov/sids/data.htm>. Acesso em: 20 de mai. 2017.

[10] Warren G. Guntheroth, Philip S. Spiers. The Triple Risk Hypotheses in Sud-den Infant Death Syndrome. PEDIATRICS, v.110, n. 5, nov. 2002. Dispon´ıvel em:<http://pediatrics.aappublications.org/content/110/5/e64>. Acesso: 22 de mai. 2017.

[11] Horne, R. S., Witcombe, N. B., Yiallourou, S. R., Scaillet, S., Thiriez, G., Franco, P.. Cardiovascular control during sleep in infants: Implications for Sudden Infant Death Syndrome. Sleep Medicine, v. 11, n. 7, p. 615-621, ago., 2010.

[12] Machaalani R, Waters KA. Neuronal cell death in the sudden infant death syndrome brainstem and associations with risk factors. Brain, v. 131, n. 1, p. 218-228, jan., 2008.

[13] Franco P, Verheulpen D, Valente F, Kelmanson I, de Broca A, Scaillet S, et al.Autonomic responses to sighs in healthy infants and in victims of sudden infant death. Sleep Medicine, v. 4,n. 6, p. 569–77, nov., 2003.

[14] Glotzbach SF, Ariagno RL, Harper RM. Sleep and the sudden infant death syndrome. Ferber R, Kryger M, eds. Principles and Practice of Sleep Medicine in the Child. Philadelphia: W.B Saunders Company; 1995.

[15] Jack G. Ganssle, Michael Barr, Embedded Systems Dictionary. S˜ao Francisco, CMP Books, 2003.

[16] Cunha, Alessandro F. O que s˜ao sistemas embarcados?. Dispon´ıvel em:< http : //f iles.comunidades.net/mutcom/ART IGOSISTEM B.pdf >. Acesso em: 28 de

mai. 2017.

[17] NUNES, Mauro; O’NEILL, Henrique.. Fundamental de UML. Lisboa: Editora FCA, 2001.

[18] ] DuBose TJ. Embryonic heart rates. Fertil Steril, v. 92, n. 4, p. 57, out., 2009. [19] Fein, Alan, Stephan L. Kamholz, and David Ost, eds. Respiratory emergencies.

Hodder Arnold, 2006.

[20] Horner RL. Autonomic consequences of arousal from sleep: mechanisms and impli-cations. Sleep, v. 19, n. 10, p. s193-s195, dez., 1996.

[21] IEEE 11073-10404 Pulse Oximeter Specialization Standard. Dispon´ıvel em: <https://standards.ieee.org/findstds/standard/11073-10404-2010.html>. Acesso em: 15 de mai. 2017.