Sistema de Monitor Amen To Remoto de Pacientes Implement Ado em Hardware de Arquitetura ARM

Universidade Federal do Cear Departamento de Engenharia de Teleinformtica Curso de Graduao em Engenharia de Teleinformtica
talo Cavalcante Sampaio
Sistema de Monitoramento Remoto de Pacientes Implementado em Hardware de Arquitetura ARM
Fortaleza Cear Dezembro 2011
Autor:
Prof. Dr. Helano de Sousa Castro
Orientador:
Monograa de Concluso de Curso apresentada Coordenao do Curso de Graduao em Engenharia de Teleinformtica da Universidade Federal do Cear como parte dos requisitos para obteno do grau de Engenheiro de Teleinformtica.
Fortaleza Cear Dezembro 2011
Esta Monograa foi julgada adequada para a obteno do diploma de Engenheiro do Curso de Graduao em Engenharia de Teleinformtica da Universidade Federal do Cear. talo Cavalcante Sampaio Banca Examinadora: Prof. Dr. Helano de Sousa Castro Orientador Prof. Alexandre Augusto da Penha Coelho Prof. Ricardo Jardel Nunes da Silveira Fortaleza, 12 de dezembro de 2011
Resumo
om os avanos da computao, sobretudo na rea de sistemas embarcados, C cada vez mais fcil realizar tarefas que necessitam de um poder computacional considervel utilizando hardware de baixo custo. Essa nova realidade faz com que outras reas, no necessariamente relacionadas com a computao, sejam beneciadas. Um bom exemplo deste fenmeno a rea de sade. Hoje, possvel desenvolver equipamentos que realizam tarefas essenciais para a sade de um paciente empregando um baixo custo, utilizando um baixo consumo de energia e com uma grande variedade de funcionalidades. Neste contexto, este trabalho descreve o desenvolvimento de um sistema de Home Care de baixo custo que utiliza tecnologias sem o para promover uma maior qualidade de vida ao paciente, permitindo que o mesmo tenha mobilidade enquanto monitorado, ao invs de car preso a uma cama de hospital. O sistema foi desenvolvido utilizando um processador Freescale iMX53, que possui um ncleo ARM, rodando o Sistema Operacional Linux. A conexo com os sensores feita atravs da tecnologia bluetooth e os sinais vitais do paciente so exibidos em uma pgina da Web, podendo ser acessados de qualquer lugar por um familiar ou por um mdico, o que garante uma maior tranquilidade ao paciente e seus familiares.
Home Care.
Palavras-chaves:
Sistemas Embarcados, Linux, ARM, Bluetooth, Telemedicina,
Abstract
he current state of the computer eld, specially on embedded systems, has allowed tasks that need high amount of computing power to be performed by low cost hardware without major diculty. This new reality benets a great amount of areas, not necessarily related to computing, such as the medicine. Nowadays, it is possible to develop an equipment that performs tasks that are essential to the health of a patient with low cost, low power and yet with a wide variety of features. This work describes the development of a low cost Home Care system, which uses wireless technology in order to provide a better life quality to the patient, allowing some mobility while the monitoring is performed, in contrast to the classic situation, where the patient has to be in a hospital bed during long periods of time. The system was developed by using a Fresscale iMX53 processor, which uses an ARM core, running Linux Operation System. The connection with the sensor uses bluetooth technology and the patient's vital signals are presented through a Web page, which allows them to be accessed from anywhere by a family member or by a doctor, which brings tranquility to both the patient and the family.
Keywords:
Embeded Systems, Linux, ARM, Bluetooth, Telemedicine, Home Care.
Dedico este trabalho aos meus pais, Cludia e James, minha irm, Thais e minha namorada, Eveline, por todo o amor e pelo apoio ao longo da graduao e por toda a vida.
Agradecimentos
Agradeo primeiramente aos meus pais, responsveis diretos por todas as minhas conquistas, por terem sempre deixado claro a importncia do estudo no crescimento enquanto ser humano e prossional, pelo apoio incondicional e pela compreenso nos momentos de ausncia. minha namorada, Eveline, por estar sempre ao meu lado ao longo desta caminhada, nos momentos de glria e nos mais difceis, pela compreenso, pelo companheirismo, amor e dedicao. A todos os colegas e amigos do LESC, pelas incontveis contribuies a esse e outros trabalhos, sempre que tive necessidade. Aos meus amigos, por sempre acreditar que eu conseguiria atingir meus objetivos. Ao professor Helano Castro, por aceitar ser meu orientador e fornecer sua valiosa contribuio para a concluso deste trabalho. A todos os alunos do curso de Graduao em Engenharia de Teleinformtica, por compartilhar momentos to especiais ao longo desses 5 anos.
Seu trabalho vai ocupar grande parte da sua vida, e o nico jeito de se sentir verdadeiramente satisfeito fazer o que voc acredita ser um timo trabalho. E o nico jeito de fazer um timo trabalho amar aquilo que voc faz.
Steve Jobs
Sumrio
Lista de Figuras Lista de Tabelas Lista de Siglas 1 Introduo
viii ix ix 1
1.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Organizao deste trabalho . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Sistema Operacional Linux . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Descrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Linux em Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . 2.2.1 Caractersticas de Sistemas Embarcados Linux . . . . . . . . . 2.2.2 Vantagens do Linux para Sistemas Embarcados . . . . . . . . 2.3 Processadores ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Viso Geral da Arquitetura de Processadores ARM . . . . . . 2.3.2 Processadores ARM em Sistemas Embarcados . . . . . . . . . 2.3.3 Famlias do Processador ARM . . . . . . . . . . . . . . . . . . 2.4 Sistemas de Home Care . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Fundamentos de Eletrocardiograa . . . . . . . . . . . . . . . 3.1 Arquitetura Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Descrio do Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Customizao do Sistema Operacional . . . . . . . . . . . . . . . . . 3.5 Descrio do Software . . . . . . . . . . . . . . . . . . . . . . . . . . vi
4
2 Fundamentao Terica
4 4 6 7 8 10 14 14 20 24 25 27
31
3 Metodologia de Desenvolvimento
31 33 34 37 38 38 40
3.5.1 Aquisio de Dados . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Anlise dos Dados . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Gerao da Pgina Web . . . . . . . . . . . . . . . . . . . . . 3.5.4 Alerta para a Famlia . . . . . . . . . . . . . . . . . . . . . . . 3.6 Metodologia de Validao . . . . . . . . . . . . . . . . . . . . . . . .
4 Resultados e sua Anlise
40 41 43 45 46
47
4.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Pgina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47 47 50 51
5 Concluses e Trabalhos Futuros Referncias Bibliogrcas
5.1 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

56
52
vii
Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 Viso em camadas da arquitetura do Android . . . . . . . . . . . . . 6 Fluxo dos dados no core do processador ARM . . . . . . . . . . . . . 15 Mapa dos registros do ARM disponveis em modo usurio . . . . . . . 16 Descrio dos bits do registro CPSR . . . . . . . . . . . . . . . . . . 17 Descrio dos bits do registro CPSR . . . . . . . . . . . . . . . . . . 19 Comparao da localizao da complexidade em sistemas RISC e CISC 21 Viso detalhada de um corao humano, com suas cavidades e as vlvulas que as interligam ( , 1999) . . . . . . . . . . . . . . . 28 Tpico sinal de ECG, com indicao das componentes da onda . . . . 29 Arquitetura proposta para o sistema de Home Care . . . . . . . . . . 32 Ambiente de desenvolvimento do SO . . . . . . . . . . . . . . . . . . 39 Fluxograma do software que realiza a aquisio dos dados . . . . . . . 41 Fluxograma do software que realiza a anlise dos sinais vitais . . . . . 42 Fluxograma do software que gera a pgina Web . . . . . . . . . . . . 44 Fluxograma do software que envia um alerta para a famlia do paciente 45 Pgina Web com o eletrocardiograma em tempo real . . . . . . . . . 48 Pgina de cadastro de novos pacientes . . . . . . . . . . . . . . . . . 49 Pgina de alterao dos dados do paciente . . . . . . . . . . . . . . . 49
BONSOR
viii
Lista de Tabelas
2.1 2.2 4.1 4.2 Principais Flags Condicionais no processador ARM . . . . . . . . . . Lista dos atributos condicionais suportados pelo ARM . . . . . . . . Inuncia de mltiplos clientes acessando a pgina Web na performance do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . Tempo de execuo para cada bloco funcional de software . . . . . . . 20 21 50 50
ix
Lista de Siglas
Sistema Operacional GPL GNU General Public License GUI Interface Grca de Usurio (Graphic User Interface ) API Interface de Programao de Aplicativos (Application Programming Interface ) IDE Ambiente Integrado de Desenvolvimento (Integrated Development Environment ) RISC Computao com Conjunto de Instrues Reduzido (Reduced Instruction Set Computing ) CISC Computao com Conjunto de Instrues Complexo (Complex Instruction Set Computing ) PDS Processamento Digital de Sinais CPSR Registro de Status do Programa Atual(Current Program Status Register )
SO SIMD Single Instruction, Multiple Data SMS
Servio de Mensagens Curtas (Short Message Service ) LTIB Linux Target Image Builder
BSP Board Support Package HDP
Perl para Dispositivos de Sade (Health Device Prole ) TFTP Protocolo de Transferncia de Arquivos Trivial (Trivial File Protocol ) NFS Sistema de Arquivos em Rede (Network File System ) ALU Unidade Lgica Aritimtica (Aritimetic Logic Unit ) MAC Unidade Multiplicador-Acumulador (Multiply-Accumulate Unit ) x
Transfer
Lista de Tabelas
xi
Eletrocardiograma GPS Sistema de Posicionamento Global (Global Positioning System ) GSM Sistema Global para Comunicaes Mveis (Global System for Mobile Communications ) MMU Unidade de Gerenciamento de Memria (Memory Management Unity )
ECG
Captulo
Introduo
1.1 Motivao
Um dos grandes problemas enfrentados pelo Brasil atualmente na rea de Sade a alta taxa de ocupao nos hospitais da rede pblica. Muitos desses hospitais, possuem taxa de ocupao superior a 100%, j que, com todos os leitos ocupados, so obrigados a fazer uso de macas que so colocadas nos corredores para conseguir atender mais pacientes que a capacidade do hospital ( , 2011). Uma consequncia grave desta situao que, alm dos pacientes que conseguem internao no receberem um tratamento adequado, j que os prossionais e os equipamentos no esto presentes em nmero suciente para atender demanda, muitos acabam no conseguindo vagas nos leitos, morrendo em corredores de hospitais ou em consequncia das longas esperas por uma vaga ( , 2011; , 2011b; , 2011a). Desta forma, necessrio que sejam criadas solues para que a demanda por leitos hospitalares seja suprida. A soluo bvia para este problema a construo de mais hospitais e ampliao dos j existentes. Contudo, esta soluo implica num alto custo para os cofres pblicos para nanciar as obras necessrias, alm de impacto na populao, j que, durante as reformas, os pacientes que j esto internados precisam ser realocados, gerando muito transtorno para a populao. Alm disso, o tempo que leva para implementar esse tipo de ao geralmente muito alto. Outra soluo para o problema diminuir a necessidade dos pacientes utilizarem os leitos j existentes. Uma forma de fazer isto atravs de sistemas de Home Care, que permitem que pacientes em situaes de menor gravidade sejam monitorados em 1
BITTENCOURT GAZETA G1 G1
1.2. Objetivos
casa, no necessitando ocupar um leito hospitalar. A adoo desta soluo menos custosa e mais rpida que a construo de novos leitos, alm de ser normalmente mais agradvel para o paciente, que pode car em casa com seus familiares. Neste trabalho, foi desenvolvido um sistema de Home Care que se utiliza de tecnologias sem o para realizar as medies dos sinais vitais do paciente. Desta forma, o dispositivo pode car xo em algum local da casa, enquanto o paciente, com o sensor acoplado ao seu corpo, tem liberdade para movimentar-se pela casa, sem estar conectado por os ao dispositivo. Isto promove uma maior qualidade de vida, j que o paciente pode realizar suas atividades normalmente sem se preocupar com o monitoramento. O desenvolvimento do sensor no faz parte do escopo deste trabalho. Todo o desenvolvimento foi realizado partindo da premissa que est disponvel um eletrocardigrafo porttil compatvel com o perl Bluetooth HDP ( , 2009).
LATUSKE
1.2 Objetivos
O objetivo principal deste projeto de concluso de curso desenvolver o prottipo de um sistema de Home Care, capaz de monitorar sinais vitais de um paciente usando tecnologias sem o e exibir as informaes atavs de uma pgina WEB, permitindo o acesso a essas informaes a partir de qualquer lugar. O projeto tem como objetivos especcos portar e personalizar o kernel do Sistema Operacional Linux para a placa de desenvolvimento utilizada, desenvolver o Device Driver para o receptor bluetooth utilizado, desenvolver a aplicao que colhe e armazena os sinais vitais do paciente via bluetooth, criar uma aplicao que realiza medidas relevantes a partir dos dados colhidos, desenvolver uma soluo de servidor WEB e a pgina WEB para exibir os dados e desenvolver o aplicativo que avisa, via SMS, a famlia do paciente caso algum valor esteja fora do normal.
1.3 Organizao deste trabalho
O restante deste trabalho est dividido em captulos. No Captulo 2 feita uma rpida reviso sobre os principais conceitos utilizados no desenvolvimento deste trabalho. O captulo fala inicialmente sobre o sistema operacional Linux e sua aplicao em sistemas embarcados. Em seguida, dada uma viso geral sobre a arquitetura de processadores ARM, suas principais caractersticas e as famlias de
1.3. Organizao deste trabalho
processadores ARM. Finalmente, feita uma reviso sobre os conceitos bsicos de sistemas de Home Care e eletrocardiograa. No Captulo 3 detalhada a metodologia de desenvolvimento do projeto. Inicialmente, o captulo mostra a arquitetura proposta para o projeto. Em seguida, apresentado o ambiente de desenvolvimento, detalhando as ferramentas utilizadas. O captulo segue apresentando a plataforma de hardware utilizada para o desenvolvimento, a metodologia utilizada para customizao do Sistema Operacional utilizado, para o desenvolvimento do software e para a validao do projeto. Finalmente, o Captulo 4 apresenta os resultados obtidos com o trabalho, uma anlise desses resultados, as concluses e previses de trabalhos futuros.
Captulo
Fundamentao Terica
2.1 Sistema Operacional Linux
2.1.1 Introduo
O Sistema Operacional Linux foi criado como um projeto pessoal do programador nlands Linus Torvalds. Em agosto de 1991, Linus postou pela primeira vez no grupo de notcias comp.os.minix que estava trabalhando em um Sistema Operacional (SO) livre baseado em Unix para computadores IBM-compatveis baseados no processador intel 80386 ( , 1991). Aos poucos, o sistema foi evoluindo, ganhando novas funcionalidades como memria virtual e um sistema de arquivos mais sosticado. Rapidamente, foram criados portes para outras plataformas, como Alpha, SPARC, Motorola MC680x0, PowerPC, e IBM System/390 ( , 2000). O principal diferencial do Linux com relao aos outros SOs da poca era seu modelo de negcio baseado em software livre. Todo o cdigo era, e continua sendo at hoje, publicado sob a GNU General Public License (GPL) ( , 2007). Esta licena diz que o cdigo fonte pode ser modicado e reutilizado por qualquer pessoa, desde que qualquer software feito usando pedaos de cdigo GPL tambm seja distribudo junto com o cdigo fonte. O resultado prtico da utilizao desta licena no Linux que o desenvolvimento do sistema no ca centralizado. Qualquer usurio pode contribuir com cdigo, customizando e melhorando o sistema sua maneira, realizando portes para diferentes plataformas e corrigindo defeitos que possam vir em cada novo lanamento. Assim, medida que
MINIX BOVET; CESATI FREE SOFTWARE FUNDATION
2.1. Sistema Operacional Linux
a base de usurios foi crescendo, a quantidade de funcionalidades foi aumentando, assim como a conabilidade do sistema como um todo. Em 1994, foi lanada a verso 1.0 do Linux. Esta verso tinha aproximadamente 165.000 linhas de cdigo ( , 2007) e incluia novas funcionalidades como um novo sistema de arquivos, arquivos mapeados em memria e suporte a rede com sockets e implementao da pilha TCP/IP. Esta verso incluia tambm vrios novos Device Drivers. Nos dois anos seguintes, vrias revises foram lanadas. Em 1996, foi lanada a verso 2.0. Nesta verso, havia cerca de 470.000 linhas de cdigo em C e 8.000 linhas de cdigo em assembly. As novidades incluiam suporte a arquiteturas de 64 bits, multiprogramao simtrica, novos protocolos de rede, dentre outras funcionalidades. Novamente, boa parte do cdigo adicionado consistia em Device Drivers, fazendo com que o sistema suportasse cada vez mais dispositivos. Por ser baseado em Unix, o Linux acabou herdando boa parte dos softwares desenvolvidos para Unix, j que os mesmos puderam ser portados sem grandes problemas. Estes programas incluem utilitrios, o gerenciador de interface grca X, alm de diversos aplicativos de rede. Alm disso, foram desenvolvidas duas Interface Grca de Usurio (Graphic User Interface )s (GUIs) para Linux: GNOME e KDE. Assim, o Linux conseguiu uma relativa popularizao herdando parte do ecossistema de usurios UNIX, somado ao ecossistema que se formou em torno do prprio Linux. Somente em 2011, foi lanada a verso 3.0 do Kernel, e segundo o prprio Linus Torvalds, a atualizao da numerao, de 2.X para 3.X no tem relao com nenhuma grande mudana estrutural no kernel, sendo mais ligada s comemoraes de 20 anos da criao do Linux ( , 2011). Hoje, o Linux ocupa apenas uma pequena parcela do mercado de computadores pessoais, que era seu foco inicial. Por outro lado, o sistema lder de mercado quando se trata de supercomputadores e grandes servidores Web. Segundo ( , 2011), 82,6% dos 500 supercomputadores mais potentes do mundo rodam o SO Linux. Outro nicho onde o Linux tem se destacado no mercado de computao mvel, j que o Android, Sistema Operacional mais usado em smartphones ( , 2011), construdo sobre uma camada de kernel Linux, conforme pode ser visto na Figura 2.1. Devido sua caracterstica de software aberto, o Linux j foi portado para
TANENBAUM TORVALDS TOP500 PCWORLD
2.1. Sistema Operacional Linux
Figura 2.1: Viso em camadas da arquitetura do Android
uma srie de arquiteturas, tornando o mesmo uma escolha interessante para o uso em sistemas embarcados. Algumas arquiteturas que suportam Linux so ARM, Atmel AVR32, Freescale 68k, IBM System/390 e Z/Architecture, Intel IA-64 e x86, Microblaze, MIPS, OpenRISC, PowerPC, dentre muitas outras. Podemos ver na lista de arquiteturas suportadas que possvel rodar Linux em sistemas para atender aos mais variados requisitos, desde grandes mainframes, passando pelos computadores pessoais high-end at sistemas embarcados de baixo consumo.
2.1.2 Descrio
Conrme mencionado na Seo 2.1.1, o Linux um SO baseado no UNIX. Desta forma, apesar de no contar com cdigo UNIX em seu kernel, muitas das funcionalidades do sistema so baseadas nas do UNIX. Como muitos outros sistemas baseados em UNIX, o Linux compatvel com alguns padres de desenvolvimento, sendo o principal deles o padro IEEE POSIX, que consiste em uma Interface de Programao de Aplicativos (Application Programming Interface ) (API) que pode ser utilizada por todos os programas de usurio. O POSIX, no entanto, dene apenas a interface de programao, que deve ser a mesma em todos os SOs que possuem suporte ao padro, no denindo nenhum detalhe de implementao dos mesmos.
2.2. Linux em Sistemas Embarcados
Apesar de no ser o nico SO baseado no UNIX e de possuir uma srie de semelhanas com outros SOs, podemos ver em ( , 2000) uma srie de caractersticas que fazem com que o Linux tenha destaque em meio aos outros SOs baseados em UNIX. As principais caractersticas so citadas a seguir.
BOVET; CESATI
Escolhendo o Linux para um projeto, corta-se o custo que poderia haver com o SO. Completamente costumizvel em todos os seus componentes: A GPL permite que o cdigo fonte de qualquer componente do sistema seja modicado para se adequar s necessidades do projeto. Capacidade de rodar em hardware de baixo custo: possvel construir um sistema simples utilizando hardware de baixssimo custo rodando Linux. possvel tambm gerar imagens do Linux com um pequeno footprint de memria. Eciente: Sistemas Linux costumam explorar ao mximo a capacidade do hardware, rodando muito rpido. O projeto do SO em si tem foco no desempenho, direcionando as decises de projeto para rejeitar qualquer funcionalidade que penalize o desempenho. Alta qualidade do cdigo fonte: Os desenvolvedores do kernel tendem a gerar cdigo bastante estvel, com baixa taxa de falhas e baixo tempo de manuteno. Suporte: Graas sua base de usurios sempre ativa, muito fcil conseguir suporte para sistemas Linux. Normalmente, os usurios respondem s dvidas em listas de discusso em pouco tempo e device drivers so facilmente encontrados na internet.
Linux gratuito:
2.2 Linux em Sistemas Embarcados
Apesar de ter sido inicialmente desenvolvido com o intuito de ser utilizado em desktops, o Linux bastante utilizado em sistemas embarcados. Neste trabalho, considera-se um sistema embarcado qualquer sistema de computao desenvolvido para um propsito bem denido, em oposio aos sistemas de propsito geral, que podem atender a uma grande quantidade de aplicaes. Devido sua natureza
especca, desejvel que um sistema embarcado tenha baixo custo para tornar-se vantajoso em relao a um sistema de propsito geral. Para garantir o baixo custo, utiliza-se a menor quantidade possvel de componentes de hardware e software, tornando o sistema o mais otimizado possvel. Em sistemas embarcados simples, como controles remotos, calculadoras, dispositivos perifricos como teclados e monitores, dentre outros, costuma-se usar um rmware, que um programa que implementa desde a camada de aplicao at a camada mais baixa, congurando os registros internos dos dispositivos de hardware. No entanto, medida que o sistema evolui em complexidade, torna-se necessrio o uso de ferramentas que no esto disponveis em um rmware, mas podem ser encontradas em um SO, como sincronizao de processos, computao concorrente, gerenciamento de memria e sistema de arquivos. Cabe ao desenvolvedor decidir at que ponto vantajoso utilizar apenas um rmware e a partir de onde passa a ser melhor utilizar um SO.
2.2.1 Caractersticas de Sistemas Embarcados Linux
Sistemas Embarcados Linux tm diversas caractersticas que os diferem dos sistemas Linux de propsito geral, como os desktops. A seguir, so listadas algumas caractersticas que encontramos nesse tipo de sistema, conforme listadas em ( , 2003).
YAGHMOUR
Tamanho
O tamanho de um sistema embarcado Linux inuencia e inuenciado por diversos fatores. Primeiramente, importante notar que um sistema embarcado Linux pode ter diferentes tamanhos fsicos, indo desde clusters que ocupam prdios inteiros at relgios de pulso. O tamanho fsico inuencia diretamente na quantidade e no tipo de componentes que podem ser acomodados no sistema, sendo esse um fator determinante na capacidade computacional do sistema como um todo. Assim, fatores como velocidade da CPU e quantidade de memria RAM e memria no voltil so fortemente inuenciados pelo tamanho fsico do sistema.
Requisitos de Tempo
Para alguns sistemas embarcados, existe uma necessidade que o sistema reaja dentro de um perodo de tempo pr-denido. Quando h essa necessidade, dizemos
que se trata de um sistema de Tempo Real. Um sistema de Tempo Real pode ser classicado em dois tipos bsicos: sistemas de tempo real crticos, ou hard real time systems, e sistemas no-crticos, ou soft real time systems. Um sistema de tempo real considerado do tipo hard caso ele precise necessariamente reagir dentro do tempo estimulado, caso contrrio algo catastrco acontecer. Alguns exemplos clssicos de um sistemas de tempo real crticos so computadores de bordo de aeronaves, sistemas de monitoramento de caldeiras, alm de sistemas em que uma falha em seu funcionamento possa por em risco vidas humanas. J os sistemas do tipo soft tambm possuem restries temporais, mas nada de catastrco ocorre caso os requisitos no sejam atendidos. Normalmente quando um sistema soft no cumpre seu requisito temporal, ocorre apenas uma degradao na experincia do usurio. Um exemplo deste tipo de sistema um sistema multimdia como um mp3 player. O Linux no considerado um SO de tempo real. Existem, no entanto, variaes do Linux desenvolvidas para dar suporte a aplicaes de tempo real do tipo hard. Um exemplo notvel o RTLinux ( , 1999), que consiste basicamente em um SO que roda o Linux inteiro como um de seus processos, sendo totalmente preemptvel. Este SO, no entanto um projeto paralelo, no relacionado com o projeto do kernel do Linux.
YODAIKEN
Conectividade
A conectividade, ou seja, a capacidade do sistema estar conectado a uma rede, cada vez mais uma necessidade para a maioria dos sistemas embarcados. Mesmo sistemas que tradicionalmente no precisam conectar-se a uma rede, como televises, geladeiras e torradeiras, agora possuem acesso internet. Desta forma, este um dos itens essenciais no design de um sistema embarcado Linux. Os dispositivos podem ter uma ou mais formas de conectar-se internet, podendo ser via cabos ou sem o. O Linux incorpora nativamente diversos protocolos de rede, o que facilita bastante o design de dispositivos com estas caractersticas.
Interao com o usurio
O grau de interao com o usurio pode variar bastante de um sistema para outro. Alguns sistemas embarcados esto completamente focados na interao com o usurio, como o caso dos leitores de livros eletrnicos. Estes dispositivos
10
apresentam uma tela para mostrar as informaes ao usurio e vrias interfaces de entrada para receber os dados. Por outro lado, existem dispositivos, como os de controle industrial, por exemplo, que possuem poucas formas de interao com o usurio, como LEDs e botes, ou mesmo nenhuma interao, realizando todo o trabalho sem a interferncia de um operador.
2.2.2 Vantagens do Linux para Sistemas Embarcados
Existem uma srie de motivos por trs da supremacia do Linux em sistemas embarcados em comparao com outros SOs. Esta seo lista alguns desses motivos. Algumas destas vantagens esto presentes tanto em ambiente desktop quanto em servidores e em ambientes corporativos, enquanto outras so especcas para ambientes embarcados.
Qualidade e conabilidade do cdigo
Em geral, a qualidade e a conabilidade so duas grandezas desejveis, porm difceis de medir em um cdigo, por serem muito subjetivas. Entretanto, possvel faz-lo analisando uma srie de caractersticas que a maioria dos programadores considera que contribuem para aumentar a qualidade e a conabilidade. Algumas caractersticas que contribuem para a qualidade do cdigo so a modularidade, a clareza do cdigo, a extensibilidade e a congurabilidade. Por outro lado, para ser considerado convel, o cdigo deve ter caractersticas como previsibilidade, capacidade de recuperao de erros e longevidade. A maior parte dos programadores concorda que o kernel do Linux se encaixa nas descries de qualidade e conabilidade. A razo principal disto o modelo de software aberto, que conta com a contribuio da comunidade que est sempre debatendo os possveis problemas de design e sugerindo melhorias. Geralmente, quando alguma deciso ruim de design tomada, as vrias pessoas espalhadas pelo mundo responsveis pelos testes apontam o problema e o mesmo rapidamente solucionado. O Linux tem mostrado bastante longevidade ao longo do tempo, no apresentando grandes problemas de design com o tempo de uso. Alm disso, possvel selecionar quais componentes do sistema sero instalados, e quais sero evitados. O mesmo vale para as funcionalidades do kernel, onde possvel escolher quais sero carregadas na imagem nal do kernel. Uma maneira simples de atestar
11
a qualidade do cdigo observar as vrias listas de discusso sobre o Linux. Nestas listas possvel ver que os problemas apontados costumam ser resolvidos muito rapidamente e novas funcionalidades so adicionadas com velocidade semelhante, o que mostra que o cdigo atende s caractersticas listadas acima.
Disponibilidade do cdigo
Um fator primordial para a adoo do Linux em um sistema embarcado o fato de que todo o cdigo fonte do Linux, bem como as ferramentas necessrias para sua compilao, esto disponveis para todos sem nenhuma restrio de acesso. Isso permite que, quando ocorre algum problema do sistema, toda a comunidade possa procurar a causa do mesmo no cdigo fonte, fazendo com que o problema seja resolvido rapidamente. Em outros SOs embarcados, cujo cdigo fonte no est disponvel ou precisa ser comprado, no existe essa possibilidade. Outra vantagem da disponibilidade do cdigo que o prprio desenvolvedor pode solucionar o problema sem ajuda externa, apenas investigando o cdigo fonte. possvel tambm ter um entendimento melhor do funcionamento do SO quando se tem o cdigo disponvel, podendo criar rotinas mais otimizadas e de acordo com as rotinas internas do sistema. A disponibilidade do cdigo tambm contribui com a padronizao das plataformas, uma vez que possvel desenvolver sistemas Linux completamente baseados em software de cdigo aberto. Os desenvolvedores, ento, tendem a adotar padres de projetos para poder tirar proveito do que j foi desenvolvido dentro do mesmo padro. Um exemplo desse tipo de comportamento, por parte dos desenvolvedores, o projeto OpenMoko ( , 2011), que consiste em um telefone celular baseado em Linux que j possui as funcionalidades bsicas necessrias para este tipo de dispositivo. Assim, um desenvolvedor interessado em projetar um telefone celular baseado em Linux pode partir do projeto OpenMoko, utilizando as funcionalidades bsicas oferecidas por este projeto e se concentrando apenas no diferencial do seu produto. Com essa abordagem, o desenvolvedor ganha bastante tempo no desenvolvimento.
OPENMOKO Inc
Suporte a Hardware
O Linux suporta uma grande quantidade de plataformas e dispositivos de hardware. Embora muitos fabricantes no disponibilizem drivers Linux para seus
12
produtos, a comunidade costuma desenvolver e dar suporte a esses drivers. Assim, no h o risco de o fabricante descontinuar o suporte a determinado hardware, j que a comunidade responsvel pelo suporte. Alm de suportar uma grande quantidade de dispositivos, o Linux j foi portado para uma grande quantidade de plataformas, rodando em diferentes arquiteturas. Mesmo que a arquitetura escolhida ainda no seja suportada, sempre possvel contactar algum que teve uma experincia semelhante de porte do Linux para diferentes plataformas e obter ajuda durante o processo. Graas a essa portabilidade, o Linux pode ser utilizado em sistemas de diferentes tamanhos, com diferentes requisitos e com uma ampla gama de custos.
Protocolos de comunicao e padres de software
Outro fator que contribui para o destaque do Linux como SO em sistemas embarcados a variedade de protocolos e padres de software suportados. Assim, fcil integrar sistemas Linux com outros sistemas j existentes. Um sistema Linux pode, por exemplo, conectar-se a uma rede local Windows sem problemas, atuando inclusive como servidor sem que os clientes percebam mudanas. O mesmo vale para protocolos como o bluetooth, Sistema de Posicionamento Global (Global Positioning System ) (GPS), Sistema Global para Comunicaes Mveis (Global System for Mobile Communications ) (GSM), dentre outros, onde um sistema Linux facilmente integrado a uma infraestrutura previamente estabelecida.
Ferramentas disponveis
Devido prpria natureza do sistema, usurios do Linux costumam seguir a losoa do software de cdigo aberto. Isto signica que, normalmente, quando algum desenvolve uma ferramenta para Linux, o cdigo disponibilizado publicamente. Isto ajuda bastante o desenvolvimento, j que muitas ferramentas que podem ser necessrias, como compiladores, device drivers e aplicativos em geral j esto disponveis, pelo menos em um estgio inicial. Em outros casos, existem ferramentas semelhantes que podem ser usadas como base para o desenvolvimento. Em todo caso, o esforo de desenvolvimento reduzido devido disponibilidade das ferramentas, bem como dos autores das mesmas, que costumam fornecer suporte no desenvolvimento.
13
Custo
Normalmente, um projeto tem trs custos associados ao software. O primeiro o custo da aquisio das licenas de desenvolvimento. Normalmente, estas licenas limitam o nmero de desenvolvedores que podem trabalhar com o projeto, alm de possuirem uma data de expirao. O segundo custo a aquisio de ferramentas adicionais, como Ambiente Integrado de Desenvolvimento (Integrated Development Environment )s (IDEs) e designs de referncia. Finalmente, depois que o produto est pronto, possvel que a empresa cobre um custo por unidade produzida, chamado de royalty. Dependendo do projeto, estes custos de software podem impactar fortemente no custo total do projeto, fazendo com que o produto nal que menos competitivo. Em um projeto que utiliza o Linux, este modelo no se aplica. Primeiramente, tanto o SO em si quanto as ferramentas de desenvolvimento so gratuitos, eliminando os dois primeiros custos. Em segundo lugar, a licena permite que o sistema seja distribudo livremente, no havendo o terceiro custo, vindo de royalties. Os custos de software que podem existir em um projeto Linux aparecem quando o desenvolvedor opta por adiquirir uma distribuio pronta, com todos os pacotes inclusos e devidamente compilados. Nesse caso, muitas vezes, as empresas cobram pela distribuio ou pelo suporte tcnico. Em outros casos, as empresas cobram para realizar o porte do Linux para a plataforma desejada. Em todos os casos, o gasto adicional ocorre apenas caso o desenvolvedor queira economizar no tempo de projeto, no sendo um gasto absolutamente necessrio. importante ter em mente que h uma tendncia cada vez maior de convergncia entre os sistemas de propsito geral, como computadores de mesa, e os sistemas embarcados. Com a grande propagao de smartphones e tablets no mercado, estes conceitos se confundem. No projeto destes dispositivos, esto presentes tanto preocupaes do mundo embarcado, como grande autonomia de bateria, conectividade e portabilidade quanto preocupaes comuns em desktops, como resposta rpida ao usurio e amplo suporte a aplicaes. Assim, necessrio que os SOs sejam adaptados aos dois mundos, pegando as principais caractersticas de cada um. Neste sentido, o Linux um bom candidato a SO utilizado nesses sistemas, j que ele tem se mostrado adaptado a ambas aplicaes. De fato, o SO Android, que roda sobre um kernel Linux, hoje o mais utilizado em smartphones ( , 2011), alm de ser o segundo mais utilizado em tablets ( , 2011), o que
PCWORLD TGDAILY
2.3. Processadores ARM
14
mostra que o Linux tem sido muito bem sucedido neste tipo de ambiente.
2.3 Processadores ARM
2.3.1 Viso Geral da Arquitetura de Processadores ARM
Nesta seo, so descritas resumidamente as caractersticas da arquitetura do core ARM. Do ponto de vista do programador, o core pode ser visto como um conjunto de unidades funcionais conectadas por barramentos de dados. Na Figura 2.2, pode-se ter esta viso, onde as linhas representam barramentos e as caixas representam uma unidade funcional ou uma rea de armazenamento. Pode-se ver na gura que os dados entram no core sempre pelo barramento de dados. Estes dados podem ser tanto instrues que devem ser executadas quanto dados propriamente ditos, como parmetros de funes. Na mesma gura, mostrada uma implementao do ARM usando a arquitetura de Von Neumann, onde os dados e instrues dividem o mesmo barramento. Existe tambm a possibilidade de termos implementaes do ARM utilizando arquitetura Harvard, ou seja, barramentos separados para instrues e dados. Como todos os processadores RISC, o ARM usa uma arquitetura do tipo load-store. Isto quer dizer que existem dois tipos de instrues para mover dados para dentro ou para fora do computador: instrues de carregamento (ou load ), que copiam dados da memria para os registros internos do processador e funes de armazenamento (ou store ), que fazem a cpia de dados dos registros internos para a memria. No h nenhuma instruo que faa a manipulao dos dados diretamente na memria, logo, todo o processamento feito dentro do processador. Cada instruo que chega no processador tratada inicialmente pelo Instruction Decoder. Dentre outras coisas, este bloco responsvel por identicar a qual conjunto de instrues cada instruo pertence. O Register File responsvel por armazenar os dados que chegam ao processador. Este bloco composto por registros de 32 bits. O bloco Sign extend trata dados de 8 e 16 bits com sinal, transformando-os em 32 bits para que sejam armazenados no Register File. Esta etapa importante porque o ARM um processador de 32 bits, ou seja, ele interpreta os dados presentes nos registros internos como dados de 32 bits. A maior parte das instrues do ARM utilizam dois registros de entrada, R e R , e um de sada, R . Os operandos de entrada de uma instruo so lidos dos
m n d
15
Figura 2.2: Fluxo dos dados no core do processador ARM
registros atravs dos barramentos A e B, mostrados na Figura 2.2. Aps o armazenamento dos dados de entrada, a Unidade Lgica Aritimtica (Aritimetic Logic Unit ) (ALU) ou a Unidade Multiplicador-Acumulador (Multiply-Accumulate Unit ) (MAC) carrega os valores R e R e computa o resultado. Instrues de processamento de dados escrevem o resultado R diretamente no Register File, enquanto instrues do tipo load-store usam a ALU para gerar um endereo que ser armazenado no Address Register para, em seguida, ser colocado no barramento de endereos. Depois de passar por todos os blocos funcionais, o resultado R escrito de volta no Register File usando o barramento marcado como result. Para instrues do tipo load-store, o bloco Incrementer atualiza o registro de endereo antes que o core leia ou escreva o prximo valor para ou da memria. Este processo continua at que ocorra uma exceo ou uma interrupo que modique o uxo normal de execuo.
m n d d
16
Registros Internos
Conforme mencionado anteriormente, a maior parte dos registros internos do ARM so registros de propsito geral. Estes registros podem ser utilizados para guardar tanto dados quanto endereos. Geralmente, os registros so identicados pela letra r seguida do nmero do registro. A Figura 2.3 mostra o mapa dos registros internos do ARM que esto disponveis em modo de usurio, que o modo que normalmente usado pelas aplicaes. possvel ver na Figura a existncia de um total de 16 registros de dados, 13 dos quais so usados para dados (r a r ). Os registros r , r e r tm propsitos especcos, funcionando, respectivamente, como stack pointer (sp), que aponta para o ltimo elemento da pilha no momento atual; link register (lr), que guarda o endereo de retorno das funes e program counter (pc), que guarda o endereo da prxima instruo que deve ser buscada pelo processador.
0 12 13 14 15
Figura 2.3: Mapa dos registros do ARM disponveis em modo usurio
Apesar de terem funes bem denidas, os registros r e r podem ser usados tambm como registros de propsito geral. Isto pode ser especialmente til, j que estes registros so salvos automaticamente quando ocorre uma mudana de modo no
13 14
17
13
processador. No entanto, no uma boa prtica usar o registro r como propsito geral quando existe um SO rodando no sistema, j que os SOs costumam assumir que h um endereo vlido de pilha no registro r . Uma caracterstica importante dos registros r a r que eles so ortogonais, ou seja, qualquer instruo pode ser aplicada da mesma forma em qualquer um desses registros. No entanto, algumas instrues operam de modo diferenciado nos registros r e r . Alm dos 16 registros de dados, o ARM possui ainda dois registros de status: o cpsr e spsr, que guardam os status do programa atual e salvo, respectivamene. O Register File possui todos os registros que esto disponveis no momento. Quais registros esto disponveis depende do modo em que o processador est operando.
13 0 12 14 15
Registro de Status do Programa Atual
O Registro de Status do Programa Atual(Current Program Status Register ) (CPSR) um registro de 32 bits utilizado pelo ARM para monitorar e controlar operaes internas. Este registro dividido em 4 blocos, com 8 bits cada, segundo mostra a gura 2.4. As partes sombreadas na gura so reservadas para uso futuro. As quatro regies nas quais o registro est dividido so: ags, status, extenso e controle. O campo de controle contm o modo do processador, estado do mesmo e os bits de mscara de interrupo. O campo de ags contm os chamados ags de condies.
Figura 2.4: Descrio dos bits do registro CPSR
Modos do Processador
O modo do processador determina quais registros esto ativos e os direitos de acesso ao CPSR. Modos privilegiado possuem acesso total, em modos de escrita e leitura, ao CPSR. Por outro lado, modos no privilegiados
18
podem apenas ler o campo de controle do CPSR, mas possuem acesso de leitura e escrita aos ags de condies. No total, o ARM possui sete modos do processador, sendo seis privilegiados: abort, fast interrupt request, interrupt request, supervisor, system e undened, e um modo no privilegiado: o modo de usurio (user mode ). O modo abort usado quando ocorre uma falha de acesso memria. O fast interrupt mode e o interrupt mode so os dois nveis de interrupo disponveis no ARM. O modo supervisor o modo no qual o ARM comea sua execuo, e tambm o modo no qual o kernel trabalha. O modo system uma verso especial do modo de usurio que possui permisses de leitura e escrita no registro CPSR. O modo undened usado quando o processador encontra uma instruo desconhecida ou no suportada. Finalmente, o modo de usurio usado por programas e aplicaes de usurio. Banked Registers A Figura 2.5 mostra os 37 registros, dos quais 20 esto escondidos dos programas na maior parte do tempo, cando disponveis apenas em alguns modos. Estes registros, identicados pelo sombreado na Figura 2.5, so chamados de Banked Registers. O modo no qual os registros esto disponveis mostrado na Figura 2.5 atravs de um prexo que representa o modo. Assim, no modo abort, por exemplo, esto disponveis os registros r13_abt, r14_abt e spsr_abt. Programas rodando em modo privilegiado podem mudar o modo atual de execuo escrevendo diretamente os bits de modo do CPSR. Cada modo do processador, exceto o modo system, possui seu prprio conjunto de banked registers. Cada um deles est relacionado a um registro em modo de usurio, contudo uma alterao feita em um banked register em modo privilegiado no altera o valor do registro em modo de usurio, j que feita uma troca de contexto quando o processador transita entre modo de usurio e modo privilegiado. Estado e Conjuntos de Instrues O estado do processador indica qual conjunto de instrues est sendo usado no momento. Existem trs conjuntos de instrues possveis: ARM, Thumb e Jazelle. O conjunto de instrues ARM s est ativo quando o processador est no estado ARM. Da mesma forma ocorre para o conjunto de instrues Thumb, que s est ativo no estado Thumb. Uma vez no estado Thumb, o processador s pode executar instrues Thumb de 16 bits, no sendo possvel misturar instrues Thumb, ARM e Jazelle sequencialmente.
19
Figura 2.5: Descrio dos bits do registro CPSR
Os bits T e J denem o estado atual do processador. Quando ambos esto em zero, que o estado inicial do processador quando o mesmo energizado, o conjunto de instrues ARM selecionado. Quando um dos bits est setado, o conjunto de instrues correspondente selecionado. Para fazer a transio entre os estados do processador, usada uma instruo especca. Mscaras de Interrupes Os bits de mscara de interrupes so utilizados para que o processador deixe de atender determinadas interrupes. No ARM, duas interrupes esto disponveis: interrupt request (IRQ) e fast interrupt request (FIQ). Para mascarar estas interrupes, so usados os bits 6 e 7 (I e F), desabilitando respectivamente a IRQ e a FIQ. Flags Condicionais Os Flags Condicionais so atualizados quando executada alguma instruo que possui o suxo S. Por exemplo, se a instruo SUBS executada e tem um zero como resultado, o ag Z setado. Estes ags so avaliados para indicar rapidamente que determinadas condies foram atingidas, permitindo saltos
20
condicionais no programa. A Tabela 2.1 mostra os Flags Condicionais mais usados. Flag Q V C Z N Nome da Flag Saturation Overow Carry Zero Negative
Tabela 2.1: Principais Flags Condicionais no processador ARM
setada quando... o resultado gera uma saturao e/ou um overow o resultado da operao causa um overow com sinal o resultado possui um carry sem sinal o resultado zero, tambm usado para indicar igualdade o bit 31 do resultado 1
Execuo Condicional
A execuo condicional controla se o core vai ou no executar determinada instruo dependendo do estado atual dos Flags Condicionais. Antes da execuo, o processador compara o atributo condicional associado instruo com a condio presente nos ags, caso a condio esteja sendo atendida, a instruo executada. Caso contrrio, a mesma descartada. Os atributos condicionais so ps-xados ao mnemnico das instrues. A Tabela 2.2 mostra a lista dos atributos condicionais suportados, seu nome e o(s) ag(s) avaliado(s) na ocorrncia do atributo. Caso nenhum atributo seja passado junto com a instruo, assumido o atributo padro AL (executar sempre).
2.3.2 Processadores ARM em Sistemas Embarcados A losoa de design RISC
O core do ARM utiliza uma arquitetura do tipo Computao com Conjunto de Instrues Reduzido (Reduced Instruction Set Computing ) (RISC). Esta losoa de design consiste em fornecer instrues do processador que executam tarefas bem simples, de modo que cada instruo executada em apenas um ciclo de clock. Assim, a complexidade do hardware reduzida, sendo transferida para o software. A justicativa desta abordagem que mais fcil prover exibilidade em software que em hardware, cando sobre o compilador a responsabilidade de quebrar operaes complexas (como uma diviso, por exemplo) em diversas operaes mais simples. Como resultado disto, a grande demanda em processadores RISC est sobre o compilador. As arquiteturas Computao com Conjunto de Instrues Complexo (Complex Instruction Set Computing ) (CISC), por outro lado, contam com instrues complexas implementadas em hardware, o que garante
21
Mnemnico EQ NE CS HS CC LO MI PL VS VC HI LS GE LT GT LE AL
Tabela 2.2: Lista dos atributos condicionais suportados pelo ARM
Nome Flags Condicionais testados equal Z not equal z carry set/unsigned higher or same C carry clear/unsigned lower c minus/negative N plus/positive or zero n overow V no overow v unsigned higher zC unsigned lower or same Z or c signed greater than or equal NV or nv signed less than Nv or nV signed greater than NzV or nzv signed less than or equal Z or Nv or nV always (no condicional) ignorado
uma performance maior, mas por outro lado diminui a exibilidade e aumenta complexidade e a rea em silcio do processador, o que resulta em um custo maior. A gura 2.6 mostra a relao de complexidade nas duas abordagens.
Figura 2.6: Comparao da localizao da complexidade em sistemas RISC e CISC
No desenvolvimento de processadores RISC, so levadas em considerao as seguintes regras de design :
22
Instrues
Conforme mencionado anteriorimente, processadores RISC possuem poucas instrues que realizam tarefas simples. Cada instruo possue um tempo de execuo xo, permitindo que uma estrutura de pipeline inicie a busca das prximas instrues enquanto a atual est sendo executada. Em processadores CISC, por outro lado, algumas instrues tm tempo de execuo varivel e podem levar vrios ciclos para terminar de executar; Pipelines O processamento das instrues quebrado em tarefas menores, que podem ser executadas em paralelo pelo pipeline. Assim, as fases de buscar, decodicar e executar so realizadas todas simultaneamente, idealmente em um s ciclo de clock, garantindo uma alta velocidade de execuo. No h a necessidade de utilizar um microcdigo para executar as instrues, como ocorre em processadores CISC; Registros Processadores RISC possuem vrios registros de propsito geral, que podem ser usados tanto para armazenar dados quanto endereos. Desta forma, os registros servem como uma pequena poro de memria local para ser utilizada durante o processamento das instrues. Isto no ocorre nas mquinas CISC, que possuem registros dedicados para propsitos especcos; Arquitetura load-store Com esta arquitetura, o processador tem instrues do tipo load and store, ou seja, carregar e guardar, que fazem a transferncia de dados entre a memria externa e os registros internos do processador. Como acessos memria externa so mais custosos, separar acessos memria do processamento dos dados permite uma maior ecincia na execuo, fazendo com que vrias instrues seguidas operem sobre os dados armazenados nos registros internos, sem a necessidade de fazer um acesso memria externa. Em processadores CISC, por outro lado, instrues de processamento de dados podem operar diretamente na memria externa. As regras de design mostradas acima permitem que processadores RISC sejam mais simples, o que permite que o core opere com uma frequncia de clock mais alta que os CISC, que possuem uma complexidade maior. A tendncia atual, no entanto, no optar por nenhuma das abordagens especicamente, fazendo um balanceamento das caractersticas de cada abordagem dependendo do objetivo do projeto, se uma simplicidade maior e reduo dos custos ou uma complexidade maior e maior robustez.
23
A losoa de design ARM
O design do processador ARM norteado por uma srie de parmetros que devem ser levados em considerao. Inicialmente, a maior parte dos sistemas embarcados devem ser portteis, por isso sua alimentao costuma vir de uma bateria. Assim, o ARM deve ser to pequeno quanto possvel, de modo a consumir o mnimo de energia e proporcionar uma maior vida til para a bateria. Outro requisito importante uma alta densidade de cdigo, ou seja, o cdigo gerado no deve ocupar muito espao na memria. Isto importante porque os dispositivos embarcados normalmente possuem restries de tamanho e de custo, o que limita a quantidade de memria disponvel. Adicionalmente, desejvel que a rea do die seja a menor possvel, j que o custo de manufatura de um chip determinado pela sua rea. Quanto menor a rea do core, mais espao ca disponvel para os perifricos, aumentando a integrao e reduzindo o custo total do projeto. Normalmente, os processadores ARM contam com ferramentas de debug integradas em hardware, o que permite que o desenvolvedor tenha total controle sobre o cdigo que est executando no processador, podendo ler os valores dos registros internos do processador e de regies de memria, enquanto o processador est executando cdigo. Desta forma, possvel resolver os problemas que surgem durante o desenvolvimento com muita rapidez, o que resulta numa reduo nos custos de produo. Devido s restries impostas pelo uso em sistemas embarcados, o ARM no utiliza uma arquitetura RISC pura. Em vez disso, ele utiliza muitos conceitos RISC, mas com algumas caractersticas adicionais que permitem um bom desempenho em sistemas embarcados. A seguir esto listadas algumas caractersticas que diferem o ARM de um sistema RISC tradicional. Tempo de execuo varivel para algumas instrues Nem todas as instrues do ARM executam em um nico ciclo de clock. As instrues do tipo load-store, por exemplo, tm tempo de execuo varivel, dependendo do nmero de registros transferidos. Pode ocorrer variao tambm caso a transferncia ocorra em endereos de memria consecutivos, j que neste caso a transferncia mais rpida em comparao com acessos a endereos aleatrios. Suporte a instrues Thumb 16-bit Conforme detalhado anteriormente, o
24
ARM possui mais de um conjunto de instrues. Alm do seu conjunto nativo com instrues de 32 bits, ele suporta o conjunto de instrues Thumb, de 16 bits. Estas instrues de 16 bits aumentam a densidade do cdigo em cerca de 30% em comparao com as instrues de tamanho xo de 32 bits ( , 2004). Execuo condicional Algumas instrues s so executadas quando alguma condio especca atendida. Isto aumenta a performance e a densidade de cdigo. Contudo, gera instrues mais complexas, o que contrrio ao que prega a losoa RISC. Instrues Aprimoradas O conjunto de instrues do ARM suporta algumas instrues complexas, usadas para Processamento Digital de Sinais (PDS), como multiplicaes rpidas de 16 por 16 bits. Estas instrues eliminam a necessidade de utilizar um DSP externo junto com o ARM.
SLOSS; SYMES; WRIGHT
Devido a esta mistura das caractersticas dos sistemas RISC com alguns elementos de sistemas CISC, os processadores ARM possuem um bom equilbrio entre exibilidade, custo e desempenho, sendo bastante adequados para o uso em sistemas embarcados.
2.3.3 Famlias do Processador ARM
As diferentes verses dos processadores ARM costumam ser divididas em famlias, de acordo com o core utilizado. Algumas famlias populares do ARM so o ARM7, ARM9, ARM10 e ARM11. Os nmeros indicam diferentes verses do core, com nmeros ascendentes representando um aumento de sosticao e potncia. importante notar que os nmeros ps-xados nos nomes das famlias no representam exatamente a verso a qual o processador pertence, apesar de nmeros diferentes indicarem verses diferentes. Por exemplo, o ARM7 tambm conhecido como ARMv4T, ou a verso 4 do core do processador ARM (o T presente no nome indica o suporte ao conjunto de instrues Thumb, j apresentado neste trabalho). J a arquitetura ARMv5E apareceu inicialmente no processador ARM9. Esta verso apresentava instrues de DSP aprimoradas (em ingls, enhanced ), da o E presente no nome. O ARM11, por sua vez, utiliza o core ARMv6. Esta verso do core inclui algumas funcionalidades no sistema de gerenciamento de memria e instrues do tipo Single Instruction, Multiple Data (SIMD), ou seja, uma nica instruo pode
2.4. Sistemas de Home Care
25
fazer operaes sobre um bloco de dados, acelerando operaes de movimentao de dados da memria. Depois da introduo da famlia ARM11, foi decidido que era necessrio desenvolver processadores focados na aplicao. Assim, o portiflio de processadores ARM passou a possuir desde representantes de baixo consumo, utilizados em aplicaes sensveis a custo, at processadores de alta performance, utilizados em aplicaes que cobram um grande poder de processamento. Assim, a partir do ARMv7, foram desenvolvidos trs pers de processadores ARM: Perl A: Desenvolvido para aplicaes de alta performance. Estes processadores so desenvolvidos para executar os principais SOs, utilizando alto poder de processamento, sistema de memria virtual com suporte a Unidade de Gerenciamento de Memria (Memory Management Unity ) (MMU). Produtos que utilizam esse perl incluem telefones celulares high-end e outros dispositivos embarcados com alto poder de processamento. Perl R Desenvolvido especialmente para aplicaes em tempo real, onde so necessrios alto poder de processamento, baixa latncia e alta conabilidade. A capacidade de cumprir tarefas de tempo real, no entanto depende do SO que roda sobre o processador, no sendo suciente o uso de um ARMv7-R. Perl M Processadores voltados para aplicaes de baixo custo, onde os fatores principais so a ecincia, o baixo consumo de potncia, baixa latncia de interrupo e facilidade de uso. Devido a essas caractersticas, processadores com perl M so muito utilizados em aparelhos celulares. Os processadores da famlia Cortex foram os primeiros produzidos com a arquitetura ARMv7. Esta famlia inclui os Cortex-A8, utilizados nos smartphones high-end, o Cortex-R4, utilizado para aplicaes de tempo real e o Cortex-M3, amplamente utilizado em sistemas embarcados devido ao seu baixo custo e baixo consumo de energia.
2.4 Sistemas de Home Care
Segundo ( , 2011), Home Care denido como uma modalidade contnua de servios na rea de sade, cujas atividades so dedicadas aos pacientes em um
LEME
26
ambiente extra-hospitalar. Ou seja, os cuidados so realizados fora do hospital, normalmente na casa do paciente. A principal vantagem dos servios de Home Care em relao aos tratamentos realizados dentro do hospital a possibilidade de manter o paciente o tempo todo prximo da famlia. Diferente de um ambiente hospitalar, onde o paciente car a maior parte do tempo em contato com desconhecidos e possveis infeces hospitalares, num sistema de Home Care ele tem a possibilidade de car instalado em sua prpria casa e cercado dos familiares, o que promove uma melhor qualidade de vida para o paciente durante o tratamento. Outra grande vantagem desse sistema, conforme explicado na seo 1.1, o alvio na superlotao de leitos hospitalares, j que cada paciente tratado em regime de Home Care um leito hospitalar a menos a ser ocupado num hospital. Esta segunda vantagem especialmente importante em pases emergentes, como o Brasil, onde a superlotao dos hospitais um problema constante. Obviamente, o sistema tem tambm algumas desvantagens, como por exemplo o fato de que, em regime hospitalar, o paciente tem acesso imediato a mdicos e a todo tipo de equipamento que possa ser necessrio no caso de uma emergncia. Num regime de Home Care, por outro lado, isso no ocorre, sendo necessrio chamar uma ambulncia para fazer o atendimento emergencial, o que pode deixar o paciente sem cuidados por alguns minutos, o que, por sua vez, pode fazer a diferena entre a sobrevivncia ou no do paciente. Desta forma, muito importante que seja feita uma anlise da gravidade do estado do paciente, para que seja tomada a deciso de deix-lo em regime hospitalar ou em regime de Home Care. A deciso depende tambm da vontade e disponibilidade da famlia, j que o paciente deve receber um acompanhamento enquanto est nesse regime. Classicamente, para manter um paciente em regime de Home Care, era necessrio contratar um prossional da sade que casse o tempo todo acompanhando o paciente. Isso gera um grande custo adicional para a famlia. Hoje em dia, possvel utilizar equipamentos de telemedicina para fazer o acompanhamento do paciente remotamente. Com isso, um mdico pode acompanhar o paciente 24h por dia sem a necessidade de se deslocar para a casa do paciente. Segundo ( , 2010), a primeira tentativa de desenvolver um sistema que coleta dados de ECG de um paciente e transferir os dados remotamente para um cardiologista ocorreu na dcada de 70. Hoje, h vrias solues no mercado,
D'ANGELO et al.
27
utilizando diferentes metodologias, que podem ser classicadas de forma simplicada em duas abordagens. A abordagem clssica consiste de um gravador de ECG, que ca na casa do paciente, um canal de comunicao (telefone ou GSM) e uma unidade receptora que ca com o cardiologista. Essa abordagem tem uma srie de desvantagens. A primeira delas que o gravador utilizado desenvolvido para uso dentro de uma clnica ou hospital, por isso acaba tendo uma operao muito complicada para um usurio normal. Outra desvantagem a falta de compatibilidade entre os aparelhos, j que a unidade receptora s funciona com determinado gravador. Alm disso, somente essa unidade receptora pode ler os dados enviados, no sendo possvel o acesso aos dados fora do hospital nem por outra pessoa que no seja o mdico. Finalmente, a abordagem muito sujeita a erros, j que o paciente ca responsvel por enviar os dados, correndo o risco de esquecer de enviar; o canal utilizado muito instvel e sujeito a perda de pacotes e a anlise dos dados feita manualmente pelo mdico. A outra abordagem, mais moderna, consiste em um sistema de ECG com gerenciamento de dados centralizado. Esta abordagem uma evoluo da clssica e est mais alinhada com a tecnologia disponvel atualmente. O gerenciamento de dados centralizado signica que os dados so enviados para um servidor atravs da internet. Assim, o sistema passa a ser dividido em duas partes: o cliente, que ca instalado localmente em um PC, e uma plataforma Web, que acessada pelo cliente. Essa abordagem permite uma srie de avanos, como disponibilizar as medidas automaticamente na tela, gravao do histrico do paciente no banco de dados e acesso aos dados a partir de qualquer computador. Alm disso, a interface construda de modo a ser mais familiar para o usurio, evitando as diculdades presentes na abordagem clssica.
2.4.1 Fundamentos de Eletrocardiograa
Para desenvolver a funcionalidade de exibir leituras dos sinais vitais dos pacientes na tela, mencionada na seo anterior, necessrio um conhecimento bsico acerca dos sinais que se deseja medir. Devido a este fato, esta seo descrever de forma resumida as principais caractersticas de um sinal obtido atravs de eletrocardiograma, que ser o tipo de sinal medido neste trabalho. Como no objetivo do sistema desenvolvido a deteco de problemas cardacos, cando esta parte a cargo do mdico, a descrio do sinal feita aqui ser focada apenas no
28
bsico, suciente para compreender as principais caractersticas do sinal gerado por um eletrocardiograma.
Fisiologia do Corao
O corao um rgo muscular que tem como funo principal impulsionar o sangue atravs dos vasos sanguneos, fazendo com que este circule por todo o organismo. A Figura 2.7, adaptada de ( , 1999), mostra o corte de um corao humano. possvel observar na gura que o corao formado por quatro cmaras internas: dois trios e dois ventrculos. Cada uma destas cmaras possui em sua sada uma vlvula unidirecional, que faz com que o sangue possa uir sempre na mesma direo.
BONSOR
Figura 2.7: Viso detalhada de um corao humano, com suas cavidades e as vlvulas que as interligam (BONSOR, 1999)
O funcionamento do corao se d em dois movimentos: um movimento de contrao, chamado sstole e um de relaxamento, chamado distole. A sstole, por sua vez, se divide em dois momentos: um primeiro em que os dois trios se contraem simultaneamente, expulsando o sangue para os ventrculos, e um segundo onde os ventrculos se contraem, expulsando o sangue para fora do corao. Estes movimentos de contrao ocorrem com fora suciente para bombear o sangue por todo o corpo. Aps a sstole, ocorre o movimento de relaxamento ou distole, que permite que o sangue entre novamente no corao. Este conjunto de movimentos do corao se repete periodicamente e recebe o nome de ciclo cardaco. Todos esses movimentos do corao so controlados por impulsos eltricos que vm do sistema nervoso. Durante um eletrocardiograma, sensores eltricos
29
so posicionados em vrios pontos do corpo do paciente, no intuito de fazer a leitura desses sinais eltricos que comandam o corao. Assim, o exame de eletrocardiograma , na verdade, uma medida dos impulsos eltricos que controlam o corao, e no dos batimentos do corao propriamente ditos.
O Eletrocardiograma
O Eletrocardiograma (ECG) , conforme dito na seo anterior, o registro de todas as atividades eltricas que ocorrem no corao, obtido por meio de eletrodos conectados superfcie corporal do paciente. O ECG uma ferramenta de diagnstico no invasivo largamente utilizada para detectar problemas como arritmias e distrbios em geral no corao. A Figura 2.8, adaptada de ( , 2010), mostra uma onda tpica de ECG. Como possvel ver na gura, a onda dividida em vrias componentes, que representam os diversos impulsos eltricos necessrios para controlar os movimentos descritos na seo anterior.
NETO
Figura 2.8: Tpico sinal de ECG, com indicao das componentes da onda
Na onda mostrada na Figura 2.8, possvel ver, inicialmente, a onda P, que coincide com a propagao da atividade eltrica nos trios e com o incio de sua contrao. O complexo QRS, formado pelas ondas Q, R e S, coincide com a propagao da atividade eltrica nos ventrculos e com o incio de sua contrao. Finalmente, a onda T coincide com o relaxamento das cavidades. Atravs da anlise dessas componentes, o mdico capaz de detectar possveis anomalias no comportamento do corao.
30
Uma medida de particular interesse que pode ser obtida facilmente atravs do ECG a frequncia cardaca, que simplesmente a quantidade de vezes que o corao realiza um ciclo cardaco em um minuto. Para aferir o ciclo cardaco, basta localizar qualquer uma das ondas que formam o ciclo e contar quantas vezes esse tipo de onda aparece em um minuto. A metodologia utilizada para medir a frequncia cardaca detalhada na Seo 3.5.2.
Captulo
Metodologia de Desenvolvimento
Este captulo apresenta a metodologia de desenvolvimento utilizada para este projeto, bem como os detalhes da arquitetura proposta. Na Seo 3.1 apresentada a arquitetura proposta para o trabalho, em forma de diagrama de blocos funcionais. A seo 3.2 mostra o ambiente de desenvolvimento utilizado, bem como as ferramentas de desenvolvimento de hardware e software. A seo 3.4 mostra como foi feita a customizao do SO para o projeto, enquanto a seo 3.3 mostra em detalhes o hardware utilizado. Finalmente, a seo 3.5 detalha o software que foi desenvolvido.
3.1 Arquitetura Proposta
A arquitetura proposta consiste basicamente em um sistema que tem como elemento de processamento um microcontrolador Freescale iMX53, que possui um core ARM Cortex-M3. O sistema todo pode ser visto na Figura 3.1. O iMX53 recebe, via bluetooth, os sinais vitais do paciente, medidos por um sensor cujo desenvolvimento no faz parte do escopo deste trabalho. Quando os sinais so recebidos, o primeiro bloco, chamado aquisio trata de organizar e armazenar os dados em um banco de dados. Estes dados cam disponveis para consultas futuras, montando assim um histrico dos sinais vitais do paciente. Alm de armazenados, os dados referentes aos sinais vitais do paciente so enviados para o segundo bloco, chamado anlise. Neste bloco funcional, a medida do sinal comparada com valores pr-denidos pelo mdico. Caso algum sinal esteja fora da faixa determinada como segura pelo mdico, um alerta acionado, utilizando a 31
3.1. Arquitetura Proposta
32
conectividade presente no sistema. Assim, o alerta pode ser mandado via Servio de Mensagens Curtas (Short Message Service ) (SMS), email ou mesmo uma ligao utilizando servios de VoIP, para a famlia do paciente, para o mdico ou para o servio de emergncia.
ARM-Based Hardware Presso BPM Temp SatO2
ELETRODO
AQUISIO
Armazena os sinais vitais
Paciente
Sinais vitais
Servidor WEB
ANLISE
Pgina WEB
Caso algum sinal esteja anormal ALERTA PARA A FAMLIA
Presso: XXX BPM: XXX Temperatura: XXX SatO2: XXX
Banco de Dados Local
Alerta via sms, ligao, email, etc. Banco de Dados Remoto Sincroniza periodicamente (ao final do dia, por ex.) Verificar os sinais vitais atuais do paciente
User
Figura 3.1: Arquitetura proposta para o sistema de Home Care
Enquanto faz a checagem descrita no pargrafo anterior, o sistema trata de formatar uma pgina Web, que publicada atravs de um servidor Web que roda no prprio iMX53. A pgina Web a principal forma de interao entre o sistema e o usurio, que pode ser um familiar do paciente, um mdico ou algum do plano de sade. Nesta pgina, exibido o estado atual dos sinais vitais, atravs de grcos temporais. tambm atravs desta pgina Web que o mdico pode congurar os limiares aceitveis para cada sinal vital do paciente. Assim, o sistema no capaz de realizar um diagnstico por si s. Em vez disso, o mdico faz os exames pertinentes e determina atravs de metodologias tradicionais quais so os limiares aceitveis para cada paciente. O que o sistema faz vericar o tempo todo se os sinais vitais esto
3.2. Ferramentas Utilizadas
33
dentro desse limiar determinado pelo mdico. Ainda na Figura 3.1, possvel ver que so usados dois bancos de dados: um local, que armazena um histrico das medidas dos sinais vitais feitas pelo dispositivo. O outro banco externo ao sistema e seria, num cenrio real, o banco de dados do plano de sade, onde seria possvel guardar um histrico dos sinais vitais do paciente, para consulta por parte do plano. A sincronia entre o banco local e o banco remoto feita peridicamente, podendo ser realizada, por exemplo, ao nal do dia. Alm de servir para manter um histrico atualizado, o banco de dados remoto serve para fornecer uma maior conabilidade ao sistema, servindo como cpia de segurana do contedo do banco de dados local. Assim, caso haja algum problema com o dispositivo ou o mesmo precise ser trocado, o custo para a troca mnimo, j que tanto os dados histricos dos sinais vitais do paciente quanto as conguraes realizadas pelo mdico esto guardados no banco de dados remoto, sendo necessrio apenas fazer a sincronizao entre os bancos para voltar a ter todos os dados localmente. importante ressaltar que a arquitetura do projeto foi pensada para monitorar qualquer sinal vital de um paciente. Contudo, o desenvolvimento do software exige que sejam escolhidos os sinais vitais que sero monitorados. Assim, para este trabalho, foi escolhido trabalhar apenas com sinais de eletrocardiograma. Assim, todo o software e a pgina da Web foram desenvolvidos para dar suporte monitorao deste tipo de sinal. A arquitetura, no entanto, permite a adio de outros tipos de sinal para monitoramento no futuro. As prximas sees detalham o hardware e o software desenvolvidos para implementar a arquitetura discutida nesta seo. Antes, porm, importante mencionar as ferramentas utilizadas para o projeto, tanto na parte de software quanto para o hardware.
3.2 Ferramentas Utilizadas
O sucesso de um projeto depende fortemente das ferramentas que so utilizadas. Sempre que possvel, deve-se selecionar cuidadosamente quais ferramentas sero utilizadas em cada fase do projeto, evitando que escolhas erradas acabem impactando no tempo de execuo do projeto. Esta seo detalha as ferramentas que foram utilizadas para este processo, justicando o uso das mesmas e mostrando o impacto de cada uma no resultado nal do projeto. Sempre que possvel, foi
34
dada a preferncia ao uso de ferramentas livres e de cdigo aberto, principalmente no desenvolvimento do software. Isto foi feito no intuito de diminuir o custo nal do projeto e para permitir, na medida do possvel, que qualquer pessoa que tenha interesse em extender este projeto no futuro tenha o mnimo possvel de diculdades para comear a trabalhar, partindo inicialmente de um ambiente de desenvolvimento de baixssimo custo.
3.2.1 Software
Esta seo descreve as ferramentas utilizadas para o desenvolvimento da parte de software do projeto.
U-Boot
O programa Das U-Boot, ou simplesmente U-Boot (Universal Bootloader) um rmware gerenciador de boot. Isto signica que ele o primeiro programa executado quando o sistema inicializado, sendo o responsvel por selecionar o SO que ser executado e congur-lo de acordo com as conguraes do usurio, passando os parmetros de inicializao adequados. Na prtica, o gerenciador de boot serve como uma interface atravs da qual o usurio pode fazer algumas conguraes iniciais no sistema, deixando-o pronto para rodar o SO sem problemas. O U-Boot distribudo sob a licena GPL ( , 2007), o que signica que seu cdigo fonte est disponvel e pode ser modicado vontade, o que d uma grande exibilidade ao mesmo, permitindo que seja utilizado em uma grande variedade de plataformas diferentes. De fato, o U-Boot hoje d suporte a uma grande variedade de plataformas, incluindo vrios exemplos de plataforma de arquiteturas ARM, AVR32, Blackn, Microblaze, MIPS, Powerpc, x86, dentre outras. A lista completa de plataformas suportadas pode ser vista explorando o cdigo fonte, disponvel em ( , 2011). O foco principal do desenvolvimento do U-Boot o suporte ao SO Linux e, como resultado, o cdigo como um todo bastante otimizado para esse SO. A escolha do U-Boot como gerenciador de boot para este projeto foi motivada pelos dois fatores discutidos acima: o fato de ser regido pela licena GPL, permitindo que fossem feitas modicaes para adaptar o rmware plataforma utilizada, caso fosse necessrio; e a grande integrao com o Linux, que j evita o esforo de integrao entre bootloader e Sistema Operacional. Adicionalmente, conforme
FREE SOFTWARE FUNDATION U-BOOT
35
ser mostrado na seo seguinte, o U-Boot suportado nativamente pelo Linux Target Image Builder (LTIB), o que tambm facilita o processo de desenvolvimento. Finalmente, um ltimo fator a favor do U-Boot que, diferente de outros bootloaders como o RedBoot, o U-Boot d suporte a uma grande variedade de sistemas de arquivos, incluindo o sistema FAT, presente em mdias de armazenamento como pendrives e sd cards e sistema ext2, presente em sistemas Linux, possibilitando o uso de tcnicas o que permitem que a imagem do SO que armazenada em um local remoto, sendo carregada via rede para o sistema alvo, eliminando a necessidade de realizar gravaes na memria ash do microcontrolador. Para este projeto, durante o desenvolvimento, o U-Boot cava armazenado em um sdcard, enquanto o kernel e o sistema de arquivos linux cavam em uma mquina remota de desenvolvimento, sendo carregados ambos via rede. Na verso nal, tanto o kernel quanto o sistema de arquivos foram transferidos para o sdcard, permitindo que o sistema funcione de modo independente. Esta exibilidade do U-Boot permitiu uma otimizao do tempo de projeto, j que dependendo do bootloader utilizado, talvez fosse necessrio fazer uma nova gravao no sdcard em cada alterao no sistema de arquivos, por exemplo.
LTIB
O Linux Target Image Builder (LTIB) ( , 2011) uma ferramenta que automatiza o processo de compilao, personalizao e instalao de uma imagem do SO Linux. Utilizando o LTIB, possvel gerar uma imagem do Linux com todos os pacotes desejados j devidamente adicionados, bem como todas as alteraes necessrias no kernel, como device drivers e seleo da plataforma de destino. Alm de congurar o Linux, conforme adiantado na seo anterior, o LTIB permite, atravs da seleo de algumas opes por meio de uma interface grca, que seja gerada uma imagem personalizada do U-Boot, tambm pronta para a plataforma de destino. Apesar de no ser estritamente necessrio para o desenvolvimento de projetos com Linux embarcado, j que todas as operaes que so feitas pelo LTIB tambm podem ser feitas manualmente editando os arquivos de congurao do Linux e do U-Boot, o LTIB facilita bastante essas operaes, pois fornece uma interface grca na qual possvel ter uma viso geral de quais opes esto selecionadas no momento. Outra vantagem do uso do LTIB que ele j incorpora imagem do Linux o
LTIB
36
(BSP) correspondente plataforma de destino, fazendo isso de maneira praticamente transparente para o usurio. Assim, uma vez congurado o ambiente, ca muito simples realizar mudanas e personalizaes, tanto no kernel quanto no sistema de arquivos, no bootloader ou no prprio BSP. Assim como o U-Boot, o LTIB tambm distribudo sob licena GPL, incorporando todas as vantagens das ferramentas de cdigo aberto.
Board Support Package
Eclipse
O Eclipse ( , 2011) uma IDE de cdigo aberto criada inicialmente para desenvolvimento em linguagem de programao Java. No entanto, devido sua natureza de cdigo aberto, rapidamente foram criadas extenses para vrias linguagens, sendo bastante usada para desenvolvimento em Ada, C, C++, COBOL, Perl, PHP, Python, Ruby, Scala, dentre outras linguagens. Para este projeto, o Eclipse foi escolhido por ter uma vasta gama de opes para desenvolvimento em linguagem C, principal linguagem utilizada no kernel Linux, por ser cdigo aberto e tambm pela familiaridade anterior com a IDE. O uso de uma IDE fundamentalmente importante em um projeto que envolve alteraes no kernel do Linux, j que o kernel possui seu cdigo distribudo entre muitos arquivos, vrios deles especcos para cada arquitetura ou plataforma. Desta forma, sem uma boa IDE, possvel que o desenvolvedor encontre problemas para manter seu cdigo organizado e para depurar as funes quando algo d errado.
ECLIPSE
Apache
Apache um servidor HTTP de cdigo aberto e o servidor mais utilizado para pginas Web. Em maio de 2010, o Apache foi usado para disponibilizar 54,68% dos sites em geral e 66% dos sites mais acessados ( , 2010). O Apache foi escolhido pela sua popularidade, por ser livre e por sua compatibilidade com o linux. Alm disso, o uso de um servidor HTTP pronto, em vez de desenvolver um proprietrio, facilita bastante o projeto, diminuindo o tempo total de projeto.
NETCRAFT
MySQL
MySQL um sistema de gerenciamento de banco de dados amplamente utilizado em diversas aplicaes no mundo inteiro. O sistema funciona basicamente atravs da troca de mensagens (chamadas queries ) utilizando strings ASCII. As mensagens
37
possuem uma sintaxe prpria, mas so geralmente simples de implementar na maioria das linguagens de programao. Neste trabalho, o MySQL foi utilizado para guardar a base de pacientes cadastrados, os valores aceitveis para os sinais vitais bem como qualquer informao que precisasse de um armazenamento a longo prazo.
PHP
PHP uma linguagem interpretada utilizada normalmente em servidores para gerar contedo dinmico na Web. Basicamente, o PHP uma linguagem de programao que possui facilidades para formatar a sada dos scripts como pginas Web ou elementos html que possam ser facilmente formatados por um navegador Web. Para este trabalho, o PHP foi utilizado para realizar diversas funes no servidor, como alterao de dados de pacientes, denio dos limiares aceitveis para os sinais vitais e gerao do grco em tempo real. interessante notar que o Apache, o MySQL e o PHP juntos rodando em um servidor Linux so uma congurao bastante comum, usada por muitos sites na Web. Normalmente, esta combinao recebe o nome de LAMP (Linux Apache MySQL PHP). Assim, ao utilizar este conjunto de ferramentas, pode-se usufruir da grande disponibilidade de suporte disponvel na rede.
3.2.2 Hardware
A plataforma de Hardware utilizada foi a Freescale i.MX53 Quick Start Board ( , 2011), que conta com um processador i.MX53, alm de uma srie de interfaces j montadas, o que facilita bastante o desenvolvimento. O hardware nal do projeto, no caso de um produto comercial, seria uma verso bastante reduzida da Quick Start Board, j que a maior parte das conexes no utilizada para este projeto. Contudo, esta plataforma de hardware foi escolhida para o prottipo para eliminar a necessidade de desenvolver uma placa proprietria. Alm disso, a Quick Start Board j fornece algumas ferramentas como um BSP padro, que facilita a personalizao do kernel do Linux, alm do suporte que pode ser obtido diretamente da Freescale.
FREESCALE
3.3. Descrio do Hardware
38
3.3 Descrio do Hardware
Conforme mencionado na seo 3.2.2, o hardware utilizado foi um kit de desenvolvimento Freescale i.MX53 Quick Start Board, o que eliminou a necessidade de desenvolver o hardware. Adicionalmente, foram utilizados mdulos comerciais para as interfaces de bluetooth e wi, ambos conectando-se Quick Start Board atravs de conexes USB. A inteno inicial do projeto era de desenvolver placas de expanso para estas duas interfaces, contudo, por restries de tempo do projeto, optou-se por utilizar mdulos prontos, o que reduziu o tempo total de desenvolvimento, mesmo que isso tenha levado a um aumento no custo nal do prottipo. Em verses posteriores, a ideia desenvolver todo o hardware, diminuindo o custo de produo por unidade. No entanto, o projeto desenvolvido permitiu validar o conceito da soluo.
3.4 Customizao do Sistema Operacional
O SO utilizado no projeto foi desenvolvido a partir do BSP fornecido pela Freescale, fabricante do processador e do kit de desenvolvimento utilizados. O BSP inclui uma verso do kernel do Linux j portada para o processador, e devidamente customizado para operar com os perifricos presentes na placa. Desta forma, o esforo necessrio para realizar o porte e customizao do kernel diminui consideravelmente. O BSP conta ainda com o U-Boot devidamente portado para o processador e uma srie de pacotes que podem ser adicionados ao Linux, aumentando as funcionalidades do SO. Partindo do BSP fornecido, foram feitas inicialmente customizaes no U-Boot e no kernel, fazendo com que ele operasse corretamente no ambiente de desenvolvimento. O ambiente , basicamente, o mostrado na Figura 3.2, consistindo de um laptop conectado na mesma rede que a Quick Start Board. O U-Boot ca gravado em um carto de memria conectado placa, enquanto a imagem do kernel e o sistema de arquivos cam no laptop. Assim, ao ser energizado, o sistema inicialmente copia o U-Boot do carto de memria para a memria RAM e comea a execut-lo. O U-Boot est congurado para buscar o kernel do Linux no laptop, via rede utilizando o Protocolo de Transferncia de Arquivos Trivial (Trivial File Transfer Protocol ) (TFTP). O kernel, depois de carregado, tambm est congurado para receber o sistema de arquivos via rede, utilizando o Sistema de Arquivos em
3.4. Customizao do Sistema Operacional
39
Serial
Ethernet
Ethernet
Switch Laptop
i.MX53 Quick Start

U-Boot
Kernel Sistema de Arquivos
Figura 3.2: Ambiente de desenvolvimento do SO
Rede (Network File System ) (NFS). O terminal do Linux ca congurado para funcionar via porta serial, tambm conectada ao laptop. A principal vantagem desse ambiente a facilidade para fazer alteraes no sistema de arquivos, mesmo enquanto programas so utilizados. Como preciso modicar diversos arquivos, instalar programas e ajustar conguraes do sistema muitas vezes ao longo do desenvolvimento, no interessante ter que gravar uma nova imagem diretamente na memria da placa alvo, como muitas vezes precisa ser feito quando se est utilizando um rmware. Esta exibilidade fornecida pelo NFS mais uma vantagem da utilizao de um SO em vez de um rmware em um sistema embarcado. Na verso nal, tanto o kernel quanto o sistema de arquivos foram gravados diretamente no carto de memria conectado placa, deixando o funcionamento do sistema completamente independente do laptop. Aps a congurao inicial do ambiente, foi necessrio adicionar uma srie de pacotes ao Linux de modo a fornecer as funcionalidades desejadas, fazendo um papel semelhante ao das empresas que desenvolvem as distribuies Linux, como Ubuntu, Debian, Red Hat, dentre outras. A principal vantagem de partir do kernel puro e adicionar os pacotes necessrios ao invs de utilizar uma distribuio pronta o tamanho nal da imagem que acaba cando menor, o que, alm de ocupar menos espao na memria, oferece um melhor desempenho, j que no h servios
3.5. Descrio do Software
40
desnecessrios rodando no sistema.

3.5 Descrio do Software
O software desenvolvido para este projeto foi dividido em quatro blocos funcionais, conforme mostrado na Figura 3.1. Cada bloco corresponte a uma rotina que executada em loop durante o funcionamento do sistema. Os blocos interagem entre si indiretamente, atravs da escrita e leitura de dados no banco de dados. Ao longo desta seo, cada bloco funcional ser detalhado.
3.5.1 Aquisio de Dados
O primeiro bloco funcional realiza a aquisio dos dados do paciente. A aquisio feita via bluetooth, de acordo com o Perl para Dispositivos de Sade (Health Device Prole ) (HDP). O perl HDP ( , 2009) foi lanado em 2008, mas somente em 2011, com o lanamento da verso 2.6.38 do kernel, o mesmo foi incorporado ao Linux. O perl foi criado para suprir a demanda por uma padronizao do protocolo de comunicao entre dispositivos mdicos bluetooth, j que, antes de haver esta padronizao, cada fabricante desenvolvia seu prprio protocolo, acoplando o design de sistemas de monitoramento ao sensor que pode ser utilizado. A vantagem do uso do novo perl que possvel ter certeza que o sistema ser compatvel com qualquer sensor que seja desenvolvido pensando na compatibilidade com o HDP. Na Figura 3.3, apresentado o uxograma do software de aquisio de dados. O programa inicia sua execuo fazendo uma busca por todos os sensores compatveis com HDP presentes no raio de alcance do bluetooth. Quando acha algum sensor, uma nova thread criada para tratar da aquisio dos dados desse sensor, enquanto a rotina principal do programa continua procurando periodicamente por novos sensores. A thread responsvel pela aquisio dos dados inicia sua execuo vericando se o sensor localizado j est cadastrado no sistema. Caso seja um novo sensor, feito um cadastro do mesmo no banco de dados. A thread inicia ento a aquisio de dados propriamente dita, adquirindo amostras numa taxa determinada pela capacidade do sensor. Cada nova amostra colhida armazenada na tabela correspondente no banco de dados. Quando o sensor para de responder, a thread nalizada. Este bloco funcional garante que, a cada momento, haver, no banco de
LATUSKE
41
Aquisio de dados
Inicializao do programa
Procura sensores compatveis

NO
SIM
Achou pelo menos um sensor?
SIM
J h pelo menos uma thread associada a esse sensor?
NO
Inicializa uma thread para cada sensor
L o ID do sensor
J um sensor cadastrado?
NO
Cadastra o sensor
SIM
SIM
Tem uma nova amostra disponvel? NO
L uma amostra
Salva a amostra
Fim da Thread
O sensor ainda est respondendo?
Figura 3.3: Fluxograma do software que realiza a aquisio dos dados
dados, informaes atualizadas de todos os sensores presentes dentro do alcance do dispositivo, e que cada novo sensor que entra no raio de alcance ser cadastrado no banco de dados. No entanto, este bloco no faz a associao entre cada sensor e um paciente. Cabe ao usurio (mdico ou familiar) fazer, atravs da pgina Web, a associao entre sensores e pacientes. Por padro, assumido que todos os sensores presentes pertencem ao mesmo paciente, mas possvel, no momento do cadastro de um paciente, explicitar quais sensores esto ligados a este paciente.
3.5.2 Anlise dos Dados
O segundo bloco funcional trata as amostras obtidas pelo primeiro, gerando dados teis para o usurio. Conforme dito na seo 3.1, o software desenvolvido para
42
este trabalho focado na aquisio de sinais de batimentos cardacos. Desta forma, este bloco funcional l amostras referentes tenso medida pelo eletrocardiograma e gera como sada a frequncia cardaca atual do paciente. Observando novamente a Figura 2.8, podemos ver que o complexo QRS tem uma peculiaridade que pode ser utilizada na medio da frequncia cardaca: nessa parte do sinal que ocorre a variao mais rpida da tenso. Devido a esse fenmeno, a derivada ser usada para localizar os complexos QRS no sinal, e a distncia mdia entre dois complexos adjacentes ser a frequncia cardaca.
Anlise dos dados
L os dados armazenados
Pega as prximas 10 amostras
NO
Fim das amostras armazenadas?
SIM
Volta para a primeira amostra Pega 10 amostras consecutivas Calcula a derivada para essas amostras
NO
Pega 10 amostras consecutivas
Calcula a derivada para essas amostras

SIM
A derivada foi a maior encontrada at agora?
Salva a derivada
A derivada maior que 90% da maior derivada? SIM
Pega as prximas 10 amostras
NO
Salva o ndice
NO
Fim das amostras armazenadas?
SIM
Salva o valor atual da frequncia cardaca em bpm
Converte a diferena de nmero de amostras para bpm
Encontra a diferena mdia entre dois ndices consecutivos
Varre os ndices armazenados
Figura 3.4: Fluxograma do software que realiza a anlise dos sinais vitais
A Figura 3.4 mostra o uxograma deste programa. A execuo do programa comea com a leitura dos dados gerados pelo bloco Aquisio. As amostras so lidas
43
em blocos de 10, tamanho este que foi denido empiricamente. O primeiro lao que se observa no uxograma tem como objetivo encontrar a regio do sinal onde ocorre a maior derivada. Uma vez localizada a maior derivada, o sinal varrido novamente em busca de todos os pontos onde aparece um valor de derivada igual a pelo menos 90% da maior derivada encontrada. Esses pontos so as localizaes dos complexos QRS. Finalmente, feita uma mdia entre as distncias entre os complexos e o resultado, obtido em nmero de amostras, convertido para unidades de tempo e nalmente para batimentos por minuto, que a unidade usual para frequncia cardaca. O valor obtido salvo em um arquivo, de onde pode ser lido por todos os outros programas.
3.5.3 Gerao da Pgina Web
O terceiro bloco funcional tem a funo de ler tanto as amostras geradas pelo primeiro bloco quanto o valor da frequncia cardaca gerado pelo segundo bloco e apresentar todas essas informaes em uma pgina Web. A Figura 3.5 mostra o uxograma para este programa. No incio de sua execuo, o programa busca no banco de dados a lista de pacientes cadastrados no sistema. Em seguida, o programa verica qual paciente est atualmente selecionado na pgina Web. Feito isso, o software busca no banco de dados as informaes pessoais do paciente, como nome, idade e sexo e as conguraes, como limites aceitveis para frequncia cardaca e os sensores associados ao paciente. Em seguida, gerado um grco com as amostras obtidas do primeiro bloco. O grco ento copiado para a rvore de diretrios do servidor Web, de modo que possa ser acessado pelo servidor na hora da montagem da pgina. Caso no haja mudana no paciente, o programa segue buscando as amostras e gerando o grco. Cada vez que o usurio seleciona um paciente diferente, os dados referentes a esse novo paciente so carregados e segue o ciclo. Tanto o software quanto o servidor Web tm participao na montagem da pgina Web. A funo do software deixar transparente para o servidor o processo de gerao do grco, fornecendo para este apenas uma gura com o grco pronto para ser exibido na pgina. O servidor, por outro lado, responsvel por tratar as requisies do usurio, atualizar o banco de dados caso o usurio faa alguma alterao cadastral nos pacientes e montar a pgina Web, cuidando da formatao e da animao do grco. A pgina Web a interface entre o usurio e o sistema.
44
Gerao da Pgina WEB

Checar qual paciente est selecionado na pgina
SIM
Buscar os dados do paciente no banco de dados
NO
Foi selecionado um paciente diferente?
Buscar o valor atual dos sinais vitais
Gerar o grfico com os ltimos valores dos sinais vitais
Copiar o grfico para os subdiretrios acessados pelo servidor web
Figura 3.5: Fluxograma do software que gera a pgina Web
atravs dela que o usurio faz a monitorao do paciente e tambm congura os valores mximo e mnimo que os sinais vitais podem atingir sem oferecer risco para o paciente.
45
3.5.4 Alerta para a Famlia
O ltimo bloco funcional tem a importante funo de monitorar o valor dos sinais vitais dos pacientes, disparando um alerta para a famlia caso o valor ultrapasse os valores pr-denidos pelo mdico como valores seguros. A Figura 3.6 mostra o uxograma para este programa. O programa funciona lendo continuamente os sinais vitais de todos os pacientes. Como j foi explicado, para este trabalho, o nico sinal vital monitorado a frequncia cardaca. Assim, o programa ca lendo o valor atual da frequncia cardaca de cada paciente e comparando com os limites denidos pelo mdico para cada paciente. Caso alguma frequncia cardaca ultrapasse o limite superior ou inferior, so lanados diversos alertas. O primeiro deles um SMS, que enviado para um telefone celular que pode ser cadastrado atravs da pgina Web. Em seguida, mandado um email, tambm para o endereo cadastrado atravs da pgina Web. Finalmente, a ocorrncia do evento registrada no banco de dados. Alm disso, o sistema exibir, na pgina Web, um alerta que informa ao usurio qual evento ocorreu e com qual paciente.
Alerta para a Famlia
L os sinais vitais atuais e compara com os limites

NO
O sinal ultrapassa algum dos limites?
SIM
Dispara um SMS para o nmero cadastrado
Registra a ocorrncia do evento no banco de dados
Envia um email para o endereo cadastrado
Figura 3.6: Fluxograma do software que envia um alerta para a famlia do paciente
3.6. Metodologia de Validao
46
3.6 Metodologia de Validao
O projeto foi desenvolvido com suporte ao perl bluetooth HDP. Por ser um perl relativamente novo, adicionado somente esse ano rvore ocial do Linux, ainda no h uma grande disponibilidade de equipamentos compatveis com esse padro. Devido a isto, foi necessrio emular um sensor utilizando um laptop rodando Linux. O laptop executa um programa que simula um sensor, enviando amostras geradas computacionalmente. As amostras pertencem a um sinal de frequncia varivel e adicionado de rudo 1, de modo a reproduzir, o mais elmente possvel, um sinal real. Com esse ambiente de validao, podemos ter uma reproduo el, j que ambos os dispositivos comunicam-se atravs de um protocolo bem estabelecido, que seria o mesmo utilizado por um sensor real. O software que emula um sensor foi desenvolvido utilizando a biblioteca BlueZ ( , 2011), disponvel na rvore do Linux e que, a partir de sua verso 4.8, disponibiliza rotinas para trabalhar com dispositivos HDP.
BLUEZ
1 Para
validao,
foi
gerado
um
Rudo
Branco
Gaussiano
Aditivo,
tipo
de
rudo
que
comumente encontrado em medies de sinais eltricos em geral.
Captulo
Resultados e sua Anlise

4.1 Resultados
Nesta seo sero apresentados os resultados do trabalho. Para uma melhor organizao, os resultados sero divididos em trs mdulos: a pgina Web, que faz a interao com o usurio e apresenta os sinais vitais do paciente, o software, que faz a aquisio dos dados e toda a anlise dos sinais e o hardware sobre o qual a aplicao executada.
4.1.1 Pgina Web
A Figura 4.1 mostra a viso principal da pgina Web. nesta tela que mostrado o ECG do paciente em tempo real. A pgina ca disponvel para acesso a partir da rede local e pode ser disponibilizada para acesso externo. Desta forma, o mdico pode fazer o acompanhamento do paciente distncia, no havendo a necessidade de manter um prossional em contato direto com o paciente. O grco mostrado na Figura 4.1 foi gerado computacionalmente, mas possui todas as caractersticas presentes em um sinal de ECG real, conforme discutido nas sees anteriores. Alm do grco, pode-se observar que a pgina mostra os dados principais para identicao do paciente: o nome, sexo e idade. Alm disso, a pgina mostra a frequncia cardaca atual do paciente. Isto uma vantagem em relao a exames clssicos de ECG, nos quais o mdico tinha que aferir a frequncia cardaca contando os quadrados ocupados por um ciclo em papel milimetrado. Em seguida, a pgina mostra um registro da maior e menor frequncia cardaca j registradas para este paciente e os limites inferior e superior para a frequncia cardaca do paciente. 47
4.1. Resultados
48
Figura 4.1: Pgina Web com o eletrocardiograma em tempo real
A Figura 4.2 mostra a tela de cadastro de pacientes. nessa tela que o mdico faz o cadastro de novos pacientes que sero monitorados pelo sistema. Conforme discutido antes, o mdico dever, atravs de exames tradicionais, determinar os limites seguros para a frequncia cardaca do paciente. uma vez determinados os limites, o mdico entra com os valores nesta tela e o sistema se encarrega de enviar um alerta caso a frequncia cardaca ultrapasse um desses limites. J a Figura 4.3 mostra a tela de alterao de conguraes do paciente, na qual o mdico pode modicar ou atualizar os dados dos pacientes cadastrados. A pgina Web oferece as ferramentas necessrias no s para o acompanhamento em tempo real do estado do paciente, mas tambm para manter o sistema atualizado, tudo isso sem que o mdico tenha que se deslocar para o domiclio do paciente. Alm disso, a pgina Web pode ser acessada por vrias pessoas simultaneamente, podendo ser acessada pelo mdico, por vrios familiares e por funcionrios do plano de sade,
4.1. Resultados
49
Figura 4.2: Pgina de cadastro de novos pacientes
Figura 4.3: Pgina de alterao dos dados do paciente
por exemplo. A Tabela 4.1.1 mostra a carga no sistema quando temos vrios clientes acessando a pgina Web ao mesmo tempo. Observando os resultados apresentados na Tabela 4.1.1, podemos ver que, mesmo com 4 clientes conectados simultaneamente, o que um cenrio superestimado, o sistema no est operando em sua carga mxima, sendo capaz de responder s requisies sem degradao na experincia do usurio e sem correr o risco de perder
4.1. Resultados
50
# Clientes Carga no processador (%) Memria ocupada (MB) 0 55 36,228 1 62 37,300 2 59 37,672 3 72 39,680 4 83 40,052
Tabela 4.1: Inuncia de mltiplos clientes acessando a pgina Web na performance do sistema
amostras.
4.1.2 Software
Nesta seo, sero apresentados os resultados ligados ao software. Conforme dito anteriormente, o software resultante uma srie de programas e scripts que desempenham as funes detalhadas na seo 3.5.2, alm de alguns scripts que realizam a comunicao entre os diversos mdulos de software. Mdulo de Software Tempo de execuo(ms) Aquisio de Dados 1 2,272 Anlise de Dados 405 Gerao da Pgina Web 1.026 Alerta para a Famlia 781
Tabela 4.2: Tempo de execuo para cada bloco funcional de software
A Tabela 4.1.2 mostra o tempo de execuo para cada mdulo do software, medidos com o sistema em funcionamento. Podemos ver nessa tabela que o principal gargalo no tempo de execuo do sistema a gerao da pgina Web, cujo tempo de execuo algumas ordens de grandeza maior que o tempo dos outros mdulos. Mesmo assim, podemos ver que a execuo de todos os mdulos de Software leva cerca de 1 segundo para ser concluda. Como o tempo razovel para realizao do atendimento a uma vtima de uma parada cardaca, por exemplo, da ordem de minutos, o tempo de execuo da ordem de 1 segundo perfeitamente aceitvel.
1O
tempo de aquisio dos dados limitado pelo sensor. Para este trabalho, foi considerado um sensor de frequncia de amostragem igual a 440 amostras por segundo
4.1. Resultados
51
4.1.3 Hardware
Conforme mencionado anteriormente, o hardware utilizado foi a Quick Start Board da Freescale, no tendo havido necessidade de desenvolver hardware extra. O nico hardware extra utilizado foi o receptor bluetooth. Adicionalmente, possvel utilizar um receptor wi para dar uma maior mobilidade ao dispositivo. No entanto, como o sistema deve car xo em um local da casa do paciente, no h necessidade de utilizar a conexo wi, sendo suciente uma rede cabeada. Apesar de no ser um projeto de hardware propriamente dito, este trabalho tem um forte apelo comercial, o que leva concluso natural de que, em trabalhos futuros, deve ser desenvolvido um prottipo de hardware para comportar o trabalho, eliminando a necessidade do uso da Quick Start Board e diminuindo o custo por unidade produzida.
Captulo
Concluses e Trabalhos Futuros

5.1 Concluses
Este trabalho descreveu o desenvolvimento de um sistema de Home Care, contemplando o porte do Sistema Operacional Linux, personalizao do kernel do sistema, desenvolvimento de software para aquisio, processamento e exibio de dados, alm de um servidor Web completo rodando em hardware de baixo custo. O sistema desenvolvido capaz de realizar todas as tarefas propostas em um tempo baixo o suciente para garantir a segurana do paciente que est sendo monitorado. O sistema desenvolvido representa um avano em relao aos sistemas de Home Care disponveis no mercado atualmente, j que ele pode funcionar de forma completamente auto-suciente, recebendo todos os comandos via Web, o que permite que um operador congure o sistema distncia. Ainda devido essa caracterstica, o sistema elimina a necessidade de um prossional da sade estar acompanhando o paciente em sua casa, o que acarreta em um custo menor do tratamento, um desafogamento de leitos hospitalares e um maior bem estar para o paciente, que ca cercado apenas por seus familiares. Outra vantagem do sistema proposto nesse trabalho o fato de trabalhar com sensores sem o, que permitem que o paciente se movimente livremente pela casa sem que a monitorao seja interrompida. Finalmente, o sistema oferece uma maior tranquilidade para a famlia do paciente, devido funcionalidade de envio de alerta caso os valores dos sinais vitais do paciente ultrapassem os valores denidos pelo mdico como seguros. Desta forma, pode-se dizer com segurana que tanto o objetivo geral do trabalho 52
5.2. Trabalhos Futuros
53
quanto os especcos foram cumpridos, resultando em um sistema completo de acordo com os objetivos estabelecidos. No entanto, conforme veremos na seo seguinte, algumas melhoras ainda precisam ser feitas antes que o dispositivo possa ser considerado pronto para ser posto no mercado.
5.2 Trabalhos Futuros
Apesar de ter cumprido com os objetivos do trabalho, o sistema proposto ainda no pode ser considerado completo o suciente para ser competitivo no mercado. A seguir so listadas algumas melhoras que sero feitas futuramente no sistema, aumentando sua ecincia, conabilidade e seu valor agregado: testar o sistema com um sensores compatveis com perl HDP ligados a pacientes reais; incluir medidas de outros sinais vitais, como presso arterial, nvel de saturao de oxignio, frequncia respiratria, etc; adicionar um bloco funcional de software capaz de fazer o processamento dos sinais vitais e detectar possveis anomalias no paciente; desenvolver um hardware dedicado para o sistema, utilizando apenas os componentes necessrios e eliminando o custo adicional de utilizar um kit de desenvolvimento; disponibilizar todo o software desenvolvido neste trabalho para a comunidade, permitindo que outras pessoas aprimorem o sistema.
Referncias Bibliogrcas
BITTENCOURT, R. A situao medieval dos hospitais. Junho 2011. Disponvel em http://www.horadopovo.com.br/2011/junho/2967-15-06-2011/P4/pag4f.htm#, acessado em 01/11/2011. BLUEZ. BlueZ - Ocial Linux Bluetooh protocol stack. Novembro 2011. Disponvel em http://www.bluez.org/, acessado em 03/11/2011. BONSOR, K. Como funcionam os coraes articiais. Novembro 1999. Disponvel em http://saude.hsw.uol.com.br/coracao-articial1.htm, acessado em 07/11/2011. BOVET, D. P.; CESATI, M. Understanding the Linux Kernel. [S.l.]: O'Reilly, 2000. D'ANGELO, L. T. et al. A system for intelligent home care ecg upload and priorisation. In: In Proc. of The 32nd Annual International Conference of the IEEE EMBS. [S.l.: s.n.], 2010. ECLIPSE. About Eclipse. Junho 2011. Disponvel em http://www.eclipse.org/org/, acessado em 14/10/2011. FREE SOFTWARE FUNDATION. GNU General Public License. Junho 2007. Disponvel em http://www.gnu.org/licenses/gpl.html, acessado em 28/08/2011. FREESCALE. IMX53QSB: i.MX53 Quick Start Board. Outubro 2011. Disponvel em http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB&parentCode=i.M acessado em 01/11/2011. G1. Idosa que foi Justia para ter vaga em UTI ser enterrada nesta tarde. Outubro 2011. Disponvel em 54
55
http://g1.globo.com/rio-de-janeiro/noticia/2011/10/idosa-que-foi-justica-para-ter-vaga-em-uti-sera-e acessado em 01/11/2011. G1. Morre paciente que teria esperado atendimento em corredor de hospital. Outubro 2011. Disponvel em http://g1.globo.com/rio-de-janeiro/noticia/2011/10/morre-paciente-que-teria-esperado-atendimento acessado em 01/11/2011. GAZETA. Famlia de aposentado que morreu em corredor de hospital pretende acionar a Justia. Maro 2011. Disponvel em http://gazetaonline.globo.com/_conteudo/2011/03/a_gazeta/minuto_a_minuto/812515-familia-de acessado em 01/11/2011. LATUSKE, R. Bluetooth Health Device Prole (HDP). Agosto 2009. Disponvel em http://www.ars2000.com/Bluetooth_HDP.pdf, acessado em 28/08/2011. LEME, E. de O. O que Home Care? Novembro 2011. Disponvel em http://www.portalhomecare.com.br/home-care/o-que-e-o-home-care, acessado em 03/11/2011. LTIB. Linux Target Image Builder. Junho 2011. Disponvel em http://ltib.org/, acessado em 14/10/2011. MINIX. MINIX OS Discussion List. Agosto 1991. Disponvel em http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b, acessado em 28/08/2011. NETCRAFT. May 2010 Web Server Survey. Maio 2010. Disponvel em http://news.netcraft.com/archives/2010/05/14/may_2010_web_server_survey.html, acessado em 01/11/2011. NETO, L. A. de L. Eletrocardigrafo Porttil com uma Derivao e Comunicao Bluetooth. Dissertao (Mestrado) Universidade Federal do Cear, 2010. OPENMOKO Inc. OpenMoko. Junho 2011. Disponvel em http://http://www.openmoko.com/, acessado em 14/09/2011. PCWORLD. Android Market Share Growth Accelerating. Junho 2011. Disponvel em http://www.pcworld.com/article/226339/android_market_share_growth_accelerating_nielsen_n acessado em 28/08/2011.
56
SLOSS, A. et al. ARM System Developer's Guide: Designing and Optimizing System Software. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2004. ISBN 1558608745. TANENBAUM, A. S. Modern Operating Systems. 3rd. ed. Upper Saddle River, NJ, USA: Prentice Hall Press, 2007. ISBN 9780136006633. TGDAILY. Android tablet market share tumbles to 26.8%. Setembro 2011. Disponvel em http://www.tgdaily.com/mobility-features/58463-android-tablet-market-share-tumbles-to-268, acessado em 19/09/2011. TOP500. Top 500 Supercomputer sites - Operating System share for 06/2011. Junho 2011. Disponvel em http://top500.org/charts/list/37/os, acessado em 28/08/2011. TORVALDS, L. Linux 3.0 release. Julho 2011. Disponvel em http://lwn.net/Articles/452531/, acessado em 28/08/2011. U-BOOT. Das U-Boot Source Code Tree. Junho 2011. Disponvel em http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree, acessado em 14/10/2011. YAGHMOUR, K. Building Embedded Linux Systems. [S.l.]: O'Reilly Media, Inc., 2003. ISBN 059600222X. YODAIKEN, V. The rtlinux manifesto. In: In Proc. of The 5th Linux Expo. [S.l.: s.n.], 1999.

Sistema de Monitor Amen To Remoto de Pacientes Implement Ado em Hardware de Arquitetura ARM

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sistema de Monitor Amen To Remoto de Pacientes Implement Ado em Hardware de Arquitetura ARM

Transféré par

Droits d'auteur :

Formats disponibles

Universidade Federal do Cear Departamento de Engenharia de Teleinformtica Curso de Graduao em Engenharia de Teleinformtica

talo Cavalcante Sampaio

Sistema de Monitoramento Remoto de Pacientes Implementado em Hardware de Arquitetura ARM

Fortaleza  Cear Dezembro 2011

talo Cavalcante Sampaio

Prof. Dr. Helano de Sousa Castro

Sistema de Monitoramento Remoto de Pacientes Implementado em Hardware de Arquitetura ARM

talo Cavalcante Sampaio

Sistema de Monitoramento Remoto de Pacientes Implementado em Hardware de Arquitetura ARM

Sistemas Embarcados, Linux, ARM, Bluetooth, Telemedicina,

Embeded Systems, Linux, ARM, Bluetooth, Telemedicine, Home Care.

Lista de Figuras Lista de Tabelas Lista de Siglas 1 Introduo

5 Concluses e Trabalhos Futuros Referncias Bibliogrcas

5.1 Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1.3. Organizao deste trabalho

2.1. Sistema Operacional Linux

2.1. Sistema Operacional Linux

Figura 2.1: Viso em camadas da arquitetura do Android

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.2. Linux em Sistemas Embarcados

2.3. Processadores ARM

2.3.1 Viso Geral da Arquitetura de Processadores ARM

2.3. Processadores ARM

Figura 2.2: Fluxo dos dados no core do processador ARM

2.3. Processadores ARM

Figura 2.3: Mapa dos registros do ARM disponveis em modo usurio

2.3. Processadores ARM

Registro de Status do Programa Atual

Figura 2.4: Descrio dos bits do registro CPSR

2.3. Processadores ARM

2.3. Processadores ARM

Figura 2.5: Descrio dos bits do registro CPSR

2.3. Processadores ARM

2.3. Processadores ARM

Tabela 2.2: Lista dos atributos condicionais suportados pelo ARM

Figura 2.6: Comparao da localizao da complexidade em sistemas RISC e CISC

No desenvolvimento de processadores RISC, so levadas em considerao as seguintes regras de design :

2.3. Processadores ARM

2.3. Processadores ARM

A losoa de design ARM

2.3. Processadores ARM

2.4. Sistemas de Home Care

2.4. Sistemas de Home Care

2.4. Sistemas de Home Care

2.4. Sistemas de Home Care

2.4. Sistemas de Home Care

2.4. Sistemas de Home Care

3.1. Arquitetura Proposta

Armazena os sinais vitais

Caso algum sinal esteja anormal ALERTA PARA A FAMLIA

Presso: XXX BPM: XXX Temperatura: XXX SatO2: XXX

Banco de Dados Local

Figura 3.1: Arquitetura proposta para o sistema de Home Care

3.2. Ferramentas Utilizadas

3.2. Ferramentas Utilizadas

3.2. Ferramentas Utilizadas

3.2. Ferramentas Utilizadas

3.2. Ferramentas Utilizadas

Fortaleza Cear Dezembro 2011

5 Concluses e Trabalhos Futuros Referncias Bibliogrcas

A losoa de design ARM