Um Simulador para Arquitetura de Redes de Sensores do Corpo Humano Baseado na Plataforma SHIMMER

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA ROBERTO VITO RODRIGUES FILHO Um Simulador para Arquitetura de Redes de Sensores do Corpo Humano Baseado na Plataforma SHIMMER Goiânia 2013

2 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: [ ] Dissertação [ ] Tese 2. Identificação da Tese ou Dissertação Autor (a): Seu pode ser disponibilizado na página? [ ]Sim [ ] Não Vínculo empregatício do autor Agência de fomento: País: UF: CNPJ: Título: 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): Co-orientador (a):* *Necessita do CPF quando não constar no SisPG Sigla: 3. Informações de acesso ao documento: Concorda com a liberação total do documento [ ] SIM [ ] NÃO 1 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) Data: / / 1 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.

3 ROBERTO VITO RODRIGUES FILHO 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

4 Dados Internacionais de Catalogação na Publicação (CIP) GPT/BC/UFG R696s Rodrigues Filho, Roberto Vito. Um Simulador para Arquitetura de Redes de Sensores do Corpo Humano Baseado na Plataforma SHIMMER [manuscrito] / Roberto Vito Rodrigues Filho 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, 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.72

5 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.

6 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.

7 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.

8 Verdade é que, se todos os gostos fossem iguais, o que seria do amarelo? Machado de Assis, O Alienista.

9 Resumo Rodrigues Filho, Roberto Vito. Um Simulador para Arquitetura de Redes de Sensores do Corpo Humano Baseado na Plataforma SHIMMER. Goiânia, p. 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

10 Abstract Rodrigues Filho, Roberto Vito. A Simulator for Body Sensor Network Architecture Based on SHIMMER Platform. Goiânia, p. 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

11 Sumário Lista de Figuras 11 Lista de Tabelas 12 Lista de Algoritmos 13 Lista de Códigos de Programas 14 1 Introdução Motivação Objetivo Metodologia Contribuições Estrutura da Dissertação 25 2 Redes de Sensores do Corpo Humano Projetos CodeBlue ALARM-NET AID-N Plataformas de Hardware Plataformas Comerciais Plataformas Acadêmicas Simuladores Network Simulator (NS) TOSSIM AVRORA WSim e WSNet MSPSim e COOJA 36 3 Plataforma de Hardware SHIMMER Descrição da Plataforma Componentes de Hardware Microcontrolador Padrões de Comunicação Sensores Software da Plataforma Ferramentas de Desenvolvimento de Software TinyOS para SHIMMER 47

12 4 Plataforma de Simulação MSPSim Descrição da Plataforma Componentes Componentes Gráficos de Interação 55 Monitor da Pilha de Execução 56 Ciclo de Trabalho 57 Porta USART1 57 Painel de Controle de Simulação 58 Representação Gráfica do Nodo Sensor 60 Terminal de Comando do MSPSim Componentes Internos da Plataforma 61 5 Um Simulador para Redes de Sensores do Corpo Humano Visão Geral Funcionalidades Arquitetura Implementação LEDs Rádio (CC2420) Sensor Eletrocardiograma (ECG) Testes da Plataforma 84 6 Considerações Finais Trabalhos Futuros Publicações Publicações em Jornais Científicos Internacionais Apresentação de Trabalho em Congresso Apresentação de Minicursos 88 Referências Bibliográficas 89 A Conjunto de Instruções MSP B Código Eletrocardiograma SHIMMER - TinyOS 96

13 Lista de Figuras 1.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 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] 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) SHIMMER implementado no MSPSim Mostra o gráfico de utilização da pilha de execução Gráfico mostrando o ciclo de trabalho Porta USART 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 Arquitetura da Plataforma de Hardware SHIMMER no MSPSim Principais classes da solução ligadas ao simulador Eletrocardiograma na Plataforma SHIMMER Pontas do ECG 84 A.1 Conjunto de Instrução - Um único operador - MSP430 [41] 94 A.2 Conjunto de Instrução - Condicionais - MSP430 [41] 94 A.3 Conjunto de Instrução - Dois operadores - MSP430 [41] 95

