Embed Size (px)
Citation preview
Dispensador de Medicamentos
Nuno Miguel Lopes dos Santos
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Orientadores: Prof. Renato Jorge Caleira Nunes
Prof. Paulo Rogério Barreiros D' Almeida Pereira
Júri
Presidente: Prof. Nuno Cavaco Gomes Horta
Orientador: Prof. Renato Jorge Caleira Nunes
Vogal: Prof. João Nuno de Oliveira e Silva
Novembro de 2015
i
Agradecimentos
A realização desta dissertação de mestrado apenas foi possível com o apoio de várias
pessoas, às quais quero deixar um agradecimento por toda a ajuda e disponibilidade.
Ao meu grande amigo Pedro Marques, Engenheiro Mecânico, por ter desenhado toda a
estrutura mecânica do protótipo criado e por, incansavelmente, se ter disponibilizado para realizar os
vários ajustes que foram necessários ao longo do processo de desenvolvimento.
À Glintt Engineering, por se ter disponibilizado para conhecer o meu projecto e por me ter
permitido realizar a impressão em 3D de toda a estrutura mecânica do protótipo, sem qualquer custo.
Ao professor Renato Nunes, pelo seu excelente trabalho enquanto orientador, disponibilidade
e apoio na resolução de todos os problemas que surgiram ao longo deste projecto.
Por fim, mas não menos importante, à minha família, por todo o apoio que me deram durante
este longo percurso e, em particular, à minha irmã, Ana Margarida Santos, por ter partilhado comigo o
seu conhecimento na área da saúde, que me ajudou em várias das decisões tomadas.
ii
iii
Resumo A esperança média de vida do ser humano tem vindo a aumentar, observando-se um
envelhecimento da população em geral. Associado ao envelhecimento, observa-se com frequência
perdas de capacidade cognitiva e falhas de memória, o que pode ter grande impacto na qualidade de
vida e autonomia das pessoas que tenham de cumprir um plano terapêutico.
Neste trabalho é descrito o desenvolvimento de um protótipo de um dispensador de
medicamentos, que pretende combater a falta de aderência a regimes de medicação, especialmente
de idosos e pessoas com limitações cognitivas.
Foram analisadas as funcionalidades de vários produtos existentes no mercado que abordam
este problema, tendo sido identificadas várias restrições e limitações. Com base nesta análise, foi
definida a lista de funcionalidades pretendidas e foi definida a arquitectura global da solução a
desenvolver.
Destaca-se como principal requisito a criação de uma solução aberta, que privilegia a
comunicação com outros dispositivos (Smartphones e Tablets) e a ligação à Internet, podendo ser
adaptada a diferentes contextos de utilização.
Dada a ênfase na abertura e na capacidade de interacção remota, foi também desenvolvida
uma API de programação que possibilita a terceiros desenvolverem aplicações de interacção com o
dispensador, podendo optimizá-las para contextos específicos e permitindo a automatização de
procedimentos de configuração (por exemplo, definição do plano terapêutico) e a recolha de
ocorrências (por exemplo, tomas falhadas e tentativas de acesso a horas indevidas).
O protótipo desenvolvido mostrou satisfazer os requisitos propostos, tendo culminado numa
solução modular, versátil e de custo acessível, que implementa as funcionalidades planeadas.
Palavras chave: Dispensador de medicamentos, Gestão terapêutica, Tecnologias assistivas,
Sistemas embebidos.
iv
v
Abstract The average life expectancy of human beings is increasing, resulting in an aging population.
Associated with aging, there is often loss of cognitive capabilities and memory problems, which can
have a major impact on quality of life and autonomy of people required to comply with a therapeutic
plan.
This report describes the development of a prototype of a medication dispenser, which aims to
combat the lack of adherence to medication regimens, especially for the elderly and people with
cognitive limitations.
The features of several products on the market that address this issue were analyzed, leading
to the identification of several restrictions and limitations. Based on this analysis, a list of required
features and the overall architecture of the solution to be developed were defined.
One of the main requirements was to create an open solution that focuses on communication
with other devices (Smartphones and Tablets) and the connection to the Internet, allowing it to be
adapted to different contexts of use.
Given the emphasis in the openness and remote interaction capacity, a programming API has
also been created, allowing third parties to develop and optimize applications to interact with the
dispenser in specific contexts, and allowing the automation of configuration procedures (e.g. defining
the therapy plan) and the collection of events (e.g. failed doses and access attempts in hours not
allowed).
The prototype developed fulfilled the proposed requirements, culminating in a modular,
versatile and affordable solution, which implements the planned features.
Keywords: Medication dispenser, Therapeutic management, Assistive technologies, Embedded
systems.
vi
vii
Índice
Agradecimentos ......................................................................................................................................i
Resumo................................................................................................................................................... iii
Abstract ...................................................................................................................................................v
Lista de Figuras ..................................................................................................................................... xi
Lista de Tabelas ................................................................................................................................... xiii
Glossário ............................................................................................................................................... xv
1. Introdução ........................................................................................................................................ 1
1.1 Motivação ............................................................................................................................. 1
1.2 Objectivos ............................................................................................................................. 2
1.3 Estrutura da tese .................................................................................................................. 3
2. Estado da Arte ................................................................................................................................ 4
2.1 Dispensadores de Medicamentos ........................................................................................ 4
2.2 MedSmart MD2 .................................................................................................................... 4
2.3 Philips Medication Dispenser ............................................................................................... 8
2.4 Medfolio Electronic Pillbox.................................................................................................. 12
2.5 MedHelper .......................................................................................................................... 14
2.6 Outros produtos .................................................................................................................. 15
3. Descrição da Solução Proposta ............................................................................................... 16
3.1 Funcionalidades do Dispensador ....................................................................................... 16
3.2 Cenários de Utilização ....................................................................................................... 19
3.3 Arquitectura do Dispensador .............................................................................................. 22
3.4 Selecção dos Módulos Constituintes ................................................................................. 23
3.4.1 Módulo GSM ........................................................................................................... 24
3.4.2 Módulo Wi-Fi ........................................................................................................... 25
3.4.3 Módulo Bluetooth .................................................................................................... 26
3.4.4 Módulo RTC ............................................................................................................ 27
3.4.5 Motor ....................................................................................................................... 28
3.4.6 Sensor de controlo de posição ................................................................................ 29
3.4.7 Teclado .................................................................................................................... 30
3.4.8 Display ..................................................................................................................... 30
viii
3.4.9 Bezouro ................................................................................................................... 31
3.5 Selecção do módulo de processamento ............................................................................. 32
3.5.1 Entradas/saídas e periféricos do microcontrolador ................................................. 32
3.5.2 Placa de desenvolvimento ...................................................................................... 34
3.5.3 Placa “Arduino Mega” ............................................................................................. 35
3.6 Outros componentes do sistema ........................................................................................ 36
4. Detalhes de implementação ...................................................................................................... 40
4.1 Estrutura do programa ....................................................................................................... 40
4.2 Data e hora ......................................................................................................................... 41
4.3 Dispensa de medicação ..................................................................................................... 42
4.3.1 Alarmes de dispensa ............................................................................................ 42
4.3.2 Modo diário........................................................................................................... 45
4.3.3 Medicação PRN ................................................................................................... 46
4.3.4 Monitorização de tentativas de dispensa não autorizadas .................................. 46
4.4 Mecanismo de dispensa .................................................................................................... 47
4.5 Avisos textuais ................................................................................................................... 48
4.6 Comunicação com o dispensador ...................................................................................... 49
4.6.1 Comunicação Bluetooth ....................................................................................... 49
4.6.2 Comunicação Wi-Fi .............................................................................................. 49
4.6.3 Comunicação GSM .............................................................................................. 50
4.6.4 Envio de comandos .............................................................................................. 51
4.6.5 Notificações remotas ............................................................................................ 54
4.6.6 API ........................................................................................................................ 55
4.6.7 Realização de chamadas ..................................................................................... 56
4.7 Interacção directa com o dispensador ................................................................................. 56
4.7.1 Organização dos menus ...................................................................................... 56
4.7.2 Implementação dos menus ................................................................................. 57
4.8 Registo persistente de informação ....................................................................................... 59
4.9 Segurança ............................................................................................................................ 62
4.10 Gestão de energia ................................................................................................................ 64
5. Análise dos resultados .............................................................................................................. 65
ix
5.1 Testes .................................................................................................................................. 65
5.2 Análise de custos ................................................................................................................ 67
5.3 Consumo energético .......................................................................................................... 68
5.4 Recursos utilizados no microcontrolador ........................................................................... 71
6. Conclusão ................................................................................................................................... 72
7. Bibliografia .................................................................................................................................. 75
Anexos .................................................................................................................................................. 81
A.1. Algoritmo de funcionamento do protocolo série .................................................................. 81
A.2. Lista de comandos do protocolo de comunicação .............................................................. 82
A.3. Tipos de notificações remotas geradas pelo dispensador .................................................. 84
A.4. Dimensões dos dados guardados em EEPROM ................................................................ 84
A.5. Custo dos componentes electrónicos utilizados .................................................................85
x
xi
Lista de Figuras
Figura 1 - Equipamento MedSmart ........................................................................................................ 5
Figura 2 - Método de retirar os comprimidos do dispensador.. .............................................................. 6
Figura 3 - Representação do interior do MedSmart e interface de programação.. ................................ 7
Figura 4 - Esquema do dispensador e dos seus principais componentes ............................................. 8
Figura 5 - Esquema do interior do dispensador da Philips.. ................................................................... 9
Figura 6 - Teclado de interação com o sistema.. ................................................................................. 11
Figura 7 - Estrutura de documentação dos medicamentos tomados . ................................................. 13
Figura 8 – Exemplo de uma arquitectura de configuração de múltiplos dispensadores. ..................... 20
Figura 9 – Exemplo de uma arquitectura com troca de dados através da Internet. ............................ 21
Figura 10 – Comunicação remota com o dispensador utilizando GSM. .............................................. 21
Figura 11 – Arquitectura do dispensador. ............................................................................................ 22
Figura 12 – Placa GSM baseada no módulo SIM900.. ........................................................................ 25
Figura 13 – Módulo ESP-01, baseado no dispositivo ESP8266.. ........................................................ 26
Figura 14 – Módulo de comunicação baseado no dispositivo HC-06 .................................................. 27
Figura 15 – Módulo RTC que usa o DS3231 e a EEPROM AT24C32 ................................................ 28
Figura 16 – Motor de passo 28BYJ-48. ................................................................................................ 28
Figura 17 – Princípio de funcionamento de um sensor de Hall e de um optocouplador ..................... 29
Figura 18 – Optocouplador ITR9608 e diagrama eléctrico correspondente . ...................................... 30
Figura 19 – Teclado de membrana utilizado no protótipo e correspondente esquema eléctrico . ...... 30
Figura 20 – LCD QC2004A, utilizado no protótipo.. ............................................................................. 31
Figura 21 – Placa de desenvolvimento Arduino Mega ......................................................................... 36
Figura 22 – Esquema eléctrico do circuito de alimentação do dispensador. ....................................... 37
Figura 23 – Esquema eléctrico do protótipo desenvolvido. .................................................................. 38
Figura 24 – Representação em memória de alarmes associados a múltiplos compartimentos. ......... 43
Figura 25 – Carregamento de alarmes para memória RAM. ............................................................... 43
Figura 26 – Exemplo de conflito entre o tempo de tolerância de um alarme e o disparo do seguinte. 44
Figura 27 – Exemplo de uma situaçao de conflito nos alarmes, causada pela dose antecipada. ....... 44
Figura 28 – Configuração dos alarmes usando o modo diário. ............................................................ 45
Figura 29 – Funcionamento da monitorização de tentativas de dispensa não autorizadas........ ........ 46
xii
Figura 30 – Processo de envio de uma notificação por GSM.... .......................................................... 51
Figura 31 – Procedimento de cópia e estruturação dos dados recebidos. .......................................... 52
Figura 32 – Estrutura das mensagens de comunicação com o dispensador. ..................................... 52
Figura 33 – Estrutura das mensagens de resposta aos comandos. .................................................... 53
Figura 34 – Esquema de tratamento dos comandos recebidos..... ...................................................... 54
Figura 35 – Formato de uma notificação textual, cuja dimensão depende do tipo de notificação. ..... 54
Figura 36 – Exemplo de alguns menus da aplicação desenvolvida para Android. .............................. 55
Figura 37 – Organização estrutural dos menus do dispensador........ ................................................. 57
Figura 38 – Exemplo da representação interna das posições navegáveis de um menu. .................... 58
Figura 39 – Exemplo da estrutura que guarda os dígitos introduzidos nos campos de entrada. ........ 58
Figura 40 – Estrutura dos alarmes...... ................................................................................................. 59
Figura 41 – Estrutura dos avisos textuais. ........................................................................................... 60
Figura 42 – Estrutura das entradas associadas aos medicamentos PRN. ......................................... 60
Figura 43 – Estrutura de uma mensagem textual........ ........................................................................ 60
Figura 44 – Estrutura de um evento de tentativa de acesso a medicação fora do horário permitido. . 61
Figura A.1.1 - Funcionamento do protocolo de recepção de dados por comunicação série...............81
xiii
Lista de Tabelas
Tabela 1 – Requisitos de entradas/saídas e interfaces de comunicação para o microcontrolador ..... 32
Tabela 2 - Principais estruturas de dados a utilizar e dimensão correspondente. ............................... 34
Tabela 3 – Listagem das interrupções utilizadas no programa desenvolvido..... ................................. 40
Tabela 4 – Tempo de envio de alguns dos comandos do dispensador. .............................................. 67
Tabela 5 – Consumo de corrente dos principais componentes do sistema. ........................................ 69
Tabela A.2.1 - Comandos do protocolo de comunicação.................................................................... 82
Tabela A.4.1 - Dimensões dos dados guardados na EEPROM do microcontrolador..........................84
Tabela A.5.1 - Custo dos componentes utilizados no desenvolvimento do protótipo..........................85
xiv
xv
Glossário API Application Programming Interface.
ASCII American Standard Code for Information Interchange.
AT Attencion.
CPU Central Processing Unit.
DC Direct Current.
EEPROM Electrically-Erasable Programmable Read-Only Memory.
GSM Global System for Mobile communications.
HTTP Hypertext Transfer Protocol.
I2C Inter-Integrated Circuit.
IDE Integrated Development Environment.
IO Input / Output.
IP Internet Protocol.
LCD Liquid-Crystal Display.
LED Light Emitting Diode.
MIPS Million of Instructions per Second.
MOSFET Metal Oxide Semiconductor Field Effect Transistor.
NPN Negative - Positive - Negative transistor.
PC Personal Computer.
PCB Printed Circuit Board.
PIN Personal Identification Number.
PRN Do latim pro re nata.
RAM Random-Access Memory.
PWM Pulse Width Modulation.
RISC Reduced Instruction Set Computing.
ROM Read-Only Memory.
RTC Real-Time Clock.
SIM Subscriber Identity Module.
SMD Surface-Mount Device
SMS Short Message Service.
SPI Serial Peripheral interface.
SPP Serial Port Profile.
xvi
SRAM Static Random Acess Memory.
TCP/IP Transmission Control Protocol / Internet Protocol.
TTL Transistor-Transistor Logic.
UART Universal Asynchronous Receiver/Transmitter.
USB Universal Serial Bus.
1
1 Introdução
1.1 Motivação
O consumo de medicamentos tem vindo a aumentar, permitindo prolongar e melhorar a
qualidade de vida das pessoas. Apesar desta tendência se verificar em todas as faixas etárias, os
idosos ocupam, naturalmente, um lugar de destaque no que toca ao consumo de medicamentos.
Nesta faixa etária, quer a quantidade de comprimidos quer a complexidade nos regimes de
toma são, tipicamente, maiores. Para além da variedade de medicamentos, as suas tomas podem
também ser complexas: por vezes um medicamento tem de ser tomado várias vezes ao longo do dia,
em doses diferentes, ou com doses que variam ao longo do mês.
Somando esta complexidade a uma diminuição das capacidades cognitivas, auditivas e
visuais dos idosos, é muito comum que estes cometam erros nas tomas, especialmente quando não
são supervisionados. Adicionalmente, é também comum observar-se uma degradação da capacidade
de memória, tornando-se muito mais difícil ao paciente recordar-se das instruções de toma dos
medicamentos, incluindo doses e horários. Do ponto de vista da visão, os idosos têm, geralmente,
maior dificuldade em ler os rótulos, sendo ainda importante considerar que uma percentagem
relevante destes são analfabetos, baseando-se muitas vezes nas cores e nos formatos das caixas
para distinguir os medicamentos. Por fim, a redução das capacidades auditivas pode levar a uma
percepção errada das instruções de toma.
Como resultado destes erros na toma da medicação, as consequências podem ir desde a
ineficácia da terapêutica a casos de sobredosagem (por toma repetida devido a esquecimento) ou
interacções medicamentosas indesejáveis, trazendo vários riscos para a saúde do paciente e
podendo até causar a morte.
Tendo em conta os referidos riscos, é fundamental que se cumpra correctamente o que foi
prescrito, respeitando os horários, as quantidades e a duração dos tratamentos. Para tal, as soluções
mais comuns passam pelo controlo das tomas por parte de familiares ou pela contratação de serviços
médicos que garantam a correcção das mesmas. No entanto, dado o contexto socioeconómico
actual, é muitas vezes incomportável para os familiares efectuar esse controlo ou contratar alguma
entidade. Por outro lado, os idosos nem sempre aceitam bem a presença de outra pessoa por
percepcionarem isso como uma perda da sua independência.
2
1.2 Objectivos
O presente trabalho tem como objectivo a implementação de uma solução que procura tentar
resolver os problemas descritos anteriormente, através da criação de um dispensador de
medicamentos inteligente que ajude os idosos a seguirem correctamente as suas terapêuticas,
evitando a necessidade de um acompanhamento presencial constante por parte de terceiros.
Assim, pretende-se desenvolver um dispositivo que guarde a medicação de uma pessoa,
alertando-a para a hora de cada toma e dispensando os medicamentos apenas no momento
adequado. Naturalmente, o dispensador terá de ser previamente configurado, o que pode ser feito
pelo próprio, por um familiar ou por terceiros devidamente autorizados, introduzindo a medicação e os
horários prescritos pelo médico.
No entanto, o objectivo do projecto não passa por criar um produto final, mas sim um
protótipo funcional que sirva de prova de conceito. Assim, nesta fase, pretende-se a sua
implementação recorrendo a um conjunto de módulos electrónicos específicos, culminando numa
solução que cumpra um conjunto de requisitos necessários à resolução do problema proposto,
podendo servir de base para uma futura implementação em hardware dedicado.
Importa ainda referir que, apesar de não ser um foco principal do trabalho, pretende-se
também fazer uma primeira abordagem à estrutura mecânica do sistema dispensador, sem a qual
não é possível desenvolver a respectiva vertente de controlo, nem identificar quais os sensores e
actuadores adequados.
Pretende-se que a solução final seja um sistema aberto, que possa ser usado como
componente de algo mais vasto. Assim, um dos objectivos passa por permitir a interacção do
dispensador com dispositivos externos, nos quais se possam desenvolver interfaces de configuração
mais amigáveis e adaptáveis a diferentes contextos de utilização, permitindo assim a sua integração
em serviços de outras entidades.
Será desenvolvido o software necessário ao correcto funcionamento do dispensador, bem
como o software necessário para interagir e configurar o mesmo, seja localmente (no próprio
dispositivo) seja a partir de um dispositivo externo. No que diz respeito aos dispositivos externos, o
objectivo passa por criar ferramentas genéricas através das quais outras entidades possam
desenvolver as referidas aplicações, evitando assim impor uma solução única e estática.
Dado o contexto referido anteriormente, associado a uma população que tende a envelhecer
cada vez mais, o desenvolvimento desta solução poderá ter um grande impacto social, contribuindo
para uma melhor qualidade de vida dos idosos, uma vez que facilitará a administração correcta das
terapêuticas, contribuindo consequentemente para uma maior eficácia das mesmas. Da mesma
forma, ajudará estas pessoas a terem uma maior autonomia, reduzindo a dependência de terceiros
para realizar uma tarefa tão básica das suas vidas como é a toma da medicação. A presente solução
tem igualmente um impacto positivo na vida de familiares, que deixam de ter de realizar uma
monitorização constante das tomas de medicamentos dos idosos.
3
1.3 Estrutura da tese
No próximo capítulo apresenta-se o estado da arte, descrevendo-se diferentes sistemas
similares ou relacionados com o trabalho que se pretende desenvolver.
No capítulo 3 é descrita a solução proposta, começando-se por detalhar as principais
funcionalidades pretendidas e alguns cenários de utilização. Seguidamente apresenta-se a
arquitectura delineada para o dispensador, concluindo-se o capítulo com uma análise dos vários
módulos e componentes electrónicos escolhidos para a sua implementação.
No capítulo 4 descrevem-se os detalhes de implementação da solução, com particular ênfase
no software de controlo do dispensador.
No capítulo 5 realiza-se a análise dos resultados obtidos e, no capítulo 6, são apresentadas
as conclusões da presente dissertação.
4
2 Estado da Arte
2.1 Dispensadores de Medicamentos
Este capítulo tem como objectivo descrever as características e funcionalidades das soluções
existentes que se mostraram mais relevantes. A generalidade dos dispensadores que foi possível
analisar correspondem a produtos comerciais e, não se podendo ter acesso aos mesmos, a sua
apreciação encontra-se limitada pela documentação disponibilizada pelos fabricantes e vendedores.
A informação disponível está sujeita à parcialidade do fabricante e, na maioria dos casos casos,
apresenta poucos detalhes técnicos.
Para complementar o estudo efectuado, inclui-se igualmente uma breve análise de uma
aplicação de telemóvel que permite ajudar na gestão da medicação. Refere-se que existem inúmeras
aplicações deste tipo, mas que a generalidade partilha as mesmas funcionalidades básicas, razão
pela qual se analisou apenas uma que se considerou representativa.
2.2 MedSmart MD2
O MedSmart é um dispensador automático de comprimidos, criado pela empresa e-pill. A
análise do produto é feita maioritariamente a partir do manual do MedSmart [1]. Este é um produto
portátil, com forma aproximadamente circular, com um peso de 0.8 kg e um diâmetro de
aproximadamente 20 cm – ver figura 1.
Mecanicamente, usa um mecanismo de rotação, em que os comprimidos são colocados
numa estrutura circular (uma espécie de disco, que corresponde ao objecto 1 da figura 1), dividida em
29 compartimentos (28 usados efectivamente para medicação). Esta estrutura é rodada de maneira a
que o compartimento com os comprimidos para um dado horário fique disponível apenas nesse
momento, de acordo com o que foi previamente configurado. Os medicamentos ficam assim
acessíveis numa abertura existente no invólucro plástico externo.
O dispensador pode ser alimentado pela rede eléctrica, utilizando um transformador, ou
através de 4 baterias do tipo AA. No primeiro caso, o dispensador deve estar colocado numa
plataforma, designada Docking Base (objecto 2 da figura 1). Quando retirado desta base ou em caso
de falha eléctrica, o dispensador é então alimentado pelas referidas baterias. Importa ter em
consideração que as baterias não são carregadas quando o MedSmart está ligado à corrente, pelo
que devem ser poupadas para uma eventual situação de falha na rede eléctrica. A inclusão das
baterias é fundamental como mecanismo de segurança, uma vez que, dependendo do regime de
medicação, poderia ser bastante perigoso deixar o utilizador sem acesso aos medicamentos.
De maneira a prevenir o acesso indevido aos medicamentos pelo idoso ou outra pessoa, os
compartimentos nos quais se colocam os comprimidos encontram-se no interior do aparelho,
5
cobertos pelo referido invólucro exterior, cujo acesso requer uma chave. Da mesma forma, para evitar
uma alteração acidental das configurações do dispensador, os botões da interface de configuração
encontram-se protegidos pelo referido mecanismo.
Figura 1 - Equipamento MedSmart. Adaptado de [2].
Cada compartimento tem capacidade suficiente para cerca de 20 comprimidos do tamanho de
uma aspirina, o que é suficiente para a generalidade das pessoas. No entanto, caso os
compartimentos não tenham tamanho suficiente, existem também discos de 24 compartimentos, de
maior dimensão. Apesar disto, não é claro se o mesmo dispensador suporta os dois tipos de discos
ou se esta solução corresponde a um dispensador diferente.
Este sistema permite definir um máximo de 6 alarmes diários para a dispensa de
comprimidos. Estes alarmes são definidos de forma rígida, isto é, não é possível definir alarmes
diferentes para cada dia. Por exemplo, suponha-se que se configuram dois alarmes, um para as
10:00 e outro para as 20:00. Então, durante todos os dias de operação, os alarmes dispararão
sempre a essas horas. Apesar de esta opção ser razoável para a generalidade dos casos, nos quais
o doente segue uma terapêutica regular, poderá tornar-se um pouco limitativo quando o regime
medicamentoso for mais complexo. Da mesma forma, o limite de 6 alarmes por dia poderá não ser
suficiente em alguns casos específicos.
Importa ainda referir que se podem configurar 2 (ou mais) alarmes para o mesmo instante, o
que permite assim aumentar a capacidade de dispensa para um dado horário. Isto é bastante útil
para doentes que tomam grandes quantidades de medicamentos numa só toma.
De maneira a alertar o utilizador, a dispensa dos comprimidos é acompanhada por um sinal
visual e sonoro. O sinal visual corresponde a uma luz intermitente. O sinal sonoro consiste numa
sequência de beeps, sendo possível escolher um de três tons disponíveis. No entanto, não é
especificado se existe a opção de não usar o alarme sonoro, o que seria algo a considerar visto que
certas pessoas poderão sentir-se incomodadas com tal funcionalidade.
Uma vez disparado o alarme, o compartimento fica acessível até que o paciente retire os
medicamentos ou, caso não o faça, até ao momento da dose seguinte, considerando-se então que a
actual não foi tomada. Caso tal aconteça, o dispensador avança para o próximo compartimento,
6
ficando os comprimidos não tomados inacessíveis, o que pode ser importante para evitar possíveis
sobredosagens. No entanto, deveria ser possível definir durante quanto tempo o compartimento fica
acessível após o alarme tocar, visto que poderá haver a necessidade de garantir um período de
guarda entre duas tomas, para evitar interacções indesejadas.
Para recolher os medicamentos, o dispositivo deve ser retirado da Docking Base e virado ao
contrário, de maneira a que os comprimidos caiam, sendo esta a única maneira do dispositivo
detectar que a toma foi efectuada. O procedimento encontra-se explicitado na figura 2. Apesar de ser
uma forma interessante de detectar que os comprimidos foram retirados do dispensador, há que ter
em consideração que nem todos os idosos poderão conseguir efectuar o movimento necessário,
devido a limitações físicas.
Figura 2 - Método de retirar os comprimidos do dispensador. Retirado de [1].
Uma função interessante disponibilizada pelo sistema é a chamada dose antecipada, que
permite ao idoso carregar num botão para antecipar a próxima dispensa. Assim, caso tenha, por
exemplo, de se ausentar, poderá levar consigo os medicamentos. No entanto, este botão pode ser
protegido mecanicamente, de maneira a impedir o seu uso. Importa referir que só se pode antecipar
uma dose, pelo que não se pode voltar a fazê-lo até que a hora do alarme correspondente à dose
antecipada seja atingida. Esta funcionalidade é pertinente uma vez que este tipo de produtos existem
precisamente para dar mais autonomia ao utilizador, pelo que há que ter em conta que este poderá
não passar todo o dia em casa. Da mesma forma, a possibilidade de inibir esta funcionalidade põe
em evidência a tentativa de fornecer um produto versátil que se possa adaptar a diferentes contextos,
visto que nem todos os utilizadores poderão ter condições para gerir a possibilidade de antecipar
dispensas. No entanto, seria pertinente haver a possibilidade de configurar um número de doses
antecipadas máximo que se poderia pedir, uma vez que a pessoa poderá ausentar-se por um período
que inclua mais que uma toma. Neste caso, uma solução seria levar consigo o dispositivo, visto ser
relativamente pequeno, leve e poder operar a pilhas.
No que diz respeito à interacção com o utilizador, o MedSmart tem uma interface simples e
minimalista. Existe um pequeno LCD, no qual estão indicados a data e a hora, o número de alarmes
por dia, o tipo de som do alarme, a hora do próximo alarme, as doses que ainda restam e as
7
condições de bateria, conforme está ilustrado na figura 3. No entanto, o idoso não precisa de
entender o seu funcionamento, uma vez que, tal como referido anteriormente, basta tomar os
comprimidos dispensados quando os alarmes visual e luminoso ficam activos.
Para configuração do dispensador, a interface é relativamente simples, correspondendo a
cinco botões de pressão que permitem configurar todas as funcionalidades, representados na figura
3. Os dois botões “Adjust” permitem modificar os valores que se estão a configurar. O botão “Set
Clock” permite entrar no modo de configuração da data e da hora. O botão “Set Alarms” permite
entrar no modo de configuração de alarmes, no qual se pode definir o tom do alarme, o número de
alarmes por dia e a hora dos alarmes. Por fim, o botão “Full Tray Reset” serve para reiniciar as
dispensas, quando se recarrega o dispositivo com medicamentos.
Figura 3 - Representação do interior do MedSmart, com o LCD em modo de operação normal, e a
interface de programação abaixo. Adaptado de [1].
Para recarregar o dispensador, basta retirar o disco do dispositivo e colocar os comprimidos
correspondentes a cada toma em diferentes compartimentos seguidos, preenchendo-os no sentido
dos ponteiros do relógio. Um dos compartimentos deverá ficar vazio, visto que corresponderá à
posição inicial. Ao colocar o disco no dispensador, este compartimento vazio deve estar alinhado com
a abertura pela qual os comprimidos são dispensados.
O MedSmart possibilita também consultar o historial das tomas, isto é, permite verificar a hora
na qual o dispensador foi virado pelo utilizador para recolher os comprimidos. Esta funcionalidade é
acedida através dos botões de “Adjust”, caso se carregue nos mesmos sem se estar em nenhum
modo de configuração.
8
Para estender as capacidades do MedSmart original, existe uma versão plus que permite a
monitorização remota do paciente, necessitando o dispositivo de ser conectado a uma linha
telefónica. Usando estas funcionalidades, o MedSmart permite avisar remotamente quando uma toma
é falhada, quando se chega a um limiar predefinido de doses restantes de medicamentos, bem como
transferir o historial de tomas [3]. O sistema permite ainda enviar notificações quando a bateria se
encontra fraca ou caso tenha ocorrido um problema de funcionamento, bem como a sua configuração
remota [3]. No caso da configuração remota, esta é feita por um profissional do centro de apoio ao
produto, e não pela pessoa que gere a medicação do utilizador [3]. Todas as notificações podem ser
feitas através de uma chamada, SMS ou email, e o serviço não tem qualquer custo extra para o
utilizador [3]. A informação acerca do historial de dispensas é disponibilizada online [3].
Ambos os produtos podem ser adquiridos no website da empresa, sendo que a versão plus
custa 789.95 dólares e a versão original 489.95 dólares [4].
2.3 Philips Medication Dispenser
O dispensador de medicamentos da Philips é um produto que se encontra integrado num
serviço da empresa [5], ou seja, não pode ser adquirido separadamente. Foi inicialmente
desenvolvido pela empresa Interactive Medical Developments [6], que foi adquirida pela Philips, em
2008 [7]. Inicialmente, era vendido a um preço de aproximadamente 845 dólares [4], sendo que,
actualmente, o serviço da Philips tem um custo mensal de 49 dólares por mês, com um custo de
instalação inicial de 99 dólares [5]. O dispensador encontra-se representado na figura 4 e a sua
análise é feita maioritariamente com base no manual do produto [8]. Este dispensador é monitorizado
remotamente, pelo que requer uma conexão à linha telefónica.
Figura 4 - Esquema do dispensador e dos seus principais componentes. Adaptado de [8].
9
Importa referir que o manual do produto não é muito claro acerca de certas funcionalidades e
procedimentos, o que poderá ser explicado pelo facto de a instalação ser feita por um profissional,
que muito provavelmente clarificará como interagir com o dispensador.
Mecanicamente, esta solução assenta num sistema baseado em cilindros, nos quais se
empilham copos de plástico que contêm a medicação correspondente a cada dose, conforme se pode
observar na figura 5. Apesar de não ser disponibilizada documentação técnica que descreva o seu
funcionamento, pode-se facilmente inferir que existe um mecanismo de rotação que permite
posicionar os cilindros por cima do local de dispensa. Este sistema é claramente mais complexo que
o anteriormente descrito, visto que é agora necessário garantir que, para cada cilindro, é apenas
dispensado um copo plástico de cada vez. O dispensador suporta um máximo de 60 doses,
distribuídas pelos 10 cilindros [9].
Figura 5 - Esquema do interior do dispensador da Philips. Retirado de [10].
No que diz respeito à energia, funciona alimentado pela rede eléctrica. No entanto, conta com
um sistema de bateria de backup que permite continuar a operar em caso de falha da energia
eléctrica. Esta bateria é recarregável e, segundo o fabricante, garante o funcionamento do
dispensador por um tempo máximo de 18 horas.
É possível definir, no máximo, 6 alarmes diários para dispensa de medicação ou para
mensagens para o utilizador, independentes das dispensas. No manual do dispensador não é claro
se estas mensagens podem ser definidas de acordo com o necessário ou se já estão pré-gravadas
no sistema mas, de acordo com outras fontes externas que descrevem o produto, existem apenas 23
mensagens predefinidas que se podem escolher. Destas, citam-se como exemplo “take medicine with
food”, “take your eye drops”, “check blood pressure”, ou “take your insuline” [11].
O facto de se poderem definir mensagens é extremamente útil, visto que certos
medicamentos não podem ser guardados no dispensador mas, ainda assim, há a possibilidade de
avisar o utilizador de que os deve tomar. Da mesma forma, pode-se alertar para outros eventos
relacionados com a saúde. No entanto, não se poder definir mensagens personalizadas é um ponto
10
negativo, visto que as 23 mensagens predefinidas não cobrirão, certamente, todo o espectro de
possibilidades de que poderá ser necessário relembrar a um utilizador.
Apesar desta incerteza relativa ao funcionamento das mensagens, é referido no manual de
produto que as mensagens e as dispensas se sobrepõem no que diz respeito à limitação de 6
alarmes diários. Ou seja, uma simples mensagem vai ocupar os recursos equivalentes a uma
dispensa. No entanto, todas as dispensas têm uma mensagem associada, que por defeito indica
“time to take your medication”. Também é possível alterar esta mensagem mas, como é dependente
da dispensa, não consome nenhum alarme extra. Obviamente que o facto de uma mensagem isolada
ocupar um alarme é um factor limitativo, visto que um máximo de 6 alarmes diários apenas para
dispensas é, já de si, um número que pode não ser suficiente para alguns utilizadores. Não obstante,
o uso de mensagens é opcional, pelo que se pode utilizar os alarmes exclusivamente para dispensas,
caso necessário.
Para sinalizar um alarme, o dispensador activa uma luz vermelha intermitente no seu painel
frontal e indica a mensagem correspondente, quer no display quer de forma audível. O facto de se
tocar uma mensagem ao invés de um beep para sinalizar os eventos poderá ser mais adequado e
intuitivo para relembrar o utilizador das tomas.
De maneira a desencadear a dispensa dos medicamentos, uma vez disparado o alarme, o
utilizador deverá carregar no botão existente no painel frontal do dispensador. Da mesma forma,
deverá fazê-lo para indicar que recebeu uma mensagem de alerta, mesmo que não esteja associada
a uma dispensa.
A mensagem de aviso é repetida de minuto em minuto durante 45 minutos, até que o
paciente carregue no botão. Se, após 90 minutos, o utilizador não carregar no botão, a dose é
considerada falhada e é enviada para um compartimento de doses perdidas, bem como o centro de
monitorização é contactado pelo dispensador, com vista a posteriormente alertar algum dos
responsáveis pelo utilizador. Este período de 90 minutos deveria de ser configurável, uma vez que a
janela de oportunidade para tomar uma dose esquecida sem consequências poderá variar.
O referido compartimento de doses perdidas tem um limite de quatro copos de
medicamentos. Uma vez atingido este limite, é indicada uma mensagem no dispensador e este deixa
de operar até que os medicamentos sejam retirados do compartimento. Consequentemente, o
responsável pelo utilizador é contactado. Apesar de ser uma limitação do sistema, tendo em conta
que o seu objectivo é garantir a toma dos medicamentos, é razoável que ao fim de quatro doses
falhadas seja necessário ao responsável deslocar-se ao local para resolver o problema.
Como referido anteriormente, a interacção do utilizador com o sistema é mínima e bastante
simples, limitando-se este a ter de carregar num botão para activar a dispensa de medicamentos ou
assinalar a recepção de uma mensagem. Para além disso, existe o display do painel frontal, que
indica o tempo que falta até à próxima dose, a data e a hora actuais e o estado do sistema. Já
durante um alarme, indica a mensagem correspondente ao mesmo.
No que diz respeito à interacção do responsável com o dispensador, existe um teclado que
permite aceder às funcionalidades disponibilizadas pelo sistema, tal como esquematizado na figura 6.
No entanto, esta interface não permite configurar os alarmes. Assim, a configuração é feita
11
remotamente pelos profissionais do centro de atendimento da Philips, que devem ser contactados
sempre que há uma alteração dos horários. O botão “Schedule” é usado para fazer o download das
configurações definidas remotamente, utilizando a linha telefónica.
Figura 6 - Teclado de interação com o sistema. Adaptado de [8].
Este dispensador suporta a funcionalidade de dose antecipada, que permite adiantar o
horário das dispensas. De acordo com o manual, pode-se adiantar mais que uma dose, não sendo
explicitado se existe algum limite máximo.
Dado o mecanismo mecânico do dispensador, o processo de recarga dos medicamentos é
ligeiramente mais complexo e requer a interacção com o teclado. Para iniciar o procedimento, deve-
se carregar na tecla “Load”. Seguidamente, os cilindros irão posicionar-se de acordo com o
necessário para iniciar o processo. Os medicamentos para um dia ficarão sempre no mesmo cilindro,
mas dias diferentes poderão ficar em cilindros diferentes ou no mesmo cilindro. Após carregar os
medicamentos para um dia, deve-se carregar na tecla “OK” e esperar até que seja indicado para
colocar os medicamentos do próximo dia, visto que poderá ser necessário reposicionar os cilindros.
Repete-se o procedimento até que todos os medicamentos estejam carregados.
Em relação à segurança, o teclado, o mecanismo de carregamento dos medicamentos e o
compartimento de doses perdidas encontram-se protegidos por uma porta, a qual requer o uso de
uma chave para abrir. Na figura 4 é possível observar quais os componentes que ficam inacessíveis
12
quando o dispensador se encontra trancado. No entanto, o botão de dose antecipada encontra-se no
teclado, pelo que disponibilizar esta funcionalidade ao utilizador implica necessariamente que este
tenha também acesso ao compartimento de doses perdidas e ao mecanismo de carregamento, o que
poderá não ser adequado.
Relativamente às suas funções remotas, o dispensador notifica o centro da Philips de certos
eventos, que posteriormente contacta o responsável pelo utilizador.
Diariamente, o dispensador faz também upload do número de doses falhadas, dias restantes
de medicação, número de doses antecipadas e erros de sistema. Estas informações são
disponibilizadas online, o que permite o seu acompanhamento remoto.
Por fim, importa fazer referência a uma funcionalidade que não é descrita no manual mas que
é indicada no website do produto, que diz respeito à possibilidade de programação do dispensador
para um regime de dispensa de medicamentos, ditos PRN, que são tomados de acordo com a
necessidade [12]. Apesar de não serem fornecidos quaisquer detalhes acerca do modo de
funcionamento, este tipo de medicamentos têm, tipicamente, restrições de tempos mínimos entre
duas tomas. Como tal, pode-se inferir que o sistema garantirá que são respeitados estes tempos
entre tomas.
2.4 Medfolio Electronic Pillbox
Este produto da empresa Medfolio corresponde a uma caixa organizadora de medicamentos
tradicional, complementada com um sistema electrónico que permite ajudar o utilizador na gestão das
tomas dos seus medicamentos [13]. Como tal, toda a medicação encontra-se sempre acessível ao
utilizador, sendo que o dispositivo serve apenas para o relembrar das horas das tomas e qual o
compartimento que deve escolher. A restante análise será baseada maioritariamente no manual do
produto [14].
As suas dimensões são de 36,6 cm de comprimento, 18.8 cm de largura e 5.8 cm de
espessura, e o seu peso de 1.4 kg [13], tornando este dispositivo fácil de transportar.
O sistema de funcionamento desta solução é muito simples. A estrutura física corresponde a
uma caixa com uma tampa, no interior da qual se encontram 7 caixas individuais, divididas em 4
compartimentos. Cada compartimento corresponde a uma altura do dia: manhã, tarde, noite e deitar,
e cada caixa a um dia da semana. Tal traduz-se na capacidade de guardar, no máximo, 7 dias de
medicação (28 compartimentos). Uma das grandes vantagens é a possibilidade de remover cada
uma das caixas individualmente, o que permite ao utilizador levar um dia de medicação consigo sem
ter de transportar todo o sistema.
Uma característica interessante é o facto de, na parte interior da tampa do produto, existir um
conjunto de 16 compartimentos, nos quais se podem colocar amostras de cada um dos tipos de
comprimidos tomados. Associada a esta estrutura, é possível anexar uma folha com informações
relativas aos comprimidos, como por exemplo, o número de vezes que são tomados por dia, o
objectivo e a dosagem, tal como ilustrado na figura 7. Desta forma, sempre que o utilizador necessitar
de indicar a um profissional de saúde quais os medicamentos que toma, basta fazer-se acompanhar
desta estrutura, que pode facilmente ser desacoplada do sistema.
13
Figura 7 - Estrutura de documentação dos medicamentos tomados. Retirado de [13].
Como referido anteriormente, existem 4 compartimentos para os medicamentos de cada dia,
o que se traduz na possibilidade de definir apenas 4 alarmes diários. No entanto, não é especificado
se os horários estão limitados aos períodos do dia indicados (manhã, tarde, noite e deitar), ou se é
possível, por exemplo, definir os 4 alarmes para a manhã.
Os alarmes são assinalados com um alerta sonoro (que pode ser desactivado com um botão
existente no produto), que se repete a cada 2 segundos, e um alerta visual, que corresponde a um
LED que pisca debaixo do compartimento que contém a dose a ser tomada. Tanto o sinal visual como
o sonoro se mantêm, até um máximo de 2 horas, até que o utilizador carregue no botão de reset do
alarme. Passadas as 2 horas, a toma é considerada falhada.
Adicionalmente aos referidos alarmes, o utilizador pode aderir a um serviço que lhe permite
receber os avisos de toma de medicação por email e/ou mensagem de texto, tendo um custo extra de
8 dólares por mês. Para a versão standard do produto, esta é a única forma de obter informações
relativas às tomas. Assim, ao receber um email ou mensagem de alerta, o utilizador deve indicar se
tomou ou não a referida dose. Para tal, deve seguir um link incluído na mensagem, que permite fazer
este registo. Estes dados ficam então acessíveis online, para poderem ser consultados pelo utilizador
ou pelos responsáveis. Dado que esta caixa de comprimidos requer uma conexão a um computador
para configurá-la, faria mais sentido dotá-la da capacidade de registar internamente as informações
das tomas, tornando-as assim acessíveis localmente no mesmo programa.
Existe também uma versão wireless do produto que, para além de usar o método referido
anteriormente, transmite igualmente a informação resultante de pressionar o botão de reset do alarme
para registar as tomas. Desta forma, se o utilizador fizer reset ao alarme no período de uma hora
após este disparar, a toma é considerada atempada. Caso este procedimento seja executado entre 1
14
a 2 horas após o alarme disparar, então a toma é registada como tardia. Por fim, após as duas horas,
considera-se que se falhou a toma. De maneira a carregar esta informação para os servidores da
empresa, é necessário estar disponível uma conexão sem fios à Internet. Apesar disto, não é
especificado se esta conexão tem de estar activa no momento em que o evento ocorre, ou se essa
informação fica registada internamente no dispositivo e pode mais tarde ser carregada. Da mesma
forma, não é explicado como é que esta abordagem interage com a notificações por email e SMS,
visto que é fácil antever que podem surgir informações contraditórias sobre uma mesma toma.
No que diz respeito à energia, é alimentado por baterias internas recarregáveis que, segundo
o fabricante, duram até 4 semanas [13].
Toda a configuração do sistema é feita através do computador, utilizando um programa
disponibilizado pela empresa, que apresenta uma interface gráfica bastante simples. A ligação ao
produto é feita através de uma interface USB.
Dadas as especificações descritas para este sistema, pode-se inferir que é adequado para
pessoas com ainda alguma autonomia e regimes medicamentosos de baixa complexidade. Da
mesma forma, o esquema de monitorização empregue na versão standard não é o mais adequado
para utilizadores idosos, visto que não é muito comum estes utilizarem email ou telemóvel.
A versão standard deste produto é vendida a um preço de 248 dólares e a versão wireless a
298 dólares [13].
2.5 MedHelper
O MedHelper é uma aplicação para Android e iOS, da empresa Earth Flare, que tem como
objectivo ajudar a gerir regimes de medicação [15]. Permite definir alarmes para relembrar as tomas,
a necessidade de comprar mais medicamentos e consultas marcadas [15]. Apesar de não ser claro
como funciona, é referida a existência de um mecanismo de confirmação de notificações, não sendo
referido se se aplica a todos os tipos ou apenas às tomas. É ainda referida a existência de um registo
que permite mostrar a hora em que uma toma foi confirmada [15] .
Para além da medicação normal, tomada regularmente, existe a possibilidade de acompanhar
as tomas de medicação PRN [15]. Apesar de ser referido que é possível aceder a um histórico
referente às tomas desta medicação [15], não é especificado se existe algum tipo de alarme ou
mecanismo que ajude o utilizador a evitar executar uma nova toma sem ter passado o período de
tempo prescrito desde a última.
Uma outra funcionalidade interessante é a possibilidade de permitir definir vários perfis [15],
possibilitando assim que um utilizador acompanhe várias pessoas.
É ainda possível exportar um relatório de vários eventos associados ao uso da aplicação,
sendo o envio feito para um email [15]. Apesar de não ser explicitamente referido que eventos podem
ser incluídos, pode-se inferir que estes incluem o registo das tomas.
15
2.6 Outros produtos
É importante referir que os produtos analisados não correspondem a todas as soluções
existentes no mercado, havendo uma grande variedade de fabricantes e modelos de dispensadores.
No entanto, aqueles que foram analisados são representativos dos restantes, que seguem fórmulas
muito semelhantes, com pequenas variações em algumas funcionalidades.
Refere-se então sucintamente mais algumas soluções analisadas, semelhantes às anteriores:
Med-Q: caixa de comprimidos que permite definir alarmes para relembrar as tomas,
assinalando o compartimento correspondente com uma luz intermitente, acompanhada de um
sinal sonoro [16];
TabTime super 8: caixa de comprimidos desenhada para doentes que sofrem de Parkinson
e Alzheimer e que permite definir até 8 alarmes diários (possui apenas 8 compartimentos),
que são assinalados por uma luz intermitente e por um sinal sonoro [17].
Pivotell Automatic Pill Dispenser: dispensador automático de medicamento baseado num
mecanismo de rotação e com 28 compartimentos [18]. Tem a particularidade de permitir
definir até 24 alarmes diários [18], o que já é um número muito elevado. No entanto, continua
a manter os comprimidos de um compartimento disponíveis até à toma seguinte, tal como o
MedSmart.
MedReady GSM Cellular Dispenser: dispensador semelhante ao MedSmart, baseado num
mecanismo de rotação, com 28 compartimentos e com possibilidade de definição de um
máximo de 4 alarmes diários, com a particularidade de permitir monitorização remota
utilizando a tecnologia GSM [19].
IVATION Automatic Pill Dispenser: dispensador semelhante ao MedSmart, com a
particularidade de poder ser adquirido por apenas 80 dólares [20], um preço bastante mais
adequado dadas as suas funcionalidades.
MedVault: dispensador desenvolvido por alunos da universidade de Brigham Young, com o
objectivo de regular a dispensa de medicamentos analgésicos, com base nas instruções dos
farmacêuticos [21]. Apesar da escassez de detalhes, esta solução é bastante interessante e
tenta resolver um problema que a generalidade dos dispensadores não contempla,
nomeadamente a gestão de medicação PRN.
16
3 Descrição da Solução Proposta
3.1 Funcionalidades do Dispensador
Da análise efectuada aos produtos existentes no mercado, foi possível verificar que existem
já várias soluções disponíveis, que apresentam abordagens interessantes para lidar com o problema.
No entanto, ficou evidente que todas essas soluções correspondem a sistemas fechados,
vocacionados para um conjunto limitado de contextos de aplicação e com baixa versatilidade. Para
além disso, disponibilizam interfaces de interacção relativamente rudimentares e apresentam várias
limitações a nível das configurações.
Assim, considera-se pertinente contribuir com a criação de uma plataforma aberta e versátil
que suporte comunicação sem fios (wireless) com outros sistemas. Será disponibilizada uma API de
programação genérica que permitirá a interacção com o dispensador através de computadores
comuns ou através de dispositivos móveis do tipo Tablet ou Smartphone, o que constitui uma clara
diferença face ao que existe no mercado. Deste modo, torna-se possível dispor de aplicações de
configuração e interacção com o dispensador que podem ser personalizadas para diferentes
contextos de utilização e que poderão automatizar muitos dos procedimentos que, de outro modo,
teriam de ser feitos manualmente no dispensador.
Adicionalmente, sendo a solução aberta, essas aplicações podem ser desenvolvidas ou
melhoradas por diferentes entidades. Desta forma, torna-se possível integrar o dispensador em
soluções mais abrangentes de gestão de terapêutica que podem, por exemplo, envolver diferentes
instituições, públicas ou privadas, e profissionais ligados aos cuidados de saúde ou apoio domiciliário.
Na óptica do cuidador, pretende-se reduzir significativamente o conjunto de limitações
existentes nas configurações dos dispositivos analisados, com particular ênfase na forma como os
alarmes podem ser configurados, que limitam a possibilidade de gerir regimes mais complexos.
Pretende-se também possibilitar um acompanhamento remoto dos eventos pertinentes da
operação do dispensador, dando possibilidade para, por exemplo, saber se o utilizador pediu ou não
a dispensa dos comprimidos. Esta possibilidade é particularmente importante se a pessoa tomar
medicação crítica e tiver tendência a falhar as suas tomas, permitindo assim ao cuidador intervir e
evitar potenciais situações perigosas para a saúde do utilizador.
Houve também cuidado na criação da interface com a pessoa cuidada, tendo-se optado por
algo minimalista e simples de usar, baseado em botões de pressão e sinais visuais e sonoros de fácil
percepção. Estes sinais deverão ter intensidades adequadas, para alertarem devidamente o idoso
sem lhe causar incómodo, podendo ser apenas sonoros, visuais ou uma combinação de ambos, com
a possibilidade de serem configuráveis para terem diferentes padrões e durações.
Apresenta-se em seguida uma lista detalhada das principais funcionalidades a implementar.
17
Dispensa de medicação
Possibilidade de definir até 28 alarmes de dispensa de comprimidos, correspondentes a 28
compartimentos de medicação distintos. Para cada alarme, é possível definir a data e a hora
de disparo, sem qualquer limitação no número máximo de alarmes diários. Desta forma,
remove-se a limitação imposta por algumas das soluções analisadas, que consideram um
número fixo de alarmes por dia e apenas permitem definir a hora de disparo (todos os dias às
mesmas horas). Assim, podem-se incluir no regime de medicação tomas esporádicas e não
lineares ao longo dos dias.
Possibilidade de definir um tempo de tolerância máximo para cada toma, a partir do qual o
utilizador não poderá recolher a medicação. Esta funcionalidade permite colmatar uma das
falhas encontradas nas soluções de mercado, que não fazem um controlo adequado deste
aspecto. Assim, fornece-se uma forma de evitar interacções medicamentosas indesejadas.
Possibilidade de definir múltiplos compartimentos associados a uma mesma dispensa, sem
limitações, desde que não seja ultrapassado o limite dos 28 compartimentos.
Possibilidade de dispensa antecipada de doses de medicação, o que é particularmente útil
para o caso do utilizador ter de se ausentar antes de uma toma. Esta possibilidade e o tempo
permitido de antecipação são configuráveis de forma independente para cada alarme.
Possibilidade de re-armar alarmes falhados (tomas não ocorridas), o que é pertinente nos
casos em que a dose falhada possa ser tomada posteriormente, sem perigo para a saúde do
utilizador (ou em que seja preferível tomar tarde face a não tomar).
Possibilidade de associar uma mensagem textual, com conteúdo configurável, a cada alarme.
Esta é mostrada no display do dispensador após o disparo do alarme correspondente.
Disponibilização de um modo de configuração simplificado para regimes regulares ao longo
dos dias da semana, designado de modo diário. Apesar da versatilidade que se pretende
oferecer na configuração de alarmes, não faz sentido obrigar o cuidador a especificar o dia
exacto de cada toma, se estas se processarem de forma regular. Assim, neste modo, basta
especificar a hora de disparo (e as restantes informações auxiliares de tolerância, dose
antecipada e mensagem textual) das tomas de um dia genérico, que serão replicadas ao
longo dos dias de operação do dispensador.
Possibilidade de gestão simultânea de medicamentos PRN, com a possibilidade de configurar
o tempo de intervalo entre tomas adjacentes. Dado que estes partilham o mesmo conjunto de
compartimentos que os medicamentos de tomas regulares, o valor total de compartimentos
usados para PRN e tomas regulares deverá ser igual ou inferior a 28.
Interface para o utilizador
A dispensa de medicação será efectuada premindo um simples botão de pressão. Uma vez
disparado um alarme de uma dispensa, basta ao utilizador carregar no referido botão para ter
acesso aos medicamentos. Este botão serve também para o utilizador antecipar doses.
18
A realização da dispensa de medicação PRN é feita através de um segundo botão de
pressão. Ao carregar neste botão, o medicamento apenas será dispensado se o intervalo de
tempo desde a última dispensa for superior ao configurado.
A sinalização da hora de toma de determinada medicação é feita através de um sinal visual e
sonoro. Estes sinais mantêm-se activos até que o utilizador carregue no botão de dispensa
ou até que o tempo limite estabelecido tenha sido ultrapassado e a toma seja considerada
falhada. A sinalização segue um padrão “on/off” cujos tempos podem ser definidos de forma
independente. A intensidade da sinalização também pode ser configurada para se adequar
ao estado auditivo e visual do utilizador, ou para se ajustar às suas preferências.
Avisos textuais
Possibilidade de definir até 30 avisos textuais para além dos que acompanham a dispensa
de medicamentos (alarmes), com liberdade de definição do conteúdo textual. Pretende-se
com esta funcionalidade possibilitar ao cuidador alertar o utilizador com informações
pertinentes, como a existência de uma consulta no médico ou a necessidade de realizar
algum procedimento de saúde, como por exemplo medir a pressão arterial. Contrariamente à
abordagem do Phillips Medication Dispenser, os avisos textuais e os alarmes não se
sobrepõem, ou seja, definir um aviso não implica poder definir menos um alarme.
Possibilidade de definir um tempo de tolerância máximo durante o qual o utilizador pode
confirmar que recebeu o aviso. A confirmação é feita carregando no botão de dispensa.
Sinalização dos avisos com recurso aos mesmos sinais visuais e sonoros dos alarmes.
Registo de informação
Registo da data e hora referentes à dispensa efectiva dos medicamentos, permitindo ao
cuidador acompanhar a aderência do utilizador ao regime de medicação.
Registo da confirmação de que o utilizador visualizou um aviso textual.
Registo de tentativas de dispensa da medicação fora dos horários configurados. Considerou-
se esta informação pertinente na medida em que pode servir de indicativo do estado do
utilizador, permitindo identificar eventuais situações de confusão psicológica.
Interacção com o dispensador
Suporte para comunicação Bluetooth. O Bluetooth é uma tecnologia amplamente utilizada e
suportada por computadores, Tablets e Smartphones, pelo que se considerou adequada para
interagir com o dispensador quando se está na proximidade deste. Assim, é possível a
configuração do dispensador e a recolha de registos a partir de uma aplicação a executar
num destes dispositivos.
Suporte para comunicação Wi-Fi, para interacção remota com o dispensador, possibilitando
quer a configuração do mesmo quer a recepção de notificações de eventos relevantes
através da Internet. Como actualmente não é comum que a casa de um idoso tenha um
19
serviço de acesso à Internet, o uso desta interface é opcional. No entanto, existem casos nos
quais o idoso vive com o cuidador e este apenas necessita de monitorizá-lo, por exemplo,
durante um período do dia em que se encontre ausente, tornando-se pertinente esta
funcionalidade. Da mesma forma, se o dispensador for utilizado no contexto de uma
instituição, a monitorização remota de várias pessoas será certamente uma opção útil.
Suporte para comunicação GSM, para possibilitar o envio de notificações remotas ao
cuidador através de SMS. O GSM apresenta a vantagem de poder ser utilizado em qualquer
local, não havendo as restrições referidas para o Wi-Fi no que diz respeito à necessidade de
a habitação possuir uma infraestrutura de acesso à Internet. No entanto, considerou-se que o
uso de SMS para configurar remotamente o dispensador não seria cómodo para o cuidador,
pelo que esta forma de comunicação apenas suporta a notificação de ocorrências.
Possibilidade de realização de chamadas de voz para e a partir do dispensador. Para realizar,
atender ou terminar uma chamada, basta ao utilizador carregar num terceiro botão de
pressão. Esta funcionalidade é relevante na medida em que permite estabelecer um contacto
directo com o utilizador, de um modo muito simples. Por este motivo, este mecanismo poderá
ser usado por um utilizador com restrições cognitivas significativas que, de outro modo,
poderia já não ter a capacidade de usar um telemóvel ou mesmo um telefone comum.
Possibilidade de interacção directa com o dispensador, através de um teclado e de um
display (LCD), para configurá-lo e aceder às ocorrências registadas.
Suporte ao desenvolvimento de aplicações
Disponibilização de um API de programação genérica e versátil, para permitir desenvolver
aplicações em dispositivos externos que possam interagir com o dispensador para efectuar
configurações e recolher informação.
Existência de um identificador único e não alterável para cada dispensador (32 bits) ao qual
pode ser associado um nome de utilizador (30 bytes).
Espaço de memória não volátil de uso livre para o programador de aplicações de interacção
com dispensador, possibilitando guardar de forma persistente informações relevantes para a
aplicação.
3.2 Cenários de Utilização
Pretende-se que o dispensador de medicamentos a desenvolver possa operar num sistema
mais vasto e complexo, com vários intervenientes e contextos de aplicação. Em seguida descrevem-
se algumas das situações nas quais o dispensador poderá ser integrado, o que só é possível dada a
sua versatilidade e capacidade de interacção remota.
O cenário de utilização mais simples consiste no uso do dispensador para gerir a medicação
de uma pessoa cujo cuidador responsável seja um familiar. Neste caso, tendo em conta que os
cuidadores não terão formação específica para lidar com o equipamento, a possibilidade de
configurá-lo a partir de um outro dispositivo permite o desenvolvimento de aplicações com interfaces
20
simples e que os guiem no procedimento. Adicionalmente, existe a possibilidade de interagir
directamente com o dispensador através do seu teclado e display, para cuidadores que não se sintam
à vontade com equipamentos como Smartphones ou Tablets.
Outro cenário de aplicação consiste no uso do dispensador integrado numa rede de cuidados
ou numa instituição de saúde. Neste caso, é expectável que um único cuidador (ou uma pequena
equipa) trate de gerir um número razoável de dispositivos. Assim, a configuração manual das várias
unidades será algo pouco prático, sendo mais adequado o uso de uma aplicação externa que permita
automatizar grande parte dos procedimentos de configuração, que serão semelhantes para os vários
dispensadores. Uma possibilidade interessante consiste em carregar previamente os regimes de
medicação das várias pessoas para a referida aplicação, sendo estes transferidos de forma
automática para o dispensador correspondente. Como se pode antecipar, este procedimento será
mais prático, rápido e menos susceptível a erros do que configurar manualmente cada dispensador.
A figura 8 exemplifica a arquitectura de uma possível solução para a situação descrita. Neste
caso, considera-se que o médico de uma instituição é responsável por definir os regimes terapêuticos
dos pacientes, que são carregados para um servidor web. Deste, o cuidador carrega os dados para
um Tablet ou Smartphone, os quais são utilizados para configurar os diferentes dispensadores. Uma
vez que cada dispensador possui um identificador único e um espaço de memória para o nome do
utilizador actual, estas informações podem ser utilizadas pela aplicação para automaticamente
procurar o regime de tomas correspondente e carregá-lo. A arquitectura referida é apenas uma
sugestão para ilustrar o que é possível criar, pelo que a entidade responsável por desenvolver a infra-
estrutura poderá usar o dispensador como considerar mais conveniente.
Figura 8 – Exemplo de uma arquitectura com automatização da configuração de múltiplos
dispensadores.
Tendo em consideração a possibilidade de ligar o dispensador directamente à Internet
usando Wi-Fi, aumenta-se o número de possibilidades de interacção com o mesmo, conforme
ilustrado na figura 9. Através desta interface de comunicação, é possível configurar e acompanhar
remotamente o funcionamento do dispensador, podendo-se receber as notificações por email ou
consultá-las directamente num Smartphone.
21
Figura 9 – Exemplo de uma arquitectura com troca de dados através da Internet.
A comunicação pela Internet pode também ser utilizada para criar um serviço de apoio ao
cuidador, permitindo efectuar alterações às configurações do dispensador e até, eventualmente,
transferir para esse serviço a responsabilidade de monitorizar e configurar o equipamento.
A possibilidade de comunicar com o dispensador através de GSM permite um esquema de
notificações remotas bastante eficiente, descrito na figura 10. Contrariamente às notificações
enviadas por Internet, nas quais não se tem garantia de que o cuidador irá estar conectado, o envio
de SMS de aviso de eventos é algo que será recebido, tipicamente, com um atraso mínimo
(assumindo que o cuidador se faz acompanhar do seu telemóvel), o que é especialmente importante
quando o utilizador toma medicamentos críticos para a sua saúde.
Apesar de as notificações serem enviadas por SMS, é viável o desenvolvimento de uma
aplicação para Smartphone que as capture e apresente num formato diferente. Para além das
notificações, considerou-se também uma adição interessante o suporte para a realização e recepção
de chamadas de voz, permitindo um modo de estabelecer contacto directo com a pessoa cuidada.
Figura 10 – Comunicação remota com o dispensador utilizando GSM.
Toda a versatilidade referida é apenas possível em virtude da solução proposta ser muito
modular e aberta, permitindo um elevado nível de funcionalidades e de alternativas.
A interacção com o dispensador é realizada usando um protocolo de comunicação genérico,
independente do canal de comunicação utilizado. O referido protocolo é simples e fácil de
implementar em qualquer linguagem de programação. No entanto, para simplificar ainda mais o
22
processo de desenvolvimento, será fornecida uma API de suporte, nas linguagens Java e Python.
Usando esta API será possível aceder ao dispensador e efectuar todas as configurações disponíveis.
A versatilidade do dispensador permite operá-lo em diferentes contextos, sendo que apenas
se referiu um número limitado de entre todas as possibilidades que podem ser desenvolvidas. Como
tal, considera-se como uma das principais características de destaque da solução proposta, face aos
restantes produtos existentes no mercado, o facto de ser aberta, versátil e configurável, com
possibilidade de interacção com dispositivos externos para facilitar os processos de configuração.
3.3 Arquitectura do Dispensador
Desenhou-se uma arquitectura modular para o protótipo do dispensador, conforme ilustrado
no diagrama de blocos da figura 11. A decomposição escolhida teve em conta as diferentes
funcionalidades pretendidas, bem como o objectivo de estabelecer interfaces bem definidas com cada
módulo. Desta forma, simplifica-se todo o processo de desenvolvimento e teste, bem como se obtém
uma solução modular, que facilita eventuais alterações no código.
Figura 11 – Arquitectura do dispensador.
Os três módulos de comunicação (GSM, Wi-Fi e Bluetooth) dizem respeito à interacção do
dispensador com dispositivos exteriores, quer localizados na proximidade deste quer remotamente
através da Internet ou da rede móvel celular. Irá recorrer-se a módulos electrónicos que implementem
os referidos protocolos e que possam interagir com um microcontrolador. Tal é justificável uma vez
que seria demasiado complexo implementar estes módulos a partir dos componentes electrónicos
básicos, o que não seria compatível com o tempo de desenvolvimento disponível nem daria garantias
de uma maior optimização de funcionamento.
No contexto do protótipo, pretende-se mostrar que as três tecnologias de comunicação são
viáveis e podem operar em simultâneo, embora um eventual produto não necessite de utilizar todas.
O display, o teclado e os botões de pressão correspondem aos dispositivos através dos quais
é possível interagir directamente com o dispensador. No que diz respeito à sinalização dos alarmes e
outros avisos, irá recorrer-se a um LED e a um bezouro (buzzer) para gerar os sinais luminosos e
sonoros, respectivamente.
23
A actuação mecânica está associada ao mecanismo físico adoptado para guardar e dispensar
os medicamentos. Apesar de não ser o foco do trabalho definir a estrutura mecânica do dispensador,
existem desafios a nível de controlo e verificação do correcto funcionamento das dispensas que se
pretendem abordar, razão pela qual se irá criar um protótipo mecânico rudimentar, mas que permite
desenvolver e validar o software em questão.
Assim, assume-se um mecanismo similar ao adotado no MedSmart, no qual se dispõe de
uma estrutura circular dividida em múltiplos compartimentos, que é rodada para disponibilizar os
medicamentos localizados num dado compartimento. Em cada momento, só um dos compartimentos
está fisicamente acessível ao utilizador, ficando alinhado com uma abertura existente no invólucro
plástico externo. Para permitir a rotação da referida estrutura, utilizar-se-á um motor de passo (step
motor), que permite garantir fiabilidade na movimentação do disco com os compartimentos.
Menciona-se também o módulo de registo de informação, que permite guardar de forma
persistente vários tipos de dados, necessários ao correcto funcionamento do dispensador, e realizar o
registo dos eventos revelantes ocorridos durante a sua utilização. Este módulo será implementado
com recurso a uma memória não volátil, do tipo EEPROM, garantindo a persistência dos dados
mesmo em caso de falhas na alimentação.
Neste sistema, os diferentes módulos são controlados por uma entidade central, a qual se
designou por módulo de processamento. Este será implementado com recurso a um
microcontrolador, que executará a aplicação que coordena o funcionamento de todo o sistema. Este
microcontrolador terá de possuir as interfaces para comunicar com os restantes dispositivos.
Uma vez que o sistema poderá ter de funcionar durante muitos dias sem interacção com o
exterior, é fundamental garantir a fidelidade no registo da data e hora. Para tal, o sistema deverá ter
um relógio com precisão adequada, pelo que se optou pelo uso de um Real-Time Clock.
Descreve-se nas secções adiante o processo de selecção de componentes e módulos para o
protótipo que se pretende implementar.
3.4 Selecção dos Módulos Constituintes
A presente secção tem como objectivo descrever os módulos electrónicos utilizados no
dispensador. Conforme referido, pretende-se a criação de um protótipo funcional e não um produto
final, sendo o tempo de desenvolvimento relativamente limitado. Como tal decidiu-se, quando
possível, utilizar módulos funcionais que contenham toda a electrónica necessária ao seu
funcionamento, requerendo apenas ligá-los a um microcontrolador e integrá-los na solução global.
Importa deixar claro que a escolha dos dispositivos se encontra limitada pelas ferramentas
disponíveis. Por exemplo, o equipamento de soldadura a que se tem acesso apenas permite o uso de
componentes com montagem through-hole (com espaçamento entre pinos que permita utilizar um
ferro de soldar convencional, adequados a placas de prototipagem tradicionais), deixando de fora os
componentes com montagem surface-mount (os quais são amplamente utilizados em produtos finais
mas requerem, tipicamente, ferramentas especializadas) [22].
Dado que a transição para um produto final irá requerer a adaptação de alguns componentes,
não se teve como um dos principais objectivos minimizar o custo do protótipo, tendo-se dado
24
prioridade à funcionalidade. No entanto, sempre que possível, optou-se pelas soluções mais baratas,
viáveis, de grande divulgação e que davam garantias de suporte. O custo final de um eventual
produto irá depender de muitos factores, em que aspectos de economia de escala serão muito
relevantes.
Por fim, convém realçar que, face ao mercado global actual, não é possível garantir uma
análise exaustiva de todas as alternativas existentes. Foi, no entanto, realizado um grande esforço de
pesquisa de múltiplas soluções e análise das mais divulgadas e com maior aceitação, o que oferece
um elevado nível de confiança nas escolhas realizadas.
3.4.1 Módulo GSM
Para realizar a comunicação por GSM, procurou-se um módulo que implementasse todo o
protocolo, simplificando o desenvolvimento ao nível do microcontrolador que gere o dispensador. O
principal requisito considerado foi a possibilidade de envio de SMS a partir dos dados recebidos de
um microcontrolador, para permitir alertar remotamente os cuidadores.
Das opções consideradas destacam-se os módulos FONA, da empresa Adafruit [23], e
SM5100B, da empresa Sparkfun [24], que foram descartados por causa do seu elevado custo (44.95
e 47.95 dólares, respectivamente). Alternativamente, optou-se por um módulo baseado no dispositivo
SIM900, da empresa SIMCom [25], que pode ser adquirido por um valor de cerca de 20 dólares1.
O SIM900 é um dispositivo quad-band, o que significa que suporta as 4 principais bandas de
frequência de operação do GSM (850/900/1800/1900 MHz) [25], tornando-o utilizável nas principais
redes do mundo. A sua potência de transmissão é de 2 Watts nas bandas dos 850 e 900 MHz e de 1
Watt nas bandas dos 1800 e 1900 MHz [25]. Possui várias interfaces, das quais se destacam o
suporte para I2C, SPI e comunicação série [25], bem como o suporte para uma interface áudio
analógica [25].
O SIM900 pode ser alimentado numa gama de tensões entre 3.2 e 4.8 V e consome cerca de
22 mA de corrente quando em modo Idle (registado na rede e pronto a comunicar), podendo atingir
picos de 2 A durante a transmissão de dados. O consumo em chamada depende da frequência de
comunicação utilizada e de um parâmetro de configuração referente ao controlo no nivel de consumo,
sendo indicado um valor máximo de 250 mA para as bandas de 850 e 900 MHz [26].
Face aos aspectos descritos e às funcionalidades disponibilizadas, a escolha recaiu sobre
este módulo, o qual está também disponível numa placa com fichas. Essa placa inclui uma antena e
as fichas para ligação a um altifalante e a um microfone, para realizar chamadas de voz. Possui ainda
um suporte para o cartão SIM, fichas de alimentação externa e alimentação por bateria e LEDs de
sinalização do estado de funcionamento. Pode ser alimentada com uma tensão de 5 V, evitando
conversões de tensões. A referida placa encontra-se representada na figura 12.
Apesar das diversas interfaces que o SIM900 tem, a placa utilizada apenas possibilita
interacção através de comunicação série, pois não tem os pinos das restantes interfaces acessíveis.
1 www.ebay.com
25
Figura 12 – Placa GSM baseada no módulo SIM900. Adaptado de [27].
3.4.2 Módulo Wi-Fi
Para a comunicação Wi-Fi, analisaram-se diversos módulos existentes no mercado, dos quais
se destacam os que utilizam o chip CC3000 da Texas Instruments [28], que aparenta ser um dos
mais comuns no desenho deste tipo de soluções. No entanto, estes produtos apresentam um preço
bastante elevado (na ordem dos 30 dólares [28]). Outra alternativa analisada foram os módulos
baseados no chip HC-21, que têm um custo na ordem dos 10 dólares2.
No entanto, uma pesquisa mais detalhada revelou uma solução recente da empresa Espressif
Systems, designada ESP8266 [29], na qual existem módulos baseados com preços da ordem dos 2.5
dólares2, razão pela qual se adoptou este dispositivo.
O ESP8266 tem uma área de apenas 5 mm x 5 mm, integra um processador 106micro
Diamond Standard core da Tensilica [30] (CPU RISC de 32 bits) e suporta as interfaces SPI, I2C e
série [29]. Possui ainda 16 pinos de entrada/saída para uso genérico e opera a uma tensão de 3.3V
[29]. No que diz respeito ao Wi-Fi, implementa as especificações dos standards 802.11 b, g e n,
suporta Wi-Fi direct e integra todo o stack do protocolo TCP/IP [29]. A nível de memória, possui 64
KB de RAM para instruções, 96 KB de RAM para dados e 64 KB de ROM [30]. O ESP8266 consome
cerca 0.9 mA em standby, cerca de 60 mA durante a recepção de pacotes e, no processo de
transmissão, pode atingir picos de 215 mA [29]. No entanto, não é clarificado em que estado se
encontra o rádio do ESP8266 quando este se encontra em modo standby, pelo que não é possível
concluir qual o consumo do módulo quando este se enconta ligado a um acess point sem estar a
comunicar.
Dos diversos módulos existentes com base no ESP2866, seleccionou-se o ESP-01. Este tem
as dimensões de 14.3 mm x 24.8 mm e integra na sua PCB uma antena e uma memória Flash [31],
conforme ilustrado na figura 13. Tem ainda a particularidade de só disponibilizar oito dos pinos do
ESP8266, sendo adequado a aplicações nas quais interage com outro processador através de
2 www.ebay.com
26
comunicação série, estando particularmente vocacionado para permitir o envio e recepção de dados
através da Internet. A placa ESP-01 consome um total de 70 mA durante a sua operação regular,
podendo atingir picos de 300 mA durante a transmissão [32].
Figura 13 – Módulo ESP-01, baseado no dispositivo ESP8266. Adaptado de [31].
3.4.3 Módulo Bluetooth
Para implementação da comunicação Bluetooth procurou-se um módulo que suportasse o
perfil SPP (Serial Port Profile), o qual permite trocar dados entre dois dispositivos simulando uma
comunicação série [33]. Este modo de comunicação é importante pois é suportado pela generalidade
dos microcontroladores. Este módulo irá servir de ponte de comunicação entre o microcontrolador e
dispositivos como Tablets ou Smartphones.
Existem no mercado vários módulos que satisfazem o requisito anterior, os quais podem ser
directamente ligados à UART de um microcontrolador [34] [35], permitindo assim estabelecer um
canal de comunicação de forma transparente. Das soluções analisadas, optou-se por um módulo
baseado no dispositivo HC-06, da empresa Guangzhou HC Information Technology [36].
Comparativamente a outras alternativas analisadas, este é um dispositivo com características
inferiores, uma vez que tem um alcance máximo de 10 metros [37] e só opera no modo slave do
protocolo Bluetooth. Existem outros produtos que têm alcances até 100 metros [38] e suportam
diferentes perfis de operação [39]. No entanto, são bastante mais caros, rondando os 30 dólares, ao
passo que os módulos baseados no HC-06 podem ser adquiridos por cerca de 3.5 dólares3. Dado
que o Bluetooth irá ser usado apenas para o dispensador comunicar com um dispositivo local, o
alcance de 10 metros é suficiente. Para além disso, será sempre o dispositivo externo a iniciar a
comunicação com o dispensador, razão pela qual o facto do módulo apenas poder operar como slave
não traz qualquer inconveniente.
Relativamente às restantes especificações, o HC-06 implementa os standards da versão
Bluetooth 2.0 e suporta ritmos de comunicação série até 1382400 Baud [37]. Opera a uma tensão de
3.3 V [37] e tem um consumo de corrente da ordem dos 30 a 40 mA no processo de emparelhamento
e de 8 mA durante a comunicação [36]. O HC-06 inclui já uma antena integrada no módulo [37].
A nível de configuração, o HC-06 suporta a recepção de comandos AT, que permitem alterar
alguns dos parâmetros de funcionamento, como o ritmo de transmissão dos dados da comunicação
série, o nome e a chave usada no processo de emparelhamento do Bluetooth. O envio de comandos
AT para o módulo só é possível antes do emparelhamento [37]. A partir desse momento, o módulo
passa apenas a servir de ponte de conversão entre as interfaces série e Bluetooth.
3 www.ebay.com
27
No contexto do projecto aqui descrito, o HC-06 é utilizado integrado num módulo que possui
um LED de sinalização do estado de emparelhamento do dispositivo e permite a sua alimentação
com tensões entre os 3.6 e os 6 V [40]. Este módulo encontra-se ilustrado na figura 14.
Figura 14 – Módulo de comunicação baseado no dispositivo HC-06. Retirado de [40].
3.4.4 Módulo RTC
Para garantir que as horas e a data são mantidas certas, será usado um RTC (Real-Time
Clock). Sendo um componente muito usado, existem opções de vários fabricantes, suportando
interfaces de comunicação como I2C e SPI [41] [42]. Um factor selecção inicial foi a existência de
módulos prontos a utilizar e de baixo custo, com uma interface I2C (uma vez que requer menos pinos
que o SPI). Das soluções analisadas, destacam-se os RTC DS1307 e DS3231 da Maxim Integrated
[43] [44], os quais servem de base a vários módulos com preços de cerca de 1 euro4.
A diferença mais relevante entre ambas as soluções prende-se com a sua precisão, uma vez
que o funcionamento do DS1307 usa um cristal de quartzo externo [43] e o DS3231 um cristal
integrado no chip, com compensação de temperatura através de condensadores ajustáveis na sua
malha de ressonância [44]. Uma vez que, entre outros factores, a precisão de uma malha de
ressonância baseada num cristal de quartzo é afectada pela temperatura do ambiente onde opera,
considerou-se o DS3231 uma opção superior. Assim, escolheu-se este RTC, que mantém a data e
hora com uma precisão de ± 2 minutos por ano [44].
Do ponto de vista da energia, pode ser alimentado com uma tensão entre 2.3 e 5.5 V, bem
como pode funcionar com uma bateria de reserva. A mudança da alimentação para a bateria é
efectuada automaticamente através de um circuito comparador de tensão. Internamente, a tensão de
operação é de 3.3 V [44]. Quando alimentado por uma tensão de 5.5 V, o consumo médio
especificado pelo fabricante é de 300 µA, enquanto que se essa mesma tensão for fornecida pela
bateria este valor baixa para os 150 µA [44].
O circuito RTC seleccionado fornece informação referente a segundos, minutos, horas, dia,
mês e ano, com ajuste automático para meses com menos de 31 dias e compensação de anos
bissextos (válido até 2100). Essa informação pode ser lida através da interface I2C [44].
Utiliza-se o DS3231 integrado num módulo, o qual se encontra representado na figura 15.
Este inclui um adaptador para colocar uma bateria e, adicionalmente, possui o circuito AT24C32 [45],
que corresponde a uma memória EEPROM de 4 KB da Atmel, também acessível por I2C [46].
4 www.ebay.com
28
Figura 15 – Módulo RTC que usa o DS3231 e a EEPROM AT24C32. Retirado de [45].
3.4.5 Motor
Para movimentar a estrutura circular que contém os compartimentos para os medicamentos
considerou-se o uso de um motor de passo (step motor). Um motor de passo é um dispositivo cuja
rotação normal do eixo consiste em movimentos angulares discretos, sendo adequado para
aplicações nas quais os sinais de controlo são pulsos digitais, ao invés de tensões analógicas [47].
Um pulso digital faz com que o motor incremente a posição do eixo por um ângulo preciso, razão pela
qual podem trabalhar em malha aberta (sem feedback) [47]. Assim, considera-se preferível este tipo
de solução face a um motor DC normal, uma vez que permite controlar de forma precisa os
movimentos angulares e alinhar correctamente os compartimentos.
Para evitar usar mais uma tensão de alimentação, procurou-se um motor que operasse a 5 V,
que é a tensão da maioria dos componentes utilizados. Outro dos requisitos impostos foi o de possuir
um sistema de desmultiplicação interno, garantindo assim que teria força suficiente para movimentar
a estrutura circular e evitando o trabalho mecânico de implementar esta desmultiplicação.
Dado que a estrutura circular irá ser dividida em 29 compartimentos (28 para medicação e um
para ser deixado vazio no início, uma vez que está logo acessível), ter-se-á um valor de
aproximadamente 12.4º de arco para cada compartimento, razão pela qual se especificou que o
ângulo correspondente a cada passo do motor teria de ser igual ou inferior a 0.1º.
Das soluções analisadas optou-se por utilizar o motor 28BYJ-48, ilustado na figura 16, que
corresponde a um motor de passo que opera a 5 V e cujas especificações indicam que possui uma
desmultiplicação interna de 1/64 e um ângulo por passo de 5.625º/64 [48] (aproximadamente 0.088º).
Estes valores correspondem a 4096 passos por rotação completa, satisfazendo assim os requisitos
anteriores. Para além disso, este modelo é produzido em grandes quantidades para unidades de ar
condicionado e ventiladores, razão pela qual pode ser comprado por um valor bastante reduzido [49].
Figura 16 – Motor de passo 28BYJ-48. Retirado de [48].
O 28BYJ-48 é um motor de quatro fases [48], pelo que são necessários quatro pinos digitais
de um microcontrolador para o controlar. Dado ser necessária uma corrente significativa para
29
movimentar o motor, o microcontrolador comandará o circuito integrado ULN2803, que corresponde a
um array de transístores na configuração Darlington [50], que pode fornecer a corrente necessária.
Importa referir que os testes experimentais executados com o 28BYJ-48 revelaram que os
valores especificados pelos vendedores para a desmultiplicação se encontram errados, o que foi
corroborado por informação fornecida por outros utilizadores do motor. Assim, o valor real é de
63.68395:1 [51], o que corresponde a aproximadamente 4075.773 passos por rotação completa.
3.4.6 Sensor de controlo de posição
Conforme referido anteriormente, o uso de um motor de passo garante uma elevada
fiabilidade no controlo da plataforma com os medicamentos. No entanto, considerou-se que tal não
invalida o uso de um mecanismo de feedback, que permitirá corrigir eventuais erros pontuais
ocorridos durante a movimentação. Para além disso, em caso de falha na alimentação do
dispensador, é fundamental ter um mecanismo que permita reposicionar o motor numa posição de
referência conhecida. Para implementar este mecanismo, considerou-se o uso de um sensor óptico
(optocouplador) ou de um sensor magnético (sensor de Hall).
Os sensores de Hall são dispositivos que detectam campos magnéticos e produzem um sinal
analógico ou digital, de acordo com a intensidade deste campo [52]. Já os optocopladores são
dispositivos que consistem num emissor de sinal óptico (tipicamente, um LED infra-vermelho) e num
receptor do sinal (um fototransístor) [53]. Quando o LED é alimentado, produz um sinal óptico que o
fototransistor capta e converte novamente para um sinal eléctrico [53]. Se existir algum objecto no
caminho do sinal óptico, o fototransístor deixa de o detectar, deixando de ser produzido um sinal na
saída. A figura 17 resume o princípio de operação de ambas as soluções.
Figura 17 – Princípio de funcionamento de um sensor de Hall (acima) e de um optocouplador
(abaixo). Adaptado de [53] [52].
Tendo em conta a explicação anterior, a solução que utiliza um sensor de Hall obrigaria ao
uso de ímans na estrutura circular, ao passo que para o optocoplador bastaria apenas que esta fosse
desenhada com extrusões plásticas nos compartimentos que se pretendessem detectar. Dado que
ambos os dispositivos podem ser adquiridos a preços relativamente baixos (inferiores a 1 euro),
considerou-se mais cómoda a solução baseada no optocoplador, que evita a aplicação dos ímans.
30
Optou-se pelo uso do modelo ITR9608 da Everlight, o qual consiste num LED infra-vermelho
e num fototransístor NPN, encapsulados num invólucro plástico [54], conforme ilustrado na figura 18.
O eixo óptico do optocouplador encontra-se na ranhura central do dispositivo, com o fototransistor e o
LED nas extremidades [54]. O pico de sensitividade espectral do dispositivo corresponde ao
comprimento de onde de 940 nm [54], o que reduz interferências causadas pela luz visível.
Figura 18 – Optocouplador ITR9608 (à esquerda) e diagrama eléctrico correspondente (à direita).
Adaptado de [54] [55].
3.4.7 Teclado
Para facilitar a interacção directa com o dispensador, considerou-se o uso de um teclado
alfanumérico, para facilitar a navegação nos menus e a introdução de valores numéricos nos campos
de configuração. Como tal, pretendia-se uma solução que pudesse acomodar os botões referentes
aos dígitos de “0” a “9”, quatro teclas de navegação e duas para funcionalidades de “ok” e “cancelar”.
Para satisfazer o requisito anterior, optou-se por utilizar um teclado genérico de membrana de
quatro linhas e quatro colunas, de baixo custo, o qual se encontra ilustrado na figura 19. A disposição
apresentada para as teclas não é a mais adequada para um produto final, pelo que o seu contexto de
utilização é apenas pertinente para o protótipo. Assim, as teclas numéricas serão utilizadas para a
introdução de dígitos, as teclas “*”, “#”, “C” e “D” para navegação nos menus (esquerda, direita, cima
e baixo) e as teclas “A” e “B” como “Ok” e “Cancelar”, respectivamente.
Figura 19 – Teclado de membrana utilizado no protótipo (à direita) e correspondente esquema
eléctrico (à esquerda). Adaptado de [56].
3.4.8 Display
Para dar suporte à interacção directa com o cuidador (para configurar o dispositivo) e face à
diversidade de informação que é conveniente poder visualizar, torna-se imprescindível o uso de um
display. Esse display será também utilizado para mostrar avisos e mensagens à pessoa cuidada.
31
Dado estar-se perante um protótipo pretende-se, nesta fase, simplificar o processo de
desenvolvimento e validar a abordagem proposta, possibilitando a demonstração das
funcionalidades. Como tal, optou-se pelo uso de um display LCD muito simples e económico.
Uma vez que existe uma enorme variedade de LCDs dentro das especificações anteriores, a
escolha baseou-se no número de caracteres pretendido. Como tal, considerou-se razoável um
número de oitenta caracteres para possibilitar a escrita de mensagens textuais com alguma margem.
Assim, optou-se pelo LCD QC2004A, o qual se encontra organizado em quatro linhas de vinte
caracteres, opera à tensão de 5 V e tem um consumo de corrente de 1.6 mA, com a retroiluminação
inactiva [57]. O referido LCD encontra-se ilustrado na figura 20. Cada caracter tem uma dimensão
2.94 mm × 4.74 mm e um espaçamento de caracteres adjacentes de cerca de 0.6 mm [57].
Figura 20 – LCD QC2004A, utilizado no protótipo. Retirado de [58].
A interacção com este display requer oito sinais para envio de dados [57], obrigando ao uso
de oito pinos para o seu controlo. Para simplificar esta interacção e tornar o sistema mais modular,
optou-se pelo uso de um módulo de interface dedicado que usa comunicação I2C. Este módulo é
baseado no circuito integrado PCF8574 e permite fazer a conversão entre I2C e uma interface de
entrada/saída de 8 bits [59], reduzindo assim o número de pinos necessários do microcontrolador.
Considerando os padrões actuais, o mais adequado seria usar um display gráfico. No
entanto, constatou-se que o uso deste tipo de display coloca outro tipo de dificuldades de
implementação, tornando o desenvolvimento complexo. Para além da vertente técnica, existem
aspectos relacionados com o desenho e estética da interface, que estão fora do âmbito do projecto.
3.4.9 Bezouro
Para gerar o sinal sonoro do dispensador recorreu-se a um bezouro (buzzer) genérico de 5 V.
Optou-se por escolher um buzzer passivo, permitindo assim controlar a frequência do som emitido.
Uma vez que se pretende ter a possibilidade de controlar a intensidade do som gerado pelo
buzzer, optou-se pelo uso de um potenciómetro digital, que permite controlar a tensão do sinal
eléctrico aplicado. A escolha de um potenciómetro digital oferece a vantagem de o volume poder ser
controlado por software, possibilitando ao cuidador configurar este parâmetro remotamente. A
solução adoptada usa o circuito integrado MCP41010, que pertence a uma família de potenciómetros
digitais de 256 posições, controlados por SPI [60].
32
Este dispositivo em concreto corresponde à versão de 10 kΩ, com um valor nominal de 52 Ω
e incrementos de 39.0625 Ω. Opera numa gama de tensões entre os 2.7 e os 5.5 V e tem um
consumo máximo de 500 µA de corrente quando activo [60].
3.5 Selecção do módulo de processamento
3.5.1 Entradas/saídas e periféricos do microcontrolador
No que diz respeito à interacção com os dispositivos analisados, a tabela 1 resume o número
de pinos de entrada/saída (IO) e as interfaces de comunicação necessárias. Conforme se pode
observar, será necessário um número considerável de pinos de IO, suporte para I2C, SPI e, no
mínimo, três UARTs para a comunicação série.
Cumprir estes requisitos não será problemático na medida em que o hardware
correspondente a estas interfaces de comunicação é relativamente simples e normalizado, sendo
muito comum em vários microcontroladores. Apesar de o número exacto de três UARTs ser uma
característica pouco comum, existem bastantes alternativas com um número superior.
Tabela 1 – Requisitos de entradas/saídas e interfaces de comunicação para o microcontrolador
Módulo / dispositivo Pinos de IO UART I2C SPI
GSM 0 X - -
Bluetooth 0 X - -
Wi-Fi 0 X - -
LCD 0 - X -
Teclado 8 - - -
Motor de passo 4 - - -
Optocouplador 1 - - -
RTC 0 - X -
Botões de pressão 3 - - -
Potenciómetro digital - - - X
Buzzer e LED 2 - - -
Total 18 3 1 1
Para além de quantificar os recursos necessários, importa ter em consideração a
necessidade de interacção quer com o utilizador quer com o cuidador, mais concretamente no que diz
respeito aos tempos de reacção aos eventos. Por exemplo, ao carregar no botão de dispensa, o
procedimento de disponibilização dos comprimidos deverá ser iniciado de imediato, na perspectiva do
utilizador. Da mesma forma, a interacção do cuidador com o teclado e consequente resposta no
display deve ocorrer de forma suave e fluída. Como tal, consideram-se adequados tempos de
reacção que não ultrapassem um décimo do segundo, o que é percepcionado como instantâneo.
Dado que se tomou a decisão de relegar para os módulos de comunicação a implementação
dos protocolos correspondentes (GSM, Wi-Fi e Bluetooth), grande parte do esforço de
33
processamento foi retirado do microcontrolador, que apenas tem de interagir com os mesmos através
de comunicação série. Para além disso, considerou-se desnecessário o uso de um sistema operativo,
que teria um overhead considerável.
Tendo em conta as observações anteriores, considerou-se suficiente o uso de um
microcontrolador que tenha uma capacidade de execução de instruções da ordem da dezena de
milhão por segundo. Este valor é adequado para o tipo de funcionalidades a implementar, permitindo
igualmente responder aos eventos assíncronos em tempos aceitáveis. Como actualmente a
generalidade dos microcontroladores implementam arquitecturas RISC que lhes permitem executar
um MIPS (Million of Instructions per Second) por cada MHz, considera-se suficiente uma velocidade
de relógio da ordem das dezenas de MHz.
No que diz respeito à dimensão da memória de programa, é difícil fazer uma estimativa
precisa. Existem factores que influenciam o tamanho final da aplicação, que vão desde detalhes de
implementação não inicialmente previstos à optimização que o compilador realiza ao código. No
entanto, sabe-se de antemão que o facto de se pretender permitir a configuração do dispensador
através do teclado e do LCD se irá traduzir em inúmeros menus, com muitas cadeias de caracteres
(strings), implementados com uma quantidade considerável de código. Para além disso, pretende-se
ter uma boa margem de manobra para a eventual implementação de funcionalidades inicialmente não
previstas, pelo que se estabeleceu um valor próximo da centena de KB para a memória de programa.
Para analisar a capacidade de memória RAM necessária, consideraram-se as principais
estruturas de dados que se antecipam ser necessárias na aplicação, as quais se encontram indicadas
na tabela 2. Uma vez que o display utilizado suporta um máximo de 80 caracteres, considerou-se 60
bytes a dimensão máxima das mensagens textuais (para ter uma linha disponível para colocar
alguma informação acessória). Todas as mensagens textuais estarão guardadas na EEPROM, pelo
que, a cada momento, só será necessário ter em RAM os dados correspondentes às mensagens do
alarme e notificação actuais, tal como as correspondentes informações de disparo.
Em relação ao protocolo de comunicação, considerou-se a criação de uma solução
decomposta em comandos simples e compactos, pelo que se antecipou que a mensagem de
dimensão maior corresponderia à configuração de uma mensagem textual, a qual, adicionada dos
cabeçalhos associados ao protocolo, se estimou não ultrapassar os 80 bytes.
O valor de 160 bytes para o buffer surge pelo facto de a recepção de bytes nas UARTs ser,
tipicamente, efectuada com recurso a interrupções, para não se perderem dados no caso de se estar
a efectuar algum outro procedimento. Como as interrupções têm de ser rápidas, não é viável realizar
verificações aos dados recebidos dentro das mesmas. Como tal, considerou-se uma implementação
na qual as interrupções colocam os dados num buffer inicial, sem qualquer tipo de verificação, sendo
depois transferidos para um buffer de mensagem quando o processador se encontrar disponível,
realizando-se neste procedimento toda a verificação referente à estrutura do protocolo. Uma vez que
se pretende ter os três canais de comunicação a operar de forma independente, cada UART terá de
ter associada uma destas estruturas.
Para o caso de existir algum problema com os canais de comunicação remotos, considerou-
se ainda uma pilha para guardar as notificações geradas, para posterior envio.
34
Tabela 2 - Principais estruturas de dados a utilizar e dimensão correspondente.
Estrutura de dados Dimensão
[bytes]
Quantidade Dimensão total
[bytes]
Buffer de recepção de dados da UART 160 3 480
Mensagem textual 60 2 120
Informação de disparo do alarme 10 1 10
Informação de disparo do aviso textual 10 1 10
Pilha para notificações remotas pendentes 100 2 200
Total 820
Conforme se pode verificar, chegou-se a um valor de aproximadamente 820 bytes, ao qual é
necessário adicionar todos os dados de configuração do funcionamento do dispensador, as variáveis
auxiliares na implementação da aplicação, o eventual uso de bibliotecas de programação e o espaço
para a pilha (stack) associada ao funcionamento do microcontrolador. Como tal, considera-se uma
dimensão para a memória RAM não inferior a 4 KB.
Apesar de o módulo RTC seleccionado dispor de uma EEPROM, considerou-se preferível
guardar os dados referentes a mensagens e alarmes numa memória do microcontrolador, para um
acesso mais rápido. Tendo em conta a existência de 28 alarmes, 30 mensagens textuais e 30 avisos,
chega-se a um valor mínimo de 2380 bytes. Considerando ainda a restante informação acessória que
poderá ser necessário guardar, definiu-se como dimensão mínima para a memória EEPROM interna
ao microcontrolador o valor de 4 KB de dimensão (como 2 KB seria insuficiente e as capacidades das
memórias são uma potência de 2, este é o valor mais adequado).
Importa deixar claro que os valores especificados correspondem à análise efectuada antes de
se iniciar o desenvolvimento da aplicação. Como tal, as especificações foram estimadas com base
nos módulos electrónicos escolhidos, bem como no planeamento inicial para a aplicação. Como se
verá adiante, o processo de desenvolvimento levou a algumas alterações, as quais puderam ser
acomodadas em virtude da escolha de uma plataforma de desenvolvimento com uma tolerância
razoável nos recursos disponíveis.
3.5.2 Placa de desenvolvimento
Dentro das opções disponíveis que cumprissem as especificações anteriormente descritas
para o microcontrolador, procurou-se uma placa de desenvolvimento pronta a utilizar, apenas com o
hardware mínimo necessário ao carregamento e execução de aplicações. Para além disso, procurou-
se uma solução bem documentada, com ferramentas de desenvolvimento estáveis e fáceis de utilizar.
Dada a enorme lista de microcontroladores existentes, produzidos pelas mais variadas
empresas [61], optou-se por reduzir a procura a duas das soluções mais divulgadas no mercado,
mais concretamente as famílias PIC da Microchip e AVR da Atmel. Em ambos os casos, existem
diversos microcontroladores que cumprem as especificações requeridas [62] [63], razão pela qual se
optou por tomar a decisão com base nas placas de desenvolvimento existentes.
35
Apesar de existirem várias placas baseadas em microcontroladores PIC [64], a opção
escolhida recaiu pela família de placas Arduino, que utilizam marioritariamente microcontroladores
AVR [65]. Esta decisão resulta do facto de esta plataforma ter uma comunidade de suporte
consideravelmente superior [66], com imensas bibliotecas de programação auxiliares que facilitam
todo o processo de desenvolvimento [67].
Para além disso, o Arduino possui uma linguagem própria com funções que escondem muitos
dos detalhes de baixo nível necessários para interagir com um microcontrolador, apesar de suportar
código normalizado em C e C++ [68]. Assim, permite balancear a abstracção das referidas funções
com a possibilidade de optimizar secções de código críticas, possibilitando o uso de bibliotecas AVR
e o acesso directo aos registos internos do microcontrolador [69].
3.5.3 Placa “Arduino Mega”
O Arduino é uma plataforma open source utilizada para o desenvolvimento de projectos de
sistemas embebidos e de electrónica [70]. Consiste numa placa com um microcontrolador
programável e dispõe de um IDE (Ambiente de Desenvolvimento Integrado) que executa num
computador (com sistema operativo Windows ou Linux) e é utilizado para desenvolver e carregar o
código para a placa [70]. Esta plataforma tornou-se bastante popular porque não necessita de
hardware auxiliar (programador) para carregar código para o microcontrolador, sendo apenas
necessário um cabo USB [70], para efectuar a ligação entre o dispositivo e o computador. O cabo
USB também pode ser usado para alimentar a placa.
No que diz respeito ao ambiente de desenvolvimento, o referido IDE permite editar, compilar
e carregar o código para a placa [71]. O código é desenvolvido numa linguagem modelada a partir da
linguagem Processing, que é traduzida para C e passada ao compilador avr-gcc, que faz a tradução
final para a linguagem do microcontrolador [72]. No entanto, estes passos de tradução são
efectuados automaticamente no IDE, não sendo necessário qualquer tipo de software auxiliar.
Importa referir que o ambiente de desenvolvimento é tão versátil que não necessita de
funcionar com uma placa Arduino [71]. Assim, apesar de se estar a desenvolver uma aplicação para
um protótipo, pode-se mais tarde utilizar o mesmo código numa PCB feita à medida para o
dispensador, bastando para tal utilizar um microcontrolador da mesma família da placa Arduino.
Embora se mencione genericamente “placa Arduino”, na realidade existe um conjunto muito
diversificado de placas de desenvolvimento que usam microcontroladores da família AVR, com
diferentes características [65]. De entre as variantes existentes, considerou-se que o Arduino Mega, o
qual se encontra ilustrado na figura 21, seria o mais adequado. Este utiliza um microcontrolador AVR
ATmega2560 [73] da Atmel, com arquitectura RISC de 8 bits [74]. O microcontrolador pode operar a
uma frequência de 16 MHz, numa gama de tensões entre 4.5 V e 5.5 V [74]. Possui uma memória
EEPROM de 4 KB para armazenamento persistente, uma memória Flash de programa de 256 KB e
uma memória SRAM de dados de 8 KB [74].
Do ponto de vista de comunicação com periféricos externos, é suportado o uso das interfaces
SPI, I2C e série, com 4 UARTs distintas [73]. Dos 86 pinos de I/O que o microcontrolador possui, o
Arduino Mega possibilita o uso de 54 pinos digitais, quer para entrada quer para saída, bem como 16
36
pinos para leitura analógica, com uma resolução de 10 bits [73]. Os pinos digitais operam a uma
tensão de 5 V e podem receber ou fornecer, no máximo, uma corrente de 40 mA [73]. Os pinos
analógicos operam numa gama de tensões entre os 0 V e os 5 V [73]. Dos referidos 54 pinos digitais,
15 possibilitam gerar sinais PWM (Pulse Width Modulation) [73].
Figura 21 – Placa de desenvolvimento Arduino Mega. Retirado de [73].
Conforme se pode concluir, o Arduino Mega cumpre todos os requisitos necessários ao
desenvolvimento da aplicação. No que diz respeito aos pinos de entrada/saída, o número disponível é
superior ao necessário, tal como a dimensão da RAM. No entanto, esta é a placa que mais se
aproxima do especificado, sendo que a outra solução que cumpre os requisitos (o Arduino DUE [65])
é ainda mais poderosa e, consequentemente, mais cara. As restantes placas de desenvolvimento
falham em cumprir um ou mais dos requisitos anteriores, pelo que foram descartadas.
3.6 Outros componentes do sistema
De modo a dar maior robustez à solução desenvolvida, o dispensador será alimentado a partir
de uma fonte principal, ligada à rede eléctrica, e incluirá uma fonte de reserva constituída por uma
bateria. Desta forma, em caso de falha da fonte principal, o dispensador comuta automaticamente
para a bateria, sendo possível manter o seu funcionamento normal. Adicionalmente, é possível avisar
o cuidador da falta de energia (através de uma notificação remota), o qual poderá tomar qualquer
medida que se mostre necessária caso esta situação se alongue demasiado no tempo.
Para a fonte principal utiliza-se um transformador de 9 V e para a fonte de reserva uma
bateria de chumbo de 6 V, com uma capacidade de 1200 Ah. Para implementar a comutação
automática entre ambas, recorreu-se a um circuito com dois díodos, configurados como indicado na
figura 22. Este circuito garante que a alimentação é realizada a partir da fonte principal se ambas
estiverem presentes e a partir da bateria caso a fonte principal falhe [75].
Para tal, a tensão da fonte principal necessita ser superior à tensão da bateria [75], o que
justifica os valores escolhidos para a bateria e para o transformador. Importa referir que o díodo da
fonte de menor tensão irá garantir que não há corrente a fluir nesse sentido [76], desde que se
respeite o valor de tensão inversa máximo suportado.
Para monitorizar qual das fontes se encontra activa num dado momento, recorreu-se a um
divisor de tensão resistivo, dimensionado com resistências de igual valor, pelo que a tensão de saída
37
é igual a metade da tensão de entrada. Como tal, a tensão de alimentação da fonte principal (9 V) é
convertida para 4.5 V, o que corresponde a um nível TTL, monitorizável por um pino digital do
microcontrolador e permitindo identificar de forma binária se esta se encontra ou não activa.
Uma vez que os módulos e circuitos utilizados no dispensador operam com tensões de 5 e
3.3 V, recorreu-se ao uso de dois reguladores de tensão, conforme indicado na figura 22. No caso da
regulação da tensão da bateria para os 5 V, foi necessário especial cuidado pois existe uma diferença
de tensão entre o valor de entrada e o valor de saída muito baixa (inferior a 1 V). Como tal, utilizou-se
o regulador LM2940, que permite diferenças de tensão entre a entrada e saída de 0.5 V (valor tipico
para uma corrente de saída de 1 A [77]), bem como se optou pelo uso de diodos Schotky, que têm
valores de queda de tensão inferiores (bem como velocidades de comutação superiores) [78].
Figura 22 – Esquema eléctrico do circuito de alimentação do dispensador.
O esquema eléctrico da solução final encontra-se representado na figura 23.
Para permitir desligar alguns dos módulos do dispensador e, desse modo, reduzir o consumo do
circuito quando não estão a ser usados, incluíram-se MOSFETs de potência no circuito da
alimentação do LCD e dos módulos Wi-Fi e Bluetooth. Desta forma, permite-se que o
microcontrolador ligue e desligue os módulos indicados.
Dado que é necessário recorrer a um botão de pressão para ligar e desligar o módulo de GSM,
esta técnica não lhe pôde ser aplicada. Porém, esta limitação seria facilmente ultrapassada no
desenho do circuito de um produto final.
38
Figura 23 – Esquema eléctrico do protótipo desenvolvido.
Na configuração usada, o MOSFET opera como um interruptor, deixando ou não fluir corrente
de acordo com os valores aplicados ao seu pino de Gate, em referência ao pino de Source.
Controlando a tensão na Gate é possível colocar o MOSFET a operar na região de saturação (existe
condução) ou corte (não existe condução) [79]. O valor do limiar de tensão que define a transição
entre estes dois estados depende do modelo utilizado, razão pela qual se optou por utilizar o
MOSFET IRF9Z24, que apresenta uma tensão de limiar máxima de 4 V [80], podendo então ser
controlado de forma binária por uma saída do microcontrolador.
Uma vez que a Gate do MOSFET tem capacidades parasitas associadas, é fundamental o
uso de uma resistência em série com o pino digital para evitar picos de corrente durante as transições
de estado, que poderiam danificar o microcontrolador.
Importa referir o MOSFET não funciona como um interruptor ideal. Na realidade, existe uma
pequena corrente de fuga, que neste circuito é desprezável, quando o dispositivo se encontra no
estado off (500 µA para o MOSFET utilizado [80]), bem como uma resistência associada ao estado de
condução (0.28 Ω para o MOSFET utilizado [80]).
Conforme referido, utiliza-se um optocouplador como mecanismo de feedback no controlo da
estrutura que contém os medicamentos. Para converter o sinal analógico da saída do optocouplador
num sinal digital, utilizou-se um esquema no qual o fototransistor está configurado numa montagem
de amplificação de emissor comum [81], a qual irá colocar um valor de tensão correspondente a VCC
39
quando o sinal óptico se encontra bloqueado e a GND caso o sinal óptico atinja o fototransístor [82].
Desta forma, pode-se monitorizar de forma binária se o espaço entre o transistor e o LED se encontra
ou não obstruído.
Dada a natureza esporádica das dispensas, a percentagem de tempo de utilização do
optocouplador é extremamente baixa. Como tal, optou-se por realizar a sua alimentação a partir de
um pino digital do microcontrolador, permitindo ligar o dispositivo apenas quando necessário e
evitando assim um gasto contínuo e desnecessário de energia.
Um dos maiores problemas que se fez sentir foi o ruído eléctrico introduzido pelo funcionamento
dos diversos módulos. Este problema manifestou-se, em particular, no controlo do motor de passo,
que operava de maneira incorrecta ou irregular.
De forma a resolver o referido problema, aplicaram-se condensadores de filtragem e de
estabilização de tensão na alimentação dos diferentes módulos e circuitos integrados. Esta técnica
permite não só reduzir o ruido como também reduzir o efeito das quedas de tensão na fonte de
alimentação, uma vez que os condensadores acumulam carga eléctrica que fornecem quando essa
situação ocorre [83].
O problema do esquema possuir módulos a operar a 3.3 V e a 5 V estende-se para além da
alimentação e afecta também as interfaces de comunicação. Uma vez que o Arduino opera a 5 V e os
módulos de Bluetooth e Wi-Fi a 3.3 V, é necessário efectuar a conversão de tensão dos sinais
gerados pela UART do microcontrolador. No sentido oposto não é necessário este procedimento
porque os sinais a 3.3 V são interpretados pelo microcontrolador como ainda correspondentes ao
nível lógico “1”. É necessário ter um especial cuidado na escolha do método de conversão para não
afectar a forma e rapidez das transições dos sinais eléctricos.
Recorre-se ao circuito integrado MCP41010 para realizar um controlo digital da intensidade
sonora do bezouro, de forma a limitar a corrente fornecida. No entanto, o MCP41010 apenas suporta
um valor máximo de corrente de 1 mA [60], razão pela qual não pode ser usado para controlar
directamente o bezouro. Como tal, utiliza-se um transistor numa montagem de colector comum para
controlar o sinal aplicado ao bezouro. Assim, o potenciómetro digital serve apenas para controlar o
sinal de entrada, sendo percorrido por uma corrente mínima. A corrente necessária ao funcionamento
do bezouro é então fornecida pela fonte externa, evitando danificar o pino de controlo do
microcontrolador e o potenciómetro.
40
4 Detalhes de implementação
4.1 Estrutura do programa
No contexto da aplicação a desenvolver para executar no microcontrolador, considerou-se
não ser necessário o uso de um sistema operativo. Esta abordagem levaria a um maior consumo de
memória e a uma perda de eficiência, associado ao próprio funcionamento do núcleo operativo, e
colocaria restrições na escolha do microcontrolador, por razões de compatibilidade, face ao núcleo
operativo que viesse a ser seleccionado.
Assim, após uma análise prévia das funcionalidades a implementar e do paralelismo das
acções a executar, concluiu-se que o uso de um ciclo principal, complementado com o recurso a
interrupções, seria suficiente. As interrupções são fundamentais para lidar com a quantidade de
eventos assíncronos possíveis, em particular para a comunicação e interacção com o utilizador.
De modo a tornar as interrupções o mais rápidas possível, estas são utilizadas apenas para
capturar a informação que gerou a interrupção, sendo depois sinalizado o ciclo principal, por meio de
flags ou contadores, que determinado procedimento deve ser executado. Desta forma, a função de
tratamento do evento é relegada para o ciclo principal, o que é particularmente relevante caso o
processamento a executar seja intensivo. A tabela 3 resume as interrupções utilizadas.
Tabela 3 – Listagem das interrupções utilizadas no programa desenvolvido.
Interrupção Utilização Observações
Temporizador 5 Actualização da hora e data numa
representação interna usada no
microcontrolador
Sempre activa.
Envio e recepção de
dados nas UARTs
Comunicação série com os
módulos Bluetooth, Wi-Fi e GSM.
Activas quando a UART
correspondente está activa.
Utilizadas internamente pela
biblioteca de comunicação série.
INT4, INT5 e PCINT6
(pinos PE4, PE5 e PB6
do microcontrolador [84])
Detecção de actuações nos botões
de dispensa, PRN e
estabelecimento de comunicação
GSM.
Sensíveis à transição do nível
lógico 1 para o nível lógico 0.
PCINT23 (pino PK7 do
microcontrolador [84])
Detecção de falta de energia na
fonte de alimentação principal.
Sensível à mudança do nível
lógico.
No que diz respeito às técnicas de programação, tentou-se encontrar um balanço entre uma
abordagem genérica e eficiente. Conforme expectável, o uso de um microcontrolador implica certas
41
restrições nos recursos disponíveis, obrigando a um estilo de programação compatível com as
mesmas. No entanto, o ATmega2560 é um microcontrolador que apresenta um poder de
processamento considerável, pelo que se considerou pertinente dar maior ênfase a uma
implementação modular e escalável, que permita uma fácil reutilização e adaptação do código, com
vista a facilitar uma eventual transição para um produto final.
Conforme foi referido, existem imensas bibliotecas de programação para a plataforma
Arduino, que permitem facilitar quer a interacção com periféricos quer a implementação de várias
funcionalidades. No entanto, estas seguem, tipicamente, abordagens genéricas que permitem
satisfazer diferentes contextos de aplicação, à custa de perda de alguma eficiência. Como tal, optou-
se por utilizar essas bibliotecas apenas quando o esforço necessário para a sua implementação de
raiz fosse demasiado elevado ou quando não houvesse garantia de obter um melhor desempenho.
4.2 Data e hora
Para a garantir o correcto funcionamento de todos os eventos de dispensa e geração de
avisos textuais, é fundamental manter de forma correcta a data e hora durante um período de tempo
significativo (superior a 4 semanas), sem ser necessário ao cuidador efectuar acertos do relógio.
Na implementação proposta, a informação relativa à data e hora é mantida numa variável
global acessível a qualquer função, mais concretamente num array de 6 bytes que contém o ano
(últimos dois dígitos), o mês, o dia, a hora, o minuto e o segundo actuais. É a esta variável que as
funções de gestão dos alarmes e avisos textuais acedem para verificar o momento dos eventos
A passagem do tempo é contabilizada com recurso a um temporizador interno do
microcontrolador, o qual é programado para disparar com a periodicidade de um segundo. A cada
disparo do temporizador, é executada uma rotina de interrupção responsável exclusivamente por
assinalar ao ciclo principal a passagem de um novo segundo, de modo a executar o algoritmo de
actualização da data e hora.
No Arduino Mega, o relógio interno é gerado a partir de uma malha de ressonância
constituida por um cristal de quartzo de 16 MHz e dois condensadores [73]. A precisão na frequência
do sinal gerado por este tipo de circuito está dependente de factores ambientais como a temperatura,
bem como pela precisão no valor dos condensadores usados. Como tal, o erro resultante destas
variáveis manifesta-se nos temporizadores, cuja precisão é significativamente afectada. Nos testes
preliminares realizados ao funcionamento do algoritmo de actualização da hora, verificou-se um
atraso de cerca de meio minuto por dia, o que se considerou intolerável pois obrigaria a um acerto
regular da data e hora do dispensador pelo cuidador.
Para solucionar este problema, utiliza-se um módulo com um RTC (Real-Time Clock),
descrito no capítulo anterior, para actualizar o relógio interno do sistema. Assim, a cada trinta
minutos, os valores de data e hora do RTC são lidos através da interface I2C e utilizados para corrigir
os valores mantidos na aplicação. Esta periodicidade permite evitar o acesso constante ao relógio
externo e garante que o erro acumulado é sempre mantido a níveis aceitáveis.
Para manter a coerência entre os valores do relógio interno e do RTC, sempre que o cuidador
configura a data e a hora ambos os valores são actualizados.
42
O funcionamento do relógio interno do dispensador opera de forma independente das
restantes funcionalidades, tendo um comportamento modular e genérico, que o permitem ser utilizado
em contextos para além deste trabalho.
4.3 Dispensa de medicação
Para reduzir a probabilidade de erro de configuração, desenvolveram-se dois modos de
funcionamento distintos para o dispensador. No primeiro modo, designado de modo de configuração,
o cuidador pode realizar a configuração dos alarmes de dispensa e dos medicamentos PRN. Neste
modo não ocorre o disparo de alarmes nem pode ser dispensada medicação.
Uma vez configurados os alarmes e os medicamentos PRN, o cuidador deve colocar o
dispensador no segundo modo, designado modo de operação, no qual ocorre o disparo dos alames e
a medicação pode ser dispensada. No entanto, existe a possibilidade de efectuar correcções pontuais
a eventuais erros de configuração após início da operação, conforme descrito adiante.
Na transição do modo de configuração para o modo de operação existe um procedimento
auxiliar, no qual o cuidador pode visualizar os valores definidos para cada alarme e medicamento
PRN, sendo que a estrutura circular é movimentada para o compartimento correspondente. Desta
forma, pretende-se minimizar a probabilidade de erros na configuração.
Na transição do modo de operação para o modo de configuração, todos os registos de
alarmes e medicamentos PRN são eliminados, para permitir nova configuração. O dispensador pode
ser colocado no modo de configuração a qualquer momento.
4.3.1 Alarmes de dispensa
Apesar de, conceptualmente, o tratamento de alarmes aparentar ser algo simples, a
implementação de todas as funcionalidades que lhe estão associadas engloba um enorme conjunto
de pormenores, tornando a implementação complexa e susceptível a erros.
Um alarme tem sempre associada uma data e uma hora de disparo, a qual é directamente
comparada com a data e hora do dispensador. Caso coincidam, então ocorre o disparo do alarme.
Dado que a granularidade com que se consegue definir o alarme é o minuto, esta comparação é
efectuada apenas uma vez a cada 60 segundos, evitando assim operações desnecessárias.
Conforme explicado em pormenor mais adiante, as informações relativas aos alarmes
encontram-se guardadas na memória EEPROM do microcontrolador, por ordem crescente de data e
hora de disparo. No entanto, para evitar acessos repetidos a esta a cada minuto, as informações
referentes ao próximo alarme a disparar encontram-se em RAM. Como tal, assim que um alarme
dispara, o conteúdo do próximo alarme tem de ser imediatamente carregado da EEPROM para RAM
e tem de se iniciar a verificação da sua hora de disparo. No caso genérico, um alarme pode ter vários
compartimentos, os quais são representados em memória como alarmes adjacentes com a mesma
estampilha temporal, tal como ilustrado na figura 24.
43
Figura 24 – Representação em memória de alarmes associados a múltiplos compartimentos.
A possibilidade de um alarme estar associado a vários compartimentos torna o seu
tratamento um pouco mais complexo, na medida em que é necessário verificar quantos alarmes
adjacentes têm a mesma estampilha temporal, para determinar quantos compartimentos é necessário
dispensar. A figura 25 demonstra o procedimento executado quando é disparado um alarme. Importa
referir que as informações carregadas para a dose antecipada, tempo de tolerância e índice da
mensagem correspondem às presentes na primeira entrada da EEPROM. Os alarmes adjacentes
com a mesma estampilha temporal servem apenas para a contagem do número de compartimentos e
as suas restantes definições são ignoradas, mesmo que sejam diferentes.
Figura 25 – Carregamento de alarmes para memória RAM.
Para um alarme disparado que envolva múltiplos compartimentos, o utilizador deve carregar
no botão de dispensa tantas vezes quantas o número de compartimentos a dispensar. Só após todos
os compartimentos serem dispensados (ou a dispensa falhar) é que o alarme deixa de ser sinalizado.
Para o tempo de tolerância optou-se por uma abordagem simples, que evita a manipulação
de datas. O tempo de tolerância de cada alarme, especificado em horas e minutos, é convertido para
minutos no momento de disparo do alarme. A partir daí, a cada minuto, esse valor é decrementado e,
caso se atinja o valor zero sem ter sido efectuada a dispensa, a toma é considerada falhada.
Na implementação descrita, pode existir um conflito no caso do tempo de tolerância do
alarme i ser superior ao momento de disparo do alarme i+1 (partindo do princípio que a dispensa não
é efectuada antes desse disparo). Neste caso, quando é atingido o momento de disparo do alarme
i+1, a toma do alarme i é considerada automaticamente como falhada, mesmo que ainda restasse
tempo de tolerância, tal como ilustrado na figura 26. Apesar de ser improvável que os alarmes sejam
44
configurados de forma a que tal ocorra, é necessário definir o que acontece neste tipo de situações
limite, para evitar erros de operação e comportamentos inesperados do dispensador.
Figura 26 – Exemplo de conflito entre o tempo de tolerância de um alarme e o disparo do seguinte.
Relativamente à funcionalidade de dose antecipada, o intervalo com que se pode adiantar a
dispensa dos comprimidos é também especificado em horas e minutos. Neste caso, no momento em
que o alarme em questão é carregado para a memória RAM, é calculada a estampilha temporal a
partir da qual a dose antecipada pode ser pedida, a partir deste intervalo e da data e hora de disparo
do alarme. À passagem de cada minuto, este valor é comparado com a data e hora do dispensador,
para determinar o momento em que coincidem. A dose antecipada é devidamente assinalada no LCD
do dispensador e pode ser executada carregando no botão de dispensa. Mesmo para alarmes com
vários compartimentos é possível definir a possibilidade de dose antecipada, sendo que o utilizador
deve carregar uma vez no botão de dispensa por cada compartimento.
Existe também um possível conflito no caso do tempo de tolerância do alarme i se sobrepor
ao momento de disponibilização da dose antecipada do alarme i+1. Nesse caso, a dose antecipada
do alarme i+1 só pode ser disponibilizada após esgotar-se o tempo de tolerância do alarme i. Claro
que, se a dispensa do alarme i for efectuada antes do tempo de dose antecipada do alarme i+1, não
existe conflito, independentemente do tempo de tolerância definido. A situação descrita encontra-se
ilustrada na figura 27.
Figura 27 – Exemplo de uma situaçao de conflito nos alarmes, causada pela dose antecipada. No
primeiro caso existe conflito, enquanto que no segundo não.
Por fim, importa referir que, mesmo após entrada no modo de operação, é possível editar,
remover e adicionar alarmes. No entanto, não é possível remover alarmes já disparados para
45
adicionar novos alarmes, uma vez que estas funcionalidades foram criadas apenas para efectuar
alterações pontuais e não para configurar todo o regime de medicação, sendo que esse procedimento
deve ser efectuado no já referido modo de configuração.
A implementação destas funcionalidades requereu um cuidado especial com a coerência das
estruturas de dados. Por exemplo, ao editar um alarme, a mudança da sua estampilha temporal pode
fazer com que tenha de ser reposicionado na lista, de forma a respeitar a ordenação crescente por
data e hora. No entanto, é fundamental garantir que o compartimento de medicação correspondente
se mantenha, mesmo que tal implique que alarmes adjacentes não estejam em posições seguidas, o
que obriga a um algoritmo de dispensa mais complexo.
4.3.2 Modo diário
Para facilitar a configuração de regimes de doses regulares, criou-se o designado modo
diário, que opera de forma semelhante ao método de configuração oferecido pelos produtos
comerciais analisados. Neste modo, o utilizador deve apenas especificar quais as horas do dia a que
as dispensas devem ser efectuadas (e, obviamente, a restante informação de dose antecipada,
tempo de tolerância e mensagem textual), bem como o número de alarmes que pretende configurar
desta forma, que irão ocorrer em dias consecutivos. A partir destes dados, o dispensador gera os
alarmes para os vários dias, os quais ficam com uma data específica de disparo associada.
A figura 28 ilustra um exemplo da configuração de alarmes utilizando o modo diário (para
simplificar, omitem-se as informações relativas à dose antecipada, tempo de tolerância e mensagem
textual). Este exemplo coloca em evidência uma das características do algoritmo, nomeadamente o
facto de que o primeiro alarme a ser configurado é aquele cuja hora definida é superior à hora actual
do dispensador. Se a hora do dispensador for superior à hora de todos os alarmes da lista do modo
diário, então os alarmes efectivos serão programados a partir do dia seguinte.
Figura 28 – Configuração dos alarmes usando o modo diário.
O modo diário foi desenhado para coexistir com a configuração individual de alarmes,
fornecendo mais versatilidade à solução. Todos os alarmes assim gerados podem ser posteriormente
eliminados e editados de forma independente (o que inclui modificar a data), bem como podem ser
adicionados novos alarmes individuais, desde que haja espaço disponível.
46
Uma vez que a activação do modo diário elimina todos os alarmes previamente configurados
em memória, só é possível realizar o procedimento em modo de configuração. Também a adição,
remoção e edição de alarmes de forma manual devem ser realizadas após a activação deste modo.
4.3.3 Medicação PRN
A gestão de medicação PRN foi implementada de forma independente dos alarmes de
dispensa já descritos, havendo apenas a restrição de que o total de compartimentos de medicação e
o mecanismo de dispensa são partilhados.
Uma vez requisitado um medicamento PRN, a possibilidade de pedir outro deste tipo é
bloqueada durante um intervalo de segurança, previamente configurado pelo cuidador. Para evitar ter
de guardar e comparar datas e horas, este valor é convertido em minutos e carregado para um
contador, que é decrementado a cada minuto que passa após a última dispensa. Quando atingido o
valor zero, poderá ser dispensado novo medicamento PRN, caso esteja disponível.
Importa referir que a necessidade de ter um botão dedicado para as dispensas de medicação
PRN está relacionado com o conflito que poderia ocorrer com a dispensa de doses antecipadas.
Assim, caso estivesse disponível uma dose antecipada de uma dada dispensa e, simultaneamente, a
possibilidade de acesso a um medicamento PRN, não haveria maneira de distinguir entre ambos.
4.3.4 Monitorização de tentativas de dispensa não autorizadas
No que diz respeito a tentativas de dispensa fora do horário programado, considerou-se
importante monitorizar quer o acesso aos comprimidos normais quer o acesso aos comprimidos PRN.
Em ambos os casos, a monitorização é feita em intervalos de tempo configuráveis, após um
clique no botão de dispensa fora do horário permitido. A partir desse primeiro clique, futuras
actuações no botão são contabilizadas incrementando um contador e reiniciam o intervalo de
monitorização. Caso decorra um periodo de tempo igual ao intervalo de monitorização sem novas
actuações, o evento é então registado e o contador reinicializado. Alternativamente, é possível
configurar o dispensador para fazer a monitorização em intervalos fixos, ou seja, para não reiniciar o
intervalo de monitorização a cada novo clique, de acordo com o ilustrado na figura 29.
Figura 29 – Funcionamento da monitorização de tentativas de dispensa não autorizadas.
47
Naturalmente, o carregar no referido botão pode ocorrer por acidente, não sendo indicativo de
qualquer estado de confusão por parte do utilizador. Desta forma, é possível definir um limiar mínimo
de número de cliques a partir do qual a informação é registada em memória não volátil.
4.4 Mecanismo de dispensa
Conforme descrito anteriormente, equipou-se o dispensador com um optocouplador que
permite detectar pontos de referência na plataforma rotativa que guarda os medicamentos. Para
aproveitar esta característica, assinalou-se um dos compartimentos com uma extrusão, o que permite
detectar quando o sensor está alinhado com essa marca, que corresponde ao compartimento zero.
Assim, a partir de qualquer posição arbitrária, é possivel alinhar o motor com o compartimento
de origem. Tal é particularmente útil para o caso de a alimentação eléctrica falhar, pois permite
regressar a um ponto conhecido quando a energia voltar a ficar disponível. A decisão de ter apenas
um ponto de referência permite identificar sem ambiguidade o compartimento zero.
Para além de permitir recuperar de falhas, o mecanismo de feedback é utilizado para forçar o
alinhamento do dispensador com o compartimento de origem sempre que se inicia o modo de
operação, o que garante que pelo menos uma vez em cada ciclo de dispensas há uma correcção da
posição, evitando assim a acumulação de eventuais erros ao longo de múltiplos ciclos de operação.
Quando ocorre a dispensa de medicamentos, o compartimento correspondente é alinhado
com a abertura existente no invólucro plástico externo do dispensador, a partir da qual o idoso pode
recolher os medicamentos, de forma semelhante ao MedSmart (ver sub-secção 2.2).
No protótipo desenvolvido, é seguida uma abordagem em que, quando se atinge a hora de
uma dispensa, isso é apenas assinalado com os alarmes visual e sonoro, sem se executar qualquer
mudança de compartimento. Só após o utilizador carregar no botão de dispensa é que a estrutura
circular roda, alinhando o compartimento correspondente com a abertura do dispensador. Desta
forma, se a dispensa falhar, o motor não é movimentado e o dispensador mantém-se num
compartimento vazio. Evita-se assim que os medicamentos possam ser tomados mais tarde,
eventualmente já na proximidade de outra toma.
Para tornar mais versátil o dispensador, o algoritmo criado permite a movimentação de um
qualquer compartimento i para um outro compartimento arbitrário j. Esta flexibilidade é fundamental
para permitir as funcionalidades de re-armar, editar, adicionar e remover alarmes após início do
funcionamento. É também com recurso a essa capacidade que se implementou a dispensa dos
medicamentos PRN em que, havendo permissão para executar a dispensa, a estrutura circular é
movida para o compartimento do próximo medicamento PRN disponível.
Uma vez que o motor de passo pode deslocar-se nas duas direcções de rotação, tira-se
partido desta característica para optimizar a movimentação entre dois compartimentos, seguindo-se
sempre o caminho mais curto. Para garantir a fiabilidade das movimentações, quando o movimento a
efectuar implica a passagem no compartimento zero, é efectuada uma sincronização.
O referido algoritmo foi criado de forma modular. Foi desenvolvida uma função genérica que
permite a movimentação do motor num espaço de 360º dividido num conjunto discreto de arcos
(neste caso, os 29 compartimentos) e com um ponto de origem. Assim, a função que comanda o
48
motor recebe como argumento a posição actual e a posição de destino, independentemente do tipo
de dispensa a realizar. O código é adaptável para um número diferente de compartimentos.
Importa referir que a atribuição de compartimentos aos alarmes e PRN só é realizada na
transição do modo de configuração para o modo de operação. Nessa transição, os compartimentos
são atribuídos em sequência, de acordo com a ordem dos alarmes de dispensa regular (que já se
encontram ordenados de acordo com a data e hora de disparo). A partir do último compartimento, são
alocados os compartimentos para os medicamentos PRN. Desta forma, minimiza-se a distância
percorrida na transição de compartimentos aquando das dispensas regulares
4.5 Avisos textuais
Para além dos já referidos alarmes, é possível definir avisos textuais, nos quais é impressa
uma mensagem na hora definida, sem estar associada nenhuma dispensa. Desta forma, é possível
sinalizar ao utilizador outros eventos, incluindo mensagens não relacionadas com assuntos médicos.
A configuração destes avisos é bastante semelhante aos alarmes, sendo necessário definir
uma data e uma hora de disparo. Existe também um campo com um objectivo semelhante ao da
tolerância nos alarmes, que corresponde ao tempo durante o qual o aviso se manterá activo e o
utilizador pode confirmar a sua visualização, carregando no botão de dispensa.
Por fim, é necessário associar ao aviso a mensagem que lhe corresponde. O espaço de
mensagens para avisos é partilhado com os alarmes de dispensas, permitindo que possam partilhar
mensagens comuns.
Para sinalizar que está disponível um aviso textual é também utilizado o bezouro e o LED,
cujas configurações (intensidade, frequência, tempo on e tempo off) são partilhadas com os alarmes.
É também registada a data e a hora na qual o utilizador confirma a visualização da mensagem, bem
como é registada uma falha no caso de ser ultrapassado o tempo de tolerância definido.
Tendo em conta que os avisos textuais são confirmados pelo utilizador da mesma forma
como numa dispensa (carregando no botão), bem como que utilizam os mesmos recursos para
sinalizar o evento, foi necessário definir um esquema de prioridades entre ambos. Assim, definiu-se
que uma dispensa é mais prioritária que um aviso. Como tal, se um aviso textual disparar quando um
alarme de dispensa ainda está activo, este não será sinalizado até o alarme ser tratado (utilizador
carrega no botão de dispensa ou o tempo de tolerância esgota).
Da mesma forma, se um aviso textual estiver a ser sinalizado e entretanto disparar um alarme
de dispensa, o que será visualizado será o texto associado à dispensa e o pressionar do botão levará
à disponibilização do respectivo compartimento. Uma vez tratado o alarme de dispensa, o aviso
textual pendente voltará a ser mostrado, excepto se o seu tempo de duração se tiver esgotado.
A duração do aviso textual n não se pode sobrepor ao momento de disparo do aviso n+1,
sendo seguida a mesma lógica já descrita para os alarmes. Se ocorrer sobreposição, o aviso n é
considerado falhado e procede-se à sinalização do aviso n+1.
No caso dos avisos textuais não existe nenhum modo de configuração específico. Como tal,
podem ser adicionados, removidos e editados a qualquer momento, independentemente de já terem
49
ou não disparado (relembre-se que, no caso dos alarmes associados a dispensas, a eliminação de
alarmes já disparados obriga à entrada no modo de configuração).
4.6 Comunicação com o dispensador
Conforme descrito anteriormente, um dos grandes factores de inovação do protótipo criado
está relacionado com as suas capacidades de comunicação sem fios, permitindo interagir quer com
dispositivos próximos (usando Bluetooth) quer remotos (usando a Internet ou a rede GSM). Destas
capacidades, destaca-se a possibilidade de comunicação com Tablets e Smartphones, que
possibilitam o desenvolvimento de interfaces mais simples e intuitivas, permitindo automatizar muitos
dos processos de configuração e recolha de informação.
Uma vez que a interacção com os módulos de comunicação é feita pelas UARTs do
microcontrolador, criou-se um protocolo com um formato dos dados simples e compacto, permitindo a
troca de informação de forma eficiente. Este protocolo é usado para comunicar com os módulos
Bluetooth e Wi-Fi, visto que o módulo de GSM é apenas utilizado para envio de mensagens SMS com
notificações para o cuidador, que usam um formato de texto legível. Usando este protocolo é possível
enviar comandos para configurar o dispensador e aceder aos eventos registados.
Por fim, importa referir que o módulo Arduino usado possui integrado um conversor de
interface série para USB, o qual pode ser utilizado para estabelecer comunicação série com um
computador. Este modo encontra-se funcional e foi utilizado durante a fase de testes ao referido
protocolo. No entanto, no protótipo final, a porta USB do módulo Arduino foi utilizada para realizar a
sua alimentação, que usa uma tensão de 5V [73]. A outra alternativa de alimentação do módulo usa
uma ficha própria que obriga ao fornecimento de uma tensão entre 7 e 12 V [73] o que colocaria
problemas quando o circuito operasse alimentado pela bateria (tem uma tensão de apenas 6 V). Por
este motivo, no protótipo final, a ligação por USB não está disponível.
4.6.1 Comunicação Bluetooth
O Bluetooth é utilizado para estabelecer comunicação sem fios com dispositivos existentes na
proximidade do dispensador. Como tal, faz sentido o seu uso apenas para envio de comandos, não
se tendo implementado qualquer esquema de envio notificações. Naturalmente, uma vez na
proximidade do dispensador, é fácil obter informações relativas aos eventos registados, procedimento
que pode ser automatizado pela aplicação que executa no dispositivo.
O módulo Bluetooth usado emula uma comunicação série, pelo que o microcontrolador limita-
se a enviar e a receber os dados em série de forma transparente, como se estivesse a comunicar
directamente com o dispositivo destino.
4.6.2 Comunicação Wi-Fi
Outra das tecnologias de comunicação suportadas é o Wi-Fi, através do módulo ESP-01, que
permite a conexão do dispensador à Internet. No contexto do protótipo, o ESP-01 é utilizado como
ponte de ligação entre o agente remoto e o módulo Arduino. Antes de poder iniciar qualquer
50
comunicação, o módulo de Wi-Fi tem de se registar numa rede local, momento a partir do qual obtém
um endereço IP e passa a poder estabelecer conexões através de sockets. Estabelecida uma
ligação, o módulo Arduino limita-se a enviar e receber dados pela porta série, de forma transparente,
como se estivesse a comunicar directamente com o dispositivo destino.
Apesar do módulo ser vendido com um firmware que permite interagir com o dispositivo
através do envio de comandos AT para a sua porta série, os testes realizados mostraram que era
pouco fiável, o que levou ao desenvolvimento de uma aplicação personalizada.
Para simplificar a criação de aplicações para o ESP8266, existe um projecto para suportar o
dispositivo no IDE do Arduino [85], permitindo o desenvolvimento de aplicações num ambiente
bastante simples, o qual se utilizou para facilitar o processo.
A aplicação criada no contexto do protótipo permite então que um cliente remoto se conecte
ao ESP8266 e envie comandos para o dispensador. Da mesma forma, permite ao dispensador enviar
notificações de eventos (como por exemplo, tomas falhadas) para um servidor remoto. Assim, o
ESP8266 opera simultaneamente como servidor e cliente.
Uma vez que não existe suporte a multi-threading, quer para o Arduino quer para o módulo de
Wi-Fi, os pedidos são tratados de forma sequencial, o que é aceitável dado que a comunicação é,
conforme descrito adiante, baseada num esquema de “reply-request”, e a quantidade de dados
trocados é relativamente reduzida. Desta forma, é suposto que o cliente que esteja a tentar
comunicar com o dispensador apenas envie um novo comando quando receber a resposta ao
anterior ou, naturalmente, após um tempo de timeout. Para além disso, não é de esperar que existam
múltiplos cuidadores a tentar comunicar simultaneamente com o dispensador e, caso aconteça, basta
às aplicações remotas implementarem um esquema de retransmissão em caso de falha.
Optou-se por implementar a comunicação directamente através de sockets e com um
protocolo compacto para minimizar os tempos de latência. No entanto, a aplicação é facilmente
escalável para comunicar através de HTTP.
Importa referir que, em consequência do ESP8266 ter sido recentemente introduzido no
mercado, a quantidade de informação e ferramentas de desenvolvimento é ainda bastante escassa.
Apesar do uso do referido IDE simplificar bastante o desenvolvimento de aplicações, encontra-se
ainda em fase de maturação e apresenta várias limitações.
4.6.3 Comunicação GSM
O suporte à comunicação por GSM usa um módulo baseado no SIM900. O dispositivo é
comercializado com um firmware que permite o seu controlo através de comandos AT [25], que
podem ser enviados através da sua porta série. Estes permitem, entre outras funcionalidades, o envio
de mensagens SMS e a realização de chamadas [27]. Os testes realizados inicialmente permitiram
demonstrar que o funcionamento deste firmware é bastante fiável.
A principal funcionalidade do módulo é permitir o envio de avisos ao cuidador acerca de
vários eventos. Para não obrigar ao uso de um Smartphone com uma aplicação dedicada à recepção
dos dados, os avisos são enviados como mensagem textual, num formato legível para uma pessoa.
51
A comunicação com o módulo é feita através de uma das UARTs do microcontrolador, com a
particularidade de que os dados necessitam respeitar a estrutura dos comandos AT suportada pelo
módulo. A figura 30 esquematiza o processo de envio de uma notificação.
Figura 30 – Processo de envio de uma notificação por GSM.
Apesar de o SIM900 suportar a recepção de SMS, considerou-se que esse meio não seria
cómodo para configurar o dispensador. Para além disso, uma vez que a formatação da mensagem
seria feita pelo cuidador, haveria grande probabilidade deste cometer erros na sua estruturação. Não
obstante, testou-se com sucesso a recepção de SMS no microcontrolador.
4.6.4 Envio de comandos
Conforme referido, é possível proceder ao envio de comandos para o dispensador através de
Bluetooth ou Wi-Fi. Dado que estes módulos dialogam com o microcontrolador através de
comunicação série, foi necessário definir um esquema de comunicação adequado com os mesmos.
Para ler e escrever dados das UARTs, optou-se pelo uso da classe Serial, definida na
linguagem de programação usada na plataforma Arduino para simplificar a comunicação. Esta classe
esconde os detalhes de implementação de baixo nível inerentes ao microcotrolador de cada placa,
disponibilizando uma interface uniforme e portável entre diferentes dispositivos da família Arduino.
Internamente, esta classe utiliza as interrupções geradas no microcontrolador quando um
byte é recebido, havendo uma interrupção distinta para cada UART [74]. Desta forma, evita-se um
esquema de polling, tornando a comunicação mais eficiente. Os bytes recebidos são guardados num
buffer circular (distinto para cada UART), com tamanho configurável.
No que diz respeito ao envio de dados, este é igualmente baseado nas interrupções
suportadas pelo microcontrolador [74], evitando assim bloquear a execução durante o tempo de
envio. Tal como no caso da recepção, existe um buffer de envio de dados que guarda os bytes
pendentes. Em ambos os casos, os referidos buffers são mantidos em memória RAM, o que se
traduz num consumo significativo deste recurso.
52
Esta implementação trata de forma indistinta os dados recebidos, que são imediatamente
colocados nos buffers internos, para tornar as interrupções o mais curtas possível. Mas, para a
aplicação desenvolvida, foi necessário estruturar os dados e atribuir-lhe um significado, tendo sido
definido um protocolo de comunicação que é simples e, ao mesmo tempo, oferece um grau adequado
de robustez e fiabilidade. O processamento da informação recebida encontra-se ilustrado na figura
31, sendo executado no ciclo principal, quando o microcontrolador se encontrar disponível. Apesar de
mais dispendioso do ponto de vista computacional, este método a dois passos permite reduzir a
probabilidade de erros e de perda de dados.
Figura 31 – Procedimento de cópia e estruturação dos dados recebidos.
Assim, definiu-se que a comunicação com o dispensador é feita através de comandos, de
acordo com a estrutura ilustrada na figura 32. Conforme indicado, todos os comandos devem ser
delimitados pelos bytes 255 e 254 no início e fim, respectivamente. Como tal, os dados recebidos só
são copiados dos buffers de baixo nível para os buffers da aplicação (que guardam os bytes dos
comandos recebidos) após a recepção do byte 255, bem como só são interpretados após a recepção
do byte 254. Todos os bytes recebidos fora destes delimitadores são ignorados.
Figura 32 – Estrutura das mensagens de comunicação com o dispensador.
Para distinguir os comandos, o segundo byte indica qual a operação que o dispensador deve
executar (código de operação). Os bytes seguintes, cujo número depende do comando, contêm os
dados necessários à sua execução. Existem comandos cuja dimensão dos dados é fixa, enquanto
que outros têm conteúdo de tamanho variável. Neste último caso, o byte imediatamente a seguir ao
código de operação deve indicar o número de bytes de dados que irão ser recebidos, permitindo
assim verificar se foi ou não perdida informação.
Para aumentar a robustez do protocolo e evitar o uso de dados corrompidos por erros de
transmissão, inclui-se um byte de checksum, para confirmação de integridade da mensagem.
Para permitir o envio dos bytes 254 e 255 como dados (e não como delimitadores), é
necessário incluir um mecanismo de escape. Assim, sempre que é enviado o byte 253, o byte
53
imediatamente a seguir é interpretado como pertencente aos dados, incluindo o próprio valor de
escape. Os bytes de escape são também contabilizados para o checksum.
O funcionamento do algoritmo que gere a comunicação encontra-se esquematizado no anexo
A.1. Como se pode verificar, não é necessário qualquer mecanismo de timeout, uma vez que, caso a
recepção de uma mensagem não seja terminada, o envio de um novo comando reinicia o
procedimento. Mesmo os comandos com dados de dimensão variável têm um limite máximo de
tamanho definido, o qual é utilizado para garantir que não existe um overflow dos buffers.
Para que a entidade que comunica com o dispensador possa obter uma confirmação da
correcta execução dos comandos enviados para o dispensador, este deve enviar uma resposta
adequada. Para tal, são usadas mensagens com uma estrutura semelhante à descrita anteriormente,
conforme indicado na figura 33. Com este mecanismo, é possível à aplicação externa que interage
com o dispensador implementar, por exemplo, um esquema de retransmissão em caso de falha.
Figura 33 – Estrutura das mensagens de resposta aos comandos.
Os vários comandos existentes foram criados com vista a permitir configurar totalmente o
funcionamento do dispensador a partir de uma aplicação externa, bem como para facilitar o teste do
sistema. Notar que todas as acções que podem ser realizadas directamente no dispensador, usando
o teclado e LCD, podem também ser executadas remotamente usando o protocolo descrito. No anexo
A.2. encontra-se uma lista detalhada de todos os comandos disponíveis.
Importa salientar que o protocolo utilizado para a comunicação série é genérico e pode ser
utilizado em contextos diferentes deste projecto. Foi implementado de forma modular, sendo que o
algoritmo de recepção da mensagem, processamento de caracteres de escape e verificação do
checksum opera de forma independente da estrutura lógica atribuída aos dados. Também o envio da
resposta é implementado por um algoritmo genérico que apenas trata da colocação dos bytes
delimitadores da mensagem, escape de caracteres e checksum, sendo a estruturação lógica do
conteúdo da resposta da responsabilidade das funções de tratamento dos comandos.
Da mesma forma, já no caso específico da aplicação em análise, a adição de novos
comandos ao protocolo é bastante simples e modular, conforme descrito na figura 34. De acordo com
o ilustrado, basta criar uma função de tratamento distinta para cada novo comando, sendo os dados
agulhados para a função correspondente de acordo com o código de operação da mensagem.
54
Figura 34 – Esquema de tratamento dos comandos recebidos.
4.6.5 Notificações remotas
Conforme referido, tirou-se partido das capacidades de comunicação remota com o
dispensador para implementar um sistema de notificações, que possibilita ao cuidador ser avisado da
ocorrência de certos eventos relevantes da sua operação, com particular ênfase para o
acompanhamento do estado das tomas.
As notificações correspondem a mensagens enviadas pelo dispensador aquando da
ocorrência de um evento, as quais incluem informação acerca do mesmo. Estas operam de forma
completamente independente do protocolo de comunicação de envio de comandos acima descrito.
Cabe ao cuidador configurar que tipo de notificações se encontram activas (Wi-Fi e/ou GSM).
O formato das notificações Wi-Fi segue uma estrutura de dados orienada ao byte, semelhante
à utilizada nos comandos, estando descrita na figura 35. Neste caso, compete à aplicação de destino
o processamento do conteúdo da mensagem e posterior apresentação ao utilizador de forma
adequada. Essa aplicação deverá responder à notificação, confirmando assim a sua recepção.
Figura 35 – Formato de uma notificação textual, cuja dimensão depende do tipo de notificação.
No caso do GSM, as notificações são enviadas ao cuidador no formato de SMS, razão pela
qual são estruturadas em texto (caracteres ASCII) antes do envio. Não é esperada nenhuma resposta
às notificações enviadas, uma vez que tal obrigaria ao cuidador a enviar uma SMS de retorno. No
entanto, o módulo de GSM retorna um código de confirmação de sucesso no envio da SMS [86], o
qual se utiliza para identificar eventuais falhas na comunicação.
Em ambos os casos, a obtenção da resposta ou confirmação demora um tempo não
desprezável, razão pela qual se criou um esquema não bloqueante de envio de mensagens. Assim,
uma vez transferidos os dados para o módulo que trata do seu envio, a função retorna
imediatamente, assinalando numa variável global que existe uma confirmação pendente. Uma vez
recebida a confirmação do envio, o dispensador fica disponível para tratar uma nova notificação.
Caso o tempo pré-definido para a recepção da confirmação esgote, a mensagem é re-enviada.
Durante o período de espera pela confirmação da notificação, o programa continua a sua execução.
55
Na abordagem descrita, poderia surgir uma nova notificação com a anterior ainda pendente.
Assim, para cada uma das tecnologias, criou-se um buffer onde é colocada a informação de cada
nova notificação. Desta forma, caso haja uma notificação pendente, as informações de novos eventos
são guardadas até haver disponibilidade para envio, evitando a perda dos dados.
O procedimento de salvaguarda das informações dos eventos é implementado com recurso a
um buffer circular, com dimensão configurável (na aplicação desenvolvida, tem uma dimensão de dez
notificações para cada tecnologia). A decisão de utilizar um buffer circular foi tomada considerando
que é preferível perder os dados de eventos mais antigos do que mais recentes.
Importa referir que o envio de notificações é uma funcionalidade opcional, que pode ser
desactivada. No anexo A.3 encontra-se uma listagem das notificações existentes.
4.6.6 API
Para facilitar o desenvolvimento de aplicações que interajam com o dispensador, criaram-se
três APIs distintas. Destas, duas foram criadas em Java, nomeadamente para comunicação Bluetooth
para Android e comunicação série e Bluetooth para PC. Criou-se também uma API em Python para
comunicação através da Internet usando o módulo Wi-Fi.
Com base na API para Android, criou-se uma aplicação de demonstração do envio de alguns
comandos, a partir de um Smartphone. Na figura 36 encontram-se algumas imagens ilustrativas.
Figura 36 – Exemplo de alguns menus da aplicação desenvolvida para Android.
Estas APIs utilizam o paradigma da programação orientada por objectos para oferecer ao
programador de aplicações uma classe com métodos que permitem dialogar com o dispensador,
abstraindo os detalhes da estrutura das mensagens (bytes delimitadores, verificação de checksums,
colocação da dimensão dos argumentos) e das tecnologias de comunicação utilizadas. Assim, são
fornecidos métodos simples de alto nível, como “lê data” ou “adiciona alarme”.
Nesta fase, tendo em conta que apenas se pretende demonstrar o conceito e testar as
funcionalidades associadas à comunicação, os métodos fornecidos correspondem às acções simples
que os comandos do protocolo de comunicação contemplam. Na generalidade dos casos, estes
56
métodos recebem vectores de bytes dos dados de configuração e retornam vectores de bytes com os
dados das respostas. No entanto, é simples estender estas classes e criar camadas de maior
abstração no topo das funcionalidades oferecidas.
4.6.7 Realização de chamadas
Para além das funcionalidades referidas, dotou-se o dispensador da capacidade de realizar e
receber chamadas de voz, disponibilizando ao cuidador uma forma de entrar em contacto directo com
a pessoa cuidada, o que pode ser particularmente importante caso se verifique uma falha numa toma.
Assim, é possível realizar uma chamada directamente para o número do cartão SIM
associado ao dispensador, que pode ser configurado para realizar um atendimento automático ou
carregando num botão. Apesar de o modo de atendimento automático poder levantar problemas de
privacidade, podem existir situações nas quais estado físico e mental da pessoa cuidada o justifique.
Para iniciar uma chamada, basta ao utilizador carregar no mesmo botão, desde que não
esteja nesse momento a ser contactado. De forma a manter a simplicidade, apenas é possível definir
um número de destino para a chamada, uma vez que múltiplos números implicariam a necessidade
de o utilizador ter de interagir com o teclado ou outro mecanismo para realizar a mudança de número.
Para terminar uma chamada, basta ao utilizador carregar no referido botão. Caso seja o
cuidador a terminá-la, esta é automaticamente encerrada no dispensador.
Apesar do principal objectivo do equipamento ser a dispensa de medicação, considerou-se
que a possibilidade de realizar e receber chamadas é um factor distintivo dos restantes produtos.
4.7 Interacção directa com o dispensador
Conforme referido, é possível interagir directamente com o dispensador a partir do seu
teclado e display LCD, possibilitando a execução da sua configuração e consulta das ocorrências
registadas.
Apesar de este método não ser algo inovador face a outras soluções, a sua implementação
requereu bastante tempo de desenvolvimento, dados os inúmeros pormenores envolvidos. Tal deve-
se a apenas existirem funções de baixo nível para interagir com o teclado e com o LCD. Para o
teclado, apenas é possível obter a tecla pressionada num dado momento. Para o LCD, existem as
funcionalidades de eliminar o conteúdo existente no ecrã, escrever conteúdo textual, posicionar o
cursor e activar ou desactivar a presença do cursor, que é constituído por uma barra a piscar.
Como tal, todos os elementos da interface criada e a sincronização entre os eventos do teclado e
correspondente efeito no display foram implementados de raiz a partir destas funções elementares.
4.7.1 Organização dos menus
A interface de interacção directa com o dispensador encontra-se organizada em diversos
menus, para facilitar a navegação e acesso aos dados. De forma genérica, estes encontram-se
divididos em três níveis de profundidade, conforme indicado na figura 37. O menu principal permite ao
cuidador navegar até ao menu das funcionalidades a que deseja aceder. Dependendo da
57
complexidade das funcionalidades oferecidas, cada menu pode encontrar-se ou não dividido em sub-
menus.
Figura 37 – Organização estrutural dos menus do dispensador.
Os menus podem conter informação para o cuidador e campos de entrada de dados, para
efectuar as várias configurações necessárias. Importa referir que se considerou conveniente limitar
algumas das configurações que são possíveis usando esta interface. Tal deve-se ao facto de
algumas serem demasiado específicas, sendo mais adequadas para o programador de aplicações
que interagem com o dispensador. Naturalmente, as configurações não contempladas nesta interface
podem ser acedidas através do protocolo de comunicação.
Para complementar os menus, existem ainda as designadas janelas de avisos, que permitem
informar o cuidador de erros, avisos e pedidos de confirmação da execução de procedimentos. Estas
são utilizadas para, por exemplo, pedir ao utilizador que confirme se pretende remover um alarme,
informá-lo que a configuração de alarmes a partir do modo diário foi bem sucedida.
Para facilitar a navegação no menu principal e nos menus que apresentam sub-menus, é
possível introduzir o número correspondente à entrada de destino a que se pretende aceder. Por
exemplo, estando no menu principal e pretendendo-se aceder ao menu 4, basta clicar na tecla “4” do
teclado para navegar automaticamente para essa entrada. Naturalmente, isto é igualmente possível
para percorrer as várias entradas de informação nos menus de acesso a dados registados.
4.7.2 Implementação dos menus
Dada a quantidade considerável de menus existentes no dispensador e a necessidade
constante de realizar pequenas alterações durante o processo de desenvolvimento, procurou-se uma
abordagem escalável e relativamente genérica para a implementação desta interface.
Um dos problemas encontrados prende-se com os campos de entrada de dados e a
movimentação do cursor ao longo dos mesmos. Conforme indicado na figura 38, os vários campos
não são adjacentes. Como tal, o movimento do cursor ao longo dos mesmos não é contínuo, sendo
necessário saber qual a posição, de entre as oitenta possíveis do LCD, que deve ser usada.
Para resolver este problema, utilizou-se uma estrutura de dados global que, para cada menu,
contém a informação correspondente às linhas e colunas nas quais o cursor pode ser movimentado.
Para cada uma das linhas desta estrutura, o conteúdo presente em cada posição indica quais as
posições navegáveis para o cursor na linha correspondente do LCD. Como se usa uma estrutura
única, a dimensão máxima de cada linha deve ser tal que permita guardar a informação relativa ao
58
menu com maior número de posições navegáveis. A figura 38 exemplifica o conteúdo correspondente
à referida estrutura para um menu com vários campos de entrada.
Dada a quantidade de menus existentes, não era comportável guardar em memória RAM
uma estrutura destas para cada menu, razão pela qual é executado um procedimento de
configuração da única estrutura existente antes de se transitar para um dado menu.
Figura 38 – Exemplo da representação interna das posições navegáveis de um menu.
Baseado na estrutura descrita, quando é pressionada a tecla de movimentação do cursor
para a direita, este é movido para a próxima posição. Caso se chegue ao fim das posições existentes
nessa linha, o cursor é movimentado para a primeira posição da próxima linha com um número de
posições de entradas não nulas. O procedimento de procura é circular, isto é, se no exemplo anterior
o cursor se encontrar na linha 4 e posição 9 e se pressionar a tecla de movimentação para a direita, o
cursor irá ser colocado na posição 2 da linha 2. Quando se pressiona a tecla de movimentação do
cursor para a esquerda, ocorre um procedimento similar mas em sentido oposto.
Para as teclas que movimentam o cursor para cima e para baixo, este é colocado na primeira
posição da próxima linha acima ou abaixo, respectivamente, com um número de posições não nulas.
Uma vez que os dados introduzidos nos campos de entrada só são utilizados quando o
cuidador carrega no botão de aceitação, estes têm de ser guardados após serem introduzidos. Mais
uma vez, optou-se por uma estrutura de dados semelhante à descrita anteriormente, tal como
ilustrado na figura 39. Esta abordagem é genérica e não impõe nenhuma estrutura ou significado aos
dados, que são apenas tratados como dígitos independentes. Ao executar o procedimento
correspondente, a função deve aceder à referida estrutura e interpretar os dados de acordo com o
necessário.
Figura 39 – Exemplo da estrutura que guarda os dígitos introduzidos nos campos de entrada.
Outro problema resultante da leitura dos campos de entrada prende-se com a gama de
valores que estes podem aceitar. Por exemplo, um campo no qual deverão ser introduzidas horas
não poderá ter valores superiores a 24. Assim, quando o utilizador introduz um valor numérico, existe
59
uma verificação que só permite a aceitação caso esse valor esteja de acordo com o formato
adequado. Caso contrário, o cursor mantém-se na mesma posição e o valor não é introduzido.
4.8 Registo persistente de informação
Todos os dados necessários à operação do dispensador e os registos de eventos pertinentes
são guardados na memória EEPROM (não volátil) do microcontrolador.
No que diz respeito aos alarmes, cada um ocupa um total de 17 bytes em memória, tal como
ilustrado na figura 40. Como se permite ao cuidador definir não só a hora de disparo (hora e minutos)
como também a data (ano, mês e dia), são necessários 5 bytes para guardar esta informação.
Para definir a tolerância durante a qual o utilizador pode recolher os medicamentos após
disparo do alarme, são utilizados 2 bytes (hora e minutos). Da mesma forma, são reservados 2 bytes
para a definição do tempo de dose antecipada. Para associar a cada alarme uma mensagem textual
utiliza-se um byte (que funciona como um índice na lista de mensagens) e, para registo da data e
hora a que ocorreu a toma efectiva, são usados 5 bytes.
Uma vez que se permite a edição de alarmes após o inicio do funcionamento do dispensador,
é necessário manter a informação relativa ao compartimento associado a cada alarme, uma vez que
uma alteração da sua ordem de disparo pode levar a uma alteração da sua ordem na lista de
alarmes. Como tal, é reservado um byte por cada alarme para manter esta informação.
Por fim, para garantir que a informação relativa aos alarmes não foi corrompida, o último byte
da estrutura associada a cada alarme guarda o checksum do alarme.
Figura 40 – Estrutura dos alarmes.
Importa referir que o limite de 28 alarmes de dispensa não está relacionado com limitações na
memória mas sim na estrutura física que guarda os comprimidos, podendo este valor ser facilmente
aumentado caso o dispositivo mecânico de dispensa o permita.
Para os avisos textuais são necessários apenas 14 bytes, conforme indicado na figura 41. A
estrutura de dados é bastante semelhante à utilizada para os alarmes de dispensas, uma vez que o
mecanismo de disparo e registo de informação é igual, com a particularidade de, neste caso, não
estar associado nenhum compartimento de medicação nem dose antecipada
60
Contrariamente aos alarmes, não existe qualquer limitação mecânica que defina o número
máximo de avisos textuais possíveis, tendo-se imposto um número máximo de 30 apenas para evitar
uma ocupação excessiva da memória. No entanto, este valor pode ser facilmente alterado.
Figura 41 – Estrutura dos avisos textuais.
Anteriormente, foi referido que é possível configurar os alarmes usando o modo diário. Neste
caso, não é necessário especificar a data, sendo apenas indicada a hora e os minutos do disparo. No
entanto, para manter o mesmo esquema de disparo e registo de informação, os dados referentes ao
modo diário são usados para configurar as estruturas de dados dos alarmes descritas anteriormente,
pelo que necessitam conter toda a demais informação. Assim, cada elemento do modo diário ocupa 8
bytes. Manter estes dados permite não obrigar o cuidador a reintroduzi-los neste modo cada vez que
necessitar de reconfigurar o dispositivo, uma vez que é expectável que os horários das tomas se
mantenham constantes durante longos períodos.
Para a medicação PRN, basta a estrutura indicada na figura 42. Como estes medicamentos
são pedidos conforme a necessidade, apenas é necessário saber qual o compartimento
correspondente e registar o momento de dispensa.
Figura 42 – Estrutura das entradas associadas aos medicamentos PRN.
Para as mensagens textuais definiu-se um máximo de 60 caracteres. A estrutura de dados
usada possui um byte que indica a dimensão do texto e um byte adicional para guardar um
checksum, conforme ilustrado na figura 43.
Figura 43 – Estrutura de uma mensagem textual.
Para os registos dos cliques no botão de dispensa e PRN fora do horário permitido, são
apenas necessários 6 bytes, conforme indicado na figura 44. É apenas usado um byte para guardar a
61
informação relativa ao número de vezes que o botão foi premido, o que implica que a contagem pode
atingir, no máximo, 255. Este valor não é limitativo na medida em que o interesse desta
funcionalidade visa identificar possíveis dificuldades ou estados de confusão. Assim, 255 já
representa um valor elevadíssimo, que claramente evidencia algum problema com o utilizador.
Figura 44 – Estrutura de um evento de tentativa de acesso a medicação fora do horário permitido.
O registo de erros de operação do dispensador segue uma estrutura semelhante ao registo
de cliques nos botões de dispensa e PRN fora do horário estipulado, com a particularidade de o byte
que regista o número de cliques ser substituido por um byte que guarda o código de erro.
O restanto espaço disponível é utilizado para guardar variáveis de configuração, como o
volume do bezouro, a intensidade do LED ou o número de alarmes configurados.
No anexo A.4. encontra-se um resumo das dimensões totais ocupadas pelos diferentes
conjuntos de dados em memória. De notar que a memória interna estará acessível, quer para leitura
quer para escrita, usando o protocolo de comunicação. No entanto, não existe qualquer mecanismo
de protecção, pelo que a sua alteração pode causar o funcionamento incorrecto do dispensador.
Assim, esta funcionalidade deve ser usada apenas para teste (por exemplo, para forçar erros no
checksum de um bloco de dados e visualizar o comportamento do dispensador).
Para dar uma maior versatilidade, fornece-se um espaço de memória adicional, para ser
utilizado por aplicações externas. Como tal, os 4 KB da memória EEPROM presentes no módulo do
RTC encontram-se disponíveis para o programador de aplicações utilizar como achar conveniente.
Este espaço pode ser acedido para leitura e escrita a partir do protocolo de comunicação.
Uma vez que os dados de configuração se encontram guardados em memória, é possível
recuperar o estado de operação após uma falha na alimentação eléctrica. Para garantir esta
possibilidade, quando uma configuração é alterada, os dados referentes são guardados na EEPROM.
Assim, quando o programa do microcontrolador começa a sua execução, existe uma primeira fase na
qual estas variáveis de configuração são carregadas, antes de se iniciar o ciclo principal.
No caso dos alarmes e avisos textuais, uma vez que dependem do valor da data e hora, é
necessário verificar em que ponto o dispensador se encontrava antes da falha energética e verificar
quantos alarmes ainda se encontram válidos, com a nova hora (carregada a partir do RTC, que
dispõe de uma bateria de reserva e lhe permite manter a informação actualizada). Todos os alarmes
e avisos que se encontravam por disparar e que são agora anteriores à nova hora são invalidados.
Como resultado da salvaguarda de dados na EEPROM, existe a possibilidade de ocorrer o
corrompimento dos dados, o que poderá afectar o correcto funcionamento do dispensador. Como tal,
utiliza-se um mecanismo de checksum associado a cada entrada de dados, com um código de
verificação com dimensão de um byte. O checksum é calculado quando se gravam os dados e
actualizado sempre que estes são alterados.
62
No registo de informação referente a tentativas de dispensa não autorizadas e erros de
operação, a corrupção dos dados não causa problemas de funcionamento ao dispensador, pelo que
apenas se apresenta uma mensagem de que estão corrompidos caso se lhes tente aceder.
As situações mais críticas correspondem a erros nos dados dos alarmes de dispensa e dos
medicamentos PRN, que podem comprometer o momento de disparo e a informação do
compartimento de medicamentos correspondente.
No caso dos alarmes, caso se detecte um erro, essa dispensa é ignorada e passa-se para a
dispensa seguinte. Caso o erro corresponda a um de vários compartimentos de uma dispensa, então
esse compartimento é ignorado. Naturalmente, isto requer que o algoritmo que identifica várias
dispensas seja mais robusto e complexo, visto que existem agora mais situações a considerar. Cita-
se como exemplo uma situação na qual existem três compartimentos para o mesmo alarme e o
segundo se encontra corrompido. Neste caso, a condição de paragem do algoritmo deixa de ser
apenas que o alarme seguinte seja diferente do actual, mas também que este não esteja corrompido.
Para os medicamentos PRN, em caso de erro, os dados são ignorados e passa-se a outro
compartimento que esteja disponível. Isso é possível pois assume-se que apenas existe um tipo de
medicamento PRN, sendo indiferente qual o compartimento dispensado.
Para os avisos textuais, em caso de corrupção, os dados são ignorados e carrega-se o aviso
seguinte. Apesar de não haver uma dispensa associada, a mensagem correspondente ao aviso
textual corrompido pode igualmente ser importante para a saúde do utilizador.
Para estes três últimos casos descritos, é gerada uma notificação remota para o cuidador
quando o erro é detectado, para que este possa corrigir a situação. Para que o alerta seja enviado
atempadamente, os erros são verificados no processo de carregamento do alarme/aviso textual para
memória RAM e não no momento de disparo (ver descrição na secção 4.3.1). Como os
medicamentos PRN são dispensados a pedido do utilizador e não de acordo com um horário
programado, a identificação do erro é feita no momento da dispensa, pelo que, na dispensa do
penúltimo PRN disponível, é feita uma verificação antecipada do checksum do último compartimento,
para evitar deixar o utilizador sem comprimidos em caso de erro.
No caso da corrupção dos dados ocorrer na mensagem textual associada ao evento, é
igualmente gerada uma notificação para o cuidador.
Refere-se ainda que, após configurar o dispensador e ao passá-lo para o modo de operação,
é verificada a informação de todos os alarmes de dispensa e medicamentos PRN, sendo que se for
detectado algum erro é impressa uma mensagem no display e o procedimento é abortado, sendo
apenas possível continuar após rectificada a situação.
4.9 Segurança
A segurança da informação e a protecção contra o acesso indevido de pessoas não
autorizadas são questões importantes a ter em consideração. No entanto, a análise e implementação
de mecanismos de segurança sofisticados transcende o contexto do projecto, pelo que se optou por
dotar o dispensador de apenas alguns mecanismos simples, para demonstrar que estes aspectos
foram considerados e abrir caminho a soluções futuras, mais robustas.
63
A possibilidade interagir directamente com o dispensador a partir do seu teclado e display
levanta algumas preocupações de segurança. Assim, nada impede que um indivíduo não autorizado
tenha acesso ao dispensador e altere as configurações ou aceda à informação registada. Existe
ainda a possibilidade de o próprio utilizador poder causar modificações acidentais nas configurações.
Apesa de existirem soluções simples, como colocar o teclado no interior do dispensador e
torná-lo acessível apenas com uma chave, optou-se por uma solução baseada em software, que
funciona independentemente da estrutura mecânica final.
Desta forma, disponibiliza-se a possibilidade de definir um PIN para o teclado, para impedir o
acesso indevido. Assim, antes de aceder aos menus de configuração do dispensador, é necessário
introduzir o referido PIN. No entanto, esta é uma funcionalidade opcional e pode ser desactivada.
Para dar alguma versatilidade a esta solução, pode-se configurar a dimensão do PIN para um
valor entre um e dez dígitos, bem como o número de falhas antes do bloqueio. Uma vez bloqueado o
teclado, só se poderão realizar novas tentativas de introdução do código após um intervalo de tempo,
também configurável.
O envio de comandos por Bluetooth também coloca o problema de uso não autorizado.
Assim, definiu-se um comando no protocolo de comunicação que permite o envio de um código de
segurança de dimensão configurável até 32 bytes, o qual deve ser enviado antes de qualquer outro
comando. Uma vez enviado o código correcto, a entidade remota passa então a poder enviar todos
os restantes comandos. Naturalmente, o uso deste mecanismo é opcional.
Neste caso, a possibilidade de tentar vários códigos até acertar (ataque brute force) é mais
crítica, uma vez que o atacante pode agora automatizar o procedimento no dispositivo remoto. Como
tal, existe um limiar de tentativas máximo de introdução do código que, uma vez atingido, bloqueia o
canal de comunicação durante um período de tempo. Ambos os parâmetros são configuráveis.
Apesar de se ter definido um comando no protocolo que permite explicitamente encerrar o
diálogo com o dispensador, existe como medida auxiliar um tempo pré-definido ao fim do qual a
comunicação é encerrada, obrigando a novo envio do código. Assim, caso esse comando não seja
recebido, o dispensador acaba por reverter automaticamente para um estado seguro.
Importa referir que este é um método de autenticação, não se tendo implementado qualquer
tipo de cifra dos dados. Desta forma, nada impede um eventual atacante de capturar e analisar a
informação, dado que esta é transmitida sem fios. No entanto, dado o alcance máximo de 10 metros
para o módulo Bluetooth utilizado, é razoável assumir que o atacante teria de estar próximo do
dispensador, pelo que, em condições normais, seria facilmente detectado pelo cuidador.
Esta solução não é utilizada para a comunicação por Wi-Fi pelo facto de que não existe a
possibilidade de controlar o percurso efectuado pelos dados entre os dois extremos da comunicação,
os quais podem ser facilmente capturados e analisados, uma vez que não são cifrados.
No que diz respeito ao GSM, optou-se por ter um especial cuidado no que diz respeito à
possibilidade de receber chamadas telefónicas. Assim, implementou-se a possibilidade de limitar a
recepção de chamadas a um conjunto máximo de três números, evitando a recepção de telefonemas
de pessoas não autorizadas. Naturalmente, esta é uma configuração opcional.
64
4.10 Gestão de energia
Conforme descrito anteriormente, a alimentação dos módulos de comunicação e do LCD
pode ser ligada e desligada sob controlo do microcontrolador. Para o LCD, é ainda possível desligar a
sua retroiluminação, mantendo o seu funcionamento. Neste caso, a comutação é realizada através do
envio de um comando para o controlador do LCD, não sendo necessário nenhum MOSFET.
Importa referir que, no caso de se desligar o LCD, continua a ser possível aceder aos menus
de configuração, por interacção directa com o dispensador.
Todas estas configurações podem ser realizadas directamente nos menus do dispensador ou
através de outro dispositivo, utilizando o protocolo de comunicação.
Dada a possibilidade de ligar e desligar os módulos indicados acima, implementou-se uma
funcionalidade de gestão energética mais sofisticada, que permite desligar de forma automática os
módulos seleccionados quando é detectada a mudança para alimentação pela bateria, possibilitando
aumentar a sua autonomia. Adicionou-se também a possibilidade de configurar o módulo de Wi-Fi
para se ligar apenas quando existem notificações a enviar, desligando-se automaticamente ao fim de
um período de tempo pré-definido sem novas notificações. Estas configurações são opcionais.
Esta funcionalidade tem ainda como característica o facto de guardar a informação de se os
módulos se encontram ligados ou desligados no momento anterior à comutação para a bateria, o qual
é automaticamente recuperado assim que a alimentação principal é restaurada.
Dado que se tratam de configurações avançadas e tendo em conta as limitações da interface
directa com o dispensador, definiram-se 3 modos energéticos que permitem configurar directamente
no dispensador o que acontece quando se comuta para a bateria:
Modo 0: o dispensador continua a funcionar sem qualquer alteração.
Modo 1: a retroiluminação do LCD é desligada, o módulo de Wi-Fi só é ligado quando
existem notificações pendentes e o módulo de bluetooth é desligado.
Modo 2: os módulos de comunicação e o LCD são desligados.
A partir do protocolo de comunicação é possível definir todas estas configurações de forma
independente, havendo por isso uma maior liberdade de combinações possíveis.
Para complementar as funcionalidades descritas, existia ainda a possibilidade de colocar o
microcontrolador em modo de sleep [74], permitindo diminuir o seu consumo. No entanto, existem
vários factores a considerar quando se utiliza estes modos, como o tempo de comutação, o consumo
energético de transição [87] e os eventos que acordam o microcontrolador [74].
Na aplicação desenvolvida, o microcontrolador teria de acordar pelo menos uma vez por
segundo para lidar com as interrupções associadas à manutenção da hora, pelo que não se pode
garantir, sem uma análise mais profunda, que a poupança energética iria compensar os consumos de
transição. Para além disso, seria necessário garantir que o tempo de transição era tal que permitisse
não falhar os eventos assíncronos, com particular ênfase para a comunicação com outros
dispositivos.
Tendo estas questões e o limite no tempo de desenvolvimento, optou-se por concentrar o
esforço nas já referidas funcionalidades de gestão dos periféricos, cujo impacto é mais significativo.
65
5 Análise dos resultados
5.1 Testes
De forma a testar a robustez da solução desenvolvida, realizou-se um conjunto de testes para
confirmar o correcto funcionamento dos vários componentes do sistema. Nesta secção referem-se
apenas os testes mais relevantes efectuados, tendo-se verificado o correcto funcionamento do
dispensador de forma exaustiva ao longo do processo de implementação das suas funcionalidades.
Para testar o funcionamento da dispensa de medicação e dos avisos textuais, simularam-se
vários cenários de utilização, incluindo o teste das situações de sobreposição e conflito de alarmes e
avisos textuais, descritas nas secções anteriores. Para além disso, introduziram-se também erros nos
dados guardados, para verificar se a resposta do dispensador era a adequada. Nestes testes, o
dispensador demonstrou operar de forma robusta, respondendo a todas as situações de conflito e de
erro dos dados de acordo com o planeado.
Destaca-se também a precisão do RTC que, associado ao algoritmo de manutenção de data
e hora criado, se verificou permitir contabilizar o tempo de forma correcta. Apesar da imprecisão
existente no relógio implementado no microcontrolador, o esquema de correcção a partir do RTC
demonstrou realizar a correcção dos valores, garantindo assim que os eventos são gerados no
momento adequado.
No que diz respeito à dispensa de medicação, confirmou-se o correcto funcionamento de todo
o mecanismo, não se tendo observado quaisquer problemas mesmo quando a medicação se
encontra em compartimentos não adjacentes. Verificou-se igualmente a precisão do motor de passo
que, associada ao mecanismo de feedback usado, garante uma elevada fiabilidade, sem se terem
verificado quaisquer falhas no posicionamento da estrutura circular. Este último ponto é fundamental
para garantir a segurança da pessoa cuidada, pelo que se consideram os resultados muito positivos.
Na interacção directa com o dispensador, verificou-se que a navegação nos menus é fluida,
havendo uma total coerência entre os cliques nos botões do teclado e a correspondente resposta no
LCD, com tempos de resposta percepcionados como instantâneos. Verificou-se também o correcto
funcionamento de todas as funcionalidades fornecidas por esta interface, cumprindo-se o objectivo de
permitir a configuração do dispensador sem recurso a dispositivos externos.
No acompanhamento remoto da operação do dispensador, verificou-se de forma extensiva a
geração e envio de notificações para o cuidador. Verificou-se também o mecanismo de salvaguarda
das notificações em caso de falha, tendo-se concluido que este opera de forma adequada, o que
permite uma maior robustez face a problemas nas entidades que comunicam com o dispensador.
Para testar a fiabilidade da comunicação por Bluetooth e do protocolo criado, realizou-se um
primeiro teste com o envio de 20000 comandos de leitura de data e hora (comando com dimensão de
66
4 bytes). Seguidamente, testou-se o envio de 2000 comandos de leitura de 50 dos parâmetros de
configurações do dispensador (comando com dimensão de 54 bytes), intercalados com mensagens
de tamanho aleatório entre 1 e 60 bytes, compostas por conteúdo aleatório. Em ambos os casos, a
totalidade das mensagens de resposta foram recebidas de forma correcta, não se tendo observado
qualquer corrompimento. O teste foi realizado utilizando um computador equipado com Bluetooth
para comunicar com o dispensador.
No caso da comunicação Wi-Fi, repetiram-se exactamente os mesmos testes, tendo a
comunicação sido estabelecida entre um computador portátil, através de Wi-Fi, e o dispensador, a
operar numa rede local. Importa referir que o router e o dispensador se encontravam em divisões
distintas, o que demonstra que o módulo utilizado tem um alcance bastante bom.
Neste caso, para o primeiro teste, verificou-se a correcta execução de todos os comandos, à
excepção de 10 tentativas de contacto que não foram possíveis de estabelecer, bem como em 6 das
conexões houve ausência dos dados na resposta recebida. Apesar de não ter sido possível
determinar a causa exacta destas falhas, supõe-se que poderão ter tido origem no facto de o módulo
estar consideravelmente distante do router, o que poderá ter causado problemas na comunicação. No
entanto, tendo em conta a percentagem de erros face ao total de mensagens enviadas e a
possibilidade de implementar mecanismos de retransmissão, consideram-se os resultados aceitáveis.
Testou-se igualmente a resposta do módulo Wi-Fi face a falhas no access point. Desta forma,
após registo do módulo de Wi-Fi na rede local, desligou-se o router e voltou-se a ligar, sendo que o
módulo restabeleceu a ligação automaticamente quando o router voltou a ficar activo. Este
comportamento é muito importante para evitar que o cuidador fique sem este método de
comunicação ao dispensador apenas por ter ocorrido uma falha na cobertura de sinal ou uma curta
falha de energia eléctrica.
Para complementar os testes à comunicação, analisou-se o tempo de envio de alguns
comandos, confome indicado na tabela 4. Os tempos apresentados correspondem à média dos
valores obtidos para a totalidade de comandos enviados e incluem todo o processamento realizado
em ambas as APIs. Para os comandos que implicam a escrita de dados na EEPROM, testou-se com
um número inferior de mensagens para evitar escritas excessivas nesta memória, que tem um limite
máximo de ciclos de escrita a partir do qual a sua fiabilidade começa a ficar comprometida.
Importa referir que as diferenças de tempo verificadas entre ambas as tecnologias dependem
de vários factores, o que inclui os próprios protocolos de comunicação (Wi-Fi e Bluetooth) e ao facto
das APIs terem sido implementadas em linguagens de programação diferentes (Python e Java).
Assim, uma análise mais aprofundada destas diferenças encontra-se fora do contexto do projecto.
67
Tabela 4 – Tempo de envio de alguns dos comandos do dispensador.
Comando Tempo
Wi-Fi [s]
Tempo
Bluetooth [s]
Nº de comandos
enviados
Lê data e hora 0.082 0.043 100
Lê mensagem (dimensão igual a 16 bytes) 0.080 0.061 100
Lê mensagem (dimensão igual a 60 bytes) 0.082 0.113 100
Adiciona mensagem (dimensão igual a 16
bytes)
0.200 0.181 20
Adiciona mensagem (dimensão igual a 60
bytes)
0.362 0.533 20
Adiciona alarme 0.145 0.143 20
Adiciona alarme ao modo diario 0.104 0.095 20
Configura alarmes utilizando lista do modo
diário (28 alarmes)
1.808 1.697 20
Para comandos simples, como ler a data e a hora, os tempos são bastante reduzidos. Para
os comandos de leitura de mensagens de memória, que necessitam de um acesso à EEPROM do
microcontrolador, os tempos continuam a ser relativamente baixos. No caso da adição de uma nova
mensagem, a sua dimensão tem já um efeito significativo, o que é explicado pela necessidade de
escrever na EEPROM, que é uma operação demorada.
Para os tempos do comando de adicionar alarme, os testes foram realizados com os alarmes
ordenados pela sua estampilha temporal. Tal deve-se ao facto de que o algoritmo de adição garante
que estes são inseridos ordenados em memória, pelo que assim se minimiza o número de operações
de leitura e escrita na EEPROM que o microcontrolador realiza, resultando em menor latência.
Por fim, considerou-se interessante analisar o tempo de execução do comando de
configuração dos alarmes a partir do modo diário, cujos valores são explicados pela necessidade de
colocar na EEPROM todos os alarmes efectivos gerados.
Tendo em conta o baixo custo de ambos os módulos de comunicação, considera-se que os
resultados obtidos são bastante satisfatórios, com particular ênfase para a sua fiabilidade. No que diz
respeito aos tempos de comunicação, consideram-se os valores obtidos adequados.
5.2 Análise de custos
A presente secção tem como objectivo a enumeração e análise sucinta dos custos do
material necessário ao desenvolvimento do protótipo.
Importa deixar claro que criação de um produto final envolve um enorme número de factores
que condicionam o seu custo e que estão muito para além dos gastos com os componentes
electrónicos. Num projecto desta natureza, é expectável que uma quantidade significativa de dinheiro
seja gasta na criação dos moldes para as peças plásticas, cuja diluição em cada dispensador está
indexada à quantidade de unidades vendidas. Da mesma forma, há que ter em conta os custos de
68
montagem, divulgação do produto e desenvolvimento da infra-estrutura tecnológica de suporte (como
por exemplo, as aplicações para Smartphone), entre outros.
A análise dos referidos factores é complexa e requer um estudo cuidado, estando fora do
contexto deste trabalho. No entanto, considera-se relevante fazer uma análise inicial, para que se
possa ter uma ordem de grandeza dos custos da implementação da electrónica do dispensador.
Apesar de não se ter tido como objectivo fundamental a redução dos custos, tentou-se
sempre que possível escolher os componentes com o menor preço (sem sacrificar as
funcionalidades) e utilizar soluções viáveis para uma futura adaptação para um produto.
No anexo A.5 encontra-se uma listagem do custo dos componentes electrónicos utilizados,
bem como algum material auxiliar necessário. Os componentes foram adquiridos no website de
vendas Ebay (www.ebay.com), razão pela qual os valores enumerados, registados no momento da
compra, poderão ser diferentes dos encontrados actualmente.
O valor total do material utilizado ascende a aproximadamente 60 euros. Para analisar este
valor, é necessário ter em conta que todos os componentes foram adquiridos em unidades individuais
ou em pequenas quantidades, razão pela qual não se beneficia dos descontos que eventualmente se
poderiam obter na compra do material em grandes quantidades para a produção de um produto final.
Outro factor a ter em conta é a impossibilidade de usar componentes SMD que, tipicamente,
têm um custo mais reduzido e apresentam um maior leque de opções. Assim, para além da redução
da área total ocupada pelos componentes, permitiriam uma redução substancial no preço final.
Para além disso, a opção de utilizar módulos electrónicos funcionais implica um custo extra
que não existiria caso apenas fossem usados os componentes estritamente necessários. Também é
necessário ter em consideração que cerca de um terço do valor total corresponde ao módulo de GSM
que, em muitos casos, pode não ser necessário. Assim, deixa-se a sugestão de, num eventual
produto, o módulo de GSM ser vendido em separado, possibilitando a sua aquisição apenas em caso
de necessidade.
Tendo em conta as considerações anteriores e face aos preços dos vários produtos
existentes no mercado que foram analisados, juntamente com as novas funcionalidades introduzidas
no protótipo desenvolvido, considera-se que o custo total obtido corresponde a um valor bastante
satisfatório, aparentado ser viável uma transição para um produto.
5.3 Consumo energético
Importa deixar claro que, dadas as limitações no leque de escolha dos componentes
electrónicos, não se teve como principal objectivo reduzir o consumo energético mas sim obter um
elevado nível funcional. No entanto, o aspecto do consumo esteve sempre presente nas opções
tomadas, tendo conduzido à opção de desligar módulos que possuem um consumo elevado e apenas
são necessários em momentos específicos do funcionamento do dispensador.
Na tabela 5 descrevem-se os valores de corrente medidos para os componentes mais
relevantes do circuito do dispensador. As medições foram feitas com recurso a um multímetro digital,
razão pela qual não é possível medir o consumo de eventos de curta duração, como por exemplo o
69
envio de mensagens pelo módulo de Wi-Fi ou GSM. No entanto, seria interessante, com acesso a
equipamento mais sofisticado, fazer uma caracterização dos picos de consumo do dispensador.
Tabela 5 – Consumo de corrente dos principais componentes do sistema.
Descrição Consumo [mA]
Circuito de alimentação (sem carga) 16
Arduino Mega 70
Circuito mínimo (Arduino, RTC, reguladores de tensão, ULN2803, conversor de
nivel, MOSFETs e Potenciometro digital)
98
LCD (retroiluminação desligada) 7
LCD (retroiluminação ligada) 44
Módulo Bluetooth (não emparelhado) 20 - 48
Módulo Bluetooth (emparelhado) 15
Módulo Wi-Fi (conectado a um access point, sem estabelecer comunicação por
socket)
75
Módulo GSM (registado na rede, sem estabelecer comunicação) 40
Módulo GSM (em chamada, sem microfone e altifalante) 90
Modulo GSM (em chamada, com microfone e altifalante no volume máximo) 250
Motor de passo (em operação) 158
LED de sinalização (intensidade máxima) 3
Bezouro (intensidade máxima, frequência = 1 kHz) 86
Bezouro (metade da intensidade máxima, frequência = 1 kHz) 30
Conforme se pode observar, o próprio circuito de alimentação tem um consumo não
desprezável, correspondente ao consumo em repouso dos próprios reguladores de tensão. No caso
do regulador de 3.3 V, este consumo vale 5 mA [88], enquanto que no caso do regulador de 5 V vale
10 mA [77], o que justifica a corrente total medida.
No que diz respeito à placa Arduino a operar de forma isolada, obteve-se um consumo de
cerca de 70 mA para a execução da aplicação desenvolvida. Este valor é bastante superior aos 20
mA referidos no datasheet do microcontrolador para uma tensão de operação de 5 V e uma
frequência de operação de 16 MHz [74]. Este valor resulta do consumo dos restantes componentes
que compõem a placa Arduino, citado-se como exemplo o controlador ATmega8U2, utilizado para
implementar a comunicação USB [73], que tem um consumo de 13.5 mA [89].
Num desenho final, os componentes auxiliares poderiam ser reduzidos para o mínimo
estritamente necessário, o que permitiria reduzir bastante o consumo. Por exemplo, a placa Arduino
Mega possui um LED de sinalização da alimentação e um conversor de tensão de 3.3 V para
alimentar outros componentes, que poderiam ser removidos sem qualquer impacto no circuito, bem
como o próprio controlador USB, visto que esta interface não é utilizada. Outra forma interessante de
reduzir o consumo passa por analisar a possibilidade de colocar o microcontrolador a operar a uma
frequência de 8 MHz, o que permitiria baixar o seu consumo para 10 mA [74]. Naturalmente, esta
70
alteração teria de ser devidamente analisada para garantir que não iria afectar as funcionalidades
implementadas e os tempos de resposta aos eventos.
No que diz respeito aos módulos de comunicação, os valores obtidos estão concordantes
com os valores tabelados. No caso do Bluetooth, o valor apresentado na secção 3.4.3 diz respeito
apenas ao HC-06, pelo que a diferença registada poderá ser resultado dos componentes extra
existentes no módulo utilizado, que incluem um LED de sinalização. No caso do módulo Wi-Fi, a
diferença poderá resultar do facto de existirem placas ESP-01 com ligeiras variações nos seus
componentes.
Para o LCD, verificou-se que a retroiluminação do módulo apresenta um consumo
considerável. Neste caso, a diferença entre os valores medido e tabelado para o consumo do módulo
com a retroiluminação desligada é justificada com o consumo do conversor para a interface I2C que,
mais uma vez, contém também um LED de sinalização.
No caso do módulo GSM, existe a já referida limitação de se ter de utilizar um botão de
pressão para ligar e desligar, o que não permite, nesta implementação, o uso de um MOSFET para
permitir reduzir o seu consumo. No entanto, poder-se-ia aplicar o mesmo conceito num eventual
produto, no qual se utilizasse apenas o SIM900. É também interessante verificar que uma parte muito
significativa do consumo resulta do microfone e do altifalante, quando em chamada.
Apesar de o motor de passo ter um consumo considerável, este opera apenas numa curta
fracção do tempo total de operação, não tendo qualquer consumo durante o restante tempo.
Para a sinalização dos alarmes, o consumo quer do bezouro quer do LED de sinalização
dependem da intensidade dos mesmos e da percentagem de tempo durante o qual estão activos. No
entanto, os valores máximos de consumo com intensidade máxima são de 3 e 86 mA,
respectivamente. No caso do bezouro, não se limitou o consumo de corrente porque se pretende que
o som gerado possa ser bastante elevado, visto que os idosos tendem a ter dificuldades auditivas.
Face aos consumos dos periféricos de comunicação, considera-se que a possibilidade de os
poder desligar tem um impacto significativo. Como se observa, com estes módulos desactivados (e
com o GSM também desligado), o consumo total do circuito mantém-se próximo dos 100 mA, o que é
um valor razoável. Adicionalmente, utilizando os modos de gestão de energia, pode-se realizar um
controlo do funcionamento do dispensador que permite maximizar o tempo de operação em bateria,
caso a alimentação principal falhe.
É assim possível obter uma autonomia aproximada de 12 horas para a bateria utilizada (tem
uma capacidade de 1.2 Ah), o que é razoável tendo em conta a tecnologia utilizada. Importa também
referir que o uso de uma bateria de chumbo deveu-se apenas ao baixo custo e facilidade de
aquisição da mesma. Naturalmente, num produto, seria pertinente utilizar uma tecnologia que permita
uma maior densidade energética, quer para aumentar a autonomia do dispensador quando
alimentado por bateria quer para reduzir a dimensão e peso do dispositivo.
Numa perspectiva geral, ficou claro o impacto de se utilizarem módulos electrónicos no
consumo que, em consequência dos vários componentes auxiliares não necessários, acabaram por
ter um overhead muito significativo no consumo final. Assim, uma solução criada numa PCB com os
71
componentes necessários teria um consumo consideravelmente inferior, o que permitiria ainda
escolher reguladores de tensão mais eficientes, uma vez que as correntes totais seriam inferiores.
5.4 Recursos utilizados no microcontrolador
O microcontrolador usado foi seleccionado com base numa estimativa inicial dos recursos
necessários (secção 3.5.1). No entanto, dada a dificuldade em antecipar com precisão esses
recursos, procurou-se ter uma tolerância razoável.
No que diz respeito às interfaces de comunicação (SPI, UART e I2C), os recursos estimados
foram os suficientes, dado que não se adicionou nenhum módulo electrónico para além dos
inicialmente propostos.
Relativamente à capacidade de RAM, os valores inicialmente calculados foram
consideravelmente inferiores ao que veio a ser usado, embora não tenha sido excedida a capacidade
do microcontrolador (8 KB). Assim, foi usado um total de aproximadamente 5000 bytes face aos 820
bytes estimados inicialmente para as principais estruturas de dados.
Esta diferença deveu-se principalmente à necessidade de estruturas de dados auxiliares não
previstas, como no caso da interface com o LCD. No que diz respeito à comunicação através das
UARTs, não foram também considerados os buffers de envio necessários para guardar os dados.
Também todas as restantes variáveis de configuração e outras pequenas estruturas de dados
acabaram por ter um impacto superior ao esperado.
Por fim, menciona-se que várias das bibliotecas utilizadas contêm código genérico, que acaba
por consumir uma porção considerável de RAM.
No que diz respeito à memória de programa, o valor total ficou, como esperado, com cerca de
100 KB. Deste valor, uma percentagem significativa corresponde a strings dos menus que, por serem
constantes, são guardadas nesta memória. Ainda assim, face ao total de 256 KB de memória de
programa que o ATMega2560 possui, existe uma grande margem para eventuais futuras adições de
funcionalidades.
No que diz respeito à frequência de operação do microcontrolador, 16 MHz mostrou-se
suficiente para conseguir implementar todas as funcionalidades pretendidas sem problemas de
desempenho. Destaca-se a interface com o utilizador, cujos eventos são tratados com uma rapidez
suficiente para que as respostas sejam percepcionadas como instantâneas.
Deixa-se apenas como nota que, apesar de não se ter utilizado no desenho final, fizeram-se
alguns testes com um LCD a cores de 240 x 230 pixéis, controlado por SPI, no qual a velocidade de
resposta se verificou ser um pouco limitada. Como tal, a futura adopção de um display deste tipo
poderá obrigar a outro tipo de solução, como por exemplo utilizar um microcontrolador dedicado com
uma velocidade de comunicação superior.
72
6 Conclusão
O presente trabalho teve como principal objectivo a criação de um protótipo funcional de um
dispensador de medicamentos. O equipamento desenvolvido destina-se a auxiliar pessoas com
problemas de memória ou degradações cognitivas a cumprirem os seus regimes terapêuticos,
tentando minimizar a ocorrência de erros e esquecimentos, que podem ter consequências nefastas
para a saúde.
Apesar de já existirem no mercado alguns produtos que ajudam a gerir a medicação, uma
análise das características dos mesmos revelou algumas limitações, com particular ênfase para a
falta de versatilidade e o facto de serem sistemas fechados, sem possibilidade de serem melhorados
ou integrados em soluções mais abrangentes.
Assim, procurou-se resolver as limitações destes produtos com a criação de uma solução
aberta e versátil, com capacidade de interacção com dispositivos como computadores, Smartphones
e Tablets, possibilitando a outras entidades o desenvolvimento de aplicações que interajam com o
dispensador e possam automatizar vários procedimentos. Desta forma, possibilita-se não só optimizar
as interfaces de interacção para os cuidadores tradicionais (familiares e outras pessoas próximas)
bem como o seu uso em contextos mais amplos, com a possibilidade de integração com equipas
cuidadoras domiciliárias ou integração em ambientes do tipo lar ou semelhante.
A implementação do protótipo proposto requereu todo um extenso trabalho em diversas áreas
da engenharia. Numa primeira fase, foi necessário conceber toda a estrutura electrónica do
dispensador. Apesar de se ter recorrido a alguns módulos funcionais, nomeadamente a nível das
comunicações, houve a necessidade de realizar um trabalho vasto de selecção e uso de
componentes discretos, com vista à obtenção de um protótipo funcional e com todas as
características requeridas. Isto implicou um grande investimento de pesquisa e aquisição de novos
conhecimentos, sendo o protótipo desenvolvido uma solução nova, desenhada de raiz para satisfazer
os objectivos definidos.
Face à complexidade considerável do sistema desenvolvido, surgiram vários problemas com
os quais foi necessário lidar. Destes destacam-se os problemas relacionados com o ruído elétrico e a
fonte de alimentação, tendo sido necessário regular as tensões para os níveis correctos e garantir o
fornecimento adequado de corrente a todos os módulos. Adicionalmente, houve grandes dificuldades
na obtenção de certos componentes, cujos tempos de entrega foram em média de três semanas,
dificultando imenso o processo de desenvolvimento.
Para além do desenho e implementação do hardware foi necessário desenvolver todo o
software de controlo do dispensador. Apesar da plataforma Arduino e suas bibliotecas oferecerem
algumas abstracções que facilitam a implementação, o desenvolvimento foi feito maioritariamente em
C, tendo exigido muitos cuidados com as limitações inerentes ao uso de um microcontrolador. Assim,
73
o estilo de programação teve de ter em consideração as limitações de memória e de velocidade de
processamento, o que implicou um cuidado especial na implementação de procedimentos mais
complexos. Ainda assim, foi feito um esforço significativo para tornar o software o mais modular e
flexível possível, no sentido de facilmente poder ser adaptado a um produto final ou até,
eventualmente, a outros projectos.
Ainda relativamente ao desenvolvimento da aplicação de controlo, destacam-se todos os
detalhes que foram necessários ter em conta para a implementação das funcionalidades propostas.
Dada a necessidade de interagir com o utilizador e o cuidador, é fundamental contemplar todas as
situações limite que podem ocorrer, como por exemplo a configuração de alarmes que se sobrepõem
ou a tentativa de entrar em operação com alarmes inválidos. Estes são apenas dois exemplos das
múltiplas situações de conflito com que foi necessário lidar. Todos estes detalhes se traduzem num
código extenso e complexo, difícil de testar e susceptível a erros, que nem sempre são evidentes à
primeira vista.
Da mesma forma, o desenvolvimento da interface de interacção directa com o dispensador,
através do teclado e do display, traduziu-se num desafio considerável, com uma extensão e
dificuldade de implementação muito superior à inicialmente esperada. Para a sua implementação,
praticamente todas as funcionalidades tiveram de ser pensadas de raiz, com um código extenso e
relativamente complexo para permitir alguma flexibilidade e capacidade de adaptação e expansão.
Apesar de se terem utilizado módulos de comunicação que implementam os respectivos
protocolos e permitem uma interacção directa com o microcontrolador, tal não significou um trabalho
simples. Na realidade, a documentação e informação disponível é relativamente escassa, o que
dificultou o seu uso. Destes módulos, destaca-se o ESP8266 que, por ter sido recentemente
introduzido no mercado, possui ferramentas de desenvolvimento pouco maduras e com alguns
problemas.
Por fim, refere-se o trabalho efectuado a nível de linguagens de alto nível, para implementar e
testar a comunicação com o dispensador. Assim, foi necessário trabalhar não só a nível da
comunicação série como também utilizando comunicação por sockets, para testar todas as interfaces
de comunicação do dispensador. Para além disso, houve ainda a necessidade de trabalhar em
Android, cuja aprendizagem revelou não ser trivial, com o objectivo de demonstrar a capacidade de
diálogo com este tipo de dispositivo.
Em suma, o trabalho realizado abordou diversas áreas, tendo-se enfrentado vários desafios e
problemas que se revelaram bastante mais extensos e complexos do que se antecipava inicialmente.
No que diz respeito ao resultado final obtido, considera-se o protótipo como bastante
adequado. As funcionalidades propostas foram implementadas e validadas, sendo a solução final
bastante versátil e aberta, que introduz várias inovações face aos produtos existentes no mercado.
Destaca-se a possibilidade de interagir com dispositivos localizados na sua proximidade
(Smartphones e Tablets) que permitem configurar o dispensador a partir de aplicações optimizadas
para o contexto de uso, bem como as capacidades de comunicação remota, que permitem a
notificação de ocorrências através de SMS e mecanismos envolvendo a Internet.
74
Apesar de o objectivo principal ter sido o de desenvolver um protótipo que pudesse realizar
uma prova de conceito e demonstrar a viabilidade do que se propôs, considera-se que foi possível
obter uma solução com um baixo custo e elevado nível de funcionalidade. Da mesma forma, ao nível
do consumo energético e da autonomia de operação em bateria, obtiveram-se resultados bastante
satisfatórios, muito embora esse não fosse um objectivo inicial do protótipo.
Deixa-se como nota menos positiva o facto de não ter sido possível testar o protótipo com
utilizadores reais, nomeadamente idosos, uma vez que a estrutura física da solução final não o
permite. No entanto, conforme referido, não fazia parte do contexto do projecto o desenvolvimento da
estrutura mecânica final do dispensador. Para além disso, dada a natureza sensível deste produto, os
testes a realizar teriam de ser supervisionados e implicaria uma logística complexa.
Apesar de todas as funcionalidades e inovações implementadas, houve algumas ideias que
não puderem ser testadas, quer por falta de tempo quer por falta de recursos. Em seguida
apresentam-se algumas dessas ideias que seria interessante explorar no contexto de trabalho futuro.
Seria interessante adicionar sensores biométricos ao dispensador, permitindo assim
acompanhar o estado de saúde da pessoa cuidada. Nesta área, cita-se como exemplo a plataforma
Bitalino [90] e e-Health [91], as quais permitem a captura de múltiplos sinais que podem ir desde a
pulsação e pressão arterial até à realização de electrocardiogramas simplificados.
Outra adição pertinente seria um conjunto de sensores genéricos, como por exemplo,
temperatura, monóxido de carbono, fumo e fugas de gás. Desta forma, poder-se-ia monitorizar vários
parâmetros do meio ambiente, tornando possível evitar acidentes como incêndios ou intoxicações
com monóxido de carbono.
Neste caso, poder-se-ia utilizar o dispensador como ponto de recolha de informação
produzida pelos outros dispositivos. Uma vez que este já possui capacidades de comunicação remota
(Wi-Fi e GSM), não seria necessário dotar os restantes dispositivos destas interfaces, tornando-os
mais económicos.
A concluir menciona-se que o desenvolvimento do presente trabalho foi muito interessante e
permitiu aumentar bastante o nível de conhecimento e experiência nas áreas abordadas. A solução
desenvolvida mostrou responder aos objectivos definidos, constituindo uma abordagem aberta,
flexível e muito funcional, que se espera que possa contribuir para uma maior autonomia de pessoas
que estejam dependentes da toma de medicamentos e apresentem algumas limitações nas suas
capacidades cognitivas. A solução oferece também a possibilidade de familiares ou cuidadores
dessas pessoas acompanharem, remotamente, o processo de toma da terapêutica, oferecendo-lhes
uma maior segurança e tranquilidade.
75
7 Bibliografia
[1] E-pill. (n.d). MedSmart manual [manual]. Acedido em Setembro 25, 2014, disponível em
http://ep.yimg.com/ty/cdn/epill/medsmartmanual.pdf
[2] Alert Utah. Acedido em Setembro 25, 2014, disponível em http://alertutah.com/medication-
dispensers/medsmart-medication-dispenser/
[3] E-pill. (n.d). Epill MedSmart Brochure [folheto]. Acedido em Setembro 25, 2014, disponível em
http://ep.yimg.com/ty/cdn/epill/epillMedSmartBrochure.pdf
[4] E-pill. ORDER / products. Acedido em Setembro 25, 2014, disponível em
http://www.epill.com/bysku.html
[5] Philips. Manage Complex Medications with Philips Medication Dispenser. Acedido em
Outubro 1, 2014, disponível em http://www.managemypills.com/content/product-costs
[6] AbleData. Acedido em Outubro 2, 2014, disponível em
http://www.abledata.com/abledata.cfm?pageid=113582&orgid=113361&discontinuetoggle=1
[7] Silfen, E., Wirahadiraksa, R. (2010). Goldman Sachs European Medtech and
Healthcare Services Conference. Acedido em Dezembro 31, 2014, disponível em
http://www.philips.com/shared/assets/Downloadablefile/Investor/2010_09_09_Silfen_Wirahadi
raksa_GoldmanSachs_London.pdf
[8] Philips. Philips Medication Dispenser User Manual [manual]. Acedido em Outubro 5, 2014,
disponível em http://www.lifeline.ca/servlet/DownloadServlet?id=5429
[9] Philips. (2008). Frequently asked questions [folheto]. Acedido em Outubro 5, 2014, disponível
em http://www.managemypills.com/servlet/DownloadServlet?id=224
[10] Eclipse. Acedido em Outubro 5, 2014, diponível em
http://www.eclipsepd.com/areas/consumer
[11] MD News. (2011). Managing Medication at Home: Philips Medication Dispensing Service Now
Offered Through the American Red Cross. Acedido em Outubro 5, 2014, disponível em
http://www.mdnews.com/news/2011_12/05782_novdec2011_managing-medication.aspx
[12] Philips. Product details. Acedido em Outubro 1, 2014, disponível em
http://www.managemypills.com/content/product-details
[13] MedFolio. MedFolio electronic pillbox. Acedido em Outubro 4, 2014, disponível em
http://www.medfoliopillbox.com/product/medfolio-pillbox/
[14] MedFolio. MedFolio User Guide [manual]. Acedido em Outubro 4, 2014, disponível em
https://www.medfoliopillbox.com/wp-content/uploads/2013/03/MedFolio-english-web1.pdf
[15] Earth Flare. MedHelper App – Your Healthcare Assistant. Acedido em Dezembro 20, 2014,
disponível em http://medhelperapp.com/
76
[16] MedQ. MedQ Pill Box Dispenser. Acedido em Novembro 15, 2014, disponível em
http://www.lifesavingpillbox.com/
[17] Tabtime Ltd. Tabtime Super 8: Daily Pill Timer - Reminder. Acedido em Outubro 10, 2014,
disponível em http://www.tabtime.com/daily-pill-reminder.html
[18] PivoTell Ltd. PivoTell Automatic Pill Dispenser Mk3-11. Acedido em Novembro 11, 2014,
disponível em http://www.pivotell.co.uk/PivoTell%C2%AE_Automatic_Pill_Dispenser_Mk3-
11.htm
[19] Bindependend. MedReady GSM Cellular Dispenser. Acedido em Novembro 14, 2014,
disponível em http://www.bindependent.com/product/mr357/Cellular-Automated-MedReady-
Dispenser/
[20] Ivation. Ivation Automatic Pill Dispenser. Acedido em Outubro 20, 2014, disponível em
http://myivation.com/ivation-automatic-pill-dispenser.html
[21] Brigham Young University. (2013). Prescription drug regulator aimed at curbing painkiller
abuse. Acedido em Dezembro 14, 2014, disponível em http://news.byu.edu/archive13-apr-
medvaultcapstone.aspx
[22] Sparkfun. Integrated Circuits. Acedido em Dezembro 24, 2014, disponível em
https://learn.sparkfun.com/tutorials/integrated-circuits/ic-packages
[23] Adafruit. Adafruit FONA. Acedido em Janeiro 4, 2015, disponível em
http://www.adafruit.com/product/1963
[24] Sparkfun. GSM/GPRS Module - SM5100B. Acedido em Janeiro 20, 2015, disponível em
https://www.sparkfun.com/products/9533
[25] M2Mcom. SIM900. Acedido em Agosto 1, 2015, disponível em
http://www.simcom.eu/index.php?m=termekek&prime=1&sub=40&id=0000000147
[26] SIMCom. (Dezembro 15, 2010). SIM900 Hardware Design V2.00, disponível em
ftp://imall.iteadstudio.com/IM120417009_IComSat/DOC_SIM900_Hardware%20Design_V2.00.
[27] Getech. Arduino GPRS Shield. Acedido em Junho 29, 2015, disponível em
http://www.geeetech.com/wiki/index.php/Arduino_GPRS_Shield
[28] Sparkfun. SparkFun WiFi Breakout - CC3000. Acedido em Janeiro 20, 2015, disponível em
https://www.sparkfun.com/products/12072
[29] Espressif Systems. (Outubro 12, 2013). Espressif Smart Connectivity Platform: ESP8266.
Acedido em Agosto 6, 2008, disponível em
http://www.adafruit.com/datasheets/ESP8266_Specifications_English.pdf
[30] Acedido em Agosto 6, 2015, disponível em https://github.com/esp8266/esp8266-wiki/wiki
[31] Acedido em Agosto 4, 2015, disponível em
http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family
[32] Addicore. Addicore ESP8266 ESP-01 WiFi Wireless Tranceiver Module. Acedido em Agosto
11, 2015, disponível em http://www.addicore.com/Addicore-ESP8266-WiFi-Wireless-
77
Tranceiver-Module-V-p/130.htm
[33] Sparkfun. Bluetooth Basics. Acedido em Março 28, 2015, disponível em
https://learn.sparkfun.com/tutorials/bluetooth-basics/bluetooth-profiles
[34] Sparkfun. Acedido em Março 2, 2015, disponível em https://www.sparkfun.com/categories/115
[35] Digilent. PmodBT2 - Bluetooth Interface. Acedido em Março 10, 2015, disponível em
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,401,947&Prod=PMOD-BT2
[36] Guangzhou HC Information Technology. (Setembro 6, 2006). HC-06 [datasheet]. Acedido em
Fevereiro 10, 2015, disponível em http://www.electronicoscaldas.com/datasheet/HC-
06_Wavesen.pdf
[37] SPP Bluetooth Modules. Acedido em Agosto 1, 2015, disponível em
http://wiki.pinguino.cc/index.php/SPP_Bluetooth_Modules
[38] Sparkfun. SparkFun Bluetooth Modem - BlueSMiRF Gold. Acedido em Março 12, 2015,
disponível em https://www.sparkfun.com/products/12582
[39] Roving Networks. (Junho 27, 2011). RN-41 [Dataheet]. Acedido em Março 12, 2015, disponível
em http://cdn.sparkfun.com/datasheets/Wireless/Bluetooth/Bluetooth-RN-41-DS.pdf
[40] FastTech. JY-MCU HC-06 Bluetooth Wireless Serial Port Module. Acedido em Agosto 6, 2015,
disponível em https://www.fasttech.com/product/1129201-jy-mcu-hc-06-bluetooth-wireless-
serial-port-module
[41] Texas Instruments. Products for Real-time Clocks. Acedido em Junho 12, 2015, disponível em
http://www.ti.com/lsds/ti/clock-and-timing/real-time-clocks-products.page
[42] NXP. Acedido em Junho 12, 2015, disponível em
http://www.nxp.com/products/interface_and_connectivity/real_time_clocks/#products
[43] Maxim Integrated. DS1307 [datasheet]. Acedido em Junho 10, 2015, disponível em
http://datasheets.maximintegrated.com/en/ds/DS1307.pdf
[44] Maxim Integrated. DS3231 [datasheet]. Acedido em Junho 10, 2015, disponível em
http://datasheets.maximintegrated.com/en/ds/DS3231.pdf
[45] Box Electronica. DS3231 AT24C32 IIC module - precision Real time clock memory. Acedido
em Junho 10, 2015, disponível em http://boxelectronica.com/sensores/22-ds3231-at24c32-iic-
module-precision-real-time-clock-memory-.html
[46] Atmel. (2003). AT24C32 - 2-Wire Serial EEPROM [datasheet]. Acedido em Junho 10, 2015,
disponível em http://www.atmel.com/images/doc0336.pdf
[47] G. Guajardo. (Agosto 8, 2012). Stepper vs. Servo: Which is Better Served with My Electric
Cylinder [white paper]. Acedido em Junho 10, 2015, disponível em
http://www.bimba.com/Global/Homepage-Spotlights/BIM-
1154%20Stepper%20Whitepaper_FINAL.pdf
[48] Kiatronics. 28BYJ-48 – 5V Stepper Motor [datasheet]. Acedido em Janeiro 20, 2015, disponível
em http://robocraft.ru/files/datasheet/28BYJ-48.pdf
78
[49] Small Stepper Motor and Driver Board. Acedido em Junho 12, 2015, disponível em
https://arduino-info.wikispaces.com/SmallSteppers
[50] Texas Instruments. (Janeiro, 2015). ULN2803A Darlington Transistor Arrays [datasheet].
Acedido em Março, 2015, disponível em https://www.ti.com/lit/ds/symlink/uln2803a.pdf
[51] Stan. (Março 1, 2014). 28BYJ-48 Stepper Motor with ULN2003 driver and Arduino Uno.
Acedido em Maio 7, 2014, disponível em http://42bots.com/tutorials/28byj-48-stepper-motor-
with-uln2003-driver-and-arduino-uno/
[52] Electronics Tutorials. The Hall Effect Sensor. Acedido em Junho 15, 2015, disponível em
http://www.electronics-tutorials.ws/electromagnetism/hall-effect.html
[53] M. Rouse. Optoisolator (Optical Coupler Or Optocoupler) Definition. Acedido em Junho 10,
2015, disponível em http://searchnetworking.techtarget.com/definition/optoisolator
[54] Everlight. (Janeiro 20, 2014). Opto Interrupter ITR9608-F [datasheet]. Acedido em Abril 10,
2015, disponível em http://www.everlight.com/file/ProductFile/ITR9608-F.pdf
[55] Octopart . Everlight ITR-9608. Acedido em Abril 20, 2015, disponível em
https://octopart.com/itr-9608-everlight-12445677
[56] Praveen. (Dezembro 5, 2014). Interfacing hex keypad to arduino. Acedido em Abril 24, 2015,
disponível em http://www.circuitstoday.com/interfacing-hex-keypad-to-arduino.
[57] QC2004A [datasheet]. Acedido em Janeiro 22, 2015, disponível em
http://www.rcscomponents.kiev.ua/datasheets/20138519401472480.pdf
[58] 5V 2004 20X4 204 2004A LCD Display Module Blue Screen For Arduino. Acedido em Abril 20,
2015, disponível em http://www.banggood.com/Wholesale-Warehouse-5V-2004-20X4-204-
2004A-LCD-Display-Module-Blue-Screen-For-Arduino-wp-Uk-915064.html
[59] Philips. (Novembro 22, 2012). PCF8574 [datasheet]. Acedido em Março 20, 2015, disponível
em http://www.nxp.com/documents/data_sheet/PCF8574.pdf
[60] Microchip. (Julho 28, 2003). MCP41XXX/42XXX - Single/Dual Digital Potentiometer with SPI™
Interface [datasheet]. Acedido em Abril 15, 2015, disponível em
http://che126.che.caltech.edu/11195c.pdf
[61] Electronics News Line. List of Top Microcontroller Companies in the World. Acedido em
Fevereiro 20, 2015, disponível em http://electronicsnewsline.com/457/list-of-top-microcontroller-
companies-in-the-world.html
[62] Futurlec. Atmel Microcontrollers. Acedido em Fevereiro 11, 2015, disponível em
http://www.futurlec.com/ICAtmel.shtml
[63] Microchip. All 8-bit Microcontrollers Products. Acedido em Fevereiro 14, 2015, disponível em
http://www.microchip.com/ParamChartSearch/Chart.aspx?branchID=1012
[64] MikroElektronika. PIC Development Boards. Acedido em Fevereiro 12, 2015, disponível em
http://www.mikroe.com/pic/development-boards/
79
[65] Arduino. Compare board specs. Acedido em Fevereiro 11, 2015, disponível em
https://www.arduino.cc/en/Products.Compare
[66] B. Benchoff. (Março 10, 2013). Acedido em Fevereiro 17, 2015, disponível em
http://hackaday.com/2013/03/10/another-salvo-in-the-pic-vs-avr-holy-war/
[67] P. Torrone. (Fevereiro 10, 2011). Why the Arduino Won and Why It’s Here to Stay. Acedido em
Fevereiro 27, 2015, disponível em http://makezine.com/2011/02/10/why-the-arduino-won-and-
why-its-here-to-stay/
[68] Neil. Acedido em Março 20, 2015, disponível em http://nrqm.ca/mechatronics-lab-guide/lab-
guide-software-environment/
[69] EngBlaze. Microcontroller tutorial series: AVR and Arduino timer interrupts. Acedido em 20
Agosto, 2015, disponível em http://www.engblaze.com/microcontroller-tutorial-avr-and-arduino-
timer-interrupts/
[70] Sparkfun. What is an Arduino?. Acedido em Agosto 5, 2015, disponível em
https://learn.sparkfun.com/tutorials/what-is-an-arduino.
[71] Evans, B. (2011). Beginning Arduino Programming. New York, NY: Apress
[72] Banzi, M. (2008). Getting started with Arduino. California: O’Reilly
[73] Arduino. Arduino Mega 2560. Acedido em Maio 24, 2015, disponível em
http://arduino.cc/en/Main/ArduinoBoardMega2560
[74] Atmel. (2014). Atmel ATmega640/V-1280/V-1281/V-2560/V-2561/V [datasheet]. Acedido em
Maio 24, 2015, disponível em http://www.atmel.com/Images/Atmel-2549-8-bit-AVR-
Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf
[75] Yasin, S. (Dezembro 11, 2012). How to switch between power supplies using diodes. Acedido
em Maio 19, 2015, disponível em http://saeedsolutions.blogspot.pt/2012/12/how-to-switch-
between-power-supplies.html
[76] Automatically switching from 9V battery to DC wall adapter on insertion. Acedido em Maio 12,
2015, disponível em http://electronics.stackexchange.com/questions/130986/automatically-
switching-from-9v-battery-to-dc-wall-adapter-on-insertion
[77] Texas Instruments. (Dezembro, 2014). LM2940x 1-A Low Dropout Regulator [datasheet].
Acedido em Maio 5, 2015, disponível em http://www.farnell.com/datasheets/1882643.pdf
[78] Future Electronics. What is a Schottky Diode?. Acedido em Maio 10, 2015, disponível em
https://www.futureelectronics.com/en/diodes/schottky-diodes.aspx
[79] Electronics Tutorials. MOSFET as a Switch. Acedido em Julho 15, 2015, disponível em
http://www.electronics-tutorials.ws/transistor/tran_7.html
[80] Vishai. (Março 21, 2011). IRF9Z24 [datasheet]. Acedido em Agosto 2, 2015, disponível em
http://www.vishay.com/docs/91090/91090.pdf
[81] Sparkfun. Transistors. Acedido em Junho 10, 2015, disponível em
https://learn.sparkfun.com/tutorials/transistors/applications-ii-amplifiers
80
[82] TT electronics. (Dezembro, 2004). Application Circuits for the Phototransistor Switch. Acedido
em Abril 10, 2015, disponível em http://optekinc.com/pdf/App%20Bulletin%20213-
Opto%20Assemblies.pdf
[83] Schmitz, T., Wong, M. (Outubro 10, 2011). Choosing and Using Bypass Capacitors [nota de
aplicação]. Acedido em Junho 19, 2015, disponível em
https://www.intersil.com/content/dam/Intersil/documents/an13/an1325.pdf
[84] Arduino. ATmega2560-Arduino Pin Mapping. Acedido em Junho 10, 2015, disponível em
https://www.arduino.cc/en/Hacking/PinMapping2560
[85] Acedido em Junho 19, 2015, disponível em https://github.com/esp8266/Arduino.
[86] SIMCom. (Dezembro 24, 2010). SIM900 AT Command Manual. Acedido em Agosto 5, 2015,
disponível em
ftp://imall.iteadstudio.com/IM120417009_IComSat/DOC_SIM900_AT%20Command%20Manual
_V1.03.pdf
[87] Gupta, S., Kumar, M. (Novembro, 2010). Optimizing Low Power Embedded Designs. Acedido
em Abril 2, 2015, disponível em
http://www.element14.com/community/servlet/JiveServlet/previewBody/28096-102-1-
77297/OptimizingLowPowerEmbeddedDesignsFinal1.pdf
[88] STMicroelectronics. (Dezembro, 2006). LD1117 series [datasheet]. Acedido em Agosto 11,
2015, disponível em http://pdf1.alldatasheet.com/datasheet-
pdf/view/94381/STMICROELECTRONICS/LD1117.html
[89] Atmel. (Setembro, 2012). ATmega8U2 [datasheet]. Acedido em Agosto 10, 2015, disponível
em http://www.atmel.com/Images/doc7799.pdf
[90] Bitalino. Get Started. Acedido em Agosto 2, 2015, disponível em
http://www.bitalino.com/index.php
[91] Cooking Hacks. e-Health Sensor Platform V2.0 for Arduino and Raspberry Pi. Acedido em
Agosto 2, 2015, disponível em https://www.cooking-hacks.com/documentation/tutorials/ehealth-
biometric-sensor-platform-arduino-raspberry-pi-medical
81
Anexos
A.1. Algoritmo de funcionamento do protocolo série
Figura A.1.1 - Funcionamento do protocolo de recepção de dados por comunicação série.
82
A.2. Lista de comandos do protocolo de comunicação
Tabela A.2.1 – Comandos do protocolo de comunicação.
Comando Descrição
Actualiza data e hora Define a data e hora do dispensador.
Lê data e hora Lê a data e hora do dispensador.
Move dispensador Move a estrutura dos comprimidos para um determinado
compartimento.
Eco Retorna uma cópia da mensagem enviada para o dispensador.
Edita mensagem Edita uma mensagem textual da memória do dispensador.
Lê mensagem Lê uma mensagem textual da memória do dispensador.
Adiciona alarme Adiciona um alarme de dispensa.
Lê alarme Lê um alarme de dispensa da memória do dispensador.
Edita alarme Edita um alarme de dispensa.
Remove alarme Remove um alarme de dispensa.
Re-arma alarme Dispara novamente um alarme falhado.
Adiciona alarme à lista do
modo diário
Adiciona um novo alarme à lista de alarmes do modo diário.
Remove alarme da lista
do modo diário
Remove um alarme da lista de alarmes do modo diário.
Lê alarme do modo diário Lê um alarme da lista de alarmes do modo diário.
Configura alarmes a
partir do modo diário
Executa o algortimo de configuração dos alarmes de dispensa a
partir da lista do modo diário.
Adiciona aviso textual Adiciona um novo aviso textual.
Elimina aviso textual Elimina um aviso textual previamente configurado.
Lê aviso textual Lê um aviso textual da memória do dispensador.
Remove PRN Remove n medicamentos PRN previamente configurados.
Adiciona PRN Adiciona n medicamentos PRN.
Lê PRN Lê estado de um medicamento PRN da memória do dispensador.
Lê dados da EEPROM Lê dados de uma lista de posições da EEPROM do
microcontrolador.
Escreve dados na
EEPROM
Escreve dados de numa lista de posições da EEPROM do
microcontrolador.
Lê dados do espaço do
programador
Lê dados de uma lista de posições da EEPROM do RTC (espaço
livre para o programador).
Escreve dados no espaço
do programador
Escreve dados de numa lista de posições da EEPROM do RTC
(espaço livre para o programador).
Define o modo do
dispensador
Permite alternar entre o modo de configuração e o modo de
operação do dispensador.
83
Escreve configurações Define os valores de uma lista de configurações de operação do
dispensador.
Lê configurações Lê os valores de uma lista de configurações de operação do
dispensador.
Lê identificador do
dispensador
Lê o identificador de 32 bits do dispensador.
Lê nome de utilizador do
dispensador
Lê o nome de utilizador associado ao dispensador.
Define nome de utilizador
do dispensador
Escreve o nome do utilizador associado ao dispensador.
Lê outros registos Lê registos de tentativas de dispensa não permitidas e erros de
operação.
Lê temperatura Lê temperatura do sensor do RTC.
Lê código PIN Lê o código PIN definido.
Define código PIN Define o código PIN.
Lê código de
comunicação Bluetooth
Lê o código de comunicação Bluetooth definido.
Define código de
comunicação Bluetooth
Define o código de comunicação Bluetooth.
Define números GSM Define a lista de números autorizados a ligar para o dispensador,
bem como o número de destino das notificações remotas.
Lê números GSM Lê a lista de números autorizados a ligar para o dispensador, bem
como o número de destino das notificações remotas.
Envia código Bluetooth* Envia o código Bluetooth, para permitir a posterior comunicação.
Termina comunicação
Bluetooth*
Termina uma comunicação Bluetooth previamente iniciada,
deixando o canal num estado seguro.
*Aplicam-se apenas à comunicação Bluetooth.
84
A.3. Tipos de notificações remotas geradas pelo dispensador
Limiar pré-definido de tentativas de dispensa de medicação regular não autorizadas excedido.
Limiar pré-definido de tentativas de dispensa de medicação PRN não autorizadas excedido.
Erro de checksum num alarme, aviso textual, medicamento PRN ou mensagem textual.
Medicamento PRN dispensado.
Dispensa de todos os medicamentos PRN existentes.
Dispensa de medicação regular efectuada ou falhada.
Aceitação ou falha de aviso textual.
Dispensador sem medicação.
Limiar pré-definido de dispensas de medicação regular atingido.
A.4. Dimensões dos dados guardados em EEPROM
Tabela A.4.1 – Dimensões dos dados guardados na EEPROM do microcontrolador.
Descrição Dimensão individual
[Bytes]
Nº de unidades Dimensão total
[Bytes]
Alarmes 17 28 476
Avisos textuais 14 30 420
Mensagens textuais 62 30 1860
Alarmes do modo diário 8 28 224
Tentativas de dispensa fora
de hora
7 10 70
Tentativas de dispensa de
PRN fora de hora
7 30 210
Medicamentos PRN 7 28 196
Erros de operação 7 10 70
85
A.5. Custo dos componentes electrónicos utilizados
Tabela A.5.1 – Custo dos componentes utilizados no desenvolvimento do protótipo.
Componente Preço unitário
(euros)
Quantidade
utilizada
Preço total
(euros)
Módulo Arduino Mega (clone) 8 1 8
LCD 20x4 4.7 1 4.7
Módulo Wi-Fi (ESP-01) 2.5 1 2.5
Módulo Bluetooth (HC-06) 3.55 1 3.55
Módulo GSM (SIM900 + placa base) 20 1 20
Conversor 5V -3.3V 0.95 1 0.95
Motor 28BYJ-48 1.50 1 1.50
Optocouplador 0.25 1 0.25
Teclado 4X4 0.75 1 0.75
Módulo RTC + memória EEPROM 0.90 1 0.90
Conversor I2C para LCD 0.80 1 0,80
ULN2803A 0.15 2 0.30
Placa perfurada 0.40 1 0.40
Bateria do RTC 0.15 1 0.15
IRF9Z24N (MOSFET) 0.30 3 0.90
LM2940 (regulador 5V) 1 0.35 0.35
LD1117 (regulador 3.3V) 1 0.35 0.35
Buzzer 0.15 1 0.15
MCP41010 0.65 1 0.65
Bateria 6V 6.25 1 6.25
Transformador 9V 3.65 1 3.65
Outros materiais* 1.5 - 1.5
Total - - 58.55
*Inclui os custos aproximados dos componentes genéricos utilizados, como condensadores, díodos e
resistências, bem como os pinos, as fichas e os conectores.
