Embed Size (px)
Citation preview
SISTEMA DE AVISOS DE EMERGÊNCIA PARA MONITORAMENTO DE PACIENTES
Douglas da Silva Poubel
Projeto de Graduação apresentado ao Curso de Engenharia Eletrônica e de Computação da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Heraldo Luis Silveira de Almeida
Rio de Janeiro
Março de 2019
ii
iii
iv
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
v
AGRADECIMENTO
Eu agradeço primeiramente a Deus e depois aos meus pais e família por terem
me dado apoio e condições para estudar, o que tornou esse sonho possível hoje. Foi uma caminhada muito árdua ao longo dos anos, mas no fim foi muito positivo para minha vida e acredito que para eles também. Sem eles nada disso seria possível já que me acompanham desde minha base educacional e de formação como pessoa até hoje. Agradeço também a minha namorada que esteve presente nesses últimos anos da minha caminhada rumo ao diploma, sua presença é de suma importância na minha vida. Agradeço aos meus familiares, especialmente meus avós, que sempre participaram incansavelmente da minha vida.
Agradeço aos colegas e amigos da UFRJ que participaram de forma ativa no meu
dia-a-dia na faculdade, tanto em momentos de estudo como de descontrações. Sem eles teria sido difícil conseguir passar pelas fases complicadas na graduação. Agradeço aos professores, coordenadores e orientadores da instituição, cujo apoio e ajuda dentro e fora de aula foi de extrema importância para chegar ao objetivo de conclusão do curso de Engenharia Eletrônica e de Computação.
Agradeço a oportunidade dada pela empresa Consub, ao abrir as portas para que
eu pudesse cumprir minhas horas de estágio. O agradecimento é curto, mas é de coração e tenta alcançar as pessoas que participaram da minha vida nos últimos anos. Obrigado.
vi
RESUMO
O monitoramento de pacientes em hospitais ou clínicas através de avisos simples de emergência ou sistemas para esse fim atualmente é pouco trabalhado e disseminado.
O projeto a ser descrito neste texto, chamado de SAEMP (Sistema de avisos de emergência para monitoramento de pacientes), foi idealizado para suprir a necessidade de uma solução viável e funcional para o monitoramento dos pacientes.
A ideia do projeto surge de um caso particular de atendimento, na qual o paciente necessitava de um acompanhamento constante durante seu repouso pós-cirúrgico. O monitoramento remoto foi importante neste caso a fim de aumentar o grau de liberdade dos responsáveis por cuidarem do mesmo. Esse grau de liberdade se caracteriza pela necessidade de o cuidador permanecer próximo ao paciente para monitorá-lo.
O SAEMP foi pensado e projetado para garantir maior flexibilidade de atendimento para os cuidadores, maior eficácia no monitoramento dos pacientes e maior qualidade no serviço prestado a estes. E como descrito no presente texto, é composto de uma central de controle, pulseiras de monitoramento de pacientes e de controles remotos para pacientes realizarem seus chamados de emergência.
Todo o hardware usado neste projeto é devidamente especificado em mais de um capítulo no decorrer do texto. A parte de software é fundamental para a implementação do hardware do projeto e para que o mesmo consiga funcionar da forma esperada.
Em relação a comunicação por radiofrequência, ela surge como um dos principais pontos do texto, pois dela que se faz possível o uso de pulseiras de monitoramento de pacientes de forma remota pelos médicos e/ou enfermeiros.
Sem esquecer que os componentes eletrônicos usados no projeto são amplamente conhecidos pela comunidade tecnológica e são considerados de custo acessível quando comparados com outras tecnologias aplicáveis na área da saúde.
Desta forma, pode-se projetar e testar o sistema, na qual obteremos os resultados esperados de funcionamento do mesmo. Palavras-chaves: monitoramento, pacientes, acessível, viável, saúde
vii
ABSTRACT
Nowadays the monitoring of patients in hospitals or clinics by simple emergency advises or type of systems for that application is little developed and spread.
The project that will be described in this text, it was called the SAEMP (Sistema de avisos de emergência para monitoramento de pacientes) or System of emergency warnings to monitoring patients, it was idealized to supply the necessity for a functional and viable solution for monitoring of patients.
The project idea was born from a particular case of private medical care, what the patient has needed to a constant care during your bed time at post surgery. The remote monitoring was important in this case for increase the liberty level of the people who cares of the patient. That liberty level is defined by the necessity of the caregiver stay close to the patient for monitoring it.
The SAEMP was thought and was designed to guarantee more flexibility of hospital care for the caregivers, to guarantee more efficiency in the monitoring of patients and more quality on the services that were done. And as describe in this text, the SAEMP is formed by one control center, patient monitoring bracelets and remote controls for the patients did their emergency calls.
All hardware used in this project is properly specified in more than one chapter of the text. The software of SAEMP is important to make the hardware works correctly as it is expected.
In relation to radio frequency communication, it comes up as one the most important subjects of the text, because it makes the use of monitoring bracelets in the remote way by the doctors and/or nurses.
Do not to forget that the electronic components that were used in this project are widely known by the technological community and they are considered of accessible cost when they are compared with other applicable technologies in the heath area.
Therefore, the system is projected and tested, which is obtain the expected results about the SAEMP operation. Key-words: monitoring, patients, accessible, viable, health
viii
SIGLAS A/D - Analógico/Digital AM - amplitude modulation AMPOP - amplificador operacional AE - aviso de emergência AT - atendimento CCAE - central de controle de avisos de emergência CI - circuito integrado CRP - controle remoto dos pacientes EN - enfermeiro(a) HW - hardware I/O - entradas e/ou saídas PAC - paciente PMP - Pulseira de Monitoramento de Pacientes RF - radio frequência RTC - real time clock RX - receptor SAEMP - Sistema de Avisos de Emergência para Monitoramento de Pacientes SD - Secure Digital SW - software TA - tempo de atendimento TI - tempo inicial de atendimento TF - tempo final de atendimento TX - transmissor UFRJ – Universidade Federal do Rio de Janeiro
ix
Sumário 1 – Introdução................................................................................................ ................... 1
1.1 – Tema ................................................................................................ .................... 1
1.2 – Delimitação ................................................................................................ .......... 1
1.3 – Motivação e Justificativa ................................................................ ..................... 1
1.4 – Objetivo................................................................................................ ................ 2
1.5 – Metodologia ................................................................................................ ......... 3
1.6 – Descrição................................................................................................ .............. 4
2 – Soluções atuais para monitoramento de avisos de emergência ................................ .. 4
3 – Conceito geral do Sistema de Avisos de Emergência para Monitoramento de
Pacientes (SAEMP) ................................................................................................ .......... 6
3.1 – Controle remoto do paciente ................................................................ ................ 7
3.2 – Central de controle de avisos de emergência ................................ ....................... 7
3.3 – Pulseira para monitoramento de pacientes................................ ........................... 8
4 - Descrição de hardware do projeto................................................................ ............... 9
4.1 – Central de Controle de Avisos de Emergência (CCAE)................................ ...... 9
4.2 – Pulseira de Monitoramento de Pacientes (PMP) ................................ ............... 12
4.3 – Controle Remoto dos Pacientes (CRP) ................................ .............................. 14
4.4 – Comunicação entre central (CCAE) e enfermeiros (PMP)................................ 17
4.5 – Levantamento de preços de material do HW................................ ..................... 20
5 - Descrição de software do projeto ................................................................ .............. 22
5.1 – Central de controle de avisos de emergência (CCAE)................................ ....... 22
..................................................................................................................................... 22
5.2 – Pulseira de Monitoramento de Pacientes (PMP) ................................ ............... 24
..................................................................................................................................... 25
5.3 – Comunicação por radiofrequência ................................................................ ..... 27
6 - Testes e resultados................................................................................................ ..... 29
6.1 – Testes de funcionamento dos módulos de radiofrequência ............................... 29
6.2 – Testes de funcionamento dos equipamentos montados e seus resultados ......... 30
7 – Conclusão e sugestões de trabalhos futuros ................................ ............................. 33
Bibliografia................................................................................................ ..................... 35
Apêndice A - Código fonte do programa da PMP ................................ ......................... 37
x
Apêndice B - Código fonte do programa da CCAE ................................ ....................... 41
Apêndice C - Esboço conceitual 3D do SAEMP ................................ ........................... 49
Apêndice D – Esquemático do SAEMP................................................................ ......... 50
xi
Lista de Figuras 3.1 – Modelo conceitual do SAEMP em forma de diagrama de blocos……..............…6 3.2 – Modelo conceitual do SAEMP de forma mais específica.......................................6 4.1 – Esquema eletrônico da Central de controle de avisos de emergência......................9 4.2 – Esquema eletrônico da Pulseira de monitoramento de pacientes.......................12 4.3 – Esquema eletrônico da CRP com as principais conexões internas.......................14 4.4 – Esquema eletrônico do Controle remoto de pacientes (CRP) ..............................15 4.5 – Esquema eletrônico do circuito inversor do CRP.................................................16 4.6 – Módulos reais do transmissor e receptor...............................................................18 4.7 – Ilustração da comunicação entre os módulos de rádio frequência.........................19 5.1 – Divisão em seções do software da Central de controle......................................... 22 5.2 – Divisão em seções do software da Pulseira de monitoramento..............................24 5.3 – Comportamento dos botões mostrados no gráfico e no trecho de código do programa da pulseira de monitoramento.................................................................25 6.1 – Teste de alcance de comunicação entre um transmissor e dois receptores............30 6.2 – Teste do controle remoto com a saída analógica ligada no multímetro.................31 6.3 – Teste do controle remoto com a saída analógica ligada no multímetro.................31 6.4 – Circuito da Central de controle e das pulseiras montados na mesa de testes....... 32 6.5 – Teste da pulseira de monitoramento recebendo dados da Central de controle......33
xii
Lista de tabelas 3.1 – Níveis das prioridades e seus respectivos avisos de emergência..............................7 4.1 – Pinos e conexões descritas na Figura 4.1. .............................................................10 4.2 – valores projetados de resistências, tensões e leituras do Arduino.........................17 4.3 – levantamento de preços de componentes do SAEMP...........................................21 5.1 – Botões e as respectivas leituras feitas pelo Arduino UNO da CCAE....................23 5.2 – Exemplo de caso com as mensagens geradas pelas PMPs.....................................26 5.3 – Funções da biblioteca LiquidCrystal_I2C usadas no projeto.................................27 5.4 – Funções da biblioteca VirtualWire usadas no projeto...........................................28
1
1 – Introdução
1.1 – Tema
O tema deste trabalho é o projeto de um sistema de comunicação de emergência para clínicas e hospitais. Nesse sentido, o problema é fazer a comunicação digital e automática entre pacientes, enfermeiros e médicos.
1.2 – Delimitação O sistema pode ser instalado preferencialmente em hospitais e clínicas, o que
não impede de ser aproveitado para uma aplicação residencial. Ele não é aplicável a pacientes inconscientes, ou sem condições físicas ou mentais de usar o sistema. E outra delimitação é quanto ao tempo de resposta, entre os avisos de emergência e os respectivos atendimentos.
1.3 – Motivação e Justificativa
A ideia para esse projeto nasceu de um caso particular, no qual eu pude participar como idealizador de uma solução para o problema. Este consistiu em: fazer o monitoramento de uma pessoa em repouso após realizar uma cirurgia de hérnia de disco. Nesse caso particular a pessoa encontrava-se com dificuldade de movimentação, cansaço e dores frequentes. Desta forma, foi necessário uma atenção especial para ela a fim de ajudá-la em tarefas básicas, porém fundamentais como: levar água, levar comida, dar remédio, levar ao banheiro, entre outras. E visto que ela estava em repouso em sua própria casa, contou com o cuidado de seus familiares que revezavam entre si para realizarem as tarefas mencionadas. E para que os familiares não precisassem permanecer o tempo todo no quarto com a paciente foi criado um sistema de avisos básicos de emergência. Tal sistema feito com alguns componentes eletrônicos tinha o objetivo de enviar um aviso para uma central localizado em um cômodo comum da casa. Por exemplo: se a paciente precisasse ir ao banheiro ela digitava o número no equipamento correspondente a necessidade dela, e este sinal era enviado para a central que emitia o som e piscava o led correspondente ao aviso de emergência escolhido pela paciente. Desta forma, o familiar que ouvia o som ia até a central verificava o aviso e apertava um botão para desligar o aviso, e assim fazia o atendimento da paciente.
A partir desta motivação buscou-se uma solução mais geral para atender a hospitais e clínicas. Essa solução visa melhorar o monitoramento dos pacientes e trazer mais qualidade de serviço para os profissionais responsáveis por esta tarefa.
O dia-a-dia de um hospital ou clínica é normalmente movimentado e atarefado para enfermeiros, médicos e demais funcionários. Os dois primeiros lidam com diferentes situações e têm que assumir, em muitos casos, atividades com diferentes funções durante o seu expediente. Fazer o acompanhamento dos pacientes internados ou lidar com eles nos leitos dos hospitais ou clínicas é uma dessas atividades.
2
É de extrema importância que médicos e enfermeiros tenham um excelente aproveitamento como cuidadores, já que a saúde dos pacientes depende disso. É dada a esses cuidadores a responsabilidade de monitorar os pacientes em diferentes leitos como: a unidade de tratamento intensivo (UTI), a unidade de tratamento semi-intensiva, o centro de tratamento intensivo (CTI), entre outras. Independentemente do leito, os pacientes costumam gerar altas demandas de serviços para os médicos e enfermeiros, que por sua vez se desdobram para realizar todos os atendimentos com rapidez e qualidade.
Neste sentido, cria-se um sistema de avisos de emergência, que consiste em enviar avisos dos pacientes para os possíveis cuidadores. Esses avisos são escolhidos pelos pacientes através de um controle remoto, encontrado na cama de cada um deles, ou são gerados por equipamentos de monitoramento. Os avisos são enviados para um receptor de dados localizado no leito de internação desses pacientes, e tal dispositivo faz o processamento de todos os avisos vindos deles. O processamento é importante para a tomada de decisões quanto à urgência de um aviso, para assim decidir qual paciente receberá o atendimento primeiro.
Os cuidadores (médicos ou enfermeiros) farão o monitoramento dos pacientes com a ajuda de pulseiras eletrônicas que serão capazes de mostrar qual paciente receberá o atendimento e qual aviso foi enviado pelo mesmo. Nesta pulseira é disponibilizado dois botões, que quando usados pelos cuidadores indica que o atendimento será feito ou não será feito ou que o atendimento chegou ao fim. Logo em seguida o sistema repassa o atendimento para o próximo cuidador disponível, e assim o atendimento pode ser realizado.
Essa explicação simples do sistema mostra que os cuidadores, em alguns casos, não precisam ficar o tempo todo próximo aos pacientes, e mesmo assim estarem aptos a atendê-los de maneira eficaz assim que necessário.
1.4 – Objetivo
O sistema tem como objetivo geral enviar avisos de emergência do paciente para médicos e enfermeiros que estejam trabalhando no mesmo leito que o paciente internado. Desta forma, tem como objetivos específicos:
(1) ou o paciente enviar o aviso desejado para o receptor através do controle remoto ou o equipamento de monitoramento cardíaco enviar algum alerta para o receptor;
(2) o aviso ser interpretado pelo receptor e entregue a pulseira do cuidador (médicos, enfermeiros ou cuidadores particulares) disponível;
(3) a pulseira interpretar o aviso e mostrar para o cuidador;
(4) o cuidador fazer o atendimento ao seu paciente;
(5) o cuidador enviar informação para central através da pulseira a fim de informar que está disponível para novos atendimentos.
3
1.5 – Metodologia
Este trabalho é fazer um sistema remoto de monitoramento de pacientes com uma interação simples entre pacientes e cuidadores. O sistema pode ser dividido em duas partes de interação; a parte 1 (interação pacientes e sistema) e a parte 2 (interação sistema e cuidadores).
Na parte 1, o sistema fica atento aos avisos de emergência que podem vir de qualquer paciente internado no leito do hospital ou clínica. Tais avisos podem vir do próprio paciente que deseja ser atendido ou de algum aparelho de monitoramento conectado ao mesmo, indicando algum tipo de anormalidade ou emergência como por exemplo: arritmia cardíaca, hipertensão, convulsão, etc. Quanto aos avisos de emergência disponíveis para os pacientes, temos:
(1) pedir informação; (2) comer alguma comida; (3) beber água; (4) ir ao banheiro; (5) emergência.
Esses avisos estão disponíveis em um controle remoto com fio que é colocado próximo à cama de cada paciente. Tais controles são equipados com cinco botões para escolha de cada aviso e um led que indica aviso enviado (do paciente para o sistema). Os controles são conectados através de cabos para a central de controle do sistema, que vai receber os sinais vindos de todos os pacientes e analisá-los. Essa análise é feita pelo Arduino [1] que compõe a central de controle do sistema e através do seu algoritmo administra o atendimento dos pacientes. Vale ressaltar que os avisos de emergência são avaliados de formas diferentes, o aviso (5) é mais prioritário do que o (1). Tais pesos associados para os avisos são fundamentais para que o sistema entenda e decida qual paciente necessita ser rapidamente atendido. Com essa decisão tomada, chega-se à parte 2.
Na parte 2 o sistema de controle verifica quais cuidadores (enfermeiros ou médicos) do leito em questão estão disponíveis para fazer atendimento e assim encaminham o paciente com maior prioridade para ser atendido. A comunicação entre central de controle e cuidadores é realizada com pulseiras contendo um microcontrolador e um módulo de comunicação. Este último capacita o circuito da pulseira de trocar informações com o sistema de controle de modo sem fio. Os cuidadores recebem em sua pulseira, em um visor lcd, qual paciente necessita de atendimento e qual aviso está associado ao mesmo. A partir disso é dado um tempo para que algum cuidador dê uma resposta ao sistema de que irá efetuar o atendimento. Isso é feito por meio de um botão disponível na pulseira, que podem enviar para o sistema uma resposta positiva ou negativa quanto ao atendimento a ser efetuado. Caso a resposta seja positiva, o primeiro cuidador disponível a apertar o botão ganha o direito de atender o paciente. Caso não surja resposta ou ela seja negativa cabe ao sistema continuar com o procedimento de verificação de cuidadores disponíveis até que consigam fazer o atendimento. No término do atendimento cabe ao cuidador enviar uma resposta através da pulseira para o centro de controle a fim de notificá-lo que já está à disposição para fazer outro atendimento.
4
Os componentes eletrônicos necessários para o projeto foram e serão comprados
em lojas especializadas na internet, junto com qualquer outro item que se julgar necessário para o projeto. O financiamento para as compras foi realizado pelo próprio aluno idealizador do projeto.
1.6 – Descrição
No capítulo 1 foi feita a introdução do projeto do Sistema de Avisos de Emergência para Monitoramento de Pacientes. A seguir, no capítulo 2, será mostrado como é feito o monitoramento de pacientes em hospitais/ clínicas atualmente e abordará possíveis soluções ou aplicações para monitorar os pacientes. A partir do capítulo 3 é apresentado de fato o SAEMP, neste capítulo mostra-se o conceito do sistema e de como ele é dividido. No capítulo 4 será mostrado o hardware usado no projeto, com especificações detalhadas e separadas em tópicos referentes aos controles remotos, pulseiras de monitoramento, central de controle e comunicação sem fio. Além de um espaço disponível para abordar um orçamento de custo do material usado no projeto. O capítulo 5 ficará responsável pelo desenvolvimento de algoritmos e software da central de controle e das pulseiras de monitoramento. No capítulo 6 serão colocados os resultados de testes feitos ao longo do desenvolvimento do projeto. O capítulo 7 contém a conclusão do trabalho e algumas sugestões para melhorias ou simplesmente novos recursos para o futuro.
2 – Soluções atuais para monitoramento de avisos de
emergência O monitoramento de pacientes em hospitais é um assunto bem geral, pois varia
de acordo com o hospital ou clínica, com o tipo de leito em que os mesmos são internados. Em geral os pacientes são separados em unidades específicas nas quais a equipe médica, formada normalmente por médicos e enfermeiros, monitora os leitos através de equipamentos que emitem som para indicar uma anormalidade em relação a “condição” monitorada como: pressão arterial, batimentos cardíacos, temperatura corporal, entre outros. Em outros casos os leitos possuem um controle remoto com um botão para ser acionado em casos de emergência pelos pacientes. Esse botão é acionado e um som é emitido para que alguém da equipe de plantão perceba o ocorrido e faça o atendimento do paciente em questão. Na questão de monitoramento da condição do paciente através de equipamentos é comum em alguns hospitais, na maioria particulares, alguns setores terem centrais de monitoramento com computadores que informam em seus monitores qual leito está solicitando atendimento e muitas vezes qual o problema o paciente apresenta no momento do alerta.
Atualmente existem diversas soluções e estudos que usam a tecnologia para monitoramento de pacientes. Com a abrangência do assunto pode-se dividir o tópico em algumas áreas específicas de atuação. Os tópicos mais relevantes sobre monitoramento hoje em dia são:
5
• Monitoramento remoto por programas ou aplicativos de celulares - o desenvolvimento de aplicativos para smartphones em diversas áreas é algo comum no cotidiano das pessoas, por isso não é visto com muita surpresa o desenvolvimento do mesmo para a área da saúde, mais especificamente para monitoramento de pacientes. Alguns exemplos podem ser citados, como:
(1) Cardiograph - aplicativo responsável por medir os batimentos através da câmera do smartphone e armazená-lo na memória do mesmo para mostrar ao médico em uma futura consulta [2]; (2) Lembrete de remédios - MediSafe - aplicativo usado como agenda pessoal de horários de remédios com alarmes sonoros para o usuário poder lembrar de tomar seus remédios nos horários devidos [3]; (3) Gerenciamento de doentes crônicos – é um serviço de monitoramento completo da empresa Br Hommed e que usa o aplicativo de autocuidado e monitoramento para o monitoramento remoto de pacientes crônicos, idosos ou gestantes em tempo real [4].
• Monitoramentos em hospitais/clínicas por equipamentos sofisticados - estes equipamentos conseguem monitorar diversas condições vitais do paciente a ele conectado, como: sinais ECG, temperatura, pressão arterial, nível de glicose, nível de oxigenação do sangue, entre outros. A marca Philips [5] [6] detém um grande avanço nesses tipos de aparelhagem para monitoramento de pacientes além de diversos equipamentos na área da saúde como equipamentos de ultrassom e ressonância magnética.
• Centrais de banco de dados - atualmente é muito comum em diversos hospitais ou clínicas terem os dados de pacientes e funcionários registrados digitalmente. Tal registro é feito a fim de facilitar nas consultas, atendimentos, geração de prontuários, receitas, etc. Tais centrais são responsáveis por manter todas essas informações para serem usadas quando necessárias pelos funcionários do hospital ou clínica em questão. A empresa Br Hommed [7] atua na área da saúde provendo serviços tecnológicos como este da geração de banco de dados com informações de pacientes, funcionários, etc.
Depois da leitura dos tópicos e do conhecimento de alguns exemplos da aplicação da tecnologia no monitoramento dos pacientes nota-se que não existe algo muito próximo ao projeto do SAEMP que será detalhado a seguir nos próximos capítulos.
6
3 – Conceito geral do Sistema de Avisos de
Emergência para Monitoramento de Pacientes
(SAEMP)
Figura 3.1 – Modelo conceitual do SAEMP em forma de diagrama de blocos.
Este item do texto descreve de forma conceitual o projeto do SAEMP. O sistema é constituído de três partes, todas necessárias para o funcionamento adequado do mesmo. Como o principal objetivo é enviar avisos dos pacientes para os enfermeiros ou médicos, foi projetado uma central de gerenciamento responsável por conectar pacientes e cuidadores com o gerenciamento adequado de avisos de emergência. Desta forma, o projeto foi dividido em: controles remotos dos pacientes (CRPs), central de controle de avisos de emergência (CCAE) e pulseiras de monitoramento de pacientes (PMPs). Um diagrama mais especifico do sistema pode ser visto na Figura 3.2.
Figura 3.2 – Modelo conceitual do SAEMP de forma mais específica. Note que no diagrama acima as setas são as mesmas usadas na Figura 3.1, pois tem o mesmo significado nas duas figuras. Elas indicam o fluxo de dados e o sentido que o mesmo percorre. Na seta continua o fluxo de dados segue dos CRPs para a CCAE
7
por meio de fios. Já a seta tracejada indica que existe fluxo de dados bidirecional sem o uso de fios. Esses conceitos ficam mais claros a seguir quando cada uma das partes do SAEMP tem seu conceito mostrado ao leitor. 3.1 – Controle remoto do paciente O controle remoto do paciente (CRP) é um dispositivo composto por cinco botões do tipo push-buttons que são acionados de acordo com a necessidade e desejo do paciente que dispõe deste controle em seu leito no hospital ou clínica. Cada botão é responsável por enviar um aviso de emergência para a central de controle, que será devidamente analisado para que o atendimento seja realizado de forma eficiente. Cada controle será conectado a central (composta de um Arduino) por fios, na qual um deles será o de dados e estará conectado a uma porta de entrada do Arduino. Os outros fios são os de alimentação do circuito (VCC e GND). Um led está presente no controle com o objetivo de indicar o funcionamento correto dos botões ao acioná-los. Vale ressaltar que o envio de dados é unidirecional e segue dos controles remotos para a CCAE. A tabela a seguir mostra os avisos destinados a seus respectivos botões neste projeto e os valores das prioridades correspondentes aos avisos. O nível de prioridade para atendimento vai do nível mais baixo (1 - Pedir informação) até o mais alto (5 - EMERGÊNCIA).
Botão e prioridade Aviso de emergência 1 Pedir informação 2 Comer alguma comida 3 Beber água 4 Ir ao banheiro 5 EMERGÊNCIA Tabela 3.1 – Níveis das prioridades e seus respectivos avisos de emergência. 3.2 – Central de controle de avisos de emergência Com os CRPs definidos, busca-se uma solução para gerenciar os avisos de emergências oriundos dos pacientes e que tem como destino os cuidadores. E esse gerenciamento tem que ser rápido e eficaz a fim de disponibilizar para as pessoas atendidas pelo sistema um serviço de qualidade, confiabilidade e de baixo custo. A solução encontrada foi projetar a CCAE com uma placa Arduino e alguns circuitos eletrônicos com objetivos específicos. O Arduino atua de forma a gerenciar as informações de entrada oriundas dos CRPs e as informações que são trocadas com as PMPs. Essas informações são, principalmente, os avisos de emergência dos diversos pacientes que devem ser processados para que assim seja feita a escolha dos cuidadores que farão atendimento. O critério para escolha do profissional que fará o próximo atendimento é explicado posteriormente no texto. O que se pode adiantar sobre o critério é que ele vai depender de dados adquiridos dos módulos de circuitos específicos, na qual cada um tem sua importância no projeto do sistema. Os módulos presentes no CCAE são: módulo de comunicação sem fio, módulo RTC e módulo de armazenamento de dados em cartão SD.
8
Os módulos RTC e SD atuam junto ao Arduino na formação e controle de dados para possibilitar a criação de critérios objetivos que gerencie as escolhas dos cuidadores que fazem os atendimentos nos hospitais ou clínicas. Já os módulos de comunicação têm a responsabilidade de implementar a comunicação sem fio entre a CCAE e as PMPs. Desta forma, passamos para o conceito das pulseiras eletrônicas. 3.3 – Pulseira para monitoramento de pacientes As PMPs são dispositivos eletrônicos projetados a fim de monitorar os pacientes de forma remota, sem a necessidade de monitoramento constante próxima a pessoa internada. Tal pulseira é composta por um CI de controle, módulos de comunicação sem fio, botões, display LCD e uma bateria para alimentação da mesma. A principal função da pulseira é indicar em seu display qual paciente deve ser atendido e qual aviso ele escolheu, e para que isso ocorra a informação trafega através do módulo de comunicação sem fio que envia para o CI de controle. Deste último, a informação é mostrada em forma de mensagem no display da pulseira. As possíveis mensagens puderam ser vistas na Tabela 3.1. O cuidador ao visualizar a mensagem no display da sua pulseira tem quatro opções de ação:
(1) apertar o botão 1, cuja a funcionalidade é indicar que ele irá realizar o atendimento;
(2) apertar o botão 2, indicando que ele não irá realizar o atendimento;
(3) apertar o botão 1 por mais de cinco segundos, indicando que ele terminou de realizar um atendimento e está pronto para o próximo;
(4) não apertar nenhum botão por mais de dois minutos, o que indica que o cuidador não está disponível para fazer atendimento.
Com isso temos a descrição conceitual do SAEMP, na qual se propôs abranger as funcionalidades do sistema e os conceitos desde a convocação feita pelo paciente através do CRP até o atendimento do mesmo por algum cuidador, portanto a PMP. A seguir no texto são mostrados mais detalhes sobre hardware e software que foram desenvolvidos para o sistema.
9
4 - Descrição de hardware do projeto 4.1 – Central de Controle de Avisos de Emergência (CCAE)
Figura 4.1 – Esquema eletrônico da CCAE com as principais conexões internas.
A CCAE é parte fundamental do projeto, e como visto anteriormente, é formada por um Arduino UNO R3 [8] e alguns circuitos eletrônicos chamados de módulos. O Arduino atua como mestre em relação aos módulos, é ele que tem a responsabilidade de gerenciar todos os dados trocados com os módulos RTC [9], SD [10], RX 433MHz [11] e TX 315MHz [12]. E cada módulo tem uma forma de se comunicar com o mestre, já que é previsto na arquitetura do microcontrolador ATMEGA328p [13] a disponibilidade de protocolos de comunicação como SPI [14] e i2C [15], usados para comunicação com SD e RTC respectivamente. O SPI é um protocolo de comunicação serial síncrona e baseia-se no conceito mestre-escravo para troca de informações. O conceito consiste em fazer a comunicação entre um dispositivo mestre com um ou mais periféricos chamados de escravos através de quatro conexões. No projeto da CCAE o Arduino é o dispositivo mestre enquanto que o módulo SD é o escravo. As conexões responsáveis por realizar a comunicação entre eles são:
• MISO (Master In Slave Out) - conexão na qual os dados são enviados do dispositivo escravo para o mestre.
• MOSI (Master Out Slave In) - conexão na qual os dados são enviados do
dispositivo mestre para o escravo.
10
• SCK (Serial Clock) - são os pulsos de clock usados para sincronizar a transmissão dos dados enviados do dispositivo mestre para o escravo.
• SS (Slave Select) - esta conexão é usada pelo dispositivo mestre para selecionar
qual dispositivo escravo irá trocar informações com ele, no caso do projeto só vai existir o módulo SD como dispositivo escravo.
A seguir uma tabela mostra a descrição dos pinos referentes a comunicação entre Arduino e o módulo SD, como pode ser visto no desenho da arquitetura de HW do CCAE.
Pino UNO Pino SD Conexão
D12 3 MISO
D11 4 MOSI
D13 2 SCK
D4 5 SS
Pino UNO Pino RTC Conexão
SDA 2 SDA
SCL 1 SCL
Tabela 4.1 – Pinos e conexões descritas na Figura 4.1.
A comunicação através do SPI possui outras características importantes como: definir se o bit mais significativo será o primeiro ou o último bit enviado e a configuração das bordas de comunicação do clock através de sua polaridade e fase. Estas características e detalhamento da biblioteca SPI da IDE do Arduino serão abordadas no capítulo cinco.
O módulo SD é um circuito eletrônico fabricado para ler ou escrever dados em um cartão de memória do tipo Micro SD ou Micro SDHC de alta velocidade. O módulo é alimentado com tensão de 5VDC e possui os pinos de dados referentes ao protocolo SPI que estão especificados na tabela anterior. A escolha desse módulo se justifica pelo uso da comunicação SPI entre Arduino UNO e o módulo em questão, da facilidade de se encontrar no mercado brasileiro e de ter um preço acessível.
Já o protocolo de comunicação i2C é capaz de conectar diferentes dispositivos presentes em um mesmo barramento serial composto de dois fios. Esse protocolo foi projetado de forma a habilitar um único dispositivo mestre no barramento com a capacidade de se comunicar com até 127 dispositivos escravos conectados ao mesmo barramento. Os dois fios mencionados são responsáveis por transmitir os sinais SDA (Serial Data) e SCL (Serial Clock). Os bits de dados do SDA são transmitidos tanto do dispositivo mestre para o escravo como do escravo para o mestre, em contrapartida, no SCL os bits do clock são enviados apenas do dispositivo mestre para o escravo. Como o módulo RTC possui em sua arquitetura esse protocolo, adotou-se o mesmo para se comunicar com o Arduino UNO. Os pinos usados para as conexões entre Arduino e
11
módulo são mostrados abaixo. A conexão SDA é bidirecional, ou seja, os dispositivos mestre e escravo enviam e recebem dados através dela. Já o SCL, além de ser unidirecional, serve para dar confiabilidade aos dados enviados já que faz a sincronia com os mesmos. Os dispositivos que usam i2C possuem um endereço de sete bits que identifica cada um, o que é fundamental para selecionar o dispositivo correto em uma comunicação. E possuem um oitavo bit que especifica se o dispositivo fará uma leitura ou escrita. Em outros casos, a leitura e a escrita feitas pelos dispositivos possuem endereços de oito bits especificados para cada tarefa. Para ambos os casos é definido que o bit mais significativo é o primeiro bit (ao olhar da esquerda para a direita), enquanto que o menos significativo é o último bit cuja função é informar se o dispositivo efetua uma leitura ou escrita. O módulo RTC usado no projeto é um circuito composto por um CI DS1307 [16] além de alguns outros componentes. Sua função é ser um relógio, na qual faz a contagem de: ano, mês, dias da semana, horas, minutos, segundos em formato de 12 horas ou 24 horas. Para anos bissextos e meses com menos de 31 dias ele realiza o ajuste automaticamente. O CI possui 56 bytes de memória não-volátil disponível para uso, e quanto a sua alimentação o mesmo utiliza uma bateria de lítio de 3VDC do modelo CR2032. A bateria serve para manter o circuito ligado mesmo quando o módulo não está com seu pino de alimentação VCC conectado a uma fonte de alimentação de 5VDC.
Os módulos de RF são os circuitos finais a serem apresentados na descrição de HW do CCAE. Eles são responsáveis por fazer a comunicação sem fio entre PMPs e a CCAE possível. A central é composta de dois módulos:
(1) modulo RF TX de 315 MHz
(2) modulo RF RX de 433 MHz.
O módulo RF TX tem como função transmitir os dados da central para as PMPs na faixa de frequência de 315 Mhz, enquanto que o RF RX recebe os dados provenientes das PMPs na faixa de frequência de 315 Mhz. Mais detalhes sobre a comunicação sem fio entre a CCAE e as PMPs, inclusive do HW dos módulos, serão mostrados no capítulo 4.4 do texto.
12
4.2 – Pulseira de Monitoramento de Pacientes (PMP)
Figura 4.2 – Esquema eletrônico da PMP com as principais conexões internas.
O projeto de HW da PMP, como pode ser visto na figura 4.2, é formado por
circuitos eletrônicos encapsulados em forma de módulos, e cada um tem sua importância na composição da pulseira eletrônica.
Adotou-se no projeto o Arduino Pro Mini [17], pois é uma placa de desenvolvimento bem versátil, pequena em comparação ao Arduino UNO, de baixo custo e atende as necessidades de HW no projeto da pulseira. O Pro Mini é composto de um microcontrolador ATMEGA328p, o mesmo encontrado no UNO, desta forma possui interfaces serial e i2C em sua arquitetura além de disponibilizar portas I/O analógicas e digitais. Tais características são fundamentais para integração com os outros componentes ou circuitos eletrônicos da pulseira. Os botões, por exemplo, foram feitos com push-buttons e foram conectados às entradas analógicas A0 e A1 do arduino. Estes botões, como pode ser visto na figura, também são conectados à resistores de pull-down R1 e R2 e à alimentação VCC de cinco volts para que eles consigam fornecer às entradas A0 e A1 níveis lógicos altos (quando os botões são pressionados) e baixos (quando os botões não são pressionados). Os botões da PMP servem como forma de interação entre enfermeiros e o SAEMP, e suas funções são descritas abaixo.
• Botão 1 acionado: é usado quando um atendimento é solicitado e mostrado no display da pulseira e tem como função informar ao CCAE que aquele
13
atendimento em questão vai ser realizado pelo (a) enfermeiro (a) usuário (a) da PMP.
• Botão 2 acionado: é usado no mesmo momento que o botão 1, mas serve para
informar ao CCAE que aquele atendimento em questão NÃO vai ser realizado pelo (a) enfermeiro (a) usuário (a) da PMP.
• Botão 1 pressionado por mais de cinco segundos: é usado pelo (a) enfermeiro (a)
para informar ao CCAE que o atendimento em questão foi finalizado. O display mencionado é o modelo LCD 16x2 [18] com letras brancas e fundo azul e possui um circuito integrado em seu módulo responsável por habilitar a comunicação do tipo i2C. Tal protocolo foi explicado anteriormente na descrição de HW do CCAE e é usado da mesma forma na PMP. O fato deste display ser capaz de se comunicar com o Arduino através do protocolo i2C foi fundamental para o seu uso no projeto, já que são utilizadas apenas portas analógicas A4 (SDA) e A5 (SCL) do Arduino Pro Mini. O baixo custo do display e a ampla disponibilidade para venda no mercado brasileiro são outros motivos para escolha deste. Como já mencionado, o display serve para mostrar ao cuidador qual paciente necessita de atendimento e seu respectivo aviso de emergência. Mais detalhes destas mensagens são mostrados no capítulo de software do projeto.
A comunicação entre a pulseira eletrônica e a CCAE é feita de forma sem fio, através de módulos de rádio frequência AM. A pulseira é composta por dois módulos, como pode ser visto na figura:
(1) módulo RF TX de 433 Mhz;
(2) modulo RF RX de 315 Mhz.
O módulo RF TX tem como função principal transmitir os dados da pulseira para a CCAE na faixa de frequência de 433 Mhz, enquanto que o RF RX recebe os dados oriundos da CCAE na faixa de frequência de 315 Mhz. Mais detalhes sobre a comunicação sem fio entre a CCAE e as PMPs serão mostrados no decorrer do texto.
14
4.3 – Controle Remoto dos Pacientes (CRP)
Figura 4.3 – Esquema eletrônico da CRP com as principais conexões internas.
O CRP é composto de um circuito eletrônico com capacitores, resistores, botões, led e um AMPOP. Ele foi projetado para ser alimentado com tensões de ±9VDC fornecidos por uma fonte de alimentação ou bateria, receber uma tensão de entrada Vin de 5VDC e fornecer uma tensão de saída variável de acordo com o botão a ser acionado. O CRP possui cinco botões, como visto antes no texto, que estão conectados a resistores de valores diferentes, e estes últimos estão conectados a mesma tensão de entrada Vin. O circuito foi feito desta forma para enviar tensões diferentes para uma única entrada analógica do Arduino, que através dessas diferentes tensões poderá saber qual botão foi acionado. Esse circuito pode ser feito simplesmente com um divisor de tensões, mas pode gerar um efeito de bouncing[19] quando os botões forem acionados e como consequência gerar um erro de leitura pelo Arduino. Tal efeito é, resumidamente, uma oscilação de tensões que ocorrem ao acionar um botão (chave) repetidamente em
15
intervalos pequenos de tempo. Existem algumas soluções de SW e HW para evitar esse efeito, e neste projeto foi adotado o uso de um circuito integrador com um AMPOP TL072 [20]. Adotou-se este CI pelos seguintes motivos: é fácil de se encontrar no mercado de componentes eletrônicos, é considerado de baixo custo e só necessita de resistores para implementar as tensões de saídas do projeto, já que a tensão de entrada é fixa em 5V. Já o principal capacitor do circuito foi calculado a fim de produzir uma constante RC (resistor e capacitor ligados em paralelo) adequada ao projeto do CRP. A corrente fornecida pela entrada Vin é responsável pelo carregamento do capacitor. E o mesmo tem como objetivo no projeto fazer com que a tensão alcançada na saída do circuito permaneça em nível lógico alto ou baixo sem a ocorrência de oscilação de voltagem que provocaria o efeito bouncing. Dois capacitores bypass foram inseridos no circuito, um conectado do -V para o terra e o outro do +V para o terra. Ambos com função de filtrar ruídos provenientes da fonte de alimentação ou bateria. O led presente no controle remoto serve apenas para indicar que os botões estão ligados quando acionados. Logo a seguir pode ser visto os principais circuitos e equações do projeto do CRP.
Figura 4.4 – Esquema eletrônico do circuito integrador do CRP. Equações do projeto do Integrador: Da análise no nó de ligação das resistências, temos: 𝑉𝑅′
+ 𝑉 − 𝑉𝑖𝑛𝑅𝑖𝑛
+ 𝑉 − 𝑉𝑜𝑅
= 0
16
𝑉𝑜 = �𝑅𝑅′
+ 𝑅𝑅𝑖𝑛
+ 1�𝑉 − 𝑅𝑅𝑖𝑛
𝑉𝑖𝑛 = 0
𝑉𝑜 ~ − 𝑅𝑅𝑖𝑛
𝑉𝑖𝑛 = 0
Figura 4.5 – Esquema eletrônico do circuito inversor do CRP.
Equação do projeto do Inversor:
𝑉𝑜 ~ − 𝑅𝐵𝑅𝐴
𝑉𝑜 O conversor A/D do Atemega328 presente no Arduino tem resolução de dez bits, desta forma ele possui uma amostragem de 210 − 1 = 1023 através de suas portas de entrada. Portanto, os valores de tensões que chegam nas entradas são convertidos de valores analógicos para digitais pela seguinte relação:
𝑉𝑑𝑖𝑔𝑖𝑡𝑎𝑙 = 1023𝑉𝑟𝑒𝑓
𝑉𝑎𝑛𝑎𝑙ó𝑔𝑖𝑐𝑜
Sabendo que 𝑉𝑟𝑒𝑓 é o valor de referência 𝑉𝑟𝑒𝑓 = 𝑉𝑖𝑛 = 5𝑉𝐷𝐶 , 𝑉𝑎𝑛𝑎𝑙ó𝑔𝑖𝑐𝑜 é o valor analógico de tensão proveniente do circuito dos CRPs e 𝑉𝑑𝑖𝑔𝑖𝑡𝑎𝑙 é o valor de tensão no formato digital.
Desta forma, conseguiu-se chegar nos valores dos componentes e grandezas necessárias para que o circuito funcionasse como desejado. Segue abaixo uma tabela com os valores mais importantes.
17
Resistência Valor (KΩ) Tensão VA0(V) Leitura Arduino (aprox.)
R 10 ±5%
R’ = R” 10 ±5%
R1 12 ±5% +4,16 851
R2 16(15) ±5% +3,33 681
R3 22 ±5% +2,27 464
R4 33 ±5% +1,51 308
R5 51(56) ±5% +0,89 182
RA 1 ±5%
RB 1 ±5%
Capacitor Valor (uF)
C 0.1
Cb 1
Tabela 4.2 – valores projetados de resistências, tensões e leituras do Arduino. 4.4 – Comunicação entre central (CCAE) e enfermeiros (PMP)
A escolha de qual tecnologia foi usada para realizar a comunicação entre a central de controle e as PMPs foi feita a fim de atender requisitos fundamentais de comunicação do SAEMP. Requisitos como:
• Fazer com que a CCAE e PMPs se comunicassem de forma sem fio, com boas
distâncias de alcance entre elas e confiabilidade na troca de dados. • Terem um HW simples, que consiste em: possuir poucos pinos de dados, baixo
consumo de corrente e tensão e de fácil integração com microcontroladores.
• Ter um custo-benefício agradável para não encarecer o projeto, além de ser facilmente encontrado no mercado brasileiro de itens eletrônicos.
• Ter um HW compacto para não ocupar muito espaço, principalmente nas PMPs,
que deveriam ser as mais compactas a fim de serem ergonômicas para os seus usuários.
18
A fase de estudo e pesquisa do projeto do SAEMP iniciou-se com algumas possibilidades para implementação da comunicação entre a central de controle e as pulseiras de monitoramento. Algumas delas são:
(1) módulos de RF AM com frequências de operação 433MHz e 315MHZ;
(2) módulos de comunicação ESP8266; [21]
(3) módulos de comunicação NRF24L01. [22]
Dentre estas a primeira foi escolhida por atender melhor aos requisitos que foram mencionados anteriormente.
Figura 4.6 – Módulos reais do transmissor e receptor
Os módulos de comunicação sem fio são dois circuitos eletrônicos, um projetado para transmitir dados enquanto que o outro faz a recepção desses dados em uma frequência específica por meio de oscilações eletromagnéticas as quais são chamadas de Radiofrequência (RF). Esta frequência já é ajustada no projeto desses circuitos e obrigatoriamente devem ser a mesma para o transmissor como para recepção. A escolha por módulos com frequências de 315 MHz e 433 MHz foi pela necessidade da comunicação bidirecional entre a CCAE e as PMPs para que não houvesse confusão das origens e destinos dos dados trocados entre a central e as pulseiras. A figura anterior mostra como são na realidade os módulos que foram usados no projeto.
O transmissor e o receptor são muito parecidos, como pode ser visto na Figura 4.6, mas possuem suas diferenças. O receptor possui uma alimentação limitada a 5VDC no pino VCC, ao passo que o transmissor pode ser alimentado com tensões de 3.3VDC a 12VDC dependendo da necessidade de quem usa o circuito. Com o aumento da tensão de alimentação do transmissor ocorre um aumento da potência do sinal irradiado pelo circuito que por consequência aumenta o alcance do mesmo. Por falar em alcance do sinal irradiado, a forma que foi adotada no projeto do SAEMP para melhorar essa característica foi inserir uma antena de fio no transmissor e outra no receptor. Cada módulo possui um local específico (indicado na Figura 4.6) para soldar uma antena e ela pode variar de tamanho, forma e material de acordo com a necessidade da aplicação. Para escolher o tamanho da antena foi feito um cálculo simples para descobrir o comprimento de onda lambda, através da velocidade da luz e frequência da portadora. Veja que cada conjunto de módulos RX e TX possuem frequências diferentes, logo os tamanhos das antenas ficaram diferentes. O cálculo pode ser visto logo a seguir:
19
𝜆 = 𝑐𝑓
Para antenas monopólos (como as usadas nos módulos): 𝑙 = 𝜆4 , onde 𝑙 é o
comprimento da antena em metros. Valores usados nos cálculos: 𝑐 = 3. 108 𝑚 𝑠⁄ 𝑓1 = 433 𝑀𝐻𝑧 e 𝑓2 = 315 𝑀𝐻𝑧.
Portanto, temos: Para 𝑓 = 𝑓1 ⇒ 𝑙 = 0,173𝑚 = 17,30𝑐𝑚 Para 𝑓 = 𝑓2 ⇒ 𝑙 = 0,238𝑚 = 23,80𝑐𝑚 Após o conhecimento dos tamanhos teóricos das antenas, foram feitos testes e
ajustes finos de seus tamanhos na prática, o que resultou em duas antenas de 17 cm para os módulos RX e TX de 433 MHz e duas antenas de 23 cm para os módulos RX e TX de 315 MHz.
A comunicação entre transmissor e receptor de mesma frequência é feita com a técnica de modulação digital ASK (Amplitude Shift-Keying) [23], que consiste na alteração da amplitude da onda portadora em função do sinal digital que é transmitido. Quando o Arduino UNO do CCAE envia o sinal em formato digital para o pino de dados do módulo de RF TX 315 MHz ele é modulado através do ASK e é transmitido de forma analógica pela antena de fio do módulo. Tal sinal analógico é recebido pelo módulo de RF RX 315 MHZ através da sua antena de fio e pela demodulação ASK entrega o sinal digital para o Arduino Pro Mini da pulseira de monitoramento. E este processo é feito sincronizado com bits zero e um: quando o bit é 1 a portadora transmite o sinal e quando é 0 não transmite nenhum sinal. Este processo é análogo para os módulos de transmissão e recepção com frequência de 433 MHz. A descrição dessa comunicação pode ser vista na ilustração da Figura 4.7.
Figura 4.7 – Ilustração da comunicação entre os módulos de RF presentes no
CCAE e nas PMPs.
20
4.5 – Levantamento de preços de material do HW
Um dos principais atrativos do SAEMP é o uso de tecnologia aberta, acessível e considerada de baixo custo. Desta forma, foi importante fazer o levantamento dos dispositivos e componentes que compõem a central de controle, as pulseiras de monitoramento e os controles remotos. Esse levantamento é fundamental para uma possível fabricação do sistema em larga escala. Logo abaixo temos a listagem dos preços dos componentes comprados para implementar o projeto. Os sites de vendas que foram usados são apenas alguns dos diversos lugares em que esses componentes podem ser encontrados, mas cumprem muito bem o objetivo de servir como referência para busca de preços. Item Preço (R$) und. QTD Preço
total Referência
CCAE
Arduino UNO R3 39,37 1 39,37 UNO R3
Modulo RTC 9,45 1 9,45 RTC
Modulo de RF 433Mhz (par RX e TX) 6,51 1 6,51 RF 433 Mhz
Modulo de RF 315Mhz (par RX e TX) 11,90 1 11,90 RF 315Mhz
Módulo de cartão Micro SD 4,94 1 4,94 Micro SD
Fonte de alimentação DC 9V 16,91 1 16,91 fonte 9V DC
Caixa de envelopamento da CCAE 13,97 1 13,97 Caixa da CCAE
Preço do CCAE (subtotal 1) 103,05
PMP
Display LCD 16x2 Azul 12,07 1 12,07 display
Arduino Pro Mini 16,80 1 16,80 Pro Mini
Push-button 0,42 2 0,84 push-button
Modulo de RF 433Mhz (par RX e TX) 6,51 1 6,51 RF 433 Mhz
Modulo de RF 315Mhz (par RX e TX) 11,90 1 11,90 RF 315Mhz
Bateria de alimentação 9V 13,90 1 13,90 bateria 9V
resistores 0,10 2 0,20 resistores
Caixa de envelopamento da PMP 6,37 1 6,37 Caixa da PMP
Preço da PMP (subtotal 2) 68,59
CRP
21
resistores 0,10 10 1,00 resistores
capacitores 0,10 3 0,30 capacitores
AMPOP TL072 1,35 1 1,35 AmpOp
led 0,20 1 0,20 led
Fonte de alimentação DC 12V 17,05 1 17,05 fonte 12V DC
push-button 0,42 5 2,10 push-button
Placa perfurada/ impresa 4,60 1 4,60 placa perfurada
Caixa de envelopamento do CRP 8,90 1 8,90 Caixa do CRP
Preço da CRP (subtotal 3) 35,5
Valor total parcial do SAEMP 207,14 Tabela 4.3 – levantamento de preços de componentes do SAEMP
O levantamento feito tem a intenção de ser o mais preciso possível para poder comparar com o preço de outras aplicações semelhantes na área de monitoramento de pacientes. Vale ressaltar que a tabela anterior descreve o preço total de um conjunto com apenas uma central de controle, uma pulseira de monitoramento e um controle remoto. Entretanto, é sugerido um SAEMP que contenha:
• Uma CCAE • Três PMPs • Seis CRPs
Desta forma o valor total do SAEMP de forma aproximada, de acordo com esse levantamento, no varejo é de:
• R$ 103,05 para uma CCAE • R$ 205,77 para três PMPs • R$ 213,00 para seis CRPS • O preço total do SAEMP sugerido seria de R$ 521,82
Vale ressaltar que mudanças no envelopamento podem e devem ser feitas para melhor adequar ergonomicamente os dispositivos aos seus usuários. Com a possível diminuição do preço do SAEMP devido a produção em escala conclui-se que o investimento na sua fabricação para atuar em clínicas/ hospitais é altamente justificável, pois agrega valor ao serviço de monitoramento de pacientes sem a necessidade de alto investimento em tecnologia.
22
5 - Descrição de software do projeto Neste capítulo será mostrado como foi projetado o software do SAEMP, com
detalhamento dos algoritmos, uso de bibliotecas, além de outras características que podem ser vistas a seguir.
O software criado para o SAEMP foi feito de forma a ser o mais simples
possível e atender aos desejos do projeto, alguns dos quais já mencionados anteriormente no texto. Como o hardware do sistema é composto de Arduinos com microcontroladores ATMEGA, a criação do software é dada por programar estes através das interfaces (IDEs) disponíveis para cumprir esse objetivo. Em suma o SW do projeto consiste em um arquivo com extensão (.ino) para cada pulseira de monitoramento e outro arquivo para a central de controle, com extensão (.ino). A seguir são detalhados os softwares para a CCAE e para a PMP. 5.1 – Central de controle de avisos de emergência (CCAE)
Figura 5.1 – Divisão em seções do software da CCAE A central de avisos de emergência tem seu hardware formado por circuitos eletrônicos modulares e circuitos de comunicação RF, além de entradas analógicas disponibilizadas para as CRPs. No capítulo anterior foi bem especificada estas informações, e a partir delas pode-se programar os arduinos UNO e Pro Mini a fim de cumprir os desejos de projeto. Pela ilustração da Figura 5.1 nota-se que o software da CCAE é formado por praticamente quatro blocos de fornecimento de dados. Os botões são provenientes do circuito dos CRPs que enviam diferentes dados provenientes de cada botão que for acionado em cada controle. Como cada controle está conectado em uma entrada analógica diferente do Arduino UNO, consegue-se fazer um programa simples para identificar o controle que foi acionado, e qual aviso foi acionado por este controle.
23
Botão Leitura Arduino (aprox.)
B1 851
B2 681
B3 464
B4 308
B5 182
Tabela 5.1 – Botões e as respectivas leituras feitas pelo Arduino UNO da CCAE
Como visto na Tabela 5.1 é criado condicionais SE no programa para ficar dentro da leitura do arduino em questão. E é feita da mesma forma a identificação de qual controle houve o acionamento de algum botão, já que pelo uso da função analogRead(pino_analógico) consegue-se saber se o pino em questão recebeu nível logico alto ou baixo.
Os controles remotos e avisos de emergência acionados são armazenados em vetores do tipo char, de forma simples, para que seja posteriormente enviado para as pulseiras de monitoramento. É bom ressaltar que declarar esses vetores desta forma facilita o envio e recebimento de dados através dos módulos de RF. Esta comunicação por esses módulos é vista ainda nesse capítulo. Depois que os dados são enviados para as pulseiras, há um aguardo para uma resposta de alguma PMP para realizar o atendimento. Em caso de resposta positiva é gerado um log no cartão micro SD do modulo contendo as informações do atendimento junto com a hora que foi realizado. Essa hora é gerada através do modulo RTC que faz parte da CCAE. Esse log fica disponível no dia de trabalho para poder ser consultado posteriormente se houver necessidade. O programa aguarda até que haja uma resposta positiva de alguma PMP, e enquanto isso realoca os possíveis casos de atendimentos em uma fila de espera. E assim a CCAE aguarda até que a pulseira de monitoramento ocupada mande uma resposta dizendo que pode fazer o AT. Desta forma o primeiro da fila é colocado para atendimento na primeira pulseira que estiver disponível. Se caso houver mais de uma PMP disponível é feito um sorteio através da função random(), presente na IDE do Arduino, para poder escolher um número aleatório acionando a pulseira desta forma. Com isso temos o ciclo de atendimentos que são gerenciados pela central de controle e que distribui os avisos de emergência provenientes dos CRPs usados pelos pacientes para as pulseiras PMPs usadas pelos enfermeiros e médicos.
24
5.2 – Pulseira de Monitoramento de Pacientes (PMP) Com a pulseira o programa criado ficou um pouco menor em termos de
conteúdo e complexidade de algoritmo em relação ao que foi feito e descrito anteriormente para o CCAE. O programa pode ser subdividido em seções referentes às diferentes interações que o Arduino Pro Mini faz quando está carregado com o mesmo, na qual é o arquivo “pmp.ino”. Tais seções podem ser observadas na figura a seguir.
Figura 5.2 – Divisão em seções do software da PMP
O programa carregado no microcontrolador trabalha o tempo todo com as entradas analógicas ativadas a espera de dados oriundos do módulo de recepção de rádio frequência e dos botões do tipo push-button. Tais entradas fornecem ao SW os dados necessários para que o mesmo possa fazer o processamento da informação e gerar uma resposta adequada para o display e módulo de transmissão de RF.
No que se refere aos botões, existe um comportamento diferente entre eles que
diferencia o botão 1 do botão 2, e tal comportamento foi criado através de SW para que o Arduíno pudesse perceber mais de uma função em um único botão. O botão 1 possui duas funções:
(1) confirmar que o cuidador, usuário da pulseira, fará o atendimento solicitado
(2) indicar que o mesmo já terminou de realizar o atendimento em questão. Já o botão 2 exerce apenas uma função: o cuidador recusar o atendimento
solicitado. Para fazer a diferenciação de comportamentos, no caso do botão 1, foi feito o uso da função millis(). Tal função retorna um valor do tipo unsigned long que significa o tempo contado em milissegundos desde o momento em que o programa carregado no Arduíno foi acionado até o momento em que a função é requisitada. Através deste dado pode-se fazer marcações de tempos em tempos a fim de calcular quanto tempo o botão 1 poderia permanecer ligado para indicar um comportamento. Experimentalmente foi atribuído dois intervalos de tempos diferentes para indicar os dois comportamentos:
(1) intervalo de tempo curto.
25
(2) intervalo de tempo longo.
Na figura abaixo pode ser visto com mais detalhes.
Figura 5.3 – Comportamento dos botões mostrados no gráfico e no trecho de código do programa da PMP.
Em suma o procedimento feito foi criar marcações de tempos que guardavam os valores de tempo em milisegundos em momentos específicos durante a execução do programa. Como pode ser visto no código fonte da PMP essas marcações foram chamadas de tempoGeral, tFinal, tInicial e deltaT. Estas variáveis são colocadas em lugares específicos no programa com a finalidade de resultar em diferentes deltaTs ao longo da execução do programa, e cada intervalo de tempo deltaT está associado com uma função diferente dentro do código como por exemplo: duas funções com o uso do mesmo botão 1.
O display LCD 16x2 é responsável por mostrar diferentes mensagens para o
usuário, e elas são criadas nos programas de acordo com as entradas de dados oriundas
26
das interações com as informações dos botões e do módulo de recepção de RF. Tais mensagens são descritas na tabela a seguir.
Mensagem no display Motivo de ser gerada Finalidade da mensagem
PAC:5 AE:3 AT SOLICITADO
O paciente 5 necessita de AT para o AE 3
Avisar aos cuidadores que o paciente 5 solicita AT
PAC:5 AE:3 TEMPO EXPIRADO
O tempo determinado de resposta do cuidador se esgotou.
Avisar ao usuário da PMP que o tempo para o AT ou para ele dar um retorno para o CCAE se esgotou.
PAC:5 AE:3 AT FINALIZADO
Servir de controle para o usuário da PMP e o CCAE
Indicar ao CCAE que o cuidador terminou o AT. Isso é feito segurando o botão 1 por mais de cinco segundos.
PAC:5 AE:3 AT EM PROGRESSO
Servir de controle para o usuário da PMP e o CCAE
Indicar ao CCAE que o cuidador iniciou o AT. Isso é feito apertando o botão 1
PAC:5 AE:3 AT RECUSADO
Servir de controle para o usuário da PMP e o CCAE
Indicar ao CCAE que o cuidador não irá realizar o AT. Isso é feito apertando o botão 2
Tabela 5.2 – Exemplo de caso com as mensagens geradas pelas PMPs.
Entretanto, para que essas mensagens sejam geradas no display o uso da biblioteca LCD LiquidCrystal_I2C [24] é necessária, visto que o modelo do display adotado usa o protocolo de comunicação i2C. As principais funções usadas no projeto estão relacionadas logo abaixo: Função usada Definição LiquidCrystal_I2c lcd (0x27, 16 , 2) no arquivo fonte do programa ela
determina a declaração do objeto lcd do tipo LiquidCrystal_I2c, que é a classe da biblioteca que é descrita nesse trecho do texto. O 0x27 significa o endereço hexadecimal do display LCD no barramento i2C, o 16 refere-se à quantidade de colunas disponíveis no display usado no projeto enquanto o 2 determina o número de linhas disponíveis neste mesmo display.
lcd.init() inicializa o display com algumas configurações básicas e necessárias para seu funcionamento, como: número de bits por linha devido ao tipo de display,
27
quantidade de colunas e linhas. Esse método invoca o método begin().
lcd.begin() está presente no lcd.init(), mas pode ser invocado sozinho para inicializar o display com número de colunas e linhas referentes ao display.
lcd.clear() limpa a tela do display e retorna o cursor na posição inicial (0,0)
lcd.setCursor(colunas, linhas) ajusta o cursor na tela do display como desejado, (coluna,linha) , na qual coluna pode variar de 0 a 15 enquanto que a linha pode variar de 0 a 1.
lcd.backlight() liga o display
lcd.print(mensagem) imprime na tela do display mensagens do tipo string
Tabela 5.3 – Funções da biblioteca LiquidCrystal_I2C usadas no projeto.
Após inicializar o objeto lcd com a configuração certa do display LCD, o próximo passo foi fazer o ajuste realizado no setup() do código fonte. Usou-se as os métodos lcd.init() e lcd.backlight() para isso. No resto do código como poderá ser visto no Apêndice A são usados os outros métodos da Tabela 5.3 para poder escrever e apagar as mensagens no display. 5.3 – Comunicação por radiofrequência
No capítulo sobre hardware foram apresentados os módulos de comunicação RF e todas as suas características, além da forma como é feita a troca de dados entre os mesmos.
Neste momento o texto aborda o código fonte que é implementado nos programas do Arduino UNO e do Pro Mini, já que estes são os dispositivos controladores da CCAE e das PMPs respectivamente. Das figuras anteriores, (5.1 e 5.2) nota-se que a seção em comum entre elas é a sobre radiofrequência. Tal característica já era esperada, pois os módulos trabalham em pares, como dito antes no texto. Desta forma, o SW atua de maneira a contribuir para que essa comunicação ocorra entre um RX de 433 Mhz e o seu respectivo par TX de 433 Mhz. Para a comunicação ser possível com estes módulos e também para os pares de 315 Mhz foi necessário o uso da biblioteca VirtualWire, pois ela fornece todas as funções/métodos importantes para realizar a comunicação entre CCAE e PMPs. A seguir é mostrado uma tabela com as funções usadas e suas respectivas definições.
28
Função usada Definição
vw_set_tx_pin(pino_do_arduino) Usada para definir o pino do Arduino que é usada como conexão com o módulo TX.
vw_set_rx_pin(pino_do_arduino) Usada para definir o pino do Arduino que é usada como conexão com o módulo RX.
vw_rx_start() Inicia o circuito do receptor
vw_wait_tx() Espera até que a mensagem seja totalmente transmitida (aguarda o envio de dados)
vw_setup() Ajusta a velocidade de comunicação entre receptor e transmissor. No projeto é de 2000 bits/segundo.
vw_tx_start() Inicia o circuito do transmissor
vw_have_message() Retorna verdadeiro se existir mensagem disponível
uint8_t vw_send(uint8_t* buf, uint8_t len)
Envia a mensagem desejada e o tamanho da mesma.
Tabela 5.4 – Funções da biblioteca VirtualWire usadas no projeto.
Na prática, os programas feitos para a CCAE e PMPs usaram as mesmas funções da biblioteca VirtualWire [25] já que os mesmos exercem função de receptor de dados como de transmissor de dados. Os códigos fonte completos podem ser vistos posteriormente no apêndice A e apêndice B. Nos programas das PMPs e CCAE são feitos ajustes iniciais para que cada um consiga assumir o papel de transmissor e receptor de dados quando necessário. Esses ajustes são feitos no setup(), e usam os métodos vw_set_tx_pin(), vw_set_rx_pin(), vw_tx_start(), vw_rx_start() e vw_setup(). Os dois primeiros métodos servem para definir qual pino da placa Arduino em questão receberá ou enviará dado para o módulo de RF correspondente. Já os dois seguintes são usados para iniciar o transmissor e habilitar o receptor respectivamente. O último método é o responsável por ajustar a velocidade de transmissão e recepção de dados, e tal velocidade deve ser a mesma para os programas a fim de não ocasionar perda de dados entre os módulos de RF. O método uint8_t vw_have_message() é usado como controle, para identificar se chegou mensagem ou não. Na CCAE principalmente foi importante o uso para indicar qual pulseira de monitoramento respondeu primeiro ao aviso de emergência enviado pelo paciente e fará o atendimento do mesmo. Na PMP é usado para indicar apenas se chegou ou não aviso de emergência.
29
O método uint8_t vw_send(uint8_t* buf, uint8_t len) é fundamental para o
projeto já que ela é usada para enviar os dados de um módulo a outro, ou seja, da central para as pulseiras e vice-versa. O escopo da mensagem enviada foi feito da seguinte maneira:
• A CCAE envia para as PMPs duas mensagens com espaço curto de tempo entre elas. Na primeira consta o número do paciente a ser atendido enquanto que a segunda consta o aviso de emergência solicitado por este paciente. O tempo entre as mensagens é de 100ms adicionado pelo método delay(100).
• As PMPs também enviam duas mensagens: a primeira corresponde a resposta para a solicitação de atendimento. Opções associadas: (1) ACEITAR AT (2) FIM DE AT (3) RECUSAR AT Já a segunda mensagem, entregue 100ms após a primeira, identifica qual PMP respondeu ao chamado.
Vale ressaltar que essas mensagens foram feitas de formas simples e usando vetores do tipo char, a fim de serem compatíveis com a definição da função vw_send utilizada. Com isso tem-se o projeto do software implementado nas placas Arduinos.
6 - Testes e resultados
Neste capítulo será mostrado os testes feitos ao longo do projeto junto com seus resultados, e daí uma discussão é estabelecida para que logo em seguida seja concluído o texto do projeto.
6.1 – Testes de funcionamento dos módulos de radiofrequência Foram usados seis módulos de RF no projeto do SAEMP, dois para a CCAE e outros quatro para os dois circuitos das pulseiras que foram montadas para os testes. As suas características foram descritas nos capítulos anteriores do texto, e o tópico atual apresentará alguns resultados para testes feitos com estes circuitos.
Era importante saber se haveria alguma interferência na comunicação entre os módulos, já que foram usados pares de módulos TX e RX de frequências 433MHz e 315MHz. Nos testes de comunicação entre a CCAE e PMPs não foram detectadas nenhuma interferência que causasse problemas na comunicação dos dispositivos. Cada módulo de transmissão de dados só consegue se comunicar com o respectivo módulo de recepção de mesma frequência.
Outra preocupação com a comunicação por radiofrequência usada foi quanto ao alcance em que se podia conseguir ao usar esses módulos. Com a ajuda de antenas acopladas aos módulos conseguiu-se um alcance de cerca de 15 metros dentro de uma
30
residência com algumas paredes entre o sinal proveniente do circuito transmissor e o receptor. Os testes iniciais foram feitos com Arduinos UNO e Pro Mini, com apenas um par de módulos de RF de 433MHz. Posteriormente foi adicionado os módulos de RF de 315MHz e o resultado não mudou, conseguiu-se alcance similar a 15 metros nos testes. A figura abaixo mostra uma representação, fora de escala, de planta baixa da residência na qual os testes foram feitos.
Figura 6.1 – Teste de alcance de comunicação entre um transmissor e dois receptores.
O teste feito acima foi bem-sucedido e mostra bem próximo como seria uma
situação de aplicação do SAEMP em um hospital ou clínica, já que na figura da planta baixa percebe-se obstáculos presentes entre o transmissor e os receptores. Neste teste também foi feita a comunicação de “volta”, entre receptores e transmissor, com resultado esperado de comunicação concluída com eficiência.
6.2 – Testes de funcionamento dos equipamentos montados e seus resultados
• Funcionamento dos CRPs Anteriormente no texto foi projetado o circuito dos controles remotos para pacientes e feita a descrição de seu funcionamento. Desta forma, o mesmo foi implementado em uma placa de circuitos perfurada para poder ser testada e mostrada como protótipo do CRP na apresentação do projeto. As fotos a seguir mostram testes feitos em laboratório, e os resultados foram dentro do esperado.
31
Figura 6.2 – Teste do CRP1 com a saída analógica ligada no multímetro, botão 3 acionado.
Figura 6.3 – Teste do CRP1 com a saída analógica ligada no multímetro, botão 5 acionado.
As figuras mostram o usuário acionando dois push-buttons diferentes, e como consequência gerando duas tensões diferentes na saída do CRP como pode ser visto no display do multímetro. O circuito foi projetado para obter esse resultado já que uma única saída do controle remoto tem que indicar o acionamento de cinco diferentes push-buttons para o Arduino UNO R3, na qual os controles são conectados. Foram montados dois CRPs para melhor apresentar o funcionamento do SAEMP, e tais controles foram posicionados em uma mesma mesa de suporte que o circuito montado da CCAE.
32
• Funcionamento da CCAE
O circuito da central de controle foi montado em uma protoboard a fim de alojar devidamente os módulos de RF, RTC e SD. Os testes foram feitos com objetivo de saber se o circuito conseguiria se comunicar com os outros enviando e recebendo dados sem a perda do mesmo. A central de controle ficou ligada por cerca de 12 horas ininterruptas enviando e recebendo dados dos circuitos das PMPs sem a perda dos mesmos. O teste inicialmente foi simples, na qual se enviou e recebeu dados já prontos, ou seja, sem a atuação dos CRPs. (Completar com o teste já com os CRPs)
Figura 6.4 – Circuito do CCAE e das PMPs montados na mesa de testes.
• Funcionamento das PMPs A quantidade de pulseiras que serão usadas em um hospital ou clínica é determinada pelos funcionários responsáveis em gerir a área hospitalar que determinam quantos cuidadores são necessários para ficarem de plantão em determinados leitos. Para fins de teste e apresentação do projeto foram montadas duas PMPs, ambas em protoboards e com fontes de alimentação individuais. A imagem a seguir mostra um pouco do seu funcionamento.
33
Figura 6.5 – Teste da PMP1 recebendo dados do CCAE.
7 – Conclusão e sugestões de trabalhos futuros Algumas possibilidades de melhorias ou simplesmente adições de novas características baseado no trabalho apresentado neste texto são sugeridas nas próximas linhas para trabalhos futuros.
A primeira sugestão é a adição de componentes eletrônicos a fim de transpassar uma limitação do Arduino UNO usado na CCAE. Tal limitação é o número pequeno de entradas analógicas que o UNO possui, no caso seis, que são usadas para conectar seis CRPs. Desta forma, se for necessário o uso de mais portas para atender a mais leitos do que o Arduino suporta é sugerido o uso de circuitos adicionais para aumentar o número de portas I/O ou trocar a placa com microcontrolador para uma com mais portas disponíveis como por exemplo o Arduino Mega [26]. O CI 74HC595 [27] que é um registrador de deslocamento ou o circuito PCF8574P [28] que é um expansor de portas I/O podem ser inseridos com o Arduino UNO a fim de aumentar o número de portas disponíveis para uso.
Uma outra sugestão para trabalho futuro é com relação ao controle remoto, que
consta em adicionar mais um fio de dados, que estará conectado a algum aparelho de
34
monitoramento das condições do paciente e informará a central de controle (CCAE) se o paciente está em condição estável ou não estável.
Uma alternativa para a sugestão anterior seria um circuito com microfone que
identificasse pelo som emitido pelos aparelhos de monitoramento de pacientes qual a necessidade do mesmo, como por exemplo: alteração da pressão cardíaca, alteração na frequência cardíaca, alteração nos níveis de oxigênio do sangue, entre outras características monitoradas.
Como última sugestão seria atualizar o trabalho atual com adição de um
computador conectado a CCAE para mostrar os atendimentos em tempo real em seu monitor, além de servir como fonte de banco de dados em relação a esses atendimentos. Tal computador teria uma conexão bluetooth disponível para que médicos ou chefes da enfermagem pudessem obter informações detalhadas do histórico de atendimentos de emergência referentes a aquela CCAE.
Conclusão Uma ressalva a se fazer é em relação ao uso dos módulos SD e RTC. Ao longo
da execução do projeto conclui-se que o uso principalmente do módulo RTC se limitou a apenas inserir horário de atendimento durante o dia de trabalho que o SAEMP fosse usado, já que se optou por não fazer grandes históricos de atendimentos e guarda-los em um micro cartão SD. Isso porque houve problemas ao longo do projeto com o módulo SD, em seu hardware e compatibilidade com os micros cartões disponíveis. Desta forma, o projeto seguiu sem o uso efetivo do módulo SD e módulo RTC como era previsto inicialmente.
Exceto pelos problemas com os módulos supracitados, o projeto funcionou muito bem quanto ao objetivo principal de realizar chamadas de avisos de emergências e estes serem atendidos pelos cuidadores usuários das pulseiras de monitoramento. Vide os testes do capitulo 6, que obtiveram resultados esperados de funcionamento completo dos dispositivos pode-se concluir bem o projeto com um saldo bem positivo e otimista para quem sabe uma continuação do mesmo a fim de lança-lo como um produto final.
35
Bibliografia
[1] “Arduino”, https://www.arduino.cc/en/Guide/Introduction, 2019 , (acesso em 4 de janeiro de 2019)
[2]“Cardiograph”,https://play.google.com/store/apps/details?id=com.macropinch.hydra.android&hl=en, 2019 , (acesso em 4 de janeiro de 2019) [3] “Lembrete de remédios”,
https://play.google.com/store/apps/details?id=com.medisafe.android.client&hl=pt_BR , 2019, (acesso em 4 de janeiro de 2019)
[4] “Brhommed”, http://www.brhommed.com.br/saude-digital/gerenciamento-remoto-de-pacientes/, 2019, (acesso em 4 de janeiro de 2019) [5] “Magnetic-resonance”, https://www.philips.com.br/healthcare/solutions/magnetic-
resonance , 2019, (acesso em 4 de janeiro de 2019) [6] “Patient-monitoring “, https://www.philips.com.br/healthcare/solutions/patient-monitoring , 2019, (acesso em 4 de janeiro de 2019) [7] “brhommed”, http://www.brhommed.com.br/ , 2019, (acesso em 12 de janeiro de 2019) [8] “Arduino UNO R3”, https://store.arduino.cc/usa/arduino-uno-rev3, 2019 , (acesso em 4 de janeiro de 2019) [9] “Modulo RTC DS 1307”, https://www.filipeflop.com/produto/real-time-clock-rtc-ds1307/ , 2019 , (acesso em 19 de janeiro de 2019) [10] “Modulo micro SD”, https://www.filipeflop.com/produto/modulo-cartao-micro-sd/, 2019 , (acesso em 19 de janeiro de 2019) [11] “Modulo RF RX 433”, https://www.filipeflop.com/produto/modulo-rf-transmissor-receptor-433mhz-am/ , 2019 , (acesso em 22 de janeiro de 2019) [12] “Modulo RF TX 315”, https://www.filipeflop.com/produto/modulo-rf-transmissor-receptor-315mhz-am/ , 2019 , (acesso em 22 de janeiro de 2019) [13] “ATMEGA328p”, http://pdf1.alldatasheet.com/datasheet-pdf/view/241077/ATMEL/ATMEGA328P.html , 2019 , (acesso em 22 de janeiro de 2019)
36
[14] “Protocolo SPI”, https://www.arduino.cc/en/Reference/SPI,
2019 , (acesso em 23 de janeiro de 2019)
[15] “Protocolo I2C”, http://www.arduinobr.com/arduino/i2c-protocolo-de-comunicacao/, 2019 , (acesso em 2 de fevereiro de 2019) [16] “DS 1307 http://pdf.datasheetcatalog.com/datasheet_pdf/dallas-semiconductor/DS1307_to_DS1307ZN.pdf , 2019 , (acesso em 2 de fevereiro de 2019) [17] “Arduino Pro Mini”, https://www.arduino.cc/en/Guide/ArduinoProMini , 2019 , (acesso em 2 de fevereiro de 2019) [18] “Display LCD 16x2”, https://img.filipeflop.com/files/download/Datasheet_Display_16x2.pdf , 2019 , (acesso em 2 de fevereiro de 2019) [19] “Efeito bouncing”, https://www.embarcados.com.br/leitura-de-chaves-debounce/, 2019 , (acesso em 16 de fevereiro de 2019) [20] “AMPOP TL072”, http://pdf.datasheetcatalog.com/datasheet/stmicroelectronics/2298.pdf , 2019 , (acesso em 16 de fevereiro de 2019) [21] “Modulo ESP-8266”, https://www.filipeflop.com/blog/guia-do-usuario-do-esp8266/ , 2019 , (acesso em 18 de fevereiro de 2019) [22] “Modulo NRF-24L01”, https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF24-series , 2019 , (acesso em 20 de fevereiro de 2019) [23] “Modulação digital ASK”, https://professores.unisanta.br/isfarias/Materia/Comunicacao%20Digital/ask.pdf , 2019 (acesso em 20 de fevereiro de 2019) [24] “LiquidCrystal-I2C-library ”, https://github.com/fdebrabander/ArduinoLiquid-Crystal-I2C-library , 2019 , (acesso em 20 de fevereiro de 2019) [25] “VirtualWire library”, https://github.com/manashmndl/VirtualWire/tree/master/VirtualWire , 2019 , (acesso em 20 de fevereiro de 2019) [26] “Arduino Mega”, https://www.arduino.cc/en/Guide/ArduinoMega2560 , 2019 , (acesso em 20 de fevereiro de 2019) [27] “74HC595”, http://pdf.datasheetcatalog.com/datasheet/motorola/MC54HC595.pdf , 2019 (acesso em 20 de fevereiro de 2019) [28] “PCF8574P”, https://pdf1.alldatasheet.com/datasheet-pdf/view/18213/PHILIPS/PCF8574P.html , 2019 , (acesso em 20 de fevereiro de 2019)
37
Apêndice A - Código fonte do programa da PMP Arquivo pmp.ino #include <Wire.h> #include <LiquidCrystal_I2C.h> #include <VirtualWire.h> #define MAX_DE_PINOS 5 #define QTD_PACIENTES 5 /*funcao abaixo importante por indicar aonde na memoria o dipositivo lcd I2c vai atuar, e a quantidade de colunas e linhas ocupadas LiquidCrystal_I2C lcd(endereço em HEX,colunas,linhas); endereço padrão = 0x27 (a maioria está ajustada para esse endereço) usa-se o i2C_scanner (feito na IDE do arduino) para procurar os dispositivos que usam o protocolo i2C e qual endereço está sendo ocupado por eles */ LiquidCrystal_I2C lcd(0x27,16,2); // set the LCD address to 0x27 for a 16 chars(colunas) and 2 line(linhas) display const int pin_botao1 = A0; // const int pin_botao2 = A1; // unsigned long tempoGeral; unsigned long deltaT = 0; unsigned contador = 0; unsigned statusBotao = 0; unsigned statusInicio = 0; unsigned statusReceptor = 0; char message[VW_MAX_MESSAGE_LEN]; void setup() { pinMode(pin_botao1,INPUT); pinMode(pin_botao2,INPUT); lcd.init(); // initialize the lcd lcd.backlight(); // liga o display lcd.setCursor(3,0); lcd.print("SAEMP - PMP"); delay(5000); Serial.begin(9600); Serial.print("## Pulseira de monitoramento de pacientes ## \n"); vw_set_rx_pin(3); // Define o pino n do Arduino como entrada RX 315MHz vw_set_tx_pin(2); //TX 433MHz vw_setup(2000); // Bits por segundo vw_rx_start(); // Inicializa o receptor
38
} void loop() { uint8_t mess[VW_MAX_MESSAGE_LEN]; //mudei aqui o nome do array uint8_t msgLength = VW_MAX_MESSAGE_LEN; unsigned long tInicial, tFinal; //ficar de olho no deltaT se aparece lixo inicialmente int botao1, botao2; statusReceptor = 1; //forçando uma inicializacao da variavel do receptor RF /*referente ao RF*/ if (vw_get_message(mess, &msgLength)) // Non-blocking { //Serial.print("Recebido: "); //lcd.clear(); //Apaga o buffer e o display for (int i = 0; i < msgLength-1; i++) { message[i] = mess[i]; //tentativa corrigir // Serial.write(message[i]);//tentativa corrigir //lcd.print(message[i]); delay(1000); } //message[i] = '\0'; DESNECESSARIO lcd.print(message);// DESNECESSARIO // Serial.println(); } //provavel que tenha uma checagem para ver em tempos em tempos qndo vem MSG do receptor RF tempoGeral = millis(); //imporante //condicionar statusInicio referente ao botao1 e a entrada do receptor RF if( (statusInicio == 0)&&(statusReceptor == 1) ) { lcd.clear(); lcd.print("PAC:"); //lcd.print("2"); //vai vim do receptor RF lcd.print(message); lcd.setCursor(9,0); //lcd.setCursor(COLUNA,LINHA) lcd.print("AE:"); lcd.setCursor(12,0);//ajusta aonde vai o AE no lcd //lcd.print("3"); //vai vim do receptor RF lcd.setCursor(1,1); lcd.print("AT solicitado");//mensagem vai aparecer SE for solicitado AT do receptor RF
39
} else if( (statusReceptor == 0) ) { lcd.clear(); lcd.print("PAC:"); lcd.print("--"); //vai vim do receptor RF lcd.setCursor(9,0); //lcd.setCursor(COLUNA,LINHA) lcd.print("AE:"); lcd.setCursor(12,0);//ajusta aonde vai o AE no lcd lcd.print("--"); //vai vim do receptor RF lcd.setCursor(1,1); lcd.print("Em espera ... ");//mensagem vai aparecer SE for solicitado AT do receptor RF } //lcd.setCursor(0,0); delay(500); botao1 = analogRead(pin_botao1); botao2 = analogRead(pin_botao2); tInicial = tempoGeral; //imporante contador++; //contador pra determinar o tempo expirado de AT /*BOTAO 1*/ while(botao1 > 900) { contador = 0; delay(100);//0.5s a cada repeticao do while tFinal = millis(); deltaT = tFinal - tInicial; botao1 = analogRead(pin_botao1); //imporante statusBotao = 1; //determina se o botao1 ou botao2 foi acionado, 0 --> indica retorno ao status inicial } delay(250);//importante deixar algo aqui if( (deltaT < 1500) && (deltaT > 20) && (statusBotao == 1) ) { lcd.setCursor(1,1); lcd.print("AT em progresso "); Serial.println("SIM para o AT"); //retirar ou nao isso aqui // ou atendimento em progresso lcd.print("AT em progresso "); // so mudar a msg qndo o AT for finalizado deltaT = 0; delay(1000); statusBotao = 0; statusInicio = 1;//indica que o AT foi iniciado e esta em progresso //ENVIAR MSG PARA O TRANSMISSOR RF }else if((deltaT < 7000)&&(deltaT > 2000)&&(statusBotao == 1)&&(statusInicio == 1)) { lcd.setCursor(1,1); lcd.print("AT terminado "); Serial.println("FIM DE AT"); //delay(1000); deltaT = 0; delay(1000);
40
statusBotao = 0; statusInicio = 0; //indica que o AT foi terminado, volta para o status ZERO //ENVIAR MSG PARA O TRANSMISSOR RF } /*BOTAO 2*/ while(botao2 > 900) { contador = 0; delay(100);//0.5s a cada repeticao do while tFinal = millis(); deltaT = tFinal - tInicial; botao2 = analogRead(pin_botao2); //imporante statusBotao = 2; } delay(250);//importante deixar algo aqui if( (deltaT < 5000) && (deltaT > 20) && (statusBotao == 2 ) ) { lcd.setCursor(1,1); lcd.print("AT recusado "); Serial.println("NAO para o AT"); //recusar AT //lcd.print("AT Recusado "); // so mudar a msg qndo o AT for finalizado deltaT = 0; statusBotao = 0; delay(1000); //ENVIAR MSG PARA O TRANSMISSOR RF } /*rotina quando nao recebe resposta dos botoes*/ if(contador > 10) //TEMPO EXPIRADO (colocar 50 ou 500, calcular o tempo em segundos e minutos) { lcd.setCursor(1,1); lcd.print("AT expirado "); delay(3000); Serial.println("passou pelo cont"); Serial.println(contador); contador = 0; //ENVIAR MSG PARA O TRANSMISSOR RF } }
41
Apêndice B - Código fonte do programa da
CCAE #include "crp.h" #include <VirtualWire.h> #define QTD_DE_CRP 3 //CRP = controle remoto do paciente #define QTD_DE_AE 5 //AE = aviso de emergencia #define QTD_MAX_AT 10 //quantidade maxima de atendimentos #define QTD_MAX_PMP 3 //quantidade máxima de pulseiras #define OK 0 #define FILA_VAZIA 30 #define FILA_NAO_VAZIA 40 #define FILA_CHEIA 50 int contVagas = 0; int pinControle1 = A0; int pinControle2 = A1; int pinControle3 = A2; int controle, avisoEmergencia; int statusFila, statusControles; int senhaFila = 0; filaDeAt filaDeAT[10]; int pinosDeEntradas[3] = {pinControle1,pinControle2,pinControle3}; filaTriagem filaDeTriagem[2];//QTD_MAX_PMP 2 /*parte referente a RF*/ char message[VW_MAX_MESSAGE_LEN]; // Armazena as mensagens recebidas byte msgLength = VW_MAX_MESSAGE_LEN; // Armazena o tamanho das mensagens
42
void setup() { Serial.begin(9600); /*parte referente a RF*/ vw_set_tx_pin(2); //Define o pino 2 do Arduino como o pino de dados do transmissor vw_set_rx_pin(3); // RX 433MHz /*parte do receptor*/ vw_setup(2000); // Bits per sec vw_rx_start(); /*parte do receptor*/ Serial.println("## ---> teste do CCAE <--- ##"); statusFila = inicializarFilaDeAtendimento(filaDeAT);//inicializar quando liga o sistema } void loop() { char ae1[5] = "AE:1 "; char ae2[5] = "AE:2 "; char ae3[5] = "AE:3 "; char ae4[5] = "AE:4 "; char ae5[5] = "AE:5 "; char pac1[6] = "PAC:1 "; char pac3[6] = "PAC:2 "; char pac2[6] = "PAC:3 "; delay(500); Serial.println("\n ...aguardando algum CRP"); Serial.println("\n ..."); statusControles = verificarControles(&controle, &avisoEmergencia); //verificarControles(controle, avisoEmergencia); se == 2, entao controles LIGADOS if(statusControles == 2) { inserirNaFilaDeAtendimento(&controle, &avisoEmergencia, filaDeAT); delay(2000); /*enviar para as pulseiras de monitoramento*/ int indiceRF_pac = filaDeAT[0].pacientes; int indiceRF_ae = filaDeAT[0].avisosDeEmergencia; //paciente 1 if(indiceRF_pac == 1)
43
{ send(pac1); delay(250); if(indiceRF_ae == 1) send(ae1); if(indiceRF_ae == 2) send(ae2); if(indiceRF_ae == 3) send(ae3); if(indiceRF_ae == 4) send(ae4); if(indiceRF_ae == 5) send(ae5); } //paciente 2 if(indiceRF_pac == 2) { send(pac2); delay(250); if(indiceRF_ae == 1) send(ae1); if(indiceRF_ae == 2) send(ae2); if(indiceRF_ae == 3) send(ae3); if(indiceRF_ae == 4) send(ae4); if(indiceRF_ae == 5) send(ae5); } //paciente 3 if(indiceRF_pac == 3) { send(pac3); delay(250); if(indiceRF_ae == 1) send(ae1); if(indiceRF_ae == 2) send(ae2); if(indiceRF_ae == 3) send(ae3); if(indiceRF_ae == 4) send(ae4); if(indiceRF_ae == 5) send(ae5); } delay(1000);
44
} /*parte do receptor*/ /*Vai receber da PMP*/ uint8_t mess[VW_MAX_MESSAGE_LEN]; //mudei aqui o nome do array uint8_t msgLength = VW_MAX_MESSAGE_LEN; int i; if (vw_get_message(mess, &msgLength)) // Non-blocking { //Serial.print("Recebido: "); //lcd.clear(); //Apaga o buffer e o display for (i = 0; i < msgLength-1; i++) { message[i] = mess[i]; lcd.print(message[i]); digitalWrite(7,HIGH); delay(1000); digitalWrite(7,LOW); delay(1000); } } }//FIM do loop() void send (char *message) { /*transmissao da CCAE para as PMPs*/ vw_send((uint8_t *)message, strlen(message)); vw_wait_tx(); // Aguarda o envio de dados } /* funcao verificarControles() verifica se os controles foram acionados, recebe o controle acionado e seu respectivo AE deixa disponivel esses dados! (FAZER POR REFERENCIA ISSO, ponteiros) e retorna controlesDesligados OU controlesLigados controle = 1,2,3,4,5 ou 6 avisoEmergencia = 1,2,3,4 ou 5
45
*/ int verificarControles(int *p_controle, int *p_avisoEmergencia) { int entradas[QTD_DE_CRP]; //variavel local para ler as entradas analogicas int controles; //var local para definir se controles estao ligados (2) ou desligados (1) for(int indiceEntradas = 0; indiceEntradas < QTD_DE_CRP; indiceEntradas++) { entradas[indiceEntradas] = analogRead(pinosDeEntradas[indiceEntradas]); } controles = 1; //controlesDesligados // for(int indiceEntradas = 0; indiceEntradas < QTD_DE_CRP; indiceEntradas++) { //entrada A0..A1..A2.. ..A5 foram acionadas, ou seja, o controle 1 a 6 if(entradas[indiceEntradas] > 100) { *p_controle = indiceEntradas + 1; /*verificacao de qual tipo de aviso de emergencia foi escolhido*/ if(entradas[indiceEntradas] > 900) { *p_avisoEmergencia = 1;// aviso de emergencia é do tipo 1 Serial.print("Paciente: "); Serial.print(*p_controle); Serial.print(" -- "); Serial.print("Aviso: "); Serial.print(*p_avisoEmergencia); Serial.print("\n\n"); }else if((entradas[indiceEntradas] < 900) && (entradas[indiceEntradas] > 600)) { *p_avisoEmergencia = 2; // aviso de emergencia é do tipo 2 Serial.print("Paciente: "); Serial.print(*p_controle); Serial.print(" -- "); Serial.print("Aviso: "); Serial.print(*p_avisoEmergencia); Serial.print("\n\n"); }else if((entradas[indiceEntradas] < 550) && (entradas[indiceEntradas] > 400)) { *p_avisoEmergencia = 3; // aviso de emergencia é do tipo 3
46
Serial.print("Paciente: "); Serial.print(*p_controle); Serial.print(" -- "); Serial.print("Aviso: "); Serial.print(*p_avisoEmergencia); Serial.print("\n\n"); }else if((entradas[indiceEntradas] < 380) && (entradas[indiceEntradas] > 250)) { *p_avisoEmergencia = 4; // aviso de emergencia é do tipo 4 Serial.print("Paciente: "); Serial.print(*p_controle); Serial.print(" -- "); Serial.print("Aviso: "); Serial.print(*p_avisoEmergencia); Serial.print("\n\n"); }else if((entradas[indiceEntradas] < 250) && (entradas[indiceEntradas] > 50)) { *p_avisoEmergencia = 5; // aviso de emergencia é do tipo 4 Serial.print("Paciente: "); Serial.print(*p_controle); Serial.print(" -- "); Serial.print("Aviso: "); Serial.print(*p_avisoEmergencia); Serial.print("\n\n"); } controles = 2; //controlesLigados }//fim do IF das entradas analogicas Serial.println("\n\n"); }// fim do FOR do indiceEntradas return controles; // retorna se o controles estao desligados ou ligados }//FIM do verificarControles
47
/* funcao para inicializar a matriz da filaDeAT em zeros retorna status OK quando termina ZERA a matriz no momento em que o sistema é ligado, */ int inicializarFilaDeAtendimento(filaDeAt filaDeAT[]) { for(int indice = 0; indice < QTD_MAX_AT; indice++) { filaDeAT[indice].pacientes = 0; } //linha apenas de teste acima Serial.println(); Serial.println("\n\n Fila de atendimento:"); for(int indice1 = 0; indice1 < QTD_MAX_AT; indice1++) { Serial.print(filaDeAT[indice1].pacientes); Serial.print("--"); } return FILA_VAZIA; } //funcao para inserir na fila de atendimento //e para inserção de avisos de emergencia? colocar na mesma funcao com passagem por referencia // da mesma forma que a filaDeAT[] //int inserirNaFilaDeAtendimento(int controle, int avisoEmergencia, int filaDeAT[]) int inserirNaFilaDeAtendimento(int *p_controle, int *p_avisoEmergencia,filaDeAt filaDeAT[]) { //linhas apenas de teste Serial.println("\n\n Fila de atendimento:"); for(int indice1 = 0; indice1 < QTD_MAX_AT; indice1++)
48
{ Serial.print(filaDeAT[indice1].pacientes); Serial.print("--"); } Serial.println("\n\n"); //-----------------------------------------// //começar aqui a inserir na filaDeAT //verificar se FILA esta vazia e se algum controle foi acionado //dai inserir no começo da fila if( (statusFila == FILA_VAZIA)&&(statusControles > 0) ) { //inserção do primeiro elemento/paciente na fila, primeira posicao filaDeAT[0].pacientes = *p_controle; filaDeAT[0].avisosDeEmergencia = *p_avisoEmergencia; senhaFila++; statusFila = FILA_NAO_VAZIA; delay(500); //retirar essa linha }else if (statusControles > 0) { //inserir aqui se a FILA não esta vazia filaDeAT[senhaFila].pacientes = *p_controle; filaDeAT[senhaFila].avisosDeEmergencia = *p_avisoEmergencia; senhaFila++; //Serial.println("\n proximo da Fila de atendimento:");//retirar essa linha //Serial.println(filaDeAT[senhaFila].pacientes); //retirar essa linha delay(500); //retirar essa linha } return OK; }//FIM do criarFilaDeAtendimento
49
Apêndice C - Esboço conceitual 3D do SAEMP A seguir são mostrados modelos 3D conceituais dos dispositivos que foram descritos ao longo do texto, são aparelhos (ou envelopamentos) que teriam em seu interior todo o hardware e software descrito e projetado neste trabalho.
CRP PMP
CCAE
50
Apêndice D – Esquemático do SAEMP A figura a baixo é um esquemático do sistema interagindo com todos os dispositivos que foram apresentados ao longo do texto. Se observar no desenho, o Arduino Pro Mini especificado do projeto e usado nas PMPs está sendo representado pelo Simulino Nano no esquemático.