14 Lista de Tabelas 1.1 Lista das Características das Aplicações Demandadas pela Área da Saúde [4] Instruções Aritméticas de um Único Operador Instruções de Desvio Condicional Instruções Aritméticas de Dois Operadores 44

15 Lista de Algoritmos 4.1 Laço de Execução de Instruções no Simulador MSPSim 63

16 Lista de Códigos de Programas 3.1 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 MSP430f 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 - SHIM- MER Método portwrite() na Simulação dos LEDs - SHIMMER Método setvregon do dispositivo CC SHIMMER Método datareceive da Classe CC SHIMMER Método setcca da Classe CC SHIMMER Método setfifo da Classe CC SHIMMER Método setfifop da Classe CC SHIMMER Método setsfd da Classe CC SHIMMER Método setupnode() do ECG - SHIMMER 83 B.1 Código do TinyOS para Controle do ECG do SHIMMER (BOOT) - Módulo 96 B.2 Código do TinyOS para Controle do ECG do SHIMMER (START SEN- SING) - Módulo 97 B.3 Código do TinyOS para Controle do ECG do SHIMMER (SENSING) - Módulo 98 B.4 Código do TinyOS para Controle do ECG do SHIMMER - Configuração 99

17 Introdução CAPÍTULO 1 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-

18 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

19 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,

20 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

21 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-

22 1.1 Motivação 20 Características Vestíveis (1) Apropriadamente colocado no corpo (2) Questões Estéticas (3) Criptografia e segurança dos dados (4) Tempo de vida operacional (5) Aplicação real (6) Aplicação em tempo real (7) Requisitos computacionais e armazenamento (8) Facilidade de uso (9) Performance e teste em casos reais (10) Confiabilidade (11) Custo (12) Robustez em caso de interferência (13) Tolerância a falha (14) Escalabilidade (15) Tabela 1.1: Lista das Características das Aplicações Demandadas pela Área da Saúde [4] Descrição O sistema deve ser leve e pequeno. O sistema deve ser discreto e comfortável, para não interferir nos movimentos do usuário e atividades diárias. O sistema não deve afetar severamente a aparencia do usuário. Transmissão criptografada dos sinais medidos e o requerimento de autenticação para acessar os dados privados. Consumo mínimo de energia a longo prazo, monitoramento da saúde com o mínimo de manutenção. O sistema desenvolvido é aplicável (e útil) para cenário e condições de saúde da vida real. O sistema vestível produz resultados, por exemplo, mostra as medidas, alertas, diagnosticos, etc, em tempo-real. A computação e o armazenamento requisitado ou utilizado pelo sistema para alcançar os resultados desejados. O sistema incorpora uma interface com o usuário amigável, fácil de usar e de aprender. Resultados suficientes e estatísticas de desempenho são providas para verificar as funcinoalidades em casos reais. O sistema produz resultados confiáveis e precisos. A quantia em dinheiro requerida para produzir ou adquirir o sistema vestível proposto. Disponibilidade e confiabilidade na transmissão dos dados fisiológicos. O sistema produz resultados confiáveis sob qualquer circunstância, mesmo com diversos movimentos do paciente. 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

23 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

24 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).

25 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: 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; 1.3 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

26 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 COOJA 1. 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.

27 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.

28 Redes de Sensores do Corpo Humano CAPÍTULO 2 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 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.

29 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 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.

30 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 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.

31 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 , 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 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.

32 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 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 ( 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 SHIM- MER 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:

33 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.

34 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 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.

35 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.

36 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 Network Simulator (NS) A plataforma de simulação Network Simulator (NS) consiste basicamente, como descrito em seu website oficial ( em um simulador de eventos discretos. Com ele é possível configurar e montar todo um ambiente de rede com o objetivo de realizar testes.

37 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 , 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 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 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.

38 2.3 Simuladores 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 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.

39 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.

40 Plataforma de Hardware SHIMMER CAPÍTULO 3 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 gateways 1 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:

41 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.

42 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.

43 3.2 Componentes de Hardware 41 Figura 3.3: Componentes de Hardware [40]

44 3.2 Componentes de Hardware 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

45 3.2 Componentes de Hardware 43 Tabela 3.1: Instruções Aritméticas de um Único Operador Código B/W AS Registradores Instrução bits 1-bit 2-bits 4-bits Forma geral /0 AS registrador PUSH Tabela 3.2: Instruções de Desvio Condicional 001 Código Deslocamento (Offset) Instrução bits 10-bits Forma Geral 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 é 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.

46 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 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 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 Blue- Tooth, e o componente que implementa esse padrão na plataforma SHIMMER é o RN-46, que comunica através de uma antena integrada.

47 3.2 Componentes de Hardware 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 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:

48 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 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

49 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 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,

50 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.

51 3.3 Software da Plataforma 49 Código 3.1 Código de Exemplo do TinyOS - Configuração Blink 1 configuration BlinkAppC 10 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; BlinkC -> MainC.Boot; 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 2 { 3 uses interface Timer<TMilli> as Timer0; 4 uses interface Leds; 5 uses interface Boot; 6 } 7 implementation 8 { 9 event void Timer0.fired() 10 { 11 dbg("blinkc", "Timer 0 %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,

52 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.

53 Plataforma de Simulação MSPSim CAPÍTULO 4 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 limi- 1 URL Grupo Sourceforge: 2 Sourceforge é um website que fornece espaço e ferramentas para a criação e gerenciamento de projetos de software.

54 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.

55 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 breakpoints 3 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.

56 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.

57 4.2 Componentes Componentes Nesta seção serão descrito os componentes que formam a plataforma do MSP- Sim, 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 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.

58 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.

59 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.

60 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.

61 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.

62 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

63 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 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

64 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.

65 4.2 Componentes 63 Algoritmo 4.1: Laço de Execução de Instruções no Simulador MSPSim enquanto estiver executando faça fim 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 endsw destino = lerorigem(op); ciclo += CICLOS_MOV; case ADD... endsw 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

66 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() { 3 public int read(int address, AccessMode mode, 4 AccessType type) { 5 //... 6 return memorysegments[address >> 8]. 7 read(address, mode,type); 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,

67 4.2 Componentes 65 uma porta USART, um conversor análogico digital (ADC12), etc. Sendo que esses são dispositivos internos 4 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 MSP430f public int setup(msp430core cpu, 2 ArrayList<IOUnit> iounits) { 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++) { 8 iounits.add(new IOPort(cpu, (3 + i), 0, 9 cpu.memory, 0x18 + i * 4)); 10 iounits.add(new IOPort(cpu, (5 + i), 0, 11 cpu.memory, 0x30 + i * 4)); 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.

68 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 { 2 public void portwrite(ioport source, 3 int data); 4 } public interface USARTListener { 7 public void datareceived(usartsource source, 8 int data); 9 } 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.

69 Um Simulador para Redes de Sensores do Corpo Humano CAPÍTULO 5 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.

70 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

71 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.

72 5.3 Arquitetura 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

73 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

74 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 MSP- Sim, 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 MSP 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-

75 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 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.

76 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 8 leds.setleds((redled? 1 : 0) + (greenled? 2 : 0) 9 + (blueled? 4 : 0)); 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.

77 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 { 10 2 //... 3 public void setleds(int leds) { 4 if (this.leds!= leds) { 5 this.leds = leds; 6 statechanged(leds); 7 } 8 } 9 } 11 public class Chip { 12 public void statechanged(int newstate) { 13 // int oldstate = chipstate; 15 chipstate = newstate; 16 // listener.statechanged(this, oldsatet, 18 chipstate); 19 } 20 } public class ShimmerGUI { 23 // private final StateChangeListener ledslistener = 25 new StateChangeListener() { 26 public void statechanged(object source, int oldstate, 27 int newstate) { 28 repaint(leds_bounds); 29 } 30 } public void setupgui() { 33 // node e uma instancia de ShimmerNode 34 node.getleds().addstatechangelistener(ledslistener); 35 } 36 // };

78 5.4 Implementação 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 // cc 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-

79 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) { 2 if (source == port5) { 3 radio.setchipselect((data & 4 CC2420_CHIP_SELECT) == 0); 5 radio.setvregon((data & CC2420_VREG)!= 0); 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 (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.

80 5.4 Implementação 78 Código 5.6 Método setvregon do dispositivo CC SHIMMER 1 public void setvregon(boolean newon) { 2 if (on == newon) 3 return; 4 if (newon) { 5 cpu.scheduletimeeventmillis(vregevent, 0.05); 6 } else { 7 on = false; 8 setstate(radiostate.vreg_off); 9 } 10 } private TimeEvent vregevent = 13 new TimeEvent(0, "CC2420 VREG") { 14 public void execute(long t) { 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

81 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 CC SHIM- MER 1 public void datareceived(usartsource source, int data) { 2 int oldstatus = status; 3 if (!chipselect) { 4 5 } else if (statemachine!= RadioState.VREG_OFF) { 6 switch (state) { 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

82 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 CC 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); 8 else 9 ccaport.setpinstate(ccapin, cca? 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 CC 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 7 : IOPort.PinState.HI); 8 } else { 9 fifoport.setpinstate(fifopin, fifo? 10 IOPort.PinState.HI 11 : IOPort.PinState.LOW); 12 } 13 }

83 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 Código 5.10 Método setfifop da Classe CC SHIM- MER 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); 8 } else { 9 fifopport.setpinstate(fifoppin, fifop? 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 Código 5.11 Método setsfd da Classe CC 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); 8 else 9 sfdport.setpinstate(sfdpin, sfd? 10 IOPort.PinState.HI 11 : IOPort.PinState.LOW); 12 }

84 5.4 Implementação 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

85 5.4 Implementação 83 MSPSim inicia-se no mesmo método que os demais, o método setupnode(), como ilustra o Código 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() { 5 public int nextdata() { 6 return ecg.getrall(); 7 } 8 }); 9 adc.setadcinput(6, new ADCInput() { 10 public int nextdata() { 11 return ecg.getlall(); 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.

86 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

87 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 plataforma MSPSim no modo de depuração na IDE Eclipse R, verificando se os eventos 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.

88 Considerações Finais CAPÍTULO 6 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-

89 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:

90 6.2 Publicações 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), 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, v. 1. p R. V. RODRIGUES FILHO, I. G. SENE-JÚNIOR TinyOS: Teoria e Prática IN: X Encontro Anual de Computação (EnAComp), 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.

91 Referências Bibliográficas [1] A. WOOD, G. VIRONE, T. DOAN, Q. CAO, L. SELAVO, Y. WU, L. FANG, Z. HE, S. LIN, J. STANKOVIC ALARM-NET: Wireless sensor networks for assisted-living and residential monitoring. University of Virginia Computer Science Department Technical Report (2006) [2] A. DUNKELS, B. GRONVALL, T. VOIGT Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors. Local Computer Networks, Annual IEEE Conference on In Local Computer Networks, th Annual IEEE International Conference on, Vol. 0 (November 2004), pp [3] A. BURNS, B. GREENE, M. MCGRATH, T. O SHEA, B. KURIS, S. AYER, F. STROI- ESCU, V. CIONCA Shimmer - A Wireless Sensor Platformfor Noninvasive Biomedical Research. IEEE Sensors Journal (2010), VOL. 10, [4] A. PANTELOPOULOS, N. G. BOURBAKIS 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, [5] A. FRABOULET, G. CHELIUS, E. FLEURY 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. TITZER, D. K. LEE, 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. LIN, N. CHOU, F. CHONG, S. CHEN Real-time Wireless Physiological Monitoring System (RTWPMS). IEEE TRANSACTIONS ON INFORMATION TECHNO- LOGY IN BIOMEDICINE, VOL. 10, NO. 4, 2006.

92 Referências Bibliográficas 90 [8] J. ERIKSSON, A. DUNKELS, N. FINNE, F. OSTERLIND, T. VOIGT, N. TSIFTES 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. LORINCZ, B. KURIS, S. M. AYER, S. PATEL, P. BONATO, M. WELSH 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 , [10] L. RILISKIS, E. OSIPOV, M. MARÓ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 Mar [11] M. A. HANSON, H. C. POWELL JR., A. T. BARTH, K. RINGGENBERG, B. H. CA- LHOUN, J. H. AYLOR, J. LACH Body Area Sensor Networks: Challenges and Opportunities. IEEE Computer 42(1): (2009). [12] P. LEVIS, N. LEE Tossim: A Simulator for Tinyos Networks. Technical report, UC Berkeley, September, [13] P. LEVIS, S. MADDEN, J. POLASTRE, R. SZEWCZYK, A. WOO, D. GAY, J. HILL, M. WELSH, E. BREWER, D. CULLER Tinyos: An operating System for Sensor Networks. In Ambient Intelligence (2005), p [14] R. V. RODRIGUES-FILHO, R. F. BULCÃO-NETO, B. O. SILVESTRE, L. L. OLI- VEIRA, R. O. OLIVEIRA, 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), [15] S. COYLE, D. MORRIS, K. LAU, D. DIAMOND Textile-based Wearable Sensors for Assisting Sports Performance. In BSN Body sensor networks, 3-5 June 2009, Berkeley, CA, USA (2009). [16] S. PATEL, K. LORINCZ, R. HUGHES, N. HUGGINS, J. H. GROWDON, M. WELSH, P. BONATO 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. GAO, T. MASSEY, L. SELAVO, D. CRAWFORD, B. CHEN, K. LORINCZ, V. SHNAY- DER, L. HAUENSTEIN, F. DABIRI, J. JENG, A. CHANMUGAM, D. WHITE, M. SARRAF- ZADEH, M. WELSH The Advanced Health and Disaster Aid Netowork: A Light-

93 Referências Bibliográficas 91 Weight Wireless Medical System for Triage. IEEE TRANSACTIONS ON BIOME- DICAL CIRCUITS AND SYSTEMS, VOL. 1, NO. 3, [18] V. SHNAYDER, B. CHEN, K. LORINCZ, T. R. F. FULFORD-JONES, AND M. WELSH Sensor Networks for Medical Care. Technical report, Division of Engineering and Applied Sciences, Harvard University, [19] A. V. F. GONÇ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, [20] E. F. A. COSTA, C. C. PORTO, A. T. SOARES Envelhecimento Populacional Brasileiro e o Aprendizado de Geriatria e Gerontologia. Revista da UFG, Vol. 5, No. 2, dez 2003 on line ( [21] M. I. SCHMIDT, B. B. DUNCAN, G. A. SILVA, A. M. MENEZES, C. A. MONTEIRO, S. M. BARRETO, D. CHOR, P. R. MENEZES Doenças Crônicas não Transmissíveis no Brasil: Carga e Desafios Atuais. THE LANCET. London, p.61-74, [22] A. MAINWARING, J. POLASTRE, R. SZEWCZYK, D. CULLER Wireless Sensor Networks for Habitat Monitoring. International Workshop on Wireless Sensor Networks and Applications, Sept ACM; Intel Research, IRB-TR , June 10, 2002, ACM. [23] L.YU, N. WANG, X. MENG Real-time Forest Fire Detection with Wireless Sensor Networks. Proceedings International Conference on In Wireless Communications, Networking and Mobile Computing, Vol. 2 (2005), pp [24] A. PIERACCI, L. BENINI, L. ROCCHI, 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 [25] D. GEER Pervasive Medical Devices: Less Invasive, More Productive. IEEE PERVASIVE COMPUTING, p , [26] J. UEYAMA 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, [27] M. XU, L. MA, F. XIA, T. YUAN, J. QIAN, M. SHAO Design and Implementation of a Wireless Sensor Network for Smart Homes. International Workshop on Mobile

94 Referências Bibliográficas 92 Cyber-Physical Systems (MobiCPS 2010), in conjunction with UIC2010, IEEE, Xi an, China, October, 2010 [28] M. IACONO, P. BARONTI, G. ROMANO, G. AMATO, S. CHESSA Monitoring Fire- Fighters 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 [29] H. GHASEMZADEH, V. LOSEU, E. GUENTERBERG, R. JAFARI 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, [30] T. GAO, D. GREENSPAN, M. WELSH, R. JUANG, A. ALM 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: [31] G. BLUMROSEN, C. A. GONZALEZ, 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 , [32] K. KIFAYAT, P. FERGUS, S. COOPER, M. MERABTI 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, April [33] E. Y. W. SETO, A GIANI, V. SHIA, C. WANG, P. YAN, A. Y. YANG, M. JERRETT, R. BAJCSY A Wireless Body Sensor Network for the Prevention and Management of Asthma. In: International Symposium on Industrial Embedded Systems - SIES, pp , [34] I.F. AKYILDIZ, W. SU, Y. SANKARASUBRAMANIAM, E. CAYIRCI Wireless sensor networks: a survey. ELSEVIER Computer Networks Volume 38, Issue 4, 15 March 2002, Pages [35] TelosB Mote Platform Datasheet. ( Datasheet.pdf) - Accessed 12/07/2012 [36] Mica2 Mote Platform Datasheet. ( Products/Product_pdf_files/Wireless_pdf/MICA2_Datasheet.pdf) - Accessed 12/07/2012

95 Referências Bibliográficas 93 [37] MicaZ Mote Platform Datasheet. ( uploadsproductos/micaz_datasheet.pdf) - Accessed 12/07/2012 [38] Specification of the Bluetooth system SIG Bluetooth. Core, version, [39] ADRIAN BURNS, MICHAEL J. MCGRATH, JOHN DELANEY, STEFAN MOELLER Open Shareable Research Platform for Developing Interoperable Personal Health Systems. First AMA-IEEE Medical Technology Conference on Individualized Healthcare. 21st-23rd March Washington, DC, USA. [40] A. A. GONZÁLEZ, A. M. NÚÑEZ, J. P. GARCÍA, M. S. MARTIN 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] TEXAS INSTRUMENT MSP430 Architecture. Manual de Descrição da Arquitetura do MSP430 - Texas Instrument R [42] J. ERIKSSON, F. OSTERLIND, N. FINNE, N. TSIFTES, A. DUNKELS, T. VOIGT CO- OJA/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. POLASTRE, R. SZEWCZYK, D. CULLER 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. SCHILLER, H. RITTER, A. LIERS, T. VOIGT. Scatterweb - Low Power Nodes and Energy Aware Routing.. In: Proceedings of Hawaii International Conference on System Sciences, Hawaii, USA, [45] B. KURIS, T. DISHONGH SHIMMER - Sensing Health with Intelligence, Modularity, Mobility, and Experimental Reusability. Guia de Descrição do Hardware do Nodo Sensor SHIMMER [46] TEXAS INSTRUMENT CC GHz IEEE / ZigBee-ready RF Transceiver. Guia de Descrição do Hardware CC Texas Instrument R

96 Conjunto de Instruções MSP430 APÊNDICE A Figura A.1: Conjunto de Instrução - Um único operador - MSP430 [41] Figura A.2: Conjunto de Instrução - Condicionais - MSP430 [41]

97 Apêndice A 95 Figura A.3: Conjunto de Instrução - Dois operadores - MSP430 [41]