U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
ROBERTO V ITO RODRIGUES F ILHO
Um Simulador para Arquitetura de
Redes de Sensores do Corpo Humano
Baseado na Plataforma SHIMMER
Goiânia
2013
TERMO DE CIÊNCIA E DE AUTORIZAÇÃO PARA DISPONIBILIZAR AS TESES E
DISSERTAÇÕES ELETRÔNICAS (TEDE) NA BIBLIOTECA DIGITAL DA UFG
Na qualidade de titular dos direitos de autor, autorizo a Universidade Federal de Goiás
(UFG) a disponibilizar, gratuitamente, por meio da Biblioteca Digital de Teses e Dissertações
(BDTD/UFG), sem ressarcimento dos direitos autorais, de acordo com a Lei nº 9610/98, o documento conforme permissões assinaladas abaixo, para fins de leitura, impressão e/ou download, a título de divulgação da produção científica brasileira, a partir desta data.
1. Identificação do material bibliográfico:
2. Identificação da Tese ou Dissertação
Autor (a):
E-mail:
Seu e-mail pode ser disponibilizado na página?
Vínculo empregatício do autor
Agência de fomento:
País:
Título:
[ ] Dissertação
[ ]Sim
[ ] Tese
[ ] Não
Sigla:
UF:
CNPJ:
Palavras-chave:
Título em outra língua:
Palavras-chave em outra língua:
Área de concentração:
Data defesa: (dd/mm/aaaa)
Programa de Pós-Graduação:
Orientador (a):
E-mail:
Co-orientador
(a):*
E-mail:
*Necessita do CPF quando não constar no SisPG
3. Informações de acesso ao documento:
Concorda com a liberação total do documento [
] SIM
[
] NÃO1
Havendo concordância com a disponibilização eletrônica, torna-se imprescindível o envio do(s) arquivo(s) em formato digital PDF ou DOC da tese ou dissertação.
O sistema da Biblioteca Digital de Teses e Dissertações garante aos autores, que os arquivos contendo eletronicamente as teses e ou dissertações, antes de sua disponibilização,
receberão procedimentos de segurança, criptografia (para não permitir cópia e extração de
conteúdo, permitindo apenas impressão fraca) usando o padrão do Acrobat.
________________________________________
Assinatura do (a) autor (a)
1
Data: ____ / ____ / _____
Neste caso o documento será embargado por até um ano a partir da data de defesa. A extensão deste prazo suscita
justificativa junto à coordenação do curso. Os dados do documento não serão disponibilizados durante o período de
embargo.
ROBERTO V ITO RODRIGUES F ILHO
Um Simulador para Arquitetura de
Redes de Sensores do Corpo Humano
Baseado na Plataforma SHIMMER
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás.
Área de concentração: Redes e Sistemas Distribuídos.
Orientador: Prof. Dr. Iwens Gervásio Sene Júnior
Co-Orientador: Prof. Dr. Renato de Freitas Bulcão Neto
Goiânia
2013
Dados Internacionais de Catalogação na Publicação (CIP)
GPT/BC/UFG
Rodrigues Filho, Roberto Vito.
R696s
Um Simulador para Arquitetura de Redes de Sensores do
Corpo Humano Baseado na Plataforma SHIMMER
[manuscrito] / Roberto Vito Rodrigues Filho. - 2013.
99 f. : il., figs., tabs.
Orientador: Prof. Dr. Iwens Gervásio Sene Júnior; Coorientador: Prof. Dr. Renato de Freitas Bulcão Neto.
Dissertação (Mestrado) – Universidade Federal de Goiás,
Instituto de Informática, 2013.
Bibliografia.
Inclui lista de figuras, abreviaturas, siglas e tabelas.
Apêndices.
1. Redes de sensores sem fio – Saúde. 2. Redes de
sensores do corpo humano – Aplicações médicas. I. Título.
CDU: 004.383.4:004.72
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho sem autorização da universidade, do autor e do orientador(a).
Roberto Vito Rodrigues Filho
Possui graduação em Ciência da Computação pela Universidade Federal de
Goiás (2010). Tem experiência na área de Ciência da Computação, com ênfase
em Redes e Sistemas Distribuídos, atuando principalmente no seguinte tema:
Redes de Sensores Sem Fio.
Dedico este trabalho à minha família, em especial à minha esposa, Débora e aos
meus pais, Carmen e Roberto e irmão, Gustavo. Sem o suporte, a força e o carinho de
vocês a realização deste trabalho não seria possível, vocês são a base do meu caráter,
educação e crescimento.
Agradecimentos
Em primeiro lugar agradeço à Deus pela vida e pela força em todos os momentos
que precisei. Agradeço à minha família; meus pais Carmen Célia e Roberto Vito, meu
irmão, Gustavo Vito, avós, tios e primos pelo apoio e torcida. Agradeço também minha
esposa Débora, pelo carinho, amor e apoio incondicional em todos os momentos.
Agradeço aos meus colegas Taciano Messias, Marcos Roriz, Mariana Soller,
Leandro Alexandre, André Coimbra, Mário Teixeira, Rommell Caixeta, Diógenes José
e todos os outros companheiros dessa jornada que lutaram ao meu lado para a obtenção
de mais essa vitória.
Agradeço ao meu orientador Prof. Dr. Iwens Gervásio Sene Júnior e ao meu
co-orientador, o Prof. Dr. Renato de Freitas Bulcão Neto, pelos conselhos, orientações e
paciência. Agradeço os demais professores do grupo de pesquisa, pela imensa contribuição para o trabalho através das críticas construtivas e sugestões.
Agradeço à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior e à
Fundação de Amparo à Pesquisa do Estado de Goiás, pelo apoio financeiro, sem o qual
esse trabalho não seria possível.
Por fim, agradeço em especial à minha avó Alice, pelas orações e carinho,
sempre.
“Verdade é que, se todos os gostos fossem iguais, o que seria do amarelo?”
Machado de Assis,
O Alienista.
Resumo
Rodrigues Filho, Roberto Vito. Um Simulador para Arquitetura de Redes de
Sensores do Corpo Humano Baseado na Plataforma SHIMMER. Goiânia,
2013. 99p. Dissertação de Mestrado. Instituto de Informática, Universidade
Federal de Goiás.
As Redes de Sensores do Corpo Humano (RSCH) são uma tecnologia utilizada para o
fornecimento de sinais vitais de um indivíduo para sistemas pervasivos. Esses sistemas
aplicados à área da saúde utilizam as RSCH para o monitoramento de sinais vitais de um
paciente de forma remota, sem que o mesmo tenha que estar em um ambiente hospitalar.
Essa tecnologia usada como base dessas aplicações, auxiliam os profissionais da saúde
no monitoramento de pacientes à distância, ajudando a resolver problemas na prestação
de serviço de saúde. Um desses problemas é a lotação dos centros de atendimento. A
utilização das RSCH, por condicionar o monitoramento remoto, colabora na redução da
necessidade constante da ida do paciente aos hospitais, contribuindo assim com a redução
da lotação nesses ambientes. Com o potencial dessa tecnologia surge a necessidade de
desenvolver aplicações de qualidade. Entretanto, considerando uma análise dos projetos
de RSCH aplicados à área da saúde, nota-se a realização de testes em ambientes e
plataformas de hardware inadequados. Dessa forma, visando facilitar o desenvolvimento
de aplicações nesta área, é proposto um simulador específico para RSCH aplicadas à área
da saúde. Assim, o objetivo deste trabalho é mostrar esse simulador de aplicações através
da utilização de uma plataforma simulada de hardware, a qual leva em consideração as
demandas da área médica, para prover um ambiente de testes.
Palavras–chave
Redes de Sensores Sem Fio, Redes de Sensores do Corpo Humano, Saúde,
Aplicações Médicas
Abstract
Rodrigues Filho, Roberto Vito. A Simulator for Body Sensor Network Architecture Based on SHIMMER Platform. Goiânia, 2013. 99p. MSc. Dissertation.
Instituto de Informática, Universidade Federal de Goiás.
Body Sensor Networks (BSN) are a technology used to supply individual’s vital signs
to ubiquitous and pervasive systems. This systems applied to the healthcare area uses
BSN to monitor patient’s vital signs remotely, that is without them being in a hospital
environment. This technology applied as a base to this application assists healthcare
professional to remotely monitor patients, which contribute to solve healthcare services
problems. One of those problems is the crowded treatments centers. The usage of BSN,
by conditioning remote monitoring, can colaborate to reduce the patients’ needs to
consistently go to hospitals, thus contributing to reduce the number of patients in those
environments. Given this tecnology potential comes the need to develop good quality
applications. However, considering an analysis of BSN projects applied to the healthcare
field, the usage of inadequated hardware platforms are noticed. Therefore aiming to
make the development of this type of applications easier, it is proposed a simulator
specific for BSN applied to the healthcare field. Hence, this work’s goal is to show this
application simulator through the usage of a simulated hardware platform which takes
into consideration health care demands to provide a test environment.
Keywords
Wireless Sensor Networks, Body Sensor Networks, Healthcare, Medical Applications
Sumário
Lista de Figuras
11
Lista de Tabelas
12
Lista de Algoritmos
13
Lista de Códigos de Programas
14
1
15
19
22
23
23
25
Introdução
1.1
1.2
1.3
1.4
1.5
2
Redes de Sensores do Corpo Humano
2.1
2.2
2.3
3
Motivação
Objetivo
Metodologia
Contribuições
Estrutura da Dissertação
Projetos
2.1.1
CodeBlue
2.1.2
ALARM-NET
2.1.3
AID-N
Plataformas de Hardware
2.2.1
Plataformas Comerciais
2.2.2
Plataformas Acadêmicas
Simuladores
2.3.1
Network Simulator (NS)
2.3.2
TOSSIM
2.3.3
AVRORA
2.3.4
WSim e WSNet
2.3.5
MSPSim e COOJA
Plataforma de Hardware SHIMMER
3.1
3.2
3.3
Descrição da Plataforma
Componentes de Hardware
3.2.1
Microcontrolador
3.2.2
Padrões de Comunicação
3.2.3
Sensores
Software da Plataforma
3.3.1
Ferramentas de Desenvolvimento de Software
3.3.2
TinyOS para SHIMMER
26
26
26
27
28
29
30
32
34
34
35
35
36
36
38
38
40
42
44
45
46
46
47
4
Plataforma de Simulação MSPSim
4.1
4.2
Descrição da Plataforma
Componentes
4.2.1
Componentes Gráficos de Interação
Monitor da Pilha de Execução
Ciclo de Trabalho
Porta USART1
Painel de Controle de Simulação
Representação Gráfica do Nodo Sensor
Terminal de Comando do MSPSim
4.2.2
5
Um Simulador para Redes de Sensores do Corpo Humano
5.1
5.2
5.3
5.4
5.5
6
Componentes Internos da Plataforma
Visão Geral
Funcionalidades
Arquitetura
Implementação
5.4.1
LEDs
5.4.2
Rádio (CC2420)
5.4.3
Sensor Eletrocardiograma (ECG)
Testes da Plataforma
Considerações Finais
6.1
6.2
Trabalhos Futuros
Publicações
6.2.1
Publicações em Jornais Científicos Internacionais
6.2.2
Apresentação de Trabalho em Congresso
6.2.3
Apresentação de Minicursos
51
51
55
55
56
57
57
58
60
61
61
67
67
69
70
72
73
76
82
84
86
87
87
87
88
88
Referências Bibliográficas
89
A
Conjunto de Instruções MSP430
94
B
Código Eletrocardiograma SHIMMER - TinyOS
96
Lista de Figuras
1.1
1.2
1.3
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.1
RSSF auxiliando profissionais da saúde a prestar socorro no local do
acidente [30]
Redes de Sensores do Corpo Humano [11]
Arquitetura Básica de RSCH Destacando o Simulador
17
18
22
Sensores da área da saúde adaptados para as plataformas MicaZ, Mica2
e Telos [18]
Ilustração de um cenário de uso do ALARM-NET [1]
Ilustração do Projeto AID-N [17]
Nodo sensor SHIMMER
Nodo sensor TelosB [35]
Arduino Lilypad [15]
A Real-Time Wireless Physiological Monitoring System (RTWPMS) [7]
27
28
29
31
31
33
34
3.3
3.4
3.5
Ilustração da Plataforma SHIMMER com Sensor de Resistência Galvânica da Pele
Análise de Movimento do Corpo Utilizando a Plataforma SHIMMER BioMOBIUS [39]
Componentes de Hardware [40]
Arquitetura do Microcontrolador MSP430F1611 [41]
Placa Base à Esquerda e Placa Filha à Direita (ECG)
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
SHIMMER implementado no MSPSim
Mostra o gráfico de utilização da pilha de execução
Gráfico mostrando o ciclo de trabalho
Porta USART1
Painel de Controle de Simulação
Representação Gráfica do Nodo Sensor
Terminal de Comando do MSPSim
Visão Geral da Arquitetura da Plataforma MSPSim
54
56
57
58
59
60
61
62
5.1
5.2
5.3
5.4
Arquitetura da Plataforma de Hardware SHIMMER no MSPSim
Principais classes da solução ligadas ao simulador
Eletrocardiograma na Plataforma SHIMMER
Pontas do ECG
70
71
82
84
A.1
A.2
A.3
Conjunto de Instrução - Um único operador - MSP430 [41]
Conjunto de Instrução - Condicionais - MSP430 [41]
Conjunto de Instrução - Dois operadores - MSP430 [41]
94
94
95
3.2
39
40
41
42
45
Lista de Tabelas
1.1
3.1
3.2
3.3
Lista das Características das Aplicações Demandadas pela Área da
Saúde [4]
20
Instruções Aritméticas de um Único Operador
Instruções de Desvio Condicional
Instruções Aritméticas de Dois Operadores
43
43
44
Lista de Algoritmos
4.1
Laço de Execução de Instruções no Simulador MSPSim
63
Lista de Códigos de Programas
3.1
3.2
4.1
4.2
4.3
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
B.1
B.2
B.3
B.4
Código de Exemplo do TinyOS - Configuração Blink
Código de Exemplo do TinyOS - Módulo Blink
Código do currentSegment da classe MSP430Core
Método setup() do MSP430f1611
Interfaces PortListener e UsartListener
Configuração e Conexão do LED com sua Respectiva Porta - SHIMMER
Método portWrite() na Simulação dos LEDs - SHIMMER
Como o StateListener é Usado para Repintar a Interface Gráfica do
Simulador - SHIMMER
Configuração e Conexão do Rádio com suas Respectivas Portas - SHIMMER
Método portWrite() na Simulação dos LEDs - SHIMMER
Método setVRegOn do dispositivo CC2420 - SHIMMER
Método dataReceive da Classe CC2420 - SHIMMER
Método setCCA da Classe CC2420 - SHIMMER
Método setFIFO da Classe CC2420 - SHIMMER
Método setFIFOP da Classe CC2420 - SHIMMER
Método setSFD da Classe CC2420 - SHIMMER
Método setupNode() do ECG - SHIMMER
Código do TinyOS para Controle do ECG do SHIMMER (BOOT) - Módulo
Código do TinyOS para Controle do ECG do SHIMMER (START SENSING) - Módulo
Código do TinyOS para Controle do ECG do SHIMMER (SENSING) Módulo
Código do TinyOS para Controle do ECG do SHIMMER - Configuração
49
49
64
65
66
73
74
75
76
77
78
79
80
80
81
81
83
96
97
98
99
CAPÍTULO 1
Introdução
Pessoas que procuram serviços hospitalares muitas vezes encontram problemas
como lotação, alto custo de internação, riscos de infecção hospitalares, dificuldade de
deslocamento para unidade de tratamento, falta de certos especialistas em alguns centro
de antendimento, dentre outros problemas que afetam a prestação de serviço de saúde. Um
dos motivos desses problemas se encontra no aumento demográfico aliado às deficiências
da própria infraestrutura de prestação de serviço de saúde.
Historicamente, por outro lado, de acordo com [19], no Brasil, havia outro
tipo de paradigma de prestação de serviço. As pessoas recebiam atendimento em suas
residências por médicos de família, e somente casos extremos, que exigiam a utilização
de equipamentos especializados, eram levados para receberem tratamento em hospitais.
Essa inversão do paradigma, no qual o paciente é tratado como indivíduo fora
do ambiente hospitalar aplicado no cenário atual, reduziria a sobrecarga da demanda de
atendimento nos hospitais, o que resultaria em um ganho substancial na qualidade de
serviço nos centros de atendimento, além de levar também a uma diminuição dos riscos
de infecção hospitalar, problemas no deslocamento de pacientes idosos para unidades de
tratamento, dentre outros.
Desta forma, para apoiar o tratamento de indivíduos fora do ambiente hospitalar,
a infraestrutura de prestação de serviço de saúde pode contar com algumas tecnologias.
Dentre elas, as que proporcionam o acompanhamento dos dados vitais do paciente de
forma remota, tornando possível assim, o acompanhamento dos sinais vitais do paciente
sem que este esteja em um hospital.
Atrelado a esse cenário, algumas situações mais específicas merecem destaque.
De acordo com a Organização Mundial de Saúde (OMS), entre os anos de 1950 e 2025,
haverá um aumento na população de idosos que nos colocará na sexta posição de países
com a maior população de idosos do mundo [20].
No caso do idoso, o provimento de uma infraestrutura de atendimento e cuidados
desses indivíduos em casas de repouso ou em suas próprias residências é de suma
importância. O monitoramento remoto de idosos os proporcionam mais independência e
autonomia, e ao mesmo tempo provê uma estrutura de monitoramento contínua, fazendo-
16
se necessário o deslocamento desse indivíduo a um centro de atendimento hospitalar
somente em casos de emergência.
Além da preocupação com envelhecimento da população, uma das prioridades
na área da saúde são as Doenças Crônicas Não Transmissíveis (DCNT) que foram
responsáveis por 72% das mortes ocorridas em 2007 [21]. Também de acordo com
os autores, devido às políticas bem-sucedidas de saúde que diminuiram o tabagismo e
aumentaram o acesso à atenção básica de saúde, a incidência de doenças cardiovasculares
e respiratórias crônicas estão diminuindo, mas houve um aumento de doenças como
hipertensão e diabetes dada a falta de exercício físico e uma alimentação não balanceada.
Desta forma, nota-se que as DCNTs requerem um acompanhamento periódico
de todos os indivíduos, sendo ele portador ou não de uma dessas doenças, sendo os
não-portadores como medida de prevenção. Assim, contar com uma infraestrutura de
monitoramento remoto que reduza a constante necessidade dos indivíduos realizarem
visitas ao hospital é desejável.
Toda essa situação aumenta a demanda de uma infraestrutura de serviços que leva
a área da saúde procurar o auxílio da tecnologia, com o objetivo de solucionar desafios
como o monitoramento remoto de pacientes, que auxiliaria nos problemas citados, e
também em diagnósticos e prevenção de doenças, no acompanhamento de pacientes
idosos em casa de repouso (ou mesmo em suas próprias residências), no auxílio dos
profissionais de saúde na prestação de socorro a vítimas no local de acidente, dentre
outros.
Através das Redes de Sensores do Corpo Humano (RSCH), termo traduzido do
inglês Body Sensor Networks (BSN), os profissionais da saúde podem usufruir da tecnologia de forma a auxiliá-los no monitoramento remoto dos sinais vitais dos pacientes.
Essa tecnologia pode ser vista como uma área de aplicação das Redes de
Sensores Sem Fio (RSSF), do inglês Wireless Sensor Networks (WSN). As RSSF são
redes formadas por nodos sensores que consistem em uma plataforma composta por uma
unidade de processamento, memória, sensores e/ou atuadores e um transceptor (para envio
e recebimento de dados). As RSSF têm ampla aplicação em diversas áreas, e podem ser
usadas para:
•
•
•
•
Monitorar pássaros selvagens em ilhas remotas [22];
Auxiliar bombeiros a apagar florestas em chamas [23];
Fazer alerta de enchentes [26];
Criação de casas inteligentes [27], e outros.
Em resumo, as RSSF podem ser utilizadas para monitorar e controlar ambientes
de difícil acesso ou hostis ao homem. Desta forma, essa tecnologia pode assistir profissionais de várias áreas em face a diversos problemas, uma dessas áreas é a coleta de sinais
17
vitais do corpo humano. A utilização de sensores para coleta de dados do corpo (ou em
relação ao corpo) recebe o nome de Redes de Sensores do Corpo Humano (RSCH), e
sua utilização vai desde o monitoramento de atletas na práticas de esporte a aplicações
militares, como por exemplo:
• Auxiliar a coordenar times de bombeiros vestidos com sensores informando-os, por
exemplo, sobre o nível de toxidade do ambiente em que se encontra [28];
• Auxiliar praticantes de golfe, vestidos com sensores, a melhorar suas tacadas [29];
• Auxiliar profissionais da área da saúde a prestar socorro a vítimas no local do
acidente [30] (vide Figura 1.1), e outros.
Figura 1.1: RSSF auxiliando profissionais da saúde a prestar socorro no local do acidente [30]
As RSCH são utilizadas em diversos domínios de aplicações, como citados
anteriormente, dentre essas áreas de aplicações está a área da saúde. Com a utilização
das RSCH na área da saúde é possível coletar dados de um paciente, acoplando nodos
sensores em seu corpo, mesmo estando em sua residência, ou no local de um acidente, ou
em uma casa de repouso e enviar esses dados para um servidor que poderá armazená-los,
processá-los e disponibilizá-los para o auxílio dos profissionais de saúde.
O histórico de dados de um paciente é importante para aplicações da área da
saúde, pois permite o acesso rápido de suas informações. Para ilustrar, considere um
paciente que tenha seus dados e sinais monitorados e armazenados em um servidor, caso
aconteça um acidente com o paciente e ele estando apenas com seus documentos de
identificação é possível acessar seu histórico e verificar problemas, como por exemplo,
se o paciente é alérgico a algum medicamento, além de seu histórico familiar de doenças,
18
seu histórico de batimentos cardíaco, e até mesmo a notificação do ocorrido a família e
o médico que o acompanha. É importante que esses dados devam ser guardados com a
segurança e o controle de acesso adequados, esse cenário foi descrito de forma a ilustrar
as funcionalidades de uma possível aplicação da tecnologia.
Figura 1.2: Redes de Sensores do Corpo Humano [11]
No exemplo anterior mostra-se o quão útil pode ser o armazenamento e a
disponibilidade dos sinais vitais de uma pessoa, principalmente em situações de acidentes.
Entretanto, não detalha a utilização das RSCH em si.
Aproveitando o exemplo do acidente, podemos imaginar a utilização de pequenos nodos sensores (leves e vestíveis) usados por um paciente equipados com sensores
como o eletrocardiograma (ECG) para coleta dos sinais elétricos do coração, um sensor
para coleta da pressão sanguínea e um oxímetro de pulso, que mede o nível de oxigênio
absorvido pelo sangue, dentre outros sensores, formando uma RSCH como ilustrado na
Figura 1.2.
Desta forma, é possível o profissional de saúde acompanhar os sinais vitais do
paciente em tempo real, e com base nestes, proporcionar tratamento adequado. Além
disso, é possível também realizar triagem do paciente de forma a encaminhá-lo da melhor
1.1 Motivação
19
maneira ao hospital e seção hospitalar mais adequada dado a identificação do trauma
sofrido pelo paciente, pela leitura de seus sinais no local do acidente.
Portanto, a utilização das RSCH na área da saúde, usadas na coleta de sinais
vitais do corpo humano e monitoração remota de pacientes, é uma importante tecnologia
que pode ser usada para prover serviços que atualmente é demandado na área da saúde.
1.1
Motivação
Na literatura há vários projetos que propõem a utilização das RSCH para o
monitoramento remoto de pacientes nas diversas situações, como para: diagnosticar,
previnir e tratar doenças, com pacientes dentro e fora do ambiente hospitalar [31, 32, 33].
Essa tecnologia é usada para prover diversos serviços no âmbito da saúde. Porém, um
estudo dos artigos que descrevem alguns desses projetos mostra que a construção de
suas soluções não levam em consideração características importantes da área da saúde,
principalmente em relação as plataforma de hardware e do ambiente de teste [14].
O desenvolvimento de aplicações de RSCH na área da saúde demanda uma série
de restrições de software e de hardware, como por exemplo, os nodos sensores que serão
colocados em contato com o corpo devem ser leves, sem fio (ou com o mínimo de fios),
pequenos, fáceis de lavar e esterializar, não devem restringir a movimentação do paciente,
incomodá-lo ou causar irritação ou infecções a pele.
Da mesma forma, a aplicação que roda no nodo deve contemplar alguns aspectos,
como tolerância a falhas, escalabilidade, alta disponibilidade, alta acurácia dos valores
coletados, segurança e privacidade dos sinais coletados do paciente. Esses aspectos são
tratados em aplicações de RSSF de propósito geral discutidos em trabalhos como [34],
mas que se agravam na área da saúde, por conta da a criticidade do desenvolvimento de
aplicações da área.
As restrições de hardware acabam por influenciar no software. O hardware
adequado para a área da saúde, como dito anteriormente, deve possuir uma série de
restrição nas suas características físicas. Como exemplo, levemos em consideração os
impactos no software causados pelo tamanho do nodo sensor. O fator que determina o
tamanho do nodo e consequentemente sua leveza é sua bateria, que quanto maior for,
mais energia é armazenada e consequentemente maior o tamanho do nodo. Como em
aplicações na área da saúde queremos o menor tamanho possível para o nodo sensor,
logo, menos capacidade energética ele possuirá e consequentemente a implementação
do algoritmo de determinadas funções da aplicação devem ser desenvolvidas visando o
menor gasto energético, para resultar em um maior tempo de vida da rede.
Todas essas restrições, sejam de hardware, software e do próprio ambiente influenciam diretamente no funcionamento da aplicação, e se não forem levados em conside-
1.1 Motivação
20
Tabela 1.1: Lista das Características das Aplicações Demandadas
pela Área da Saúde [4]
Características
Descrição
Vestíveis (1)
O sistema deve ser leve e pequeno.
Apropriadamente colocado no corpo (2)
O sistema deve ser discreto e comfortável, para não interferir nos
movimentos do usuário e atividades diárias.
Questões Estéticas (3)
O sistema não deve afetar severamente a aparencia do usuário.
Criptografia
e
segurança dos dados
(4)
Transmissão criptografada dos sinais medidos e o requerimento
de autenticação para acessar os dados privados.
Tempo de vida operacional (5)
Consumo mínimo de energia a longo prazo, monitoramento da
saúde com o mínimo de manutenção.
Aplicação real (6)
O sistema desenvolvido é aplicável (e útil) para cenário e condições de saúde da vida real.
Aplicação em tempo
real (7)
O sistema vestível produz resultados, por exemplo, mostra as
medidas, alertas, diagnosticos, etc, em tempo-real.
Requisitos computacionais e armazenamento
(8)
A computação e o armazenamento requisitado ou utilizado pelo
sistema para alcançar os resultados desejados.
Facilidade de uso (9)
O sistema incorpora uma interface com o usuário amigável, fácil
de usar e de aprender.
Performance e teste em
casos reais (10)
Resultados suficientes e estatísticas de desempenho são providas
para verificar as funcinoalidades em casos reais.
Confiabilidade (11)
O sistema produz resultados confiáveis e precisos.
Custo (12)
A quantia em dinheiro requerida para produzir ou adquirir o
sistema vestível proposto.
Robustez em caso de
interferência (13)
Disponibilidade e confiabilidade na transmissão dos dados fisiológicos.
Tolerância a falha (14)
O sistema produz resultados confiáveis sob qualquer circunstância, mesmo com diversos movimentos do paciente.
Escalabilidade (15)
Potencial de atualização, melhorando e facilmente incorporando
componentes adicionais para o desenvolvimento do sistema.
Suporte a decisão (16)
O sistema implementado inclui algum tipo de diagnóstico/mecanismo de decisão ou um algoritmo/padrão de reconhecimento para sensoriamento de parâmentros sensíveis ao contexto.
ração ou testados apropriadamente comprometem sua funcionalidade ao ser utilizado em
um ambiente real.
A aplicabilidade de um projeto de RSCH em um ambiente real, ou seja, no ambiente em que de fato seria utilizado, com todas as interferências naturais de comunicação
1.1 Motivação
21
daquele meio, determina o nível de maturidade do projeto. O nível de maturidade de um
projeto consiste na relação entre suas características e sua capacidade de ser de fato utilizado em um ambiente real de produção.
Sendo assim, foi estabelecido uma escala de maturidade que está diretamente
atrelada a utilização do projeto em um ambiente real, de forma que quanto mais aspectos
da área da saúde for considerado no projeto mais apto ele estará para funcionar em um
ambiente de produção, e consequentemente maior é seu nível de maturidade.
Desta forma, foram levantadas algumas características (vistas na Tabela 1.1),
estas contidas em [4], as quais os projetos de RSCH aplicados na área da saúde deveriam
contemplar. De posse dessa lista de características foi levantado uma lista dos projetos
mais relevantes da área e foi verificado se os projetos contemplavam tais características.
Como resultado, chega-se a conclusão de que os projetos, ao testar suas aplicações, o
fazem em ambientes de testes inadequados em cima de plataforma de hardware também
inadequadas, de forma a não validar corretamente as características levantadas de forma
coerente, levando-os a uma média baixa no nível de maturidade por não contemplar
inteiramente as características necessárias, conforme descrito em [14].
Levou-se em consideração que um projeto para ter sua solução validada precisa
desenvolvê-la de acordo com tais características, pois se não levar em consideração, por
exemplo, as características de hardware específicas da área de saúde, a solução não irá
funcionar em um ambiente real por falta de memória, recursos energéticos (limitação do
hardware) ou falha na comunicação de seus nodos sensores por interferência do próprio
ambiente, causada por exemplo, por uma parede de chumbo em um hospital (adversidades
característica do ambiente), que não foram considerados.
É importante ressaltar que há projetos de RSCH na literatura que propõem
plataformas de hardware adequadas para área da saúde [24]. Porém, muitas delas não
são acessíveis comercialmente, o que acaba voltando ao problema de teste de aplicações
em plataformas de hardware não adequadas, por não se ter acesso fácil a esse tipo de
plataforma. Com o objetivo de propor uma plataforma de hardware acessível, projetos
como CodeBlue [18], propõem plataformas de hardware como o Pluto [25], específicas
para RSCH baseadas em plataformas de hardware de RSSF de propósito geral, e assim
surge plataformas de hardawre comerciais como o SHIMMER [3].
Porém, mesmo com plataformas de hardware específicas para área da saúde,
ainda assim os ambientes de teste são inadequados. As plataformas de hardware para
RSSF e RSCH não fornecem um ambiente próprio de teste de aplicações. O desenvolvimento de software para RSSF de propósito geral é uma tarefa difícil, pesada e que consome bastante tempo. Isso se dá devido às limitações de recurso das plataformas de hardware, e ferramentas limitadas de depuração de código. Na área de RSCH, especificamente
aplicadas à área da saúde, esse cenário se agrava, principalmente devido à criticidade das
1.2 Objetivo
22
aplicações da área da saúde.
Dado esse contexto, o presente trabalho identifica uma carência de ferramentas
que fornecem um ambiente de teste de aplicações, utilizando plataformas de hardware
adequada, para o auxílio do desenvolvimento de aplicações de RSCH específicas para a
área da saúde.
1.2
Objetivo
Considerando o baixo nível de maturidade dos projetos de RSCH aplicados
à área da saúde, que apresentam resultados de testes em ambientes e plataformas de
hardware inadequados, e visando facilitar o desenvolvimento de aplicações nesta área,
é proposto um simulador específico para RSCH aplicadas à área da saúde, com o objetivo
de prover um ambiente de teste apropriado.
O simulador proposto é contextualizado na Figura 1.3. Nela é ilustrada uma arquitetura básica de uma aplicação de RSCH para o monitoramento de pacientes remotos.
O primeiro nível, representado na figura pelo 1, abrange somente a troca de dados entre
os nodos sensores que compõem a rede. O segundo nível, por sua vez, ilustra a comunicação da rede de sensores com um dispositivo móvel (tablets, smartphones, palm top, etc.),
também chamado Servidor Pessoal, do inglês Personal Server. Os servidores pessoais fazem parte também do terceiro nível de comunicação, pois são responsáveis por enviar os
dados através da Internet (em caso do paciente estar sendo monitorado remotamente) para
um servidor que irá processá-los e armazená-los de acordo com o objetivo da aplicação.
Figura 1.3: Arquitetura Básica de RSCH Destacando o Simulador
Desta forma, dado o contexto da Figura 1.3, este trabalho tem por objetivo
implementar a simulação do primeiro nível, ou seja, somente a simulação da arquitetura
dos nodos sensores em um corpo humano, mais especificamente apenas a parte do
simulador que emula o comportamento da plataforma de hardware (parte hachurada da
imagem).
1.3 Metodologia
23
Uma das características fundamentais do simulador é sua capacidade de simular
uma plataforma de hardware específica da área da saúde, por isso a marcação do simulador
de hardware na figura. Como objetivos específicos tem-se a implementação de uma
ferramenta de depuração do software para sensores da área da saúde, de forma a prover
uma alternativa menos limitada de depuração de código (em comparação as JTAGS),
auxiliando o desenvolvimento de aplicações para área. Sendo assim, o simulador deve ser
capaz de:
•
•
•
•
1.3
simular troca de dados entre nodos sensores;
simular dados de sensoriamento da área da saúde;
simular aplicações escritas em qualquer linguagem; e
depurar o código sendo executado em um sensor, estando este trocando mensagens
em uma rede;
Metodologia
Com o intuito de atingir os objetivos estabelecidos, a seguinte metodologia de
pesquisa foi adotada:
• Revisão do estado da arte dos projetos de RSCH aplicadas à área da saúde, o qual
levou à identificação da carência de ferramentas que auxiliem o desenvolvimento
para aplicações específicadas de RSCH voltadas para área médica;
• Estudo das principais plataformas de RSCH;
• Estudo das plataformas de simulação para área de RSCH e RSSF de propósito geral;
• Escolha da construção do simulador utilizando como base a plataforma de simulação MSPSim, uma plataforma de simulação conhecida para RSSF de propósito
geral, de forma a ter uma maior exposição da solução e torná-la mais acessível;
• Estudo da plataforma SHIMMER, escolhida por ser uma plataforma comercial
específica para área da saúde;
• Estudo da plataforma de simulação MSPSim;
• Construção da plataforma SHIMMER no simulador MSPSim;
• Teste do simulador construído comparando seu comportamento com o comportamento esperado da plataforma real SHIMMER.
1.4
Contribuições
Uma das contribuições deste trabalho é a própria implementação do nodo sensor
SHIMMER utilizando como base a plataforma de simulação MSPSim. Esse trabalho é
um primeiro passo para a implementação de um ambiente de simulação específico para
1.4 Contribuições
24
RSCH aplicadas à área da saúde, sendo ele integrado com tecnologias de código aberto
vastamente utilizadas para o desenvolvimento de aplicação de RSSF de propósito geral.
Desta forma, vê-se necessário a separação dos benefícios obtidos da implementação do próprio nodo sensor SHIMMER, para área da saúde, assim como as contribuições
obtidas da utilização do ambiente MSPSim.
A implementação de um simulador do nodo sensor SHIMMER, como uma
ferramenta que auxilia o desenvolvimento de aplicações de RSCH na área da saúde, traz
as seguintes contribuições:
• Uma ferramenta que possibilita o desenvolvimento de aplicação de RSCH específico para área da saúde, independente de se ter o nodo sensor real;
• O provimento de um ambiente que permite a depuração de código, dado a criticidade das aplicações da área da saúde e a dificuldade de verificar código em plataformas de hardware físicas, como o próprio SHIMMER;
• Um simulador capaz de ser integrado com ferramentas de simulação de código
aberto que estão sendo vastamente utilizadas, como o MSPSim e o COOJA1 .
Contribuições para área da saúde por utilizar uma plataforma de simulação
MSPSim como base da implementação do nodo sensor SHIMMER:
• Um ambiente de simulação não atrelado à tecnologia, sendo possível o desenvolvimento de aplicações utilizando qualquer sistema operacional e linguagem, importando somente o código executável compatível com o conjunto de instruções do
microcontrolador;
• Um ambiente que provê uma interface de verificação da aplicação de RSCH, provendo mecanismos de depuração do código, ciclo de trabalho do nodo sensor, sendo
possível verificar através de gráficos a utlização em termos de porcentagem o uso
do microcontrolador e dos dispositivos de nodo sensor como o rádio (transmissão e
recebimento), LEDs, etc.
• Facilidade de integração com o COOJA de forma a poder simular o comportamento
de uma rede de sensores completa, definindo topologias, rotas de comunicação, etc.
A utilização do MSPSim, como base de um ambiente de simulação, permite a
criação de outras plataformas de hardware para área da saúde, tornando-as disponíveis
para o teste de aplicações escritas específicamente para a plataforma em questão. Ao
utilizar o MSPSim, é possível também, utilizar os dispositivos já implementados além de
1 COOJA
é uma plataforma de simulação de RSSF capaz de simular redes de sensores compostas por
diversos tipos de sensores, estes implementados a partir da plataforma de simulação MSPSim. Ambas as
plataformas serão descritas em mais detalhes no Capítulo 4.
1.5 Estrutura da Dissertação
25
implementar novos, que possam ser utilizados para criar um novo tipo de plataforma
de hardware, e testar aplicações escritas para elas antes de implementar o hardware
fisicamente.
Desta forma mostra-se a flexibilidade do ambiente de simulação do MSPSim,
que provê uma base para a construção de diversos tipos de plataformas de hardware.
1.5
Estrutura da Dissertação
Este trabalho está dividido em seis capítulos. Sendo o Capítulo 2 que descreve
o estado da arte das RSCH aplicadas à área da saúde, descrevendo projetos importantes
da literatura, o estado da arte dos simuladores e trabalhos relacionados. O Capítulo 3
mostrando de forma detalhada a plataforma de hardware SHIMMER, seus componentes
de hardware e outros de software utilizados para compor soluções utilizando a plataforma.
O Capítulo 4 que descreve de forma detalhada o simulador MSPSim, escolhido para
ser base da construção do simulador de RSCH em questão. O Capítulo 5 que mostra
os detalhes de implementação da solução e descute o processo de teste do simulador
construído. E finalmente o Capítulo 6, que trás a conclusão deste trabalho e discute
propostas de trabalhos futuros.
CAPÍTULO 2
Redes de Sensores do Corpo Humano
O estado da arte dá a visão do que se tem de mais recente na área, desta forma,
este capítulo irá descrever desde os trabalhos mais importantes e recentes sobre RSCH
aplicados à área da saúde, assim como o ambiente em que esses projetos foram testados e
as plataformas de hardware mais utilizadas. Também serão descritos os simuladores mais
importantes e que estão relacionados ao objetivo do trabalho.
2.1
Projetos
Nesta seção estão descritos alguns dos principais projetos que utilizam as RSCH
aplicadas à área da saúde. Esses projetos utilizam sensores vestíveis aplicados à área da
saúde para o monitoramento remoto dos sinais vitais, triagem e auxílio dos profissionais
de saúde.
Esses projetos foram utilizados para a realização do estudo de maturiadade [14],
e de acordo com o mesmo foram os três projetos com maior nível de maturidade, ou seja,
que mais levou em consideração e/ou implementou as características essenciais para a
aplicação do projeto em um ambiente real.
2.1.1
CodeBlue
O CodeBlue foi desenvolvido pela Divisão de Engenharia e Ciências Aplicadas
da Universidade de Harvard, nesse projeto foi desenvolvido plataformas de software e
de hardware voltadas especificamente para a área da saúde, na tentativa de alinhar a
necessidade da área da saúde e as tecnologias já existentes nas RSSF.
A plataforma CodeBlue é composta pela plataforma de software e de hardware
que endereça os problemas da área médica, a plataforma de hardware foi construída com
base nas mais utilizadas plataformas o MicaZ, Mica2 e Telos, construindo sensores específicos para a área da saúde, tais como: ECG, oxímetro de pulso, pressão; compatíveis com
essas plataformas (ilustrados na Figura 2.1). Foi desenvolvido também uma plataforma de
hardware baseada nessas citadas, o chamado nodo sensor PLUTO.
2.1 Projetos
27
Figura 2.1: Sensores da área da saúde adaptados para as plataformas MicaZ, Mica2 e Telos [18]
O PLUTO foi criado por se ter notado que as plataformas já existentes em
RSSF não eram totalmente adequadas para serem vestidas no corpo humano. Notou-se
que as características físicas do nodo como tamanho, peso, presença de fios, lavável e
esterializável eram caracteríticas que os nodos sensores para área da saúde deveria conter.
Além da plataforma de hardware, é de extrema importância a plataforma de
software que facilita a implementação de algumas características essenciais para a área
da saúde. Essa plataforma de software, o CodeBlue framework, foi construída utilizando
do sistema operacional TinyOS, e provê protocolos para descoberta de dispositivos,
roteamento multi-salto no modelo “publish/subscribe”, e uma interface simples para que
os profissionais de saúde possam buscar dados de um ou um grupo de pacientes.
2.1.2
ALARM-NET
No domínio de aplicação da área da saúde, o monitoramento de pacientes idosos
em casa de repouso é um cenário comum, mesmo assim, há uma série de desafios
para serem endereçados e resolvidos. No trabalho [1] é apresentado uma RSCH para
assistência em tempo real e monitoramento residencial, o projeto ALARM-NET ilustrado
na Figura 2.2.
2.1 Projetos
28
Figura 2.2: Ilustração de um cenário de uso do ALARM-NET [1]
Os desafios que presentes no comum cenário de monitoramento de pacientes
em casa de respouso, no auxilio na prestação de assistência e no monitoramento de seu
progresso, são abordados no projeto ALARM-NET. A plataforma que dá suporte a essa
solução é composta por um mote MicaZ com sensor infra-vermelho, sensor de poeira,
temperatura, luminosidade, pulso e oxigenação sanguínea, a plataforma de software que
foi utilizada na solução foi o TinyOS.
2.1.3
AID-N
O projeto Advanced Health and Disaster Aid Network (AID-N) descrito em [17]
é outro projeto que aplica RSCH com o objetivo de prover auxílio aos profissionais da
área da saúde. O projeto utiliza as RSCH com o objetivo de alimentar a base dados da
aplicação e também para auxílio na triagem dos pacientes atendidos no local do acidente,
de forma a facilitar o encaminhamento da vítima ao hospital e alas hospitalares mais
adequadas.
2.2 Plataformas de Hardware
29
Figura 2.3: Ilustração do Projeto AID-N [17]
A Figura 2.3 ilustra a visão geral do projeto AID-N mostrando os níveis da
arquitetura de sua solução. Cada nível se comunica entre si através de padrões de
comunicação implementados pelos dispositivos envolvidos.
O primeiro nível trata da comunicação da RSCH entre si, os dispositivos que
compõem esse nível são os nodos sensores que são colocados no paciente e são responsáveis por enviar sinais para os Servidores Pessoais (Personal Servers, PS). Os servidores
pessoais fazem parte do segundo nível, eles são compostos por dispositivo como um celular ou um computador possuindo um nodo sensor sorvedouro atrelado a sua porta serial.
Em ambos os casos a RSCH comunicará com os dispositivos do segundo nível através do
padrão de comunicação IEEE 802.15.4, enviando as informações colhidas do paciente.
A medida que os dados são enviados para o segundo nível eles serão repassados
para o terceiro nível pelo padrão de comunicação IEEE 802.11. Esses dados então
são armazenados nos servidores que compõem o terceiro nível. Esse dados podem ser
requisitados pelos profissionais de saúde que possuem acesso aos dados do paciente para
auxílio na triagem e identificação do estado de saúde do paciente.
O projeto utiliza sensores de ECG, pressão sanguínea e oxímetro de pulso assim
como uma tag (ETag) de identificação para triagem, esses sinais são utilizados para o
monitoramento contínuo dos sinais vitais do paciente e para enviar informações do mesmo
para os profissionais de saúde que irão prestar os próximos socorros. Como parte da
solução é utilizado nodo sensores MicaZ ou TMoteSky que foram programados utilizando
o framework CodeBlue em cima do TinyOS.
2.2
Plataformas de Hardware
No decorrer da pesquisa foram identificados nos projetos de RSCH aplicados à
área da saúde duas categorias de hardware utilizados. As categorias se dividem basicamente em plataformas comerciais e plataformas específicas de projetos.
2.2 Plataformas de Hardware
30
Será apresentada cada categoria de forma específica, assim como projetos que
utilizam esse tipo de plataforma de hardware, além dos prós e contras.
2.2.1
Plataformas Comerciais
As plataformas de hardware comerciais, como o próprio nome já diz, são
plataformas disponíveis para comércio. Na área da saúde a plataforma comercial mais
referenciada é a plataforma SHIMMER.
A plataforma SHIMMER [3], ilustrado na Figura 2.4 1 , é licenciada pela
Intel Research e comercializada pela empresa Shimmer Research (http://www.
shimmer-research.com), e é composta por um microcontrolador MPS430, rádio
CC2420, uma bateria de Li-íon recarregável, possui também o dispositivo RN-46 para
troca de dados pelo padrão BlueTooth, GPS, e sensores para saúde incluindo eletrocardiograma (ECG), eletromiograma (EMG) e resistência galvânica da pele (GRS). Essa
plataforma de hardware vestível e específica da área da saúde é suportada pelo TinyOS,
além de ter software que mostra os dados coletados para plataforma Android.
O SHIMMER é uma plataforma específica para área da saúde com suas características e tipos de sensores vastamente utilizadas na área, além de ter o suporte de um dos
sistemas operacionais mais utilizados em RSSF, TinyOS, com isso a plataforma ganha,
além do suporte de um sistema operacional preparado para gerenciar memória, processos
e a pilha de comunicação do sensor, também um aparato de software como algoritmos
de roteamento, segurança e frameworks escritos pela comunidade do TinyOS. Um desses frameworks é o CodeBlue, também específico para área da saúde e desenvolvido pelo
Universidade de Harvard [18].
Há vários trabalhos na literatura que utilizam a plataforma de hardware SHIMMER como parte de sua solução, um deles [9] trata de uma aplicação que utiliza sensores
SHIMMER para acompanhar o status de pacientes com problemas neurais, e um outro
trabalho [16] que utiliza essa plataforma de hardware para monitorar pacientes com Parkinson. Mais detalhes da plataforma SHIMMER é descrita no Capítulo 3.
1 Imagem
retirada do sítio: http://shimmer-research.com
2.2 Plataformas de Hardware
31
Figura 2.4: Nodo sensor SHIMMER
Outra plataforma comercial, vastamente utilizada em RSSF no geral é a plataforma TelosB (ilustrada na Figura 2.5), criada na Universidade de Berkeley e comercializada pela empresa Crossbow, a plataforma é composta por um microcontrolador MSP430,
2 pilhas AA como bateria e o chip CC2420 para interface de rádio com 2.4 GHz de banda
e alcance de 50 metros em ambientes fechados e 128 metros em ambientes abertos. Possui também uma porta USB para deploy de aplicações e vem equipado com sensores de
umidade, temperatura e liminosidade [35].
Figura 2.5: Nodo sensor TelosB [35]
A grande vantagem dessas plataformas é que seu hardware já leva em consideração os componentes que devem compor um nodo sensor para RSSF, uma unidade de
processamento, uma unidade de memória e um dispositivo de comunicação, além disso já
contam também com suporte de sistemas operacionais vastamente utilizados que consideram gerencia de memória, processo, e o básico para comunicação, além de poder contar
com algoritmos de roteamento, segurança e frameworks específicos da área.
2.2 Plataformas de Hardware
32
É importante ressaltar que essa plataforma não foi projetada para ser empregada
em soluções voltadas para área médica. Entretanto, o projeto CodeBlue desenvolveu
sensores exclusivos para saúde para essa plataforma, que embora possa ser interessante
para validar provas de conceito em situações específicas, não devem ser aplicadas em
cenários reais pois não levam em consideração aspectos fundamentais da área da saúde.
2.2.2
Plataformas Acadêmicas
As Plataformas Acadêmicas, neste trabalho, referem-se as plataformas que são
criadas específicamente para um projeto e levam em conta somente as especificidades do
mesmo, não podendo ser reaproveitadas. Dentre essas plataformas estão os nodo sensores
criados a partir da plataforma comercial Arduino [15].
O Arduino, apesar de ser comercial, encaixa nessa categoria por ser um conjunto
de placas, a placa principal, sendo o próprio Arduino e seus shields que podem ser
utilizados para compor uma solução específica de um projeto de RSCH.
O Arduino é uma plataforma que segue os conceitos do hardware open source,
basicamente isso quer dizer que há no website oficial da plataforma todas as informações
de seu projeto de hardware que permite sua criação e replicação. O Arduino é basicamente
uma placa com um microcontrolador e pinos de entrada e saída para se “encaixar”
dispositivos externos, os chamados shields. Os shields são placas específicas para um
propósito, por exemplo, há shields que implementam o padrão de comunicação BlueTooth
[38], ou que implementam um sensor de temperatura, ou até mesmo que controlam um
motor. O Arduino também provê um pacote de software para facilitar a programação de
seu microcontrolador e shields.
Na área da saúde, há vários trabalhos na literatura que utilizam tal plataforma.
Um deles está descrito em [15] que utiliza o Arduino Lilypad (ilustrada na Figura 2.6) para
construir um dispositivo acoplado a roupa para coleta de dados fisiológicos de um pessoa,
enquanto a mesma está realizando atividades físicas. Vale ressaltar que neste trabalho em
específico houve a utilização de outros tipos de sensores que compõem a solução.
2.2 Plataformas de Hardware
33
Figura 2.6: Arduino Lilypad [15]
Outro tipo de plataforma de hardware que se encaixa nessa categoria são os
hardwares totalmente criados, e não montados a partir de uma plataforma (como é o
caso do Arduino), para resolver os problemas de um projeto. Um exemplo de projeto que
utiliza esse tipo de aplicação é o trabalho descrito em [7] (sua plataforma de hardware é
ilustrada na Figura 2.7).
O projeto The Real-Time Wireless Physiological Monitoring System (RTWPMS)
é voltado para o monitoramento de pessoas idosas em centros de repouso. A aplicação
coleta dados em tempo real da frequência cardíaca, pressão sanguínea e temperatura corpórea. O paciente tem seus dados coletados e armazenados, de forma que os profissionais
de saúde possam montorá-lo em tempo real ou consultar seu histórico de dados com o objetivo de encontrar mudanças em seu estado de saúde. Essa solução utiliza uma plataforma
de hardware que consiste basicamente em quatro partes: um dispositivo móvel que coleta
dados fisiológicos; uma estação base sem fio; um dispositivo de troca de dados e voz; e
um centro de gerenciamento de rede. Como a plataforma de hardware foi desenvolvida
especificamente para essa aplicação, teve-se que também desenvolver toda plataforma de
software.
2.3 Simuladores
34
Figura 2.7: A Real-Time Wireless Physiological Monitoring System (RTWPMS) [7]
Soluções que possuem em sua integração plataformas de hardware criadas a
partir de plataformas que possam ser montadas, como o Arduino, assim como projetos
que criam sua própria plataforma de hardware têm a vantagem de poderem montar todas
as suas estruturas utilizando apenas os dispositivos adequados específicamente para sua
solução. Isso faz com que esse tipo de solução não se torne uma rede de sensores e
sim apenas um sensor ou um hub de sensores acoplados, de forma a não levar em
consideração todas as caracterísiticas e vantagens de uma rede. O que leva também a
utilização de softwares específicos para plataforma de hardware deixando de utilizar
todo um aparato de software existente, tais como: sistemas operacionais, frameworks,
algoritmos de roteamento e segurança que levam em consideração a economia de energia
para o prolongamento do tempo de vida dos sensores da rede, técnicas de acurácia,
tolerância a falhas, dentre outros desafios comuns de aplicações de RSCH.
2.3
Simuladores
Esta seção descreverá algumas características de alguns simuladores e verificará
suas funcionalidades a fim de expor a plataforma de simulação mais adequada para
atender os objetivos desse trabalho.
2.3.1
Network Simulator (NS)
A plataforma de simulação Network Simulator (NS) consiste basicamente, como
descrito em seu website oficial (http://www.nsnam.org/), em um simulador de eventos
discretos. Com ele é possível configurar e montar todo um ambiente de rede com o
objetivo de realizar testes.
2.3 Simuladores
35
Esse simulador utiliza um conjunto de scripts e modelos para realizar as simulações. Em suas versões anteriores, como o NS2, apesar de possibilitar a criação de simulações de RSSF utilizando protocolos de comunicação como IEEE 802.15.4, não era a
plataforma mais adequada para esse tipo de rede. O seu sucessor, o NS3, apesar de também não ser o mais referenciado para simulação de RSSF, há esforços para torná-lo mais
propício a simulação desse tipo de rede, como consta em [10], onde descreve uma pesquisa, em estágio inicial, com o objetivo de criar um framework para emular aplicações
de RSSF no simulador NS3.
Embora haja esforços para simular RSSF no NS3, o que se tem hoje da plataforma NS para simulação é bastante imatura para RSSF. Se levarmos em consideração o
objetivo do trabalho que é implementar um simulador para plataforma de hardware específica da área da saúde, o NS não atenderia as necessidades.
2.3.2
TOSSIM
O simulador TOSSIM [12] é o simulador de eventos discretos do sistema
operacional TinyOS. Basicamente após compilar a aplicação escrita para TinyOS com
o comando do simulador, é gerado o código para que se possa escrever o script de
simulação. Os scripts de simulação podem ser escritos em Python e C++ e com eles
pode-se instanciar nodo sensores e compor toda uma RSSF para testar a aplicação.
Dentre as restrições e limites deste simulador está o fato de que ele apenas simula
a plataforma de hardware MicaZ [37], esse é um dos motivos que o exclui de ser utilizado
neste trabalho, já que o objetivo consiste na criação de uma plataforma de hardware
específica para área da saúde.
2.3.3
AVRORA
A plataforma de simulação AVRORA [6] consiste em um aparato de ferramentas
e simulação para emular aplicações escritas para o microcontrolador AVR, utilizados, por
exemplo, em plataformas de RSSF como Mica2 [36].
Essa plataforma permite a simulação de aplicações escritas em qualquer sistema
operacional, ou framework que irá rodar na plataforma de hardware simulada. O simulador recebe como entrada um arquivo compilado.
Visando a construção de uma plataforma de hardware para RSCH específica
para área da saúde, o AVRORA poderia ser a plataforma a ser escolhida para dar
prosseguimento ao trabalho. Porém, o objetivo do trabalho é construir a plataforma de
hardware SHIMMER, que utiliza o microcontrolador MSP430 e não um AVR, o que torna
inviável a sua utilização.
2.3 Simuladores
2.3.4
36
WSim e WSNet
A plataforma de simulação WSim [5] consiste, da mesma forma que o AVRORA,
em basicamente a emulação de microcontroladores, sua diferença está no fato de que
o WSim implementa mais de um microcontrolador e consequentemente possui mais
plataformas de hardware de RSSF implementadas. O WSim implementa a emulação dos
microcontroladores MSP430 e AVR e assim possui a implementação de plataformas de
hardware como MicaZ, Telos, SkyMote.
Esta plataforma simula apenas um nodo sensor, para montar uma rede de sensores é necessário o WSNet. O WSNet é responsável por criar uma rede de sensores escalável com base na emulação do nodo sensor WSim. No WSNet é possível montar toda a
topologia da rede, gerar ruídos e simular a comunicação de mais de um nodo sensor.
Existem algumas complexidades de uso, de instalação e de alterações do código
da plataforma de simulação WSim. O simulador implementa um grande número de
funcionalidades e plataformas de RSSF e utiliza projetos de terceiros e independentes do
núcleo da plataforma de simulação. Um exemplo da utilização de códigos de terceiro é o
uso de ferramentas do próprio pacote de compiladores do MPS430 (insight) para realizar
depuração do código simulado. Esse caso em particular, pode gerar problemas de conflito
e dependência de pacotes o que pode dificultar a instalação.
A utilização de bibliotecas de terceiros causa dependência do projeto às mesmas.
Caso queria alterar algum detalhe do depurador, por exemplo, é necessário estudar e
conhecer a estrutura de todo um outro projeto para fazer essa modificação ou criar sua
própria ferramenta de depuração.
Um outro ponto observado da plataforma WSim foi que, a utilização de bibliotecas de terceiros, muitas das funcionalidades que geram visão da simulação não são
mostradas em tempo de execução da mesma. O simulador realiza a simulação e escreve
os resultados em um arquivo, este por sua vez serve de entrada para outros processos que
irão analisar o tracing resultante da simulação e então criar arquivos gráficos, isso é um
ponto negativo pois a plataforma não fornece formas de avaliar a execução da simulação
em tempo de execução.
2.3.5
MSPSim e COOJA
O MSPSim [8] também contempla, basicamente, as mesmas funcionalidades
do AVRORA. Porém emula somente o microcontrolador MSP430 e tem implementado
plataformas de hardware como TMoteSky, ESB e WiSMOTE. Assim como o AVRORA
e WSim, o MSPSim recebe como entrada para simulação um arquivo compilado para a
plataforma que se quer simular e apresenta como funcionalidade a depuração do código e
o acompanhamento em tempo de execução da pilha de execução e o ciclo de trabalho.
2.3 Simuladores
37
Da mesma forma que o WSNet permite a criação de uma rede utilizando como
base o WSim, o COOJA pode realizar sua simulação utilizando o MSPSim como base de
um nodo sensor e assim pode-se estabelecer a topologia da rede, gerar ruídos e simular a
comunicação de mais de um nodo sensor.
Ao contrário do WSim, o COOJA/MSPSim possui a implementação de todas
as suas funcionalidade em um único projeto, de forma a facilitar alteração do código,
instalação (pois não há dependências) e facilita o uso, pois como tudo é integrado pode-se
acompanhar toda a execução da aplicação simulada em tempo de execução.
Desta forma o MSPSim foi a plataforma escolhida para a implementação da
plataforma de hardware SHIMMER.
CAPÍTULO 3
Plataforma de Hardware SHIMMER
Neste capítulo será relatado o estudo feito sobre a plataforma de hardware
SHIMMER, descrevendo de forma geral a origem da plataforma, a motivação de sua
criação, cenários de utilização e seus componentes de hardware. Por fim, também serão
descritos os componentes de software disponíveis para o desenvolvimento de aplicações,
componentes estes utilizados para o desenvolvimento de software tanto na perspectiva do
sensor, quanto da perspectiva dos dispositivos móveis que são utilizados como gateways1
entre a rede de sensores e o servidor remoto.
3.1
Descrição da Plataforma
O desenvolvimento de aplicações para o sensoriamento da saúde com inteligência, modulariadade, mobilidade e reusabilidade formam a base ideológica na qual a platafroma SHIMMER foi criada. Seu nome, SHIMMER, é um acrônomo dessas palavras, do
inglês Sensing Health with Intelligence, Modularity, Mobility and Experimental Reusability. Em resumo, pode-se dizer que SHIMMER é uma plataforma de hardware comercial
utilizada para compor soluções de RSCH, e se caracteriza por ser pequena, leve e capaz
de coletar, processar e transmitir dados.
A plataforma de hardware SHIMMER foi desenvolvida para explorar a capacidade de sensores da área da saúde, de forma a prover uma plataforma de hardware para
RSCH com o objetivo de beneficiar engenheiros, pesquisadores da área médica e aos próprios profissionais de saúde. Desta forma, o SHIMMER é uma plataforma que deve ser
utilizada para compor uma RSCH, na qual os nodos sensores são vestidos pelos usuários,
e que tenha por objetivo a coleta de sinais vitais do corpo humano, como mostra a Figura
3.1 2 , na qual o usuário veste a plataforma que coleta a resistência galvânica de sua pele
(capaz de medir seu nível de stress) e transfere esses dados em tempo real a um servidor.
1 Gateway
é uma ponte de ligação, que neste caso faz a ligação dos dados trafegados na rede de sensores
para um outro tipo de rede que levará os dados a um servidor.
2 Imagem retirada do sítio: http://shimmer-research.com
3.1 Descrição da Plataforma
39
Figura 3.1: Ilustração da Plataforma SHIMMER com Sensor de
Resistência Galvânica da Pele
Assim, a plataforma é utilizada em um contexto que demanda a coleta de sinais
como: batimentos cardíacos, resistência galvânica da pele, força, atividade muscular,
pressão atmosférica, movimentos do corpo, etc. Esses dados são coletados a partir dos
sensores disponibilizados pela plataforma.
O uso do SHIMMER, como uma plataforma de hardware que compõe uma
RSCH, permite e facilita o cruzamento dos sinais vitais coletados, de forma a prover
informações que podem ser correlacionados para inferir estados de saúde de pacientes,
e assim auxiliar o profissional da área médica. A partir dessa perspectiva, a plataforma
SHIMMER foi utilizada em diversos projetos que ilustram diversos cenários de uso da
mesma. Dentre eles, o projeto BioMOBIUS [39], desenvolvido pelo centro de pesquisa
TRIL Centre o qual foi um dos primeiros a adotar o SHIMMER como plataforma de
hardware.
O projeto BioMOBIUS resume-se a uma plataforma compartilhada de pesquisa
que reuni software, hardware, sensores e serviços, que podem ser utilizados para compor
aplicações na área médica, com o objetivo de fornecer uma plataforma de tecnologia
interoperável para o rápido desenvolvimento dessas aplicações. Dentro desse contexto, o
SHIMMER foi utilizado em diversos cenários, dentre eles:
• Análise de Movimento do Corpo (Gait Analysis): Uma aplicação que monitora os
movimentos do corpo com o objetivo de identificar problemas de postura e andado,
Figura 3.2;
• Análise do Movimento do Corpo de Idosos em Ambientes Residenciais: Monitoramento da velocidade dos movimentos do idoso em sua residência, de forma a
detectar limitação de suas atividades.
3.2 Componentes de Hardware
40
Figura 3.2: Análise de Movimento do Corpo Utilizando a Plataforma SHIMMER - BioMOBIUS [39]
Há também outro projeto que ilustra a utilização da plataforma SHIMMER, este
descrito em [16], no qual ilustra uma aplicação que utiliza a plataforma para monitorar
pacientes com a Doença de Parkinson em suas residências.
O trabalho descreve a utilização da plataforma para a coleta de dados de forma
remota, ressaltando pontos como a importância de se ter uma plataforma capaz de não só
armazenar dados coletados, mas também processá-los de forma eficiente no próprio nodo
sensor. Além disso, o trabalho relata a utilização de sensores para acompanhar flutuções
motoras dos pacientes, que são efeitos decorrentes de complicações no tratamento, de
forma a ter o acompanhamento contínuo do quadro dos pacientes.
3.2
Componentes de Hardware
A plataforma de hardware SHIMMER, como exemplo de um nodo sensor de
RSSF, é composto basicamente por um microcontrolador, memória, rádio e sensores. A
Figura 3.3 mostra a plataforma de hardware, destacando seus componentes. Nesta seção,
serão descriminados os principais elementos que compõem a plataforma.
3.2 Componentes de Hardware
Figura 3.3: Componentes de Hardware [40]
41
3.2 Componentes de Hardware
3.2.1
42
Microcontrolador
O microcontrolador utilizado no SHIMMER é o microcontrolador MPS430 da
Texas Instrument, especificamente o MPS430F1611. Esse microncontrolador tem como
principal característica seu baixo consumo de energia, principalmente durante os períodos
de inatividade.
Figura 3.4: Arquitetura do Microcontrolador MSP430F1611 [41]
O MSP430, como ilustrado na Figura 3.4 de sua arquitetura, é um microcontrolador RISC de 16-bits que possui 16 registradores. Dentre eles se destacam o R0, como
o contador de programa; o R1 como ponteiro de pilha; o R2 registrador de estado, que
contém bits de controle aritmético, e o R3 como um registrador de gerador de constantes.
Este último registrador tem por objetivo prover acesso a seis valores constantes comumente utilizados sem a necessidade de uma operação adicional, o que contribui com a
eficiência na codificação. O restante dos registradores são de propósito geral.
Como destacado anteriormente, o MSP430 é um microcontrolador RISC, ou
seja, é um microcontrolador que possui um conjunto reduzido de instruções físicas, sendo
elas agrupadas em três conjuntos.
O primeiro grupo a ser descrito é o conjunto de instrução aritmética de um
único operador, e tem seu código representado pela Tabela 3.1. Basicamente essa família
de instruções segue o formato ilustrado pela primeira linha da tabela, no qual os seis
3.2 Componentes de Hardware
43
Tabela 3.1: Instruções Aritméticas de um Único Operador
000100
Código
B/W
AS
Registradores
Instrução
000100
3-bits
1-bit
2-bits
4-bits
Forma geral
000100
100
1/0
AS
registrador
PUSH
Tabela 3.2: Instruções de Desvio Condicional
001
Código
Deslocamento (Offset)
Instrução
001
3-bits
10-bits
Forma Geral
001
000
10-bits
JNZ
primeiros bits representam o próprio conjunto, de forma que todas as instrução que
começam com a sequência de bits 000100 é uma instrução aritmética de um único
operador. Os três bits mostrados na segunda coluna, “Código”, são os bits que representa
a operação em si, assim, cada instrução dessa família possui um código único.
As operações no microcontrolador podem ser executadas em B (8 bits) ou W
(16 bits), dependendo do valor de B/W na instrução. Desta forma a terceira coluna da
instrução, caso for 0 indica que o tamanho da operação é de 16 bits e caso for 1 indica
que é 8 bits. Já a quarta coluna “As” com 2 bits representa os modos de endereçamento,
presentes no Anexo A.
Na segunda linha da Tabela 3.1 é um exemplo de instrução aritmética de um
único operador, no caso é ilustrada pela instrução PUSH, que adiciona um valor à pilha
de execução (ou pilha de chamada).
O segundo grupo de instrução é representado pelas instruções de desvio. Essas
instruções são utilizadas para testar condições no código, caso as condições forem
verdadeiras o fluxo de execução do código é alterado. Essa família de instrução é ilustrada
na Tabela 3.2.
A primeira coluna, assim como na tabela do conjunto de instruções aritméticas
de um único operador, possui os bits que representa esse grupo de instrução, de forma
que todas as instruções contidas nesse grupo começa com 001. Os próximos três bits
da instrução, representado na tabela pela segunda coluna é o código da instrução de
forma a identificar unicamente uma instrução em si dentro dessa família. Levando em
consideração a natureza dessas instruções que validam uma condição e faz o desvio do
fluxo de execução do programa, a terceira coluna da tabela é onde se encontram os 10 bits
de deslocamento, que apontam para a próxima instrução que será executada.
Como exemplo desse tipo de instrução, na segunda linha da tabela, é ilustrado a
instrução JNZ, do inglês Jump If Not Zero. Essa instrução é utilizada para verificar se o
bit zero dos bits de estado do R2 foi resetado, caso afirmativo, o fluxo de execução pula
para a instrução contida no endereço de “Deslocamento”.
3.2 Componentes de Hardware
44
Tabela 3.3: Instruções Aritméticas de Dois Operadores
Código
Origem
Ad
B/W
As
Destino
Instrução
4-bits
4-bits
1-bit
1-bits
2-bit
4-bits
Forma Geral
0100
origem
Ad
1/0
As
destino
MOV
O terceiro grupo é composto pelas instruções aritméticas de dois operandos,
ilustrados na Tabela 3.3. Esse conjunto de instruções é caracterizado por ter um endereço
de origem e um endereço de destino, de forma que o dado a ser manipulado será buscado
no endereço de origem e será manipulado junto com o valor contido no endereço de
destino, e o resultado será armazenado no próprio endereço de destino.
Os quatro primeiros bits desse conjunto de instrução compõem o código da instrução, de forma a identificar unicamente a própria instrução. Os quatro bits subsequentes
formam o endereço do qual o dado será buscado, juntamente com o valor As, é definido
se o dado será buscado de um registrador, por exemplo, dependendo do tipo de endereçamento especificado na instrução. Da mesma forma, tem-se o Ad e o endereço de destino,
que de acordo com o modo de endereçamento irá armazenar o dado resultante em um
registrador, memória, etc.
Como exemplo desse conjunto de instrução pode-se citar as intruções aritméticas
de soma ou subtração, além dessas, na segunda linha da tabela, tem-se a instrução MOV,
responsável por mover o dado provindo do endereço de origem para o endereço de destino.
As tabelas dos conjuntos de instruções, assim como os modos de endereçamento,
do MPS430 podem ser verificados com mais detalhes no Anexo A.
Em resumo, de acordo com o manual do microcontrolador [41], a família
MSP430F1611, utilizada pelo SHIIMER é um microcontrolador composto por dois
temporizadores (timers) de 16 bits, um conversor analógico digital (ADC) de 12 bits,
um conversor digital analógico (DAC) dual de 12 bits, de uma a duas interfaces de
comunicação chamada Transmissor/Receptor Universal Síncrono e Assíncrono (USART),
um dispositivo de acesso direto a memória (DMA) e 48 pinos de extensão.
3.2.2
Padrões de Comunicação
A plataforma SHIMMER possui dois componentes de hardware que implementam dois padrões de comunicação. Um deles é o CC2420 juntamente com uma antena
gigAnt Rufa de 2.4GHz. O componente CC2420 implementa o padrão de comunicação
IEEE 802.15.4 e se encontra também em diversas outras plataformas hardware para RSSF
de propósito geral. Outro padrão de comunicação implementado pela plataforma é o BlueTooth, e o componente que implementa esse padrão na plataforma SHIMMER é o RN-46,
que comunica através de uma antena integrada.
3.2 Componentes de Hardware
3.2.3
45
Sensores
A plataforma SHIMMER é composta por uma placa base e uma placa filha,
essa separação torna a plataforma mais extensível. A placa base é composta pelos
elementos básicos de funcionamento da plataforma, dentre esse elementos encontram-se
basicamente o microcontrolador, memória, rádio, e um conector de extensão.
O conector de extensão é utilizado para acoplar a placa base com as placas filhas.
As placas filhas, por sua vez, servem para estender a funcionalidade da plataforma. São
elas os sensores biofísicos disponíveis pela plataforma, como ilustrado na Figura 3.5 3 .
Figura 3.5: Placa Base à Esquerda e Placa Filha à Direita (ECG)
Os sensores são divididos em três grandes grupos, o grupo dos sensores biofísicos, o dos sensores de ambiente e dos sensores de movimento (kinematics). Dentro do
grupo de sensores biofísicos, responsáveis pela coleta de sinais vitais do corpo tem os
seguintes sensores:
•
•
•
•
Eletrocardiograma (ECG);
Eletromiograma (EMG);
Resitência Galvânica da Pela (GSR); e
Extensômetro;
Há também, como citado anteriormente, o grupo de sensores que coleta dados do
ambiente, esses sensores são capazes de coletar dados do ambiete que cerca os usuários
da plataforma, que são:
• Temperatura;
3 Imagem
retirada do sítio: http://shimmer-research.com
3.3 Software da Plataforma
•
•
•
•
46
Barômetro (Pressão Atmosférica);
Infravermelho (PIR);
GPS; e
Vibração.
E, por fim, os sensores de movimento, o SHIMMER possui uma série de modulos
vestíveis para medidas inerciais, muitas vezes referenciadas como unidades de medidas
inerciais, do inglês (IMU - Inertial Measurement Units), utilizados em aplicações que
necessitam da captura dos movimentos do corpo, de forma determinar se o usuário
venstindo a plataforma de hardware se encontra parado, em pé, andando, deitado, etc.,
são eles:
• Acelerômetro (3 eixos);
• Acelerômetro e Giroscópio (6 eixos);
• Acelerômetro, Giroscópio e Magnetômetro;
3.3
Software da Plataforma
Ao adquirir a plataforma SHIMMER tem-se acesso às ferramentas que auxiliam
o desenvolvimento de aplicações para a plataforma. Os softwares disponíveis contemplam
várias tecnologias tais como C#, LabView, MatLab e Android, para aplicações que receberão e mostrarão os dados recebidos da rede em um computador ou dispositivo móvel.
Para o desenvolvimento da aplicação que são executados no próprio sensor é utilizado
o sistema operacional embarcado TinyOS, que fornece suporte ao desenvolvimento de
aplicações para plataforma de hardware SHIMMER. Nesta seção será apresentado essas
ferramentas que dão suporte ao desenvolvimento de software para plataforma SHIMMER.
3.3.1
Ferramentas de Desenvolvimento de Software
As ferramentas que dão suporte ao desenvolvimento das aplicações que receberão os dados das redes formadas pelos nodos sensores SHIMMER serão detalhadas nesta
seção. Dentre essas ferramentas há também as que serão executadas em dispositivos móveis, que servirão para mostrar os dados em tempo real ao usuário e ao mesmo tempo
como gateways entre a rede de sensores e o servidor remoto.
• LabView: O LabView é uma plataforma da National Instruments que permite
o desenvolvimento de aplicações de forma gráfica, sem a necessidade de escrita
de código. É uma plataforma voltada para engenheiros e cientistas que permite
integração com hardware para o projeto e implementação de software de medição
3.3 Software da Plataforma
47
e controle. Aproveitando essa plataforma de desenvolvimento, o SHIMMER provê
uma biblioteca para facilitar o desenvolvimento de aplicações que integram com
plataforma de hardware SHIMMER, facilitando a integração e o desenvolvimento
de software.
• MatLab: O MatLab é um ambiente programável para o desenvolvimento de aplicações para cálculo númerico, ele engloba, dentre outras funções, a capacidade de
fazer cálculo com matrizes, construção de gráficos e processamento de sinais, sendo
os problemas expressos em sua forma matemática, ao contrário da programação
convencional.
O SHIMMER possui também uma biblioteca que facilita a integração de aplicações
escritas para MatLab com a plataforma de hardware SHIMMER. Facilitando a
captura e manipulação dos sinais providos por uma rede de sensores formados por
nodos sensores SHIMMER. Dessa forma, é fornecido manipulação de matrizes,
plotagem de funções e dados, implementação de algoritmos, criação de interfaces
gráficas e a interface com outros programas escritos em outras linguagens.
• C#: Para o desenvolvimento de aplicações em C#, que irá receber os dados de uma
rede composta por nodos SHIMMER, é fornecido o framework ShimmerConnect
que foi desenvolvido em C# com o framework .NET. O ShimmerConnect provê
aos desenvolvedores de C# .NET a integração com o nodo SHIMMER, de forma a
facilitar o envio de comandos para rede e o recebimento de dados enviados pelos
nodos.
• Android: A plataforma SHIMMER também oferece o SHIMMER ANDROID
INSTRUMENT DRIVER. Essa biblioteca facilita o envio de dados em tempo real
coletado da rede diretamente para dispositivos Android, como tablets e celulares.
Essa solução permite a fácil integração e configuração de dispositivos Android com
nodos SHIMMER. Os dados trocados entre essas duas plataformas se dá através do
padrão de comunicação Bluetooth em tempo real.
3.3.2
TinyOS para SHIMMER
O desenvolvimento da aplicação que irá controlar o nodo sensor SHIMMER é
feito em TinyOS, o único sistema operacional, até então, que provê suporte à plataforma.
O TinyOS é um Sistema Operacional Embarcado opensource mais referenciado na área de
RSSF. Ele é um sistema operacional e um framework de desenvolvimento, cuja linguagem
para escrever programas é o nesC (Network Embedded Sensor C), uma adaptação da
linguagem C. Seu paradigma de desenvolvimento é orientado a eventos, como será
descrito e detalhado nesta seção.
O TinyOS foi projetado para sensores com restrições de energia, desta forma,
3.3 Software da Plataforma
48
ele se distingue dos demais, pois suas operações foram projetadas para consumir o
mínimo de energia do nodo sensor possível. Além da preocupação com o gasto energético
do nodo, o sistema operacional/framework, provê um modelo de desenvolvimento que
facilita a escrita de programas, de forma a prover componentes e serviços recorrentes
desse tipo de aplicação, incentivando a reusabilidade de código. O sistema operacional
suporta inúmeras plataformas de hardware, também facilita o desenvolvimento de novas
plataformas, sensores e serviços.
A reusabilidade de código e a facilidade de extensão de seus serviços e plataformas é alcançado pela sua estruturação. O TinyOS é composto por componentes, e estes
organizados em níveis de abstração. Os componentes facilitam a reusabilidade de código,
pois cada um fornece a implementação de uma determinada funcionalidade. Por exemplo,
em aplicações de RSSF é uma necessidade comum realizar leitura de medições provindas
de um sensor, assim, o TinyOS provê uma interface de leitura padrão, o Read<uint16_t>.
A implementação dessa interface é dada pelo componente de leitura específico do sensor
que se quer captar o dado, podendo ser este um sensor de temperatura, umidade, luminosidade, etc., com isso, haveria um componente para cada tipo de sensor para implementar
essa interface de leitura padrão.
Já os níveis de abstração foram pensados para abstrair as particularidades das
inúmeras plataformas de hardware, de forma a prover interfaces padrão que poderiam ser
utilizadas pelos desenvolvedores sem se preocuparem com detalhes de implementação
de baixo nível. Assim, quanto mais “baixo” o nível do componente, mais atrelado a
uma plataforma de hardware ele está, e quando mais “alto” o nível, mais independente
da plataforma é o componente, podendo assim, ser utilizado pelos desenvolvedores
independente da plataforma de hardware que eles estejam utilizando. Assim, facilita a
reutilização de componentes e a extensão de serviços e plataformas.
Como mencionado anteriormente, o TinyOS provê interfaces para determinadas funcionalidades e serviços que são implementadas por componentes mais específicos.
Para fazer essa ligação da interface que está sendo utilizada pelo desenvolvedor e o componente que a implementa, o TinyOS espera do desenvolvedor no mínimo dois arquivos
para compor a aplicação, o módulo e sua configuração. O módulo é a parte da aplicação
que possui a implementação do programa em si. Nessa parte que o desenvolvedor irá declarar as interfaces que irá utilizar e utilizá-las em seu código. A configuração, por outro
lado, é responsável por fazer a ligação das interfaces utilizadas com os componentes que
as implementam. Como ilustrados nos exemplos de códigos 3.1 e 3.2.
3.3 Software da Plataforma
49
Código 3.1 Código de Exemplo do TinyOS - Configuração
Blink
1
configuration BlinkAppC
2
{
3
}
4
implementation
5
{
6
components MainC, BlinkC, LedsC;
7
components new TimerMilliC() as Timer0;
8
components new TimerMilliC() as Timer1;
9
components new TimerMilliC() as Timer2;
10
11
BlinkC -> MainC.Boot;
12
13
14
BlinkC.Timer0 -> Timer0;
15
BlinkC.Timer1 -> Timer1;
16
BlinkC.Timer2 -> Timer2;
17
BlinkC.Leds -> LedsC;
18
}
19
Código 3.2 Código de Exemplo do TinyOS - Módulo Blink
1
module BlinkC @safe()
2
{
3
uses interface Timer<TMilli> as Timer0;
4
uses interface Leds;
5
uses interface Boot;
6
}
7
implementation
8
{
event void Timer0.fired()
9
{
10
11
dbg("BlinkC", "Timer 0 fired @ %s.\n", sim_time_string());
12
call Leds.led0Toggle();
}
13
14
}
15
O exemplo de código do módulo e configuração foi retirada da aplicação Blink,
3.3 Software da Plataforma
50
uma aplicação de exemplo do próprio TinyOS. Essa aplicação pode ser comparada com
aplicações do tipo Hello World, comumente escritas como uma primeira aplicação quando
se está aprendendo uma nova tecnologia. A aplicação Blink se resume basicamente em
uma aplicação que pisca os LEDs de um sensor. Assim, ele utiliza os componentes
de Timer e LED. Os Timers, são componentes que executam um trecho de código
periodicamente, no caso há três Timers, cada um executando um trecho diferente em um
período diferente. Os componentes LEDs, por sua vez, são utilizados para prover controle
sobre os LEDS do hardware, nesse caso, eles são acesos e apagados.
O desenvolvimento de aplicações para o SHIMMER não é diferente. O desenvolvedor poderá utilizar todos os componentes e serviços fornecidos pelo TinyOS, inclusive
para coleta e manipulação dos dados capturados pelos sensores da área médica, específicos do SHIMMER. Na estrutura de diretórios do TinyOS é possível achar exemplos de
códigos de aplicações para o SHIMMER que utilizam, por exemplo um ECG, e os dados
são enviados pela interface de comunicação Bluetooth. Esses trechos de código fazem o
uso de componentes que controlam a DMA (acesso direto à memória), ADC (conversor
analógico e digital) e o próprio RN-46 que implementa o padrão Bluetooth. O código
completo da aplicação pode ser encontrada no Anexo B, e apesar de mais complexa, o
código não foge dos conceitos apresentados da aplicação Blink.
CAPÍTULO 4
Plataforma de Simulação MSPSim
Neste capítulo será descrito a plataforma de simulação MSPSim. As informações
descritas aqui foram retiradas de basicamente dois artigos, o artigo [8] e o [42].
O primeiro artigo [8] é uma breve descrição da plataforma MSPSim, contendo
motivação, objetivo, funcionalidades da plataforma e detalhes superficiais de sua implementação. É importante ressaltar que o trabalho [8] é um artigo resumo, de apenas quatro
páginas, mas um dos únicos acessíveis na literatura que descreve através de um exemplo
a integração de um dispositivo periférico com o núcleo do simulador.
Já o segundo artigo, [42], descreve além da plataforma MSPSim a plataforma
COOJA também, e principalmente como ambas são integradas de forma a prover um
ambiente de simulação heterogênio e interoperável, capaz de fornecer um ambiente no
qual é possível a realização de testes de caixa-branca.
Buscas realizadas para encontrar informações aprofundadas acerca do MSPSim
nos levaram a somente essas duas fontes relevantes e confiáveis. No grupo 1 do Sourceforge 2 do projeto, não se encontra informações acerca da plataforma com mais detalhes,
a maior parte das informações foram obtidas com o estudo do próprio código.
O estudo do código foi conduzido fazendo a execução e depuração do mesmo,
o que acarretou em um maior gasto de tempo para o entendimento e consequentemente a
implementação da plataforma SHIMMER integrada ao MSPSim, que é o objetivo desse
trabalho.
4.1
Descrição da Plataforma
O desenvolvimento de aplicação para RSSF de propósito geral é conhecido por
ser uma tarefa bastante difícil e lenta. Isso se dá principalmente por sua nateraza distribuída, pelas restrições de recurso das plataformas e pelas ferramentas de depuração limi1
URL Grupo Sourceforge: http://sourceforge.net/projects/mspsim/
Sourceforge é um website que fornece espaço e ferramentas para a criação e gerenciamento de projetos
de software.
2
4.1 Descrição da Plataforma
52
tas. Somada às dificuldades no processo de desenvolvimento, há também a necessidade
de se testar aplicações de RSSF em um ambiente heterogênio, ou seja, que se possa testar
aplicações escritas com plataformas de software diferentes utilizando sensores diferentes.
Desta forma, com o objetivo de prover um ambiente que ofereça formas mais abrangentes
de depuração de código, e a simulação de redes heterogêneas com a finalidade de testar aplicações interoperáveis, é construído a plataforma de simulação MSPSim integrável
com a plataforma de simulação COOJA [42].
O MSPSim é uma plataforma de simulação extensível de nodos sensores. Por
vezes também definida como um simulador de nível de instrução do microcontrolador
MSP430. Assim, juntando as duas definições, temos que o MSPSim é uma plataforma de
simulação extensível, escrita em JAVA, capaz de simular o microcontrolador MSP430 a
nível de instrução, ou seja, capaz de simular o comportamento do MSP430 simulando a
execução de código binário específico dessa plataforma. Além disso, o simulador também
permite a criação de dispositivos periféricos que são integrados com o simulador do microcontrolador, de forma a compor um nodo sensor, simulando todo seu funcionamento.
Portanto, o MSPSim permite a simulação de plataformas de redes de sensores completas,
como o TelosB [43] e ESB/2 [44], e assim, torna possível a criação de nodos sensores
baseados no microcontrolador MSP430, como a própria plataforma SHIMMER.
Uma das motivações da criação do MSPSim é a falta de ferramenta que não
limita a atividade de depuração de código. Para entender o que seria limitar a atividade
de depuração de código para esse tipo de aplicação, é necessário descrever as ferramentas
mais comuns que se propõe a realizar essa atividade.
O método mais comum para depurar aplicações em nodo sensores é via JTAG. O
JTAG possibilita acompanhar e depurar a aplicação enquanto ela é executada em tempo
real por uma plataforma de hardware física. Fazer o acompanhamento da execução do
código com JTAG é importante para entender padrões de execução, uso da pilha de
chamada, dentre outros pontos, como por exemplo, a detecção de erros na lógica da
própria aplicação. Por outro lado, diz-se que JTAG é uma ferramenta limitada para a
depuração de código, pois não permite a depuração da transmissão dos dados entre dois
ou mais nodos sensores, não permite depuração de código dos drivers dos sensores, e
outras partes essenciais desse tipo de aplicação.
Outra forma de se estudar o comportamento de uma aplicação em RSSF é por
simuladores como o TOSSIM. Ele é o simulador oficial do sistema operacional TinyOS,
que foi descrito com mais detalhes no capítulo anterior. Esse simulador simplifica o
desenvolvimento de algoritmos, e permite que pesquisadores estudem o comportamento
e interação dos algoritmos em um ambiente controlado. Entretando, ainda assim, afirmase que o TOSSIM é um ambiente limitado pois simula somente aplicações escritas em
TinyOS, utilizando o nodo sensor MicaZ.
4.1 Descrição da Plataforma
53
Assim, o MSPSim é utilizado com o intuito de reduzir o tempo de desenvolvimento e depuração, permitindo o acompanhamento de baixo nível de vários aspectos
da execução do software. Fornecendo, ao contrário das formas de depuração, a possibilidade de duprar código passo-a-passo, inserindo breakpoints3 no código, estando os nodos
sensores trocando mensagens entre si. Além disso, o simulador fornece interfaces para o
acompanhamento da pilha de execução, a estatística de utilização dos periféricos como
LEDs, rádios, e operações de entrada e saída pela porta Serial e USART.
Uma funcionalidade importante do MSPSim, é sua capacidade de interpretar código binário específico de uma plataforma baseada em MSP430 sem nenhuma alteração,
ou seja, da mesma forma como o código binário iria ser executado na plataforma de hardware física ela será simulada pelo MSPSim. Assim, vale ressaltar que o simulador recebe
como parâmetro de execução códigos ELF e IHEX. Desta forma, é possível o desenvolvimento de aplicações e a depuração do código sem que se tenha acesso a plataforma de
hardware física para a qual esteja escrevendo a aplicação.
Outras funcionalidades da plataforma são identificadas ao executá-la. A Figura
4.1 ilustra o MSPSim sendo executado, simulando a plataforma SHIMMER (resultado
da implementação deste trabalho), nela pode-se verificar a interface gráfica do simulador,
mostrando a representação do nodo sensor na tela, com seus botões e as cores corretas
dos LEDs da plataforma, também pode-se observar a tela de depuração de código, e
as telas de acompanhamento de estatísticas de uso dos periféricos. É possível adicionar
“instrumentos” (trechos de código que são capazes de coletar métrica da execução de
periféricos) que monitoram a execução da aplicação. As saídas na interface gráfica (LEDs
piscando), assim como a saída Serial/USART permitem a verificação visual de que a
aplicação está executando de forma correta.
3 breakpoints
são pontos de parada no código, com a finalidade de depurá-lo.
4.1 Descrição da Plataforma
54
Figura 4.1: SHIMMER implementado no MSPSim
Uma das limitações do simulador MSPSim é o fato dele ser um simulador a
nível de instrução do microcontrolador MSP430, de forma que só é possível a simulação
do comportamento de um nodo sensor. Porém, para o desenvolvimento e teste apropriado
de aplicações vê-se necessário um simulador cross-level. Esse tipo de simulador é capaz
de simular todos os níveis de rede, simulando plataformas de hardware diferentes que
utilizam protocolos diferentes de comunicação (IPv6, WirelessHART, ZigBee, etc.), e que
utilizam sistemas operacionais diferentes. Para isso, o MSPSim foi construído de forma a
integrar com o COOJA.
O simulador COOJA é capaz de realizar essas simulações. Ele simula nodos sensores de RSSF no qual cada nodo possa ser de uma plataforma de hardware diferente, de
uma plataforma de software (TinyOS/Contiki) diferente, e com padrões de comunicação
diferentes.
4.2 Componentes
4.2
55
Componentes
Nesta seção serão descrito os componentes que formam a plataforma do MSPSim, esses componentes serão apresentados em dois grupos diferentes. O primeiro grupo
são os componentes da interface gráfica, eles permitem a interação com o simulador.
Objetiva-se que a descrição desses componentes facilitará o entendimento das funcionalidades providas pelo simulador do ponto de vista do usuário.
O segundo grupo reuni os componentes internos da plataforma, com isso visa-se
descrever de forma a facilitar o entendimento do funcionamento interno do simulador,
e como se daria a criação de novos dispositivos periféricos. Esses componentes irão
proporcionar um entendimento do simulador da perspectiva de quem pretende estendêlo.
4.2.1
Componentes Gráficos de Interação
De forma a detalhar as funcionalidades do simulador, é ilustrado os componentes
gráficos de interação do MSPSim. Esses componentes são apresentados ao executar uma
simulação com a plataforma.
Ao iniciar uma simulação com a plataforma, o simulador recebe os seguintes
parâmetros de execução: java -jar MSPSim.jar -platform=shimmer main.ihex.
No comando de execução do simulador acima, é passado o mínimo de parâmetros necessários para a execução da plataforma, sendo eles o nome da plataforma, no
caso SHIMMER (na ausência desse parâmetro a plataforma padrão é a TMoteSky), e o
segundo parâmetro, que é o arquivo executável que será simulado (no caso, main.ihex).
Além disso, por padrão, o simulador busca no diretório raiz do projeto um
arquivo de configuração, chamado “autorun.sc”. Esse arquivo possui as configurações
da própria simulação, de forma a definir o comportamento do simulador. Por exemplo,
para que o simulador apresente a tela de controle de depuração, é necessário adicionar
a este aquivo o código: service controlgui start. Outro exemplo de uso é para
redirecionar o fluxo de envio de dados de um dispositvo periférico como o CC2420
(o rádio) para um arquivo, de forma a poder verificar seu comportamento. Para isso é
adicionado a linha rflistener output CC2420 >> arquivo.txt .
Assim, sabemos que a simulação é altamente configurável, e os elementos
gráficos apresentados nessa seção devem ser configurados para aparecer, alguns deles
por parâmetro no comando de inicialização da simulação, e outros no próprio arquivo de
configuração.
4.2 Componentes
56
Monitor da Pilha de Execução
Como apresentado, o MSPSim fornece maneiras de monitorar componentes
internos da plataforma de hardware simulada. O monitoramento da pilha de execução
de uma aplicação sendo simulada pelo nodo sensor é uma das formas de acompanhar seu
funcionamento interno. A Figura 4.2 ilustra esse monitoramento.
Figura 4.2: Mostra o gráfico de utilização da pilha de execução
Pela figura pode-se acompanhar os picos de utilização da pilha, sendo a linha
vermelha (Max Stack) o valor máximo que pode ser utilizada pela pilha, e a linha verde
(Stack) representando a quantidade em bytes do uso da pilha. Sabe-se que a pilha de
execução é onde se guarda os endereços de retorno do fluxo de execução do código, nos
casos que há uma interrupção que deva ser manipulada, e também nos casos de chamada
de função.
A pilha é preenchida de cima para baixo, ou seja, ocupando os espaços de
memória de endereçamentos mais altos para os de endereçamento menores, ao contrário,
a área de dados da memória cresce em direção oposta. Assim, o valor representado pela
linha vermelha (max stack) é o maior tamanho, em bytes, disponível na área da pilha para
guardar os endereços de retorno, como as informações armazenadas na área de dados da
memória cresce em direção a área da pilha, quanto mais dados tiver nesse local, menor o
tamanho máximo disponível para a pilha, fazendo com que o tamanho máximo disponível
oscile no decorrer da execução da simulação.
O valor representado pela linha verde (stack) é o tamanho, em bytes, que está
sendo ocupado pela pilha. Desta forma, é importante notar que a linha verde nunca pode
ser maior que a linha vermelha, ou seja, não se pode armazenar mais informações na pilha
do que o seu tamanho máximo. Pois, caso isso ocorra, haverá dados sendo escritos na área
de memória da pilha ou endereços de retorno sendo escritos na área de memória de dados,
o que resultaria no transbordamento da pilha (stack overflow), que leva a corrupção dos
dados da RAM e subsequentemente falhas no nodo sensor difíceis de serem identificadas.
4.2 Componentes
57
Ciclo de Trabalho
O ciclo de trabalho de execução de uma simulação no MSPSim, representado na
Figura 4.3, é mais uma forma de acompanhar os componentes internos do nodo sensor
ao executar uma aplicação. O ciclo de trabalho, neste caso, mostra em porcentagem o uso
de cada componente monitorado (LED, rádio e CPU).
Figura 4.3: Gráfico mostrando o ciclo de trabalho
Desta forma, para cada intervalo de dez segundos é verificada, para o componente LED, se foi requisitado que eles acendecem ou apagassem, para o rádio, se houve
o recebimento ou envio de dados, para a CPU, a busca, decodificação e execução de instruções.
Porta USART1
A porta USART1, diferentemente dos outros componentes descritos até então,
não é para monitorar um componente interno do nodo sensor sendo simulado, não da
forma de gráfico, porcentagem de utilização, etc. Esse componente é uma interface da
porta serial do nodo sensor, de forma que tudo que for enviado do nodo sensor para a
porta serial é mostrado nesta interface, como ilustra a Figura 4.4. Da mesma forma, tudo
que se é enviado para plataforma pela porta serial, pode ser enviado por esse componente
de interação.
4.2 Componentes
58
Figura 4.4: Porta USART1
Painel de Controle de Simulação
O Painel de Controle de Simulação, ilustrado na Figura 4.5, é a interface de
interação pela qual os usuários controlam a execução da aplicação sendo executada pelo
nodo sensor simulado.
4.2 Componentes
59
Figura 4.5: Painel de Controle de Simulação
Através dessa interface é possível visualizar o código em linguagem de montagem em execução, sendo possível definir breakpoints e depurar a aplicação. Essas características acabam tornando essa interface uma das mais importantes do simulador. Ela
contém vários botões ao lado esquerdo da tela. Cada botão possui a seguinte funcionalidade:
• Debug On: Este botão tem a função de habilitar e desabilitar o depurador. O
depurador quando ligado imprime na saída padrão todos os passos executados da
aplicação simulada, juntamente com os valores manipulados.
• Run/Stop: Ao ser pressionado o botão run aparece escrito o botão stop (como
ilustra a figura). Esses botões são responsáveis por iniciar e parar a simulação.
• Single Step: Para habilitar essa funcionalidade é necessário que o simulador não
esteja executando, ou seja, caso a simulação esteja rodando (como ilustrado na
figura) deve-se pressionar o stop. Essa funcionalidade permite, diferentemente do
run, que a aplicação seja executada passo-a-passo, de forma que a cada clique no
botão, uma instrução será executada.
4.2 Componentes
60
• Stack trace: Essa funcionalidade, quando ativada, imprime na saída padrão o
estado da pilha de execução, mostrando os endereços de retorno armazenados e
o endereço que está no contador de programa.
• Show source: Com essa funcionalidade é possível visualizar o código fonte que
está sendo executado pelo nodo sensor simulado.
• Profile Dump: O Profile Dump imprime na saída padrão outras informações
estatísticas do sistema. Neste caso é impresso o total de ciclos de execução, o
número de chamadas a cada função, e uma média de quantos ciclos para cada
função.
Representação Gráfica do Nodo Sensor
A representação gráfica do nodo sensor, representada pela Figura 4.6, é a interface que mostra o hardware do nodo sensor sendo simulado. Nessa interface é possível
verificar o piscar dos LEDs, assim como a interação com os botões de reset presentes na
própria plataforma de hardware. Desta forma, é possível uma avaliação inicial de que a
aplicação está funcionando. Essa interface simula o mesmo comportamento que a plataforma física de hardware teria, visualmente, ao executar a aplicação.
Figura 4.6: Representação Gráfica do Nodo Sensor
4.2 Componentes
61
Terminal de Comando do MSPSim
Além da interface de controle da simulação, o simulador MSPSim oferece, como
forma alternativa e mais completa, o controle da simulação através de um terminal de
comando, ilustrado na Figura 4.7.
O terminal de comando do MPSSim, pode ser utilizado para controlar a simulação de diversas formas, dentre elas alguns controles que podem ser alterados pela interface
de controle, apresentada anteriormente, como ligar ou desligar o modo de depuração. Um
exemplo de comando que não pode ser feito por interface gráfica é o comando que imprime a fila de eventos da simulação, sendo um comando próprio do terminal (MSPSim>
events). Alguns comandos podem ser vistos na figura, ela retrata a saída do comando help.
Figura 4.7: Terminal de Comando do MSPSim
4.2.2
Componentes Internos da Plataforma
Os componentes internos do simulador MSPSim compõem a sua própria arquitetura de software, esses componentes irão dar uma visão mais detalhada acerca de sua
implementação. A plataforma MSPSim foi escrita utilizando a linguagem de programação
JAVA, com o paradigma orientado a objetos um paradigma de programação. Desta forma,
os componentes internos descritos nesta seção são as principais classes que compõem sua
4.2 Componentes
62
estrutura. Porém, antes de descrevê-los de forma detalhada, é necessário uma visão geral
de sua arquitetura.
A arquitetura da plataforma MSPSim, definida em [8], é ilustrada na Figura 4.8.
Nela é apresentada todo o simulador MSPSim, o núcleo do simulador, sendo o emulador
do microcontrolador MSP430 e os dispositivos periféricos, de forma a compor uma plataforma de simulação de um nodo sensor. O componente que ilustra o emulador permite
a integração com os dispositivos periféricos por meio das portas de entrada e saída, e por
meio do componente que implementa o padrão USART (Transmissor/Receptor Universal
Síncrono e Assíncrono), note que cada tipo de dispositivo é atrelado a um tipo de porta ao
microcontrolador.
Figura 4.8: Visão Geral da Arquitetura da Plataforma MSPSim
O núcleo da plataforma de simulação é seu microcontrolador. Para entender seu
funcionamento e como se dá a utilização das portas para conectá-lo aos periféricos é
necessário descrever três classes, são elas: MSP430, MSP430Core e MSP430Config.
A classe MSP430 estende MSP430Core, e serve como uma classe intermediária que leva as requisições da interface gráfica, de controle da simulação, para o núcleo
do simulador do microcontrolador, implementada pela classe MSP430Core. Dentre os
métodos que a compõem um dos principais é o cpuloop(), método responsável pela inicialização do laço de execução de instruções do microcontrolador. Esse laço de execução
realiza as atividades de buscar as instruções, decodificá-las e executá-las. O Algoritmo
4.1 fornece uma visão geral da implementação do laço de execução de instruções.
4.2 Componentes
63
Algoritmo 4.1: Laço de Execução de Instruções no Simulador MSPSim
enquanto estiver executando faça
executeEventosDeCiclo(cicloAtual);
executeEventoDeTempo(tempoAtual);
/*Busca as instruções, cp quer dizer Contador de Programa*/
op = memoria[cp++] | (memoria[cp++] « 8);
instrucao = decodificarInstrucao(op);
switch instrucao do
case MOV
destino = lerOrigem(op);
ciclo += CICLOS_MOV;
endsw
case ADD ...
endsw
fim
O laço de execução de uma instrução verifica o estado do microcontrolador, ou
seja, verifica se ele ainda está em execução. Enquanto estiver em execução, é verificado
se há eventos de ciclo para serem executados naquele ciclo, e se há eventos de tempo para
serem executados naquele momento.
Após a verificação e a execução dos eventos é feito a busca da instrução da
memória e a atualização do endereço do contador de programa para a próxima instrução.
O processo de decodificação da instrução consiste em decodificar uma série de bits em
um código (número inteiro) referente a uma instrução. Com esse código identifica-se a
instrução e como ela deve ser executada.
No caso desse algoritmo há o exemplo da instrução MOV, que busca dados de
uma origem e os copiam em um destino. Como no simulador essa operação é executada
com uma única operação de atribuição, não correspondendo com o número real de
ciclos de trabalho do microcontrolador, deve-se adicionar o número de ciclos reais que
o microcontrolador levaria para executar essa instrução à variável que mantém o número
de ciclos de trabalho. E assim é feito para a execução de todas as instruções.
Os métodos implementados pela classe MSP430 são implementações alto-nível
que fazem chamadas aos métodos herdados da classe MSP430Core. No caso do laço de
execução de instruções, a própria decodificação da instrução e sua execução é implementada pelo método emulateOP() da classe MSP430Core.
Assim, a classe MSP430Core implementa o núcleo de execução do microcontrolador, fazendo a simulação de fato, do conjunto de instruções, recebendo a instrução e
implementando a estrutura de switch-case (caso-faça) contendo todos os casos para cada
4.2 Componentes
64
tipo de instrução do microcontrolador MSP430, como o JMP, PUSH, MOV, etc. Encontrase também os métodos que controlam os registradores e que enviam e recebem dados dos
dispositivos de entrada e saída, memórias e portas, além de executar os eventos de ciclo e
de tempo.
Com o objetivo de fazer a escrita e leitura de dados, a classe MSP430Core
possui um objeto chamado currentSegment (segmento atual), esse objeto é da interface
Memory, e possui a implementação dos métodos de leitura e escrita. Esses métodos
apenas escrevem ou leem dados de um objeto chamado memorySegments (segmentos de
memória), como ilustra o trecho do Código 4.1.
Código 4.1 Código do currentSegment da classe MSP430Core
1
Memory currentSegment = new Memory() {
2
@Override
3
public int read(int address, AccessMode mode,
4
AccessType type) {
5
//...
6
return memorySegments[address >> 8].
read(address, mode,type);
7
}
8
9
}
O objeto memorySegments é um vetor do tipo Memory e possui 256 posições.
Nessas posições há objetos do tipo RAMSegment, FlashSegment e IOSegment, sendo esses
objetos representações de segmentos de memória RAM, memória Flash e unidades de
entrada e saída. Desta forma, ao acessar a posição memorySegments[address >> 8]
é retornado um dos objetos de segmentos mencionados anteriormente e executado seus
métodos de leitura ou escrita.
Cada um desses objetos de segmento possui um vetor chamado mem. No caso
do IOSegment, o vetor mem é do tipo IOUnit (unidade de entrada e saída) e possui 512
posições contendo objetos do tipo DMA, ADC12, USART, IOPort, dentre outros. Dessa
forma, ao executar o método de leitura e escrita, é acessado o vetor mem na posição do
endereço passado, escrevendo ou lendo o dado da unidade de entrada e saída.
É importante ressaltar que o valor contido na variável address (endereço),
utilizada para acessar o índice do vetor memorySegments, determina o tipo de segmento
que está tentando ler ou escrever dados, e que o mesmo endereço é utilizado pelos objetos
de segmento para acessar um tipo de dispositivo, no caso uma porta de entrada e saída,
4.2 Componentes
65
uma porta USART, um conversor análogico digital (ADC12), etc. Sendo que esses são
dispositivos internos4 que compõem o microcontrolador.
O valor de endereçamento da variável address para acessar os dispositivos variam de acordo com a família do microcontrolador MSP430. A plataforma SHIMMER,
por exemplo, utiliza a família MSP430F1611. As mudanças de uma família para outra
relevantes para o simulador é o endereçamento desses dispositivos, desta forma, a atribuição dos dispositivos a cada endereço é feita de forma dinâmica, de acordo com a família
do microcontrolador que esteja simulando.
Para realizar essa atribuição dinâmica de endereços aos dispositivos tem-se a
classe MSP430Config. Essa é uma classe abstrata que possui, dentre outros métodos e atributos, o método abstrato setup(MSP430Core cpu, ArrayList<IOUnit> ioUnits).
Esse método atribui aos dispositivos faixas de endereçamento. Desta forma, uma aplicação escrita para uma família espera encontrar um dispositivo em um endereço diferente
de um código escrito para outra família. E assim, cada família possui uma classe que estende de MSP430Config e implementa o método de setup, atribuindo aos dispositivos seus
respectivos endereçamentos de acordo com a família. Como ilustra um trecho do Código
4.2 da classe MSP430f1611, que mostra somente a configuração das portas.
Código 4.2 Método setup() do MSP430f1611
1
public int setup(MSP430Core cpu,
ArrayList<IOUnit> ioUnits) {
2
3
//Adiciona as portas 1 e 2
4
ioUnits.add(new IOPort(cpu, 1,4, cpu.memory, 0x20));
5
ioUnits.add(new IOPort(cpu, 2, 1, cpu.memory, 0x28));
6
// Adiciona as portas 3,4 e 5,6
7
for (int i = 0, n = 2; i < n; i++) {
ioUnits.add(new IOPort(cpu, (3 + i), 0,
8
cpu.memory, 0x18 + i * 4));
9
ioUnits.add(new IOPort(cpu, (5 + i), 0,
10
cpu.memory, 0x30 + i * 4));
11
}
12
13
}
14
Foram descritas as classes que fazem acesso aos dispositivos internos do microcontrolador ao executar instruções de leitura e escrita, porém, ainda assim, é necessário
4 Não
está sendo feito referência aos dispositivos externos utilizados para compor um nodo sensor, como
o rádio, sensores, etc. Esses dispositivos externos serão descritos mais adiante.
4.2 Componentes
66
descrever as duas interfaces que permitem a criação dos dispositivos externos. As interfaces PortListener e USARTListener, ilustrados no Código 4.3, são utilizadas para ligar
os dispositivos externos aos dispositivos IOPort e USART, como ilustrado na Figura 4.8,
como exemplo dos LEDs conectados ao IOPort e o rádio conectado ao USART.
Código 4.3 Interfaces PortListener e UsartListener
1
public interface PortListener {
public void portWrite(IOPort source,
2
int data);
3
4
}
5
6
public interface USARTListener {
public void dataReceived(USARTSource source,
7
int data);
8
9
}
10
As classes IOPort e USART possuem um atributo do tipo PortListener e UsartListener respectivamente. Assim, para conectar um dispositivo externo a uma porta, basta criar uma classe que implemente essas interfaces, obter uma instância de um IOPort através de um objeto do tipo MSP430 (como em
IOPort port1 = cpu.getIOUnit(IOPort.class, "P1")), e se passar como referência para a própria porta, como no código: port1.addPortListener(this).
Assim, quando a porta tiver que escrever dados ao dispositivo, ele chamará o método
portWrite() ou dataReceived() do dispositivo externo.
E assim o simulador se torna extensível, possibilitando a integração do emulador
com dispositivos externos. Um exemplo completo que liga os dispositivos externos com o
microcontrolador de forma a montar um nodo sensor completo será descrito no Capítulo
5 em detalhes.
CAPÍTULO 5
Um Simulador para Redes de Sensores do
Corpo Humano
Este capítulo fornece uma visão geral dos problemas levantados e apresentados
nos capítulos anteriores acerca da arquitetura para RSCH. Também, com base no conteúdo
já apresentado é descrito, de forma detalhada, a solução proposta que auxilia a criação de
outras plataformas de hardware integradas ao simulador MSPSim. E por fim, é relatado
os resultados obtidos, e como se deu a validação da solução proposta.
5.1
Visão Geral
Encontra-se na literatura trabalhos que utilizam RSCH na área da saúde que
testam suas soluções em ambientes e plataformas de hardware inadequadas [14]. Este
fato invalida algumas dessas soluções por não considerarem restrições importantes do
hardware e do ambiente impostas pela área médica.
As plataformas de hardware de RSCH específicas da área da saúde devem ser
leves, esterializáveis, pequenas e construídas com material que não cause irritação à
pele, de forma a não incomodar o usuário e não limitar sua movimentação [4]. Essas
restrições rígidas impostas por esse tipo de aplicação impacta, em várias aspectos, o
projeto da solução, não podendo ser consideradas como parte de uma solução adequada
as plataformas que não levarem em consideração essas restrições.
Por outro lado, uma plataforma de hardware adequada, ou seja, que leva essas
restrições em consideração geram nodos sensores com recursos mais limitados. Um dos
exemplos dessas limitações é resultado da diminuição do tamanho do nodo sensor.
O tamanho de um nodo sensor é afetado principalmente pelo tamanho de sua
bateria, de forma que quanto menor for seu tamanho, menor é a sua capacidade energética.
Assim, quanto mais restrições se impor a plataforma, menos recursos são providos, o que
impacta diretamente no projeto de seu software, que se torna uma tarefa complexa e que
demanda bastante cuidado na criação e teste.
5.1 Visão Geral
68
Os impactos sofridos pelo software por parte do hardware invalida soluções
propostas por projetos que testam seus software em plataformas inadequadas. Pois o
software desenvolvido para uma plataforma inadequada pode não levar em consideração
as restrições de recurso presentes nas plataformas adequadas.
Além dos problemas de restrição de recursos do hardware, a área da saúde, por
ser uma área crítica por lidar com vidas, exige a implementação de softwares tolerante a
falhas, com alta disponibilidade, alta acurácia dos dados sensoriados e um alto nível de
segurança dos dados trafegados, o que demanda ferramentas que fornecem um ambiente
adequado de teste dessas aplicações.
Dessa forma, com o objetivo de prover um ambiente que facilite o desenvolvimento de software levando em consideração as restrições exigidas da área, é proposto um
simulador da plataforma SHIMMER. A plataforma SHIMMER, descrita no Capítulo 3, é
uma plataforma comercial desenvolvida especificamente para atender os desafios da área
da saúde.
A simulação dessa plataforma de hardware tem por objetivo auxiliar o teste
de aplicações de RSCH vestíveis na área da saúde, tornando possível e facilitando
tarefas como: depuração de aplicações para achar erros e verificar o comportamento dos
algoritmos ao serem executados, teste da solução ao inserir pacotes de dados malicioso
ou defeituosos e dados faltosos provindos do sensores. Essas funcionalidades tornam
possível o teste da aplicação, em termos da acurácia, tolerança a falhas e segurança, além
do comportamento da solução em uma plataforma de hardware que leva em consideração
as restrições demandadas da área de saúde.
A solução aqui descrita contempla as necessidade daqueles que possuem ou não a
plataforma SHIMMER real. Pois, apesar dessa plataforma possuir JTAG para depuração
do código, depurar uma aplicação utilizando esse método demanda muito tempo, além
de ser desgastante visto sua dificuldade como descrito no Capítulo 4. Levando isso em
consideração, o simulador provê uma forma menos dispendiosa e que demanda menos
tempo para teste de aplicações em uma plataforma de hardware específica de RSCH, de
forma a não precisar gravar o programa na memória flash do dispositivo que possui um
número limitado de gravações, aumentando, assim, o tempo de vida útil da plataforma.
O simulador da plataforma SHIMMER foi construído utilizando da plataforma
MSPSim. O MSPSim, como descrito no Capítulo 4, é uma plataforma de código aberto
escrita em JAVA que permite a simulação de códigos compilados para o microcontrolador
MSP430. Essa plataforma possui a implementação de outras plataformas de hardware de
RSSF como TMoteSky, ESB e WiSMOTE.
A plataforma de hardware SHIMMER foi construída, contemplando os dispositivos básicos para seu funcionamento, sendo esses: o microcontrolador MSP430F1611,
incluindo seus dispositivos internos, como as portas de entrada e saída (IOPorts) e USART
5.2 Funcionalidades
69
descritos nos capítulos anteriores, e os dispositivos externos como o rádio CC2420, os
LEDs e um eletrocardiograma (ECG). Alguns desses dispositivos foram aproveitados de
outras plataformas implementadas no próprio MSPSim e serão apenas reutilizados, enquanto outros dispositivos foram construídos e incorporados na solução.
Espera-se com este trabalho fornecer um ambiente de auxilio ao desenvolvimento de aplicações para a plataforma SHIMMER, sendo possível a execução, depuração
e o acompanhamento da execução do código binário de aplicações para área da saúde ao
utilizarem o rádio, LEDs e um eletrocardiograma (ECG).
É importante ressaltar que o escopo deste trabalho leva em consideração apenas a
implementação dos dispositivos citados e que compõe o básico da plataforma. No entanto
a plataforma real abrange outros dispositivos como sensores de oxímetro de pulso, GPS,
acelerômetro, bluetooth, dentre outros que não fazem parte do escopo deste trabalho.
5.2
Funcionalidades
As funcionalidades do simulador são basicamente as mesmas oferecidas pela
plataforma MSPSim. Dessa forma, os desenvolvedores de aplicações da plataforma
SHIMMER podem utilizar as seguintes funcionalidades no auxílio do desenvolvimento
de aplicações para área médica:
• Simulação da execução de aplicações escritas em qualquer linguagem para a
plataforma SHIMMER;
• Simular aplicações que utilizam sensores da área da saúde;
• Simular o envio e o recebimento de dados entre nodos sensores;
• Depuração de aplicações escritas para SHIMMER, mesmo enquanto troca mensagens na rede; e
• Monitoramento da plataforma de hardware simulada com gráficos em tempo real
do ciclo de trabalho, monitoramento da pilha de execução, dentre outras variáveis.
As funcionalidades oferecem ao desenvolvedor uma plataforma para simular
aplicações escritas o hardware SHIMMER, com a finalidade de auxiliá-lo a encontrar
erros de lógica na aplicação, além da capacidade de acompanhar o comportamento de seu
algoritmo ao ser executado.
Contudo, não é foco do simulador verificar questões de uso de contas com pontos
flutuantes ou o uso energético do dispositivo, por exemplo. Essas questões demandaria a
utilização do hardware real, ou a extensão do simulador que proveria a simulação dessa
funcionalidade.
5.3 Arquitetura
5.3
70
Arquitetura
No Capítulo 4 foi descrito em detalhes a plataforma de simulação MSPSim,
incluindo as principais classes que compõem o núcleo da arquitetura do simulador,
sendo elas o MSP430, MSP430Core e MSP430Config. Também foram detalhados alguns
dispositivos internos como o IOPort e USART e algumas classes e interfaces responsáveis
por conectar o microcontrolador aos dispositivos externos.
Apesar da solução utilizar o simulador MSPSim, a arquitetura da solução inclui
classes importantes que não foram abordadas anteriormente, por estarem mais relacionadas à solução do que com o próprio MSPSim, são as classes ShimmerNode, ShimmerGUI
e outras que estão relacionadas a essas. Assim, a partir da Figura 5.1 será detalhado na
próxima seção a arquitetura de forma a mostrar o que é específico da solução e o que é do
próprio MSPSim, e como se dá a integração dos componentes da arquitetura.
Figura 5.1: Arquitetura da Plataforma de Hardware SHIMMER no
MSPSim
A Figura 5.1 é uma adaptação da Figura 4.8 ressaltando detalhes específicos
do simulador da plataforma SHIMMER. Os principais componentes da arquitetura da
solução é o microcontrolador, núcleo do simulador MSPSim, juntamente com seus
dispositivos internos (IOPort, USART, ADC12 e DMA). Como dispositivos externos
fazem parte o rádio (CC2420), aproveitado da plataforma MSPSim, os LEDs, que também
foram aproveitados, e o sensor eletrocardiograma (ECG) implementado especificamente
para essa solução. Apesar de aproveitado a implementação de alguns componentes,
estes tiveram que ser conectados ao microcontrolador de forma específica e própria do
SHIMMER. Pois as aplicações escritas para uma dada plataforma não funcionam quando
5.3 Arquitetura
71
executadas em outra, mesmo sendo compostas pela mesma família do microcontrolador
e utilizando os mesmos componentes externos (rádio e LED).
O motivo para que códigos escritos para plataformas diferentes que utilizam o
mesmo microcontrolador e os mesmos dispositivos externos não funcionarem está nas
diferentes formas de integração dos dispositivos com as portas. Apesar dos dispositivos
serem os mesmos, o número da porta difere. Um exemplo é se compararmos as plataformas TMoteSky e SHIMMER, o LED na primeira plataforma é conectada na porta cinco,
já na segunda plataforma esse mesmo dispositivo é conectado na porta quatro.
Por conta dessas diferenças, o simulador da plataforma SHIMMER foi construído seguindo o guia de seu hardware [45]. Esse guia mostra todo o projeto do hardware
da plataforma física, incluindo o número das portas que os dispositivos externos estão
conectados com o microcontrolador da plataforma, assim como a sequência de bits que
ativa seu comportamento. Toda essa configuração na plataforma MSPSim é feita na classe
ShimmerNode que será detalhada na Seção 5.4, que descreverá os detalhes de implementação.
A classe ShimmerNode, juntamente com a classe ShimmerGUI, como citado
anteriormente, formam as principais classes que compõem a solução. A Figura 5.2 mostra
como se dá a integração dessas classes com o simulador MSPSim.
Figura 5.2: Principais classes da solução ligadas ao simulador
5.4 Implementação
72
A integração da solução com a plataforma MSPSim se dá simplesmente pela
extensão da classe GenericNode. Esta por sua vez, se relaciona com as classes que formam
o núcleo da plataforma de simulação MSPSim, as classes MSP430 e MSP430Core.
A classe GenericNode é uma classe abstrata que permite a ligação de novos
nodos sensores ao simulador MSPSim. Dessa forma, todo nodo sensor que for implementado na plataforma MSPSim deve estendê-la. O principal método da classe GenericNode
é seu método abstrato setupNode(), e é através dele que se dá a integração com o nodo
sensor desenvolvido. Esse método é chamado durante a inicialização do simulador MSPSim, e serve para configurar e conectar os dispositivos externos da plataforma com suas
respectivas portas. Esse método será mostrado em detalhes na Seção 5.4.
Além disso, é através dessa classe que os componentes gráficos de interação
(descritos no Capítulo 4), que permitem o usuário controlar a simulação, se integram
com o núcleo do microcontrolador, executando os comandos de iniciar o processamento,
executar passo-a-passo, adicionar breakpoints, etc. Assim, eventos que surgem nos componentes gráficos de interação, resultado da ação dos usuários, são passados para a classe
GenericNode que chama os respectivos métodos na classe MSP430.
5.4
Implementação
A implementação da solução engloba basicamente as classes ShimmerNode e
ShimmerGUI. Também, para propósito deste trabalho, foi implementado a classe ECG
para testes de aplicações escritas para o SHIMMER que utilizam esse sensor. Alguns
métodos de outras classes também serão descritos com o objetivo de ter uma descrição
mais completa e clara do processo de desenvolvimento de um nodo sensor na plataforma
MSPSim.
A classe ShimmerNode, como ilustra a Figura 5.2, estende a classe abstrata
GenericNode e implementa seu método setupNode(). Basicamente a implementação
desse método, como dito anteriormente, configura e conecta os dispositivos externos que
fazem parte do nodo sensor às portas corretas, dessa forma, como a solução contempla
somente os dispositivos externos rádio, LEDs e um sensor, a implementação de cada um
desses elementos serão descritos separadamente.
É importante ressaltar que esses componentes externos, implementados na solução aqui descrita, ilustra praticamente todas as formas de conectar dispositivos externos
nessa plataforma de simulação, dado que cada um é conectado de uma forma diferente.
Sendo assim, o processo que se deu para implementação da plataform SHIMMER no
MSPSim, descrito a seguir, servirá de base para a construção de outros sensores deste
mesmo nodo sensor, e outros dispositivos externos como o próprio módulo Bluetooth dis-
5.4 Implementação
73
ponível pela plataforma real. Além de poder servir como guia para a criação de novas
plataformas de hardware no MSPSim.
5.4.1
LEDs
Na implementação dos LEDs, sua própria classe foi aproveitada da estrutura do
simulador MSPSim, e pode ser reaproveitada para qualquer outra plataforma de nodo
sensor que for construída para essa plataforma de simulação, independente do número de
LEDs presentes no nodo sensor.
Como descrito anteriormente, o primeiro método executado é o setupNode()
estendido da classe abstrata GenericNode e chamado por ela mesma durante o fluxo de
inicialização da plataforma de simulação. Neste método, como ilustrado no Código 5.1,
deve-se configurar o dispositivo externo e conectá-lo em sua respectiva porta, sendo essa
especificada pelo guia de hardware do nodo sensor que esteja implementando.
Código 5.1 Configuração e Conexão do LED com sua Respectiva Porta - SHIMMER
1
public void setupNode() {
2
// led
3
leds = new Leds(cpu, LEDS);
4
port4 = cpu.getIOUnit(IOPort.class, "P4");
5
port4.addPortListener(this);
6
}
No caso dos LEDs, o processo de configuração e conexão é bastante simples.
A comunicação com esse dispositivo externo, como descrito no guia do hardware do
SHIMMER, é dado pela porta quatro. Para fazer essa integração basta instanciar um
objeto da classe LED, como ilustrado no código, obter uma instância do microcontrolador,
sendo ela provida pela classe GenericNode, e obter a porta quatro.
Durante o Capítulo 4 foi descrito a interface PortListener. Essa interface serve
basicamente para conectar dispositivos externos aos objetos IOPort que representam as
portas de entrada e saída. O que de fato acontece é a conexão do nodo sensor com a
porta. Como ilustrado no código, no trecho port4.addPortListener(this), a instância
que se passa é da própria classe ShimmerNode, devendo esta implementar a interface
PortListener e consequentemente o método portWrite(IOPort source, int data).
Assim, quando o microcontrolador executar uma operação de escrita na porta
quatro, ela irá chamar o método portWrite() da instância PortListener que tiver,
passando sua própria instância, no caso o objeto IOPort da porta quatro, além do dado
que deverá ser escrito na porta, sendo este dado, no caso dos LEDs, qual deve ser ligado.
5.4 Implementação
74
Com isso o código executado pelo microcontrolador que envia um dado à porta
quatro chegará na instância da classe ShimmerNode em seu método portWrite(), e a
partir daí cabe a plataforma simular o comportamento da plataforma física, no caso dos
LEDs, acendê-los ou apagá-los. Como mostra parte da implementação do portWrite()
no Código 5.2.
Código 5.2 Método portWrite() na Simulação dos LEDs SHIMMER
1
public void portWrite(IOPort source, int data) {
2
// led
3
if (source == port4) {
4
redLed = data == RED_LED;
5
blueLed = data == BLUE_LED;
6
greenLed = data == GREEN_LED;
7
leds.setLeds((redLed ? 1 : 0) + (greenLed ? 2 : 0)
8
+ (blueLed ? 4 : 0));
9
10
}
O código utiliza o método setLeds() da classe LED para fazer a simulação
do comportamento dos LEDs. Esse método basicamente muda o estado do componente
que irá refletir na interface gráfica do simulador, neste caso, fazendo eles acenderem ou
apagarem.
Os dispositivos externos, no geral, estendem a classe Chip, que implementa as
funções básicas que um chip deveria implementar dentro da plataforma MSPSim. Uma
dessas funções é a representação de seu estado, de forma a conseguir notificar seu estado
atual a qualquer classe que tenha interesse. Dentro do contexto dos LEDs, a classe que
tem interesse em seu estado é interface gráfica, representada pela classe ShimmerGUI,
que deve refazer a imagem dos LEDs a cada mudança de seu estado.
O Código 5.3 mostra como se dá a notificação da mudança de estado do LED
à interface gráfica. No processo de inicialização do simulador, o método setupNode()
implementado pela classe ShimmerNode cria uma instância da classe ShimmerGUI e
chama seu método setupGUI() lhe passando sua própria instância. Esse método acessa
o objeto led criado pela classe ShimmerNode passando seu atributo ledsListener. Esse
atributo é uma instância da interface StateChangeListener que implementa o método
stateChanged() que renderiza a interface gráfica atualizando o estado dos LEDs quando
executada. Assim, uma vez que é alterado o estado dos LEDs com o método setLeds(),
a própria classe Leds executa o método stateChanged(), herdado da classe Chip,
renderizando a interface do simulador.
5.4 Implementação
75
Código 5.3 Como o StateListener é Usado para Repintar a
Interface Gráfica do Simulador - SHIMMER
1
public class Leds extends Chip {
2
// ...
3
public void setLeds(int leds) {
if (this.leds != leds) {
4
5
this.leds = leds;
6
stateChanged(leds);
}
7
}
8
9
}
10
11
public class Chip {
public void stateChanged(int newState) {
12
13
// ...
14
int oldState = chipState;
15
chipState = newState;
16
// ...
17
listener.stateChanged(this, oldSatet,
chipState);
18
}
19
20
}
21
22
public class ShimmerGUI {
23
// ...
24
private final StateChangeListener ledsListener =
new StateChangeListener() {
25
public void stateChanged(Object source, int oldState,
26
int newState) {
27
repaint(LEDS_BOUNDS);
28
}
29
}
30
31
public void setupGUI() {
32
33
// node e uma instancia de ShimmerNode
34
node.getLeds().addStateChangeListener(ledsListener);
35
}
36
// ...
37
};
5.4 Implementação
5.4.2
76
Rádio (CC2420)
A implementação da classe CC2420 do rádio, também foi aproveitada da plataforma MSPSim, e pode ser aproveitada na construção de outros nodos sensores que utilizam o rádio CC2420. Entretanto, da mesma forma que os LEDs, mesmo aproveitando
a implementação do dispositivo, deve-se ter o cuidado de conectá-lo às portas certas, seguindo o guia de descrição do hardware da plataforma que está se implementando.
O rádio, em comparação com os LEDs, é um pouco mais complexo, levando em
consideração o número de interfaces que se deve implementar para executá-lo. Contudo,
também deve-se começar sua configuração no método setupNode(), como mostra o
Código 5.4.
Código 5.4 Configuração e Conexão do Rádio com suas Respectivas Portas - SHIMMER
1
public void setupNode() {
2
// cc2420
3
radio = new CC2420(cpu);
4
port1 = cpu.getIOUnit(IOPort.class, "P1");
5
port2 = cpu.getIOUnit(IOPort.class, "P2");
6
port5 = cpu.getIOUnit(IOPort.class, "P5");
7
port5.addPortListener(this);
8
USART usart = cpu.getIOUnit(USART.class, "USART1");
9
usart.addUSARTListener(this);
10
radio.setCCAPort(port2, CC2420_CCA);
11
radio.setFIFOPPort(port1, CC2420_FIFOP);
12
radio.setFIFOPort(port1, CC2420_FIFO);
13
radio.setSFDPort(port1, CC2420_SFD);
14
}
Para fazer a conexão do rádio na plataforma SHIMMER, como mostra o código,
faz-se necessário as portas um, dois e cinco. Entretanto, diferentemente do LED que
somente é criada uma instância de sua classe e feita a conexão do nodo sensor com a
porta quatro, o rádio necessita que se faça esse mesmo processo somente com a porta
cinco, e um processo diferente com as portas um e dois. Isso se dá porque a porta cinco
recebe comandos provindos do microcontrolador para o rádio, ao contrário das portas um
e dois, usadas pelo rádio para sinalizar estados para o microcontrolador.
Os comandos do microcontrolador enviados para o rádio são mostrados no Código 5.5, e são repassados para o rádio através de seus métodos
radio.setChipSelect() e radio.setVRegOn(). Cada um desses métodos é res-
5.4 Implementação
77
ponsável por ativar diferentes funcionalidades no radio CC2420 e serão descritos separadamente.
Código 5.5 Método portWrite() na Simulação dos LEDs SHIMMER
1
public void portWrite(IOPort source, int data) {
if (source == port5) {
2
radio.setChipSelect((data &
3
CC2420_CHIP_SELECT) == 0);
4
radio.setVRegOn((data & CC2420_VREG) != 0);
5
}
6
7
}
Na plataforma real, o VReg (Voltage Regulator) é responsável por alimentar o
dispositivo com uma voltage uniforme. No simulador, o método radio.setVRegOn(),
da mesma forma, é responsável por ligar/desligar o rádio. A constante CC2420_VREG
guarda o valor inteiro representado pelo número binário 1000000 (no caso específico da
plataform SHIMMER), dessa forma, pra que se passe o valor true para o método, o valor
de data deve conter o valor um para o sétimo bit.
A implementação desse método, na classe CC2420 consiste basicamente em
verificar se o estado (true ou false) coincide com o estado anterior do dispositivo.
Caso coincida, nada é feito, mas se o valor difere, para o valor false o estado de
funcionamento do dispositivo é simplesmente definido para desligado. Caso seja true
o método adiciona um evento para inicializar o rádio pelo método definido no objeto
vregEvent. Este método, quando executado, altera o estado para seu estado primário,
definido como POWER_DOWN, como ilusta o Código 5.6.
5.4 Implementação
78
Código 5.6 Método setVRegOn do dispositivo CC2420 SHIMMER
1
public void setVRegOn(boolean newOn) {
if (on == newOn)
2
return;
3
if (newOn) {
4
cpu.scheduleTimeEventMillis(vregEvent, 0.05);
5
} else {
6
7
on = false;
8
setState(RadioState.VREG_OFF);
}
9
10
}
11
12
private TimeEvent vregEvent =
new TimeEvent(0, "CC2420 VREG") {
13
public void execute(long t) {
14
15
on = true;
16
setState(RadioState.POWER_DOWN);
17
updateCCA();
}
18
19
};
Já o método setChipSelect() é responsável apenas por permitir a interação
com os registradores do rádio, como definido no funcionamento do dispositivo [46]. Na
plataforma física, para interagir com os registradores do CC2420, é necessário solicitar o
padrão SPI (Serial Peripheral Interface). Esse padrão define a comunicação do microcontrolador a diferentes dispositivos seguindo o modo mestre/escravo. Neste caso, o microcontrolador funciona como mestre e pode se comunicar com diversos escravos, fazendo a
diferenciação entre eles através de um seletor, no caso o chip select.
A simulação do chip select pela classe CC2420 é bastante simples. O microcontrolador envia para a porta cinco o comando para selecionar o rádio, como ilustrado no
Código 5.5, representado pela variável data. Esse valor é então comparado com a constante CC2420_CHIP_SELECT. Essa constante possui um valor inteiro cuja representação
em binário é 10000, dessa forma o valor do chip select só vai ser ativada (ter o valor
true) quando o quinto bit de data for igual a zero, sendo false para os outros casos.
A ativação do chip select, como na plataforma física, permite que dados sejam
lidos e escritos no rádio. A leitura e escrita desses dados se dá pela classe USART que
implementa, de certa forma, o padrão SPI. Assim, quando há a necessidade de troca de
dados com o rádio, o método handleTransmit() da classe USART é chamado por um
5.4 Implementação
79
evento executado pelo microcontrolador, chamando assim o método dataReceived() da
interface USARTListener, que neste caso é uma instância do ShimmerNode passado para
a classe USART ao configurar o rádio, no método setupNode().
O método dataReceived() foi descrito no Capítulo 4 e permite que o microcontrolador possa trocar dados com os dispositivos externos que compõem o nodo sensor.
Neste caso, a classe ShimmerNode implementa o método dataReceived() repassando
os dados provindos da classe USART para o mesmo método (dataReceived()) da classe
CC2420, possibilitando assim a troca de dados do microcontrolador e o rádio. No momento em que o método dataReceived() na classe CC2420 é executado, como ilustra
o Código 5.7, se verifica a condição do chip select, barrando a execução do método caso
seu valor não tenha sido definido como true.
Código 5.7 Método dataReceive da Classe CC2420 - SHIMMER
1
public void dataReceived(USARTSource source, int data) {
2
int oldStatus = status;
3
if (!chipSelect) {
4
} else if (stateMachine != RadioState.VREG_OFF) {
5
switch (state) {
6
// ...
7
}
8
}
9
10
}
As portas um e dois, como dito anteriormente, ao invés de receberem comandos do microcontrolador para ligar o rádio, ou requererem permissão para acesso
dos dados pelo USART, enviam sinais de estado para o microcontrolador. No método
de configuração do rádio foram executados quatro métodos da classe CC2420, são
eles setCCAPort(), setFIFOPPort(), setFIFOPort() e setSFDPort(), que recebem
como parâmetro as portas para o envio de seus sinais de controle.
O método setCCAPort, tem por objetivo definir a porta para envio dos sinais
de CCA (Clear Channel Assessment), que verifica se o canal de comunicação está
vazio para transmissão do dado e evitar colisão de pacote. O CCA verifica o canal de
comunicação seguindo a premissa básica de que os pacotes sendo transmitidos carregam
uma intensidade de sinal, chamada RSSI (Received Signal Strenght Indication), e a
partir da intensidade desse sinal é inferido se o canal de comunicação está limpo para
realização da transmissão dos dados. Sendo assim, o CC2420 comunica o estado do canal
de comunicação à porta passada pelo método setCCAPort, na simulação após verificar o
5.4 Implementação
80
estado do canal de comunicação do rádio é definido a voltagem do pino 0x07 da porta dois
para o valor IOPort.PinState.HI, ou IOPort.PinState.LOW, dependendo do estado
do canal, como ilustra o Código 5.8.
Código 5.8 Método setCCA da Classe CC2420 - SHIMMER
1
private void setCCA(boolean cca) {
2
currentCCA = cca;
3
if ((registers[REG_IOCFG0] & CCA_POLARITY) ==
4
CCA_POLARITY)
5
ccaPort.setPinState(ccaPin, cca ?
6
IOPort.PinState.LOW
7
: IOPort.PinState.HI);
else
8
ccaPort.setPinState(ccaPin, cca ?
9
10
IOPort.PinState.HI
11
: IOPort.PinState.LOW);
12
}
O método setFIFO() define a porta que receberá o sinal de aviso quando
chegarem os primeiros bytes na fila do rádio, o FIFO (First In First Out) não é uma
referência direta a própria fila, mas sim um evento de notificação de que chegaram dados.
No caso do SHIMMER, esse sinal deverá ser enviado para a porta um no pino 0x05, como
mostra o Código 5.9.
Código 5.9 Método setFIFO da Classe CC2420 - SHIMMER
1
private void setFIFO(boolean fifo) {
2
currentFIFO = fifo;
3
if ((registers[REG_IOCFG0] & FIFO_POLARITY)
4
== FIFO_POLARITY) {
5
fifoPort.setPinState(fifoPin, fifo ?
6
IOPort.PinState.LOW
: IOPort.PinState.HI);
7
} else {
8
fifoPort.setPinState(fifoPin, fifo ?
9
10
IOPort.PinState.HI
11
: IOPort.PinState.LOW);
}
12
13
}
5.4 Implementação
81
De forma semelhante, define-se pelo método setFIFOP() a porta que receberá
os sinais de quando o número de bytes da fila ultrapassar o tamanho máximo estipulado,
para esse evento (referenciado como FIFOP) a porta que receberá o sinal é a um no pino
0x00. O método setFIFOP() é representados pelo Código 5.10.
Código 5.10 Método setFIFOP da Classe CC2420 - SHIMMER
1
private void setFIFOP(boolean fifop) {
2
currentFIFOP = fifop;
3
if ((registers[REG_IOCFG0] & FIFOP_POLARITY)
4
== FIFOP_POLARITY) {
5
fifopPort.setPinState(fifopPin, fifop ?
6
IOPort.PinState.LOW
7
: IOPort.PinState.HI);
} else {
8
fifopPort.setPinState(fifopPin, fifop ?
9
10
IOPort.PinState.HI
11
: IOPort.PinState.LOW);
}
12
13
}
Por fim, o rádio necessita de configurar o SFD (Start Frame Delimiter). Esse
sinal é ativado para indicar que o início de um delimitador de pacote foi detectado, de
forma a indentificar o começo de um novo pacote. O método setSFDPort() define a
porta que receberá o sinal de identificação de início de um novo pacote. A porta que
receberá o sinal é a porta um no pino 0x2, como descrito no Código 5.11.
Código 5.11 Método setSFD da Classe CC2420 - SHIMMER
1
private void setSFD(boolean sfd) {
2
currentSFD = sfd;
3
if ((registers[REG_IOCFG0] & SFD_POLARITY)
4
== SFD_POLARITY)
5
sfdPort.setPinState(sfdPin, sfd ?
6
IOPort.PinState.LOW
7
: IOPort.PinState.HI);
else
8
sfdPort.setPinState(sfdPin, sfd ?
9
10
IOPort.PinState.HI
11
: IOPort.PinState.LOW);
12
}
5.4 Implementação
5.4.3
82
Sensor Eletrocardiograma (ECG)
A plataforma SHIMMER, descrita em detalhes no Capítulo 3, é uma plataforma
de hardware específica para área da saúde. Dessa forma, para ser possível a simulação de
aplicações no simulador nessa área foi desenvolvido o sensor eletrocardiograma (ECG).
Um eletrocardiograma é o registro dos impulsos elétricos originados durante a
atividade cardíaca, esses sinais são coletados através do aparelho eletrocardiógrafo capaz
de capturar os sinais elétricos do coração. O ECG disponível pela plataforma SHIMMER
é o ECG de três pontas (a quarta seria o terra), que são fixadas no peito do paciente, como
ilustrado na Figura 5.3. Com propósito de simplificação, o que será referenciado como
ECG é o próprio sensor disponível pela plataforma SHIMMER.
Figura 5.3: Eletrocardiograma na Plataforma SHIMMER
É importante frisar que o simulador ECG não foi implementado com o objetivo
de simular todo o comportamento de um eletrocardiograma real. Esse sensor foi desenvolvido para permitir a execução de códigos escritos para plataforma SHIMMER que faz o
uso do sensor ECG. Dessa forma, torna-se possível a depuração de código e o acompanhamento do comportamento da aplicação escrita para o SHIMMER no simulador MSPSim.
Assim, é possível verificar a lógica por trás da manipulação do valor coletado do sensor,
depurando o código da aplicação que faz acesso aos dados coletados.
Ademais, a implementação do sensor ECG pode servir de referência na construção de outros sensores, tanto da plataforma SHIMMER quanto de outras, que são integradas ao microcontrolador através dos mesmos dispositivos internos.
O ECG é integrado à plataforma SHIMMER através do ADC12, e seus dados
são enviados para memória através da DMA. A configuração desse sensor na plataforma
5.4 Implementação
83
MSPSim inicia-se no mesmo método que os demais, o método setupNode(), como
ilustra o Código 5.12.
Código 5.12 Método setupNode() do ECG - SHIMMER
1
public void setupNode() {
2
ecg = new ECG(cpu);
3
ADC12 adc = cpu.getIOUnit(ADC12.class, "ADC12");
4
adc.setADCInput(5, new ADCInput() {
public int nextData() {
5
return ecg.getRall();
6
}
7
8
});
9
adc.setADCInput(6, new ADCInput() {
public int nextData() {
10
return ecg.getLall();
11
}
12
});
13
14
}
A configuração do ECG é basicamente sua ligação ao dispositivo ADC12 (Analogic Digital Converter), para isso é obtido sua instância do objeto cpu da classe MSP430
e definido através do método setADCInput() seu índice de entrada e o valor a ser armazenado. Esse índice de entrada serve para posicionar o dado passado ao ADC12 em
seu vetor de armazenamento de dados. Já o valor a ser armazenado é obtido de forma
dinâmica da própria classe do ECG ao implementar o método nextData() da interface
ADCInput.
É necessário destacar que o índice do vetor passado ao ADC12 é definido no
próprio guia de descrição do hardware SHIMMER, assim como o dado a ser mantido
naquela posição. No caso, o dado a ser passado na posição cinco do ADC12 é o dado
concatenado provindo das pontas RA e LL, e da posição seis, os dados das pontas LA LL.
As pontas do ECG e seus respectivos valores são armazenados na própria classe
ECG, e são somente valores constantes, mas que podem ser manipulados pela aplicação
simulada. Para ilustrar as pontas e o local onde elas coletam seus dados é mostrada a
Figura 5.4.
5.5 Testes da Plataforma
84
Figura 5.4: Pontas do ECG
O entendimento do porquê posicionar as pontas nas posições mostradas, e o
próprio funcionamento do eletrocardiógrafo foge do escopo deste trabalho. Essa figura
ilustra somente a origem dos sinais que o simulador trata.
Dessa forma, para implementar um sensor ECG da plataforma SHIMMER
no simulador MSPSim, basta conectá-lo com o dispositivo ADC12, como mostrado
anteriormente, obedecendo a posição de armazenamento, juntamente com qual dado deve
ser passado.
O funcionamento da própria aplicação, que faz a coleta e o tratamento do sinal
do ECG, se encarrega de definir o evento que dispara a conversão do sinal analógico que
chega ao ADC12 para um valor digital, em uma frequência de 200 Hz. Da mesma forma, é
a aplicação que adiciona um evento que executa periodicamente que faz a DMA buscar os
dados no ADC12 e colocá-los em um lugar na memória. O código fonte dessa aplicação
pode ser encontrado no Anexo B.
5.5
Testes da Plataforma
O objetivo deste trabalho foi a implementação da plataforma SHIMMER no
ambiente de simulação MSPSim, de forma a prover aos desenvolvedores de aplicações
da área médica uma ferramenta de alto nível para o teste dessas aplicações, utilizando
5.5 Testes da Plataforma
85
uma plataforma de hardware adequada. Logo, com a finalidade de verificar se o simulador
contemplava as características básicas do hardware real, códigos escritos especificamente
para a plataforma real, encontradas no repositório oficial do TinyOS, foram executadas
no simulador para verificar seu comportamento.
A verificação do comportamento da aplicação sendo executada pelo simulador
foi feita de forma simples e direta. Como a implementação da plataforma simulada
contemplava apenas os componentes de LEDs, rádio e o sensor ECG, foram utilizados
códigos exemplos que exigiam o funcionamento desses três componentes. É importante
notar que as aplicações eram escritas em TinyOS e compiladas para serem executadas
na plataforma de hardware SHIMMER, passando para o simulador somente o arquivo de
execução.
O primeiro componente testado foram os LEDs. Para realizar o teste dos LEDs
duas aplicações exemplos foram utilizadas, foram elas a Blink e a RadioCountToLeds.
A primeira aplicação consiste basicamente no acender e o pagar dos três LEDs em
frenquência diferente. De forma que o primeiro LED acende e apaga em um quarto de
segundo, o segundo LED em meio segundo e o terceiro LED a cada um segundo. Dessa
forma, ao executar a aplicação bastou a observação do acender e o apagar dos LEDs.
A segunda aplicação, o RadioCountToLeds, consiste em enviar de um sensor para
outro o número do LED que deve ser ligado ou desligado. Essa aplicação conta com dois
nodos sensores, de forma que um envia a informação de quais LEDs devem ser ligados e
o outro que recebe os dados e liga os respectivos LEDs.
Dessa forma, essa aplicação serviu para o teste tanto dos LEDs, como do envio
de dados pelo rádio, testando assim o envio e o recebimento de dados entre ambos os
sensores. O componente de rádio também foi testado por um aplicação que foi escrita
usando TinyOS que somente emitia um dado qualquer pelo rádio, de forma que ao simular
foi utilizado o comando no arquivo de configuração. Esse comando força o envio dos
dados que saem do rádio para um arquivo, assim pôde-se verificar também, a formação
do pacote transmitido.
Por último foi testado o sensor do ECG utilizando o código (do Anexo B)
escrito especificamente para a plataforma SHIMMER que obtém os dados do sensor
ECG. Originalmente essa aplicação fazia a coleta dos dados do sensor e os enviava por
Bluetooth, por conta disso ela foi modificada para fazer o envio dos dados pelo rádio.
Para verificar o funcionamento da aplicação no simulador, foi executado a
R verificando se os eventos
plataforma MSPSim no modo de depuração na IDE Eclipse,
para conversão estavam ativando o ADC12, e se o mesmo estava pegando a constante na
classe ECG. Dessa forma, uma vez que o código ativava os componentes que deveria, ela
estava simulando corretamente o mesmo comportamento da plataforma física.
CAPÍTULO 6
Considerações Finais
As RSCH têm um enorme potencial em aberto para aplicações na medicina,
sendo uma delas o monitoramento remoto de indivíduos. Esse monitoramento pode
ser utilizado no auxílio da infraestrutura de prestação de serviço de saúde em diversos
cenários, servindo como tecnologia para o apoio de diagnóticos, monitoramento de sinais
vitais para a prevenção de doenças ou acompanhamento de tratamentos.
Todavia, um estudo dos projetos que utilizam essa tecnologia para auxiliar
na solução de problemas da área médica aponta uma necessidade de ferramentas que
auxiliem no desenvolvimento de aplicações de qualidade, principalmente ao levar em
consideração a criticidade das aplicações da área da saúde, sendo elas utilizadas em
cenários nos quais vidas de seres humanos podem estar em risco.
Assim, este trabalho apresenta um simulador para aplicações de RSCH, simulando a plataforma de hardware comercial SHIMMER, específica da área médica. Esse
simulador beneficia a área da saúde oferecendo um ambiente de teste de baixo custo e alto
nível para aplicações específicas da área. Esse ambiente de simulação fornece funcionalidades essenciais para que aplicações possam ser devidamente testadas com objetivo de
garantir sua qualidade.
O simulador foi escrito utilizando o MSPSim, uma plataforma de código aberto
que simula a nível de instrução o microcontrolador MSP430. Essa plataforma possui dispositivos externos ligados ao seu microcontrolador, de forma a compor simuladores completos de nodos sensores. Além disso, a plataforma se mostra extensível a ponto de fornecer formas de integração de novos dispositivos externos com seu núcleo, possibilitando a
criação de outros nodos sensores.
Dessa forma, a utilização dessa plataforma para construir o simulador do nodo
sensor SHIMMER foi essencial para atingir os objetivos deste trabalho. Assim foi possível implementar o ambiente de RSCH capaz de simular aplicações escritas em qualquer
linguagem, bastando somente o fornecimento do código binário resultado do processo de
compilação. Além disso, a solução pôde contar com a depuração do código simulado de
forma a verificar seu comportamento, mesmo ele estando trocando mensagens em uma
rede, além de ser possível acompanhar, em porcentagem, o uso dos dispositivos que for-
6.1 Trabalhos Futuros
87
mam o nodo sensor.
Por fim, acredita-se que este trabalho contribuiu com o amadurecimento da
tecnologia, provendo o simulador de RSCH como ferramenta que auxilia na construção
de aplicações de qualidade, e que garantam requisitos fundamentais às aplicações na área
médica com alto nível de tolerância à falhas, disponibilidade, dentre outras características
demandadas da área da saúde.
6.1
Trabalhos Futuros
O escopo deste trabalho, apesar de suas contribuições e benefícios para o
desenvolvimento de aplicações para área médica, conteve-se somente a criação de um
simulador da plataforma de hardware SHIMMER, concentrando-se apenas nos aspectos
de simulação do comportamento da plataforma ao executar aplicações, como descrito nos
objetivos deste trabalho.
Dessa forma, como trabalhos futuros, julga-se importante pensar em uma plataforma de simulação completa, capaz de não só prover a simulação da plataforma de
hardware, mas também oferecer formas de criar visualmente topologias de RSCH para o
teste dessas aplicações, a partir da plataforma SHIMMER criada no MSPSim.
Como forma de prover esse ambiente, a utilização da plataforma MSPSim
como base de desenvolvimento do simulador do SHIMMER facilita a criação dessa
funcionalidade. Como descrito anteriormente, o MSPSim se integra a plataforma COOJA
que oferece um ambiente de simulação mais completo, capaz de permitir a simulação de
uma rede de sensores heterogênia e a criação de topologias de redes.
Portanto, é importante a verificação da integração da plataforma COOJA e
MSPSim para criação de topologias de redes de sensores com o hardware SHIMMER para
testes de aplicações. Ademais, a modificação da interface gráfica do simulador COOJA
para disposição dos nodos sensores em um corpo humano, além de adicionar regras de
simulação que aproxime o ambiente de teste dessas aplicações com o ambiente médico,
como simular ruídos causados pelo corpo humano, é desejável.
6.2
Publicações
No decorrer da realização deste trabalho foram publicados os seguintes artigos,
períodicos e apresentação em congressos e eventos:
6.2 Publicações
6.2.1
88
Publicações em Jornais Científicos Internacionais
• R. V. RODRIGUES FILHO, R. F. BULCÃO NETO, B. O. S ILVESTRE , L.
L. O LI - VEIRA, R. O. O LIVEIRA , I. G. SENE-JÚNIOR An Evaluation
Method of Research on Wearable Wireless Body Area Networks in Healthcare.
International Journal of Computer Science and Information Technology (Print),
2013.
6.2.2
Apresentação de Trabalho em Congresso
• LEMES, M. T. ; BULCÃO-NETO, R. F. ; OLIVEIRA, L. L. G. ; RODRIGUES
FILHO, R. V. ; Sene Júnior, I. G. . Uma Nova Abordagem de Distribuição de
Chaves Criptográficas para o Framework de Segurança TinySec. In: Simpósio
Brasileiro em Segurança da Informação e de Sistemas Computacionais, 2013,
Manaus-AM. XIII Simpósio Brasileiro em Segurança da Informação e de Sistemas
Computacionais, 2013. v. 1. p. 1-5.
• R. V. RODRIGUES FILHO, I. G. SENE-JÚNIOR TinyOS: Teoria e Prática IN:
X Encontro Anual de Computação (EnAComp), 2013.
6.2.3
Apresentação de Minicursos
• R. V. RODRIGUES FILHO, I. G. SENE-JÚNIOR TinyOS: Teoria e Prática IN:
I ENCONTRO ANUAL DE TECNOLOGIA DA INFORMAÇÃO - (ENATI), 2013.
Referências Bibliográficas
[1] A. W OOD, G. V IRONE , T. D OAN , Q. C AO, L. S ELAVO, Y. W U, L. FANG , Z. H E , S.
L IN , J. S TANKOVIC ALARM-NET: Wireless sensor networks for assisted-living
and residential monitoring. University of Virginia Computer Science Department
Technical Report (2006)
[2] A. D UNKELS , B. G RONVALL , T. VOIGT
Contiki - A Lightweight and Flexible
Operating System for Tiny Networked Sensors.
Local Computer Networks,
Annual IEEE Conference on In Local Computer Networks, 2004. 29th Annual IEEE
International Conference on, Vol. 0 (November 2004), pp. 455-462
[3] A. B URNS , B. G REENE , M. M C G RATH , T. O’S HEA , B. K URIS , S. AYER , F. S TROI ESCU,
V. C IONCA Shimmer - A Wireless Sensor Platformfor Noninvasive Biome-
dical Research . IEEE Sensors Journal (2010), VOL. 10, 2010.
[4] A. PANTELOPOULOS , N. G. B OURBAKIS A survey on wearable sensor-base systems for health monitoring and prognosis. IEEE TRANSACTIONS ON SYSTEMS,
MAN, AND CYBERNETICS - PART C: APPLICATIONS AND REVIEWS, VOL. 40, NO
1, 2010.
[5] A. F RABOULET, G. C HELIUS , E. F LEURY Worldsens: Development and Prototyping Tools for Application Specific Wireless Sensors Networks. In Proceedings
of the 6th international conference on Information processing in sensor networks
(2007).
[6] B. L. T ITZER , D. K. L EE , J. PALSBERG Avrora: Scalable Sensor Network Simulation with Precise Timing. Proceedings of the Fourth ACM/IEEE International Conference on Information Processing in Sensor Networks In Proceedings of the Fourth
ACM/IEEE International Conference on Information Processing in Sensor Networks
(15 April 2005).
[7] B. L IN , N. C HOU, F. C HONG , S. C HEN Real-time Wireless Physiological Monitoring System (RTWPMS). IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 10, NO. 4, 2006.
Referências Bibliográficas
90
[8] J. E RIKSSON , A. D UNKELS , N. F INNE , F. O STERLIND, T. VOIGT, N. T SIFTES Demo
abstract: Mspsim - An Extensible Simulator for Msp430-Equipped Sensor Boards. In: 5th European Conference on Wireless Sensor Networks (EWSN 2008), 30
Jan - 1 Feb 2008, Bologna, Italy.
[9] K. L ORINCZ , B. K URIS , S. M. AYER , S. PATEL , P. B ONATO, M. W ELSH Wearable Wireless Sensor Network to Assess Clinical Status in Patients with Neurological
Disorders. Proceedings of the 6th international conference on Information processing in sensor networks, Pages 563-564, 2007.
[10] L. R ILISKIS , E. O SIPOV, M. M ARÓTI Tos-ns3: A Framework for Emulating Wireless
Sensor Networks in the NS3 Network Simulator. Workshop on ns-3 in conjuction
with the SIMUTools 2010 Mar. 15 2010 - Mar. 15 2010.
[11] M. A. H ANSON , H. C. P OWELL J R ., A. T. B ARTH , K. R INGGENBERG , B. H. C A LHOUN ,
J. H. AYLOR , J. L ACH Body Area Sensor Networks: Challenges and Op-
portunities. IEEE Computer 42(1): 58-65 (2009).
[12] P. L EVIS , N. L EE Tossim: A Simulator for Tinyos Networks. Technical report, UC
Berkeley, September, 2003.
[13] P. L EVIS , S. M ADDEN , J. P OLASTRE , R. S ZEWCZYK , A. W OO, D. G AY, J. H ILL ,
M. W ELSH , E. B REWER , D. C ULLER Tinyos: An operating System for Sensor
Networks. In Ambient Intelligence (2005), p. 115-148.
[14] R. V. RODRIGUES-FILHO, R. F. BULCÃO-NETO, B. O. S ILVESTRE , L. L. O LI VEIRA ,
R. O. O LIVEIRA , I. G. SENE-JÚNIOR An Evaluation Method of Research
on Wearable Wireless Body Area Networks in Healthcare. International Journal
of Computer Science and Information Technology (Print), 2013.
[15] S. C OYLE , D. M ORRIS , K. L AU, D. D IAMOND Textile-based Wearable Sensors for
Assisting Sports Performance. In BSN 2009 - Body sensor networks, 3-5 June
2009, Berkeley, CA, USA (2009).
[16] S. PATEL , K. L ORINCZ , R. H UGHES , N. H UGGINS , J. H. G ROWDON , M. W ELSH ,
P. B ONATO Analysis of Feature Space for Monitoring Persons with Parkinson
Disease with Application to a Wireless Wearable Sensor System. In Proc. 29th
IEEE EMBS Annual International Conference (August 2007).
[17] T. G AO, T. M ASSEY, L. S ELAVO, D. C RAWFORD, B. C HEN , K. L ORINCZ , V. S HNAYDER ,
L. H AUENSTEIN , F. DABIRI , J. J ENG , A. C HANMUGAM , D. W HITE , M. S ARRAF -
ZADEH ,
M. W ELSH The Advanced Health and Disaster Aid Netowork: A Light-
Referências Bibliográficas
91
Weight Wireless Medical System for Triage. IEEE TRANSACTIONS ON BIOMEDICAL CIRCUITS AND SYSTEMS, VOL. 1, NO. 3, 2007.
[18] V. S HNAYDER , B. C HEN , K. L ORINCZ , T. R. F. F ULFORD -J ONES , AND M. W ELSH
Sensor Networks for Medical Care. Technical report, Division of Engineering and
Applied Sciences, Harvard University, 2005.
[19] A. V. F. G ONÇALVES Avaliação do Acolhimento no Serviço de Emergênciado
Hospital de Clínicas de Porto Alegre na Perspectiva da Pessoa Idosa. Dissertação de Mestrado em Enfermagem, UFRGS, 2011.
[20] E. F. A. C OSTA , C. C. P ORTO, A. T. S OARES
Envelhecimento Populacional
Brasileiro e o Aprendizado de Geriatria e Gerontologia. Revista da UFG, Vol.
5, No. 2, dez 2003 on line (www.proec.ufg.br).
[21] M. I. S CHMIDT, B. B. D UNCAN , G. A. S ILVA , A. M. M ENEZES , C. A. M ONTEIRO, S.
M. B ARRETO, D. CHOR, P. R. M ENEZES Doenças Crônicas não Transmissíveis
no Brasil: Carga e Desafios Atuais. THE LANCET. London, p.61-74, 2011.
[22] A. M AINWARING , J. P OLASTRE , R. S ZEWCZYK , D. C ULLER
Networks for Habitat Monitoring.
Wireless Sensor
International Workshop on Wireless Sensor
Networks and Applications, Sept.2002. ACM; Intel Research, IRB-TR-02-006, June
10, 2002, ACM.
[23] L.Y U, N. WANG , X. M ENG Real-time Forest Fire Detection with Wireless Sensor
Networks. Proceedings. 2005 International Conference on In Wireless Communications, Networking and Mobile Computing, Vol. 2 (2005), pp. 1214-1217.
[24] A. P IERACCI , L. B ENINI , L. R OCCHI , A. ACQUAVIVA
Interfacing human and
computer with wireless body area sensor networks: the WiMoCA solution.
Multimedia Tools and Applications archive, Volume 38 Issue 3, July 2008, Pages 337363.
[25] D. G EER Pervasive Medical Devices: Less Invasive, More Productive. IEEE
PERVASIVE COMPUTING, p. 85-88, 2006.
[26] J. U EYAMA e-NOÉ Usando Rede de Sensores Sem Fio para Detectar Enchentes.
In: NetCOM 2011 Redes e Telecom (5a. Edição), 2011, São Paulo. V NetCOM 2011,
2011.
[27] M. X U, L. M A , F. X IA , T. Y UAN , J. Q IAN , M. S HAO Design and Implementation of
a Wireless Sensor Network for Smart Homes. International Workshop on Mobile
Referências Bibliográficas
92
Cyber-Physical Systems (MobiCPS 2010), in conjunction with UIC2010, IEEE, Xi’an,
China, 26 - 29 October, 2010
[28] M. I ACONO, P. B ARONTI , G. R OMANO, G. A MATO, S. C HESSA Monitoring FireFighters Operating in Hostile Environments with Body-Area Sensor Networks.
In: Proceedings of Risk Assessment and Management in the Civil and Industrial
Settlements (VGR), Pisa, Italy, Oct. 2006.
[29] H. G HASEMZADEH , V. L OSEU, E. G UENTERBERG , R. J AFARI Sport Training Using
Body Sensor Networks: A Statistical Approach to Measure Wrist Rotation for
Golf Swing. In: 4th International ICST Conference on Body Area Networks, ACM,
2011.
[30] T. G AO, D. G REENSPAN , M. W ELSH , R. J UANG , A. A LM Vital Signs Monitoring and
Patient Tracking Over a Wireless Network. Annual International Conference of the
IEEE Engineering in Medicine and Biology Society. IEEE Engineering in Medicine
and Biology Society. Conference 02/2005; 1:102-5.
[31] G. B LUMROSEN , C. A. G ONZALEZ , B. RUBINSKY New Wearable Body Sensor for
Continuous Diagnosis of Internal Tissue Bleeding. Wearable and Implantable
Body Sensor Networks, International Workshop on IEEE Computer Society, p. 120124, 2009.
[32] K. K IFAYAT, P. F ERGUS , S. C OOPER , M. M ERABTI Body Area Networks for Movement Analysis in Physiotherapy Treatments. In proceeding of: 24th IEEE International Conference on Advanced Information Networking and Applications Workshops,
WAINA 2010, Perth, Australia, 20-13 April 2010.
[33] E. Y. W. S ETO, A G IANI , V. S HIA , C. WANG , P. YAN , A. Y. YANG , M. J ERRETT, R.
B AJCSY A Wireless Body Sensor Network for the Prevention and Management
of Asthma. In: International Symposium on Industrial Embedded Systems - SIES ,
pp. 120-123, 2009.
[34] I.F. A KYILDIZ , W. S U, Y. S ANKARASUBRAMANIAM , E. C AYIRCI Wireless sensor
networks: a survey. ELSEVIER Computer Networks Volume 38, Issue 4, 15 March
2002, Pages 393-422
[35]
TelosB Mote Platform Datasheet.
(http://www.willow.co.uk/TelosB_
Datasheet.pdf) - Accessed 12/07/2012
[36]
Mica2 Mote Platform Datasheet.
(http://bullseye.xbow.com:81/
Products/Product_pdf_files/Wireless_pdf/MICA2_Datasheet.pdf) - Accessed 12/07/2012
Referências Bibliográficas
[37]
MicaZ Mote Platform Datasheet.
93
(http://www.openautomation.net/
uploadsproductos/micaz_datasheet.pdf) - Accessed 12/07/2012
[38] Specification of the Bluetooth system SIG Bluetooth. Core, version, 2001.
[39] A DRIAN B URNS , M ICHAEL J. M C G RATH , J OHN D ELANEY, S TEFAN M OELLER Open
Shareable Research Platform for Developing Interoperable Personal Health
Systems. First AMA-IEEE Medical Technology Conference on Individualized Healthcare. 21st-23rd March 2010. Washington, DC, USA.
[40] A. A. G ONZÁLEZ , A. M. N ÚÑEZ , J. P. G ARCÍA , M. S. M ARTIN
Diseño de un
simulador para redes de sensores. Monografia em Sistemas Informáticos, Facultad
de Informática Universidad Complutense de Madrid, 2008/2009.
[41] T EXAS I NSTRUMENT MSP430 Architecture. Manual de Descrição da Arquitetura do
R
MSP430 - Texas Instrument
[42] J. E RIKSSON , F. O STERLIND, N. F INNE , N. T SIFTES , A. D UNKELS , T. VOIGT COOJA/MSPSim: Interoperability Testing for Wireless Sensor Networks. Proceeding Simutools ’09 Proceedings of the 2nd International Conference on Simulation
Tools and Techniques Article No. 27
[43] J. P OLASTRE , R. S ZEWCZYK , D. C ULLER Telos: Enabling Ultra-low Power Wireless Research. In: Proc. 4th Int. Symp. Inf. Process. Sens. Networks, Los Angeles,
CA, 2005, pp. 364â“369.
[44] J. S CHILLER , H. R ITTER , A. L IERS , T. VOIGT. Scatterweb - Low Power Nodes
and Energy Aware Routing.. In: Proceedings of Hawaii International Conference on
System Sciences, Hawaii, USA, 2005.
[45] B. K URIS , T. D ISHONGH SHIMMER - Sensing Health with Intelligence, Modularity,
Mobility, and Experimental Reusability. Guia de Descrição do Hardware do Nodo
Sensor SHIMMER
[46] T EXAS I NSTRUMENT CC2420 - 2.4 GHz IEEE 802.15.4 / ZigBee-ready RF TransR
ceiver. Guia de Descrição do Hardware CC2420 - Texas Instrument
APÊNDICE A
Conjunto de Instruções MSP430
Figura A.1: Conjunto de Instrução - Um único operador - MSP430
[41]
Figura A.2: Conjunto de Instrução - Condicionais - MSP430 [41]
Apêndice A
95
Figura A.3: Conjunto de Instrução - Dois operadores - MSP430
[41]
APÊNDICE B
Código Eletrocardiograma SHIMMER TinyOS
Código B.1 Código do TinyOS para Controle do ECG do
SHIMMER (BOOT) - Módulo
1
event void Boot.booted() {
2
init();
3
call Leds.led0On();
4
post startConfigTimer();
5
}
6
7
void init() {
8
call AccelInit.init();
9
call shimmerAnalogSetup.addAccelInputs();
10
call shimmerAnalogSetup.addECGInputs();
11
call shimmerAnalogSetup.finishADCSetup(sbuf0);
12
NBR_ADC_CHANS = call shimmerAnalogSetup
13
.getNumberOfChannels();
14
15
atomic {
16
17
enable_sending = FALSE;
18
activity_led_on = FALSE;
}
19
20
}
Apêndice B
97
Código B.2 Código do TinyOS para Controle do ECG do
SHIMMER (START SENSING) - Módulo
1
task void startConfigTimer() {
call SetupTimer.startPeriodic(5000);
2
3
}
4
5
event void SetupTimer.fired() {
atomic {
6
7
call ActivityTimer.stop();
8
post startSensing();
}
9
10
}
11
12
task void startSensing() {
13
call ActivityTimer.startPeriodic(1000);
14
call Accel.setSensitivity(RANGE_4_0G);
15
call Accel.wake(TRUE);
16
call SampleTimer.startPeriodic(sample_freq);
17
}
Apêndice B
98
Código B.3 Código do TinyOS para Controle do ECG do
SHIMMER (SENSING) - Módulo
1
event void ActivityTimer.fired() {
atomic {
2
3
/* toggle activity led every second */
4
if (activity_led_on) {
5
call Leds.led1On();
6
activity_led_on = FALSE;
7
}
8
else {
call Leds.led1Off();
9
activity_led_on = TRUE;
10
}
11
}
12
13
}
14
15
event void SampleTimer.fired() {
call shimmerAnalogSetup.triggerConversion();
16
17
}
18
19
async event void DMA0.transferDone(error_t success) {
if (current_buffer == 0) {
20
call DMA0.repeatTransfer((void*)ADC12MEM0_,
21
(void*)sbuf1, NBR_ADC_CHANS);
22
23
atomic timestamp1 = call LocalTime.get();
24
current_buffer = 1;
}
25
26
else {
27
call DMA0.repeatTransfer((void*)ADC12MEM0_,
28
(void*)sbuf0, NBR_ADC_CHANS);
29
30
atomic timestamp0 = call LocalTime.get();
31
current_buffer = 0;
}
32
33
34
35
}
Apêndice B
99
Código B.4 Código do TinyOS para Controle do ECG do
SHIMMER - Configuração
1
configuration AccelECGAppC {
2
}
3
implementation {
4
components MainC, AccelECGC;
5
AccelECGC -> MainC.Boot;
6
7
components LedsC;
8
AccelECGC.Leds -> LedsC;
9
10
components new TimerMilliC() as SampleTimer;
11
AccelECGC.SampleTimer -> SampleTimer;
12
components new TimerMilliC() as SetupTimer;
13
AccelECGC.SetupTimer
14
components new TimerMilliC() as ActivityTimer;
15
AccelECGC.ActivityTimer -> ActivityTimer;
-> SetupTimer;
16
17
components Counter32khz32C as Counter;
18
components new CounterToLocalTimeC(T32khz);
19
CounterToLocalTimeC.Counter -> Counter;
20
AccelECGC.LocalTime -> CounterToLocalTimeC;
21
22
components AccelC;
23
AccelECGC.AccelInit -> AccelC;
24
AccelECGC.Accel -> AccelC;
25
26
components shimmerAnalogSetupC, Msp430DmaC;
27
MainC.SoftwareInit -> shimmerAnalogSetupC.Init;
28
AccelECGC.shimmerAnalogSetup -> shimmerAnalogSetupC;
29
AccelECGC.DMA0 -> Msp430DmaC.Channel0;
30
31
32
}