AT Sistema Operacional Y OS para Redes de Sensores sem Fio

Vin cius C. de Almeida1 , Luiz F. M. Vieira1 , Breno A. D. Vitorino1 , Marcos A. M. Vieira1 , Jos e A. Nacif1 , Ant onio O. Fernandes1 , Di ogenes C. da Silva2 , Claudionor N. Coelho Jr1
1

Departamento de Ci encia da Computac a o Universidade Federal de Minas Gerais Av. Ant onio Carlos, 6627 31270-010, Belo Horizonte/MG
2

Departamento de Engenharia El etrica Universidade Federal de Minas Gerais Av. Ant onio Carlos, 6627 31270-010, Belo Horizonte/MG

{makish, vitorino, lfvieira, mmvieira, jnacif, otavio, coelho}@dcc.ufmg.br diogenes@cpdee.ufmg.br

AT Abstract. This paper describes Y OS , an operating system developed for sensor nodes of wireless sensor networks (WSN). A sensor node is a computing AT device with limited communication, sensing and processing capability. Y OS maps events and tasks, it is event-driven and it provides an application programming interface (API). We present the related works in the area that helped designing the new system, which is also described in this paper. AT Resumo. Este artigo descreve o Y OS , um sistema operacional desenvolvido especicamente para n os sensores de redes de sensores sem o (RSSF). Um n o sensor e um pequeno dispositivo computacional com capacidades limitadas AT de comunicac a o, sensoriamento e processamento. O Y OS atende aos requisitos impostos pelas RSSFs, mapeia eventos em tarefas, e dirigido por eventos e fornece uma interface de programac a o de aplicativos (API). Apresentamos os trabalhos relacionados na a rea que ajudaram a projetar o novo sistema, o qual tamb em e descrito neste artigo.

o 1. Introduc a
Redes de sensores [10] s ao formadas por milhares de pequenos dispositivos, aqui denominados n os, dotados de capacidade de armazenamento, processamento, comunicac a o e sensoriamento. Esses n os t em fortes restric o es quanto a ` mem oria, capacidade de processamento e principalmente energia, sendo desej avel que possuam mecanismos de autocongurac a o e adaptac a o devido a problemas como falha de comunicac a o e perda de n os. Nessa rede, cada n o pode ser equipado com diferentes sensores, dada a natureza dos aplicativos executados nele, tais como: temperatura, press ao, etc. N os sensores podem ser usados para monitorac a o cont nua, detecc a o de eventos, localizac a o e controle local de atuadores. As a reas de aplicac a o das RSSFs s ao proeminentes e se destacam a a rea militar, meio-ambiente, sa ude, automac a o residencial, monitorac a o de estruturas e aplicac o es comerciais. RSSFs possuem recursos limitados, sendo energia o mais importante desses. Cada n o sensor possui uma fonte de energia, que em geral e uma bateria com capacidade limi tada. E praticamente invi avel recarregar manualmente todas as baterias, uma vez que RSSFs s ao compostas por milhares de n os sensores e, al em disso, estes podem estar em locais inacess veis. Dessa forma, o foco de projeto em RSSFs, do hardware aos protocolos de redes, e o uso eciente de energia.

Devido a ` s caracter sticas dos n os e da pr opria rede de sensores, algumas quest oes devem ser consideradas no projeto de um sistema operacional: dadas suas limitac o es de mem oria, os n os n ao podem armazenar todos os aplicativos em sua mem oria local, sendo desej avel que possuam um mecanismo para que novos aplicativos sejam transferidas de um n o para outro; deve-se fornecer tamb em algum suporte a ` execuc a o concorrente de aplicativos em um n o; a quantidade de n os em uma dada rede de sensores pode ser muito grande, tornando dif cil a congurac a o manual de cada n o individual; Devido a ` s limitac o es quanto ao consumo de energia e capacidade computacional limitada dos n os, torna-se indispens avel o uso eciente de seus recursos. Dessa forma, um sistema operacional projetado especicamente para atender a esses requisitos pode oferecer maior toler ancia a falhas, bem como economia de energia e facilidade de desenvolvimento de aplicac o es. Ele deve ser pequeno para caber na mem oria, consumir pouca energia, executar sem bloqueio e ser voltado para sistemas distribu dos. Este trabalho apresenta como contribuic a o o primeiro sistema operacional brasileiro voltado especicamente para RSSFs. Este artigo est a organizado da seguinte forma. A sec a o 2 descreve brevemente rede de sensores sem o. A sec a o 3 apresenta os trabalhos relacionados, a sec a o 4 mostra AT as caracter sticas do Y a o 5 os trabalhos futuros e conclus ao. OS e a sec

2. Redes de Sensores Sem Fio

Redes de Sensores Sem Fio s ao redes ad-hoc formadas por n os sensores e por pelo menos um ponto de comunicac a o denominado estac a o-base. O objetivo destas redes e coletar informac a o. Usualmente, n ao possuem infra-estrutura pr e-estabelecida, como ocorre com redes de celulares ou redes locais sem o. es 2.1. Aplicac o Redes de Sensores Sem Fio tem o potencial de serem aplicadas em v arias a reas. RSSFs permitem monitorar uma grande variedade de condic o es ambientais que incluem: temperatura, umidade, movimentos veiculares, condic o es de iluminac a o, press ao, n vel de ru do, presenc a ou aus encia de certos tipos de objetos, n vel de estresse mec anico em objetos atachados, caracter sticas correntes como velocidade, direc a o e tamanho de um objeto. N os sensores podem ser usados para monitorac a o cont nua, detecc a o de eventos, localizac a o e controle local de atuadores. As a reas de aplicac a o das RSSFs s ao proeminentes e se destacam a a rea militar, meio-ambiente, sa ude, automac a o residencial, monitorac a o de estruturas e aplicac o es comerciais. Podemos citar algumas aplicac o es de meio-ambiente de redes de sensores. Elas incluem o rastreamento do movimento dos p assaros, pequenos animais, e insetos; monitorac a o de condic o es ambientais que afetam colheitas e plantio; irrigac a o; detecc a o de componentes qu micos ou biol ogicos; agricultura de precis ao; monitorac a o da a gua, solo e atmosfera; detecc a o de inc endio em orestas; pesquisa meteorol ogica ou geof sica; detecc a o de inundac a o; mapeamento da bio-complexidade ambiental e estudo da poluic a o.

3. Trabalhos relacionados
Para atender a ` s necessidades de dispositivos com severas restric o es quanto ao consumo de energia, espac o em mem oria e poder computacional, j a foram propostos e/ou desenvolvidos diferentes SOs, que utilizam diferentes abordagens ao problema. Sistemas baseados em Linux, tal como Clinux, n ao se mostraram adequados para RSSFs, pois s ao voltados para sistemas embutidos com maior capacidade computacional (i.e. mem oria, bateria, processador). Os sistemas descritos a seguir atendem algumas das demandas espec cas de RSSFs. 3.1. EYES-PEEROS EYES [5] e um projeto desenvolvido na Universidade de Twente - Holanda. Seu funcionamento baseia-se nos seguintes princ pios: operac a o dirigida por eventos, divis ao da execuc a o em tarefas e separac a o de funcionalidades correlatas em unidades distintas. Uma primeira iniciativa de implementar o SO do projeto EYES e o sistema PEEROS (Preemptive Eyes Real Time Operating System) [9]. Seus elementos principais s ao descritos abaixo: Escalonamento de tarefas: sistema dirigido por eventos, com pol tica de escalonamento preemptiva. Sistema de mensagens: comunicac a o entre os componentes do SO e entre os n os sensores. Gerente de m odulos: armazena m odulos execut aveis, n ao usados, na mem oria externa (EEPROM) e os carrega no n o sensor sob demanda. Shell de comandos: conectado a ` interface serial do n o, permite a um usu ario digitar comandos e receber respostas do n o sensor (quando este estiver ligado a ` porta serial de um computador pessoal). 3.2. SensorWare Desenvolvido na Universidade da Calif ornia, SensorWare [1] e um arcabouc o para RSSFs. Suas caracter sticas principais s ao: mobilidade de c odigo atrav es de scripts m oveis e separac a o de funcionalidades correlatas em unidades distintas. Scripts m oveis s ao entidades do SensorWare que podem se deslocar de um n o para outro numa RSSF. Executam at e um certo ponto num n o e, ao transferir-se para outro, continuam a execuc a o a partir de pontos de entrada bem denidos. A maioria dos comandos e func o es s ao agrupadas em APIs distintas. Elas possuem funcionalidades que fornecem acesso a um recurso ou servic o do n o sensor. 3.3. Bertha Bertha OS [8] e um sistema operacional para a arquitetura de hardware Pushpin [2](redes de sensores com o e com n os id enticos). Desenvolvido no MIT Media Lab, seu modelo de programac a o e baseado em um sistema de agentes m oveis [7] muito simples, com tr es componentes: fragmentos de processos (PFrags), um sistema de quadro de boletins (BBS) e um vigia de vizinhanc a (NW). Fragmentos de processos, ou PFrags, s ao entidades de programac a o aut onomas e m oveis, escritas em C, que podem interagir com seu ambiente local, podendo migrar de um n o para outro. Para isso, eles possuem c odigo execut avel e estado persistente e podem se comunicar atrav es do BBS do n o. Um sistema de quadro de boletins, ou BBS, est a dispon vel para os PFrags em cada n o da rede. Ele e usado para permitir a comunicac a o entre PFrags, que postam mensagens nele. Sinopses do BBS dos n os vizinhos s ao espelhados no vigia de vizinhanc a, ou NW, do n o local. Quando um PFrag posta alguma mensagem

em um BBS, aquele pode escolher que uma sinopse daquela postagem esteja dispon vel no NW de todos os n os vizinhos. Infelizmente, PFrags n ao s ao exiv eis, limitando o tamanho de c odigo dos programas. 3.4. TinyOS Desenvolvido na UC Berkeley e ativamente utilizado por uma grande comunidade de usu arios, TinyOS [6] e um escalonador de eventos que prov e execuc a o concorrente para redes de sensores embutidos, com recursos de hardware escassos usando a arquitetura Motes [3]. As caracter sticas relevantes do TinyOS s ao sua arquitetura e seu modelo de concorr encia, os quais s ao brevemente descritos a seguir. 3.4.1. Arquitetura baseada em componentes Todo aplicativo possui pelo menos um arquivo de congurac a o e um de implementac a o. O primeiro especica o conjunto de componentes do aplicativo e como eles se invocam. No segundo est ao listadas as interfaces fornecidas e as usadas por um componente. Um aplicativo usa um ou mais componentes, sendo poss vel reutilizar alguns componentes mais simples para criar outros mais elaborados. Isso cria uma hierarquia de camadas, na qual componentes em n veis altos na hierarquia originam comandos para componentes em n veis baixos. Estes, por sua vez, sinalizam eventos para aqueles. 3.4.2. Modelo de concorr encia baseado em eventos Concorr encia e obtida atrav es do uso de eventos e tarefas, usando escalonamento em dois n veis. No n vel de mais baixa prioridade est ao as tarefas e no de mais alta est ao os eventos. Tarefas de um componente s ao at omicas entre si, executando at e seu t ermino, mas podem ser preemptadas por eventos externos. Podem executar comandos de componentes em n veis baixos na hierarquia, sinalizar eventos para componentes em n veis altos e agendar a execuc a o de outras tarefas em um componente. Eventos s ao generalizac o es de tratadores de interrupc a o, propagando processamento para cima na hierarquia (atrav es da sinalizac a o de outros eventos) ou para baixo (por meio da execuc a o de comandos). S ao executados quando sinalizados, preemptando a execuc a o de uma tarefa ou outro evento.
AT 4. Caracter sticas do Y OS

Esta sec a o descreve o sistema operacional desenvolvido, o hardware utilizado, bem como suas principais estruturas e funcionalidades. Na sec a o 3, p ode ser visto que existem diferentes sistemas operacionais que podem ser aplic aveis ao paradigma de RSSFs. No entanto, h a algumas caracter sticas que n ao s ao encontradas em nenhum deles ao mesmo tempo: Ser dirigido por eventos: Um sistema dirigido por eventos, pode entrar no modo de menor consumo de energia sempre que poss vel. Al em disso, elimina a espera ocupada. A tarefa esperando por algum recurso, ao inv es de realizar espera ocupada, pode dormir e ser acordada por um evento que notica a liberac a o do recurso. Conforme [11], um sistema dirigido por eventos chega a economizar at e 12 vezes mais energia que um sistema tradicional e prop osito geral.

Ocupar pouca mem oria de um n o sensor: O hardware de um n o sensor possui mem oria limitada. Neste espac o, al em do c odigo do sistema operacional, tem o c odigo das aplicac o es e os dados coletados. Por isso, o espac o ocupado pelo sistema operacional deve ser o menor poss vel. Consumir pouca energia: Energia e um recurso precioso em uma Rede de Sensores Sem Fio e seu consumo deve ser eciente. O sistema operacional deve, sempre que poss vel, minimizar o consumo de energia dos componentes. Por exemplo, quando apenas uma computac a o estiver sendo realizada, o r adio pode ser colocado no modo de mais baixo consumo de energia de modo que n ao interra na computac a o sendo realizada. A eci encia de uma rede de sensores depende da aplicac a o desta. O sistema operacional deve prover os mecanismos, como permitir o processador mudar de modo de operac a o de energia, para que a aplicac a o possa gerenciar a rede ecientemente. Oferecer multi-tarefa baseada em prioridade: Pode ser necess ario que mais de uma tarefa execute em um mesmo dado intervalo de tempo. Ainda mais, elas podem ter prioridades diferentes e/ou terem que ser executadas em uma ordem espec ca (neste caso, a elas s ao atribu das prioridades que forcem a execuc a o na ordem denida). O sistema operacional deve ser modular: Um sistema modular facilita a manutenc a o e o desenvolvimento de novos componentes. Al em disso, componentes n ao necess arios podem ser exclu dos. O sistema operacional deve ser f acil de usar: A facilidade de uso e um requisito importante. De nada adianta um sistema operacional que ningu em consegue usar ou integrar com a sua aplicac a o. Al em disso, o tempo gasto para aprender a us alo n ao deve atrapalhar o tempo de desenvolvimento da aplicac a o. Nem mesmo o tempo necess ario para aprender uma nova linguagem de programac a o e paradigma AT de programac a o. Por esta raz ao, Y OS foi desenvolvido em C, uma linguagem de programac a o bem difundida entre programadores e desenvolvedores de sistemas embutidos. Para os casos em que eci encia era requerida e o c odigo n ao estaria vis vel externamente, o desenvolvimento foi feito em linguagem de m aquina. 4.1. Hardware A arquitetura de sistema de um n o sensor gen erico e formada por 4 componentes principais: suprimento de energia, comunicac a o, unidade de processamento e sensores. O bloco de suprimento de energia consiste, geralmente, de uma bateria, tendo como objetivo suprir o n o com a energia necess aria. O bloco de comunicac a o e constitu do de canal de comunicac a o sem o, comumente um r adio de curto alcance. A unidade de processamento e formada pelos componentes de mem oria e um processador. A mem oria e usada para armazenar dados e aplicativos, enquanto o microcontrolador executa os aplicativos, al em de usar ADCs para converter sinais anal ogicos para digitais, advindos do bloco sensor. Um esquema dessa arquitetura pode ser visto na gura 1.
AT OY o sensor BEAN, do projeto SensorOS foi inicialmente desenvolvido para o n Net [15, 14], mostrado na gura 2. Ele usar a um r adio CC1000 [4] e um microcontrolador TI MSP430F149 [12]. O r adio disp oe de freq ue ncia program avel (300 - 1000 MHz) com granularidade de 250 Hz, baixo consumo de corrente (Rx: 7,4 mA) e baixa tens ao (2,1 3,6 V).

O microcontrolador escolhido usa uma arquitetura RISC de 16 bits, dispondo de 2 KB de RAM para armazenar dados e 60 KB + 256 B de mem oria Flash para armazenar c odigo e constantes. Possui 6 modos de operac a o: 1 modo ativo (AM ) e 5 modos de baixo consumo de energia (LPM0, LPM1, LPM2, LPM3 e LPM4). Os modos de baixo consumo

 Figura 1: Componentes de um no sensor.

Figura 2: Foto do BEAN.

desligam a unidade central de processamento (CPU) e certas partes do microcontrolador. Atrav es da escolha do modo de operac a o, pode-se congurar o microcontrolador para consumir apenas a energia necess aria para seu funcionamento. Por exemplo: quando houver tarefas para executar no escalonador, o sistema se encontrar a ativo; mas quando n ao houver mais tarefas para executar num dado momento, o microcontrolador entra em modo de economia de energia, apenas aguardando a ocorr encia de algum evento. Como pode ser observado na gura 3, o modo mais econ omico e o LPM4, mas este n ao e usado por desligar alguns perif ericos utilizados pelo sistema. Para saber mais sobre os modos de operac a o, vide [13]. Outras caracter sticas relevantes do microcontrolador: temporizadores program aveis; conversores ADC de 12 bits, que possibilitam converter sinais do ambiente para sinais digitais; comparadores que podem comparar valores lidos com um certo limiar e avisar quando este for ultrapassado. Por m, cada n o sensor possui um chip identicador, que armazena o n umero do n o na rede de sensores. 4.2. Princ pios de funcionamento
AT OY odigo execut avel. NorOS utiliza o termo tarefa para descrever um trecho de c malmente, haver a muitas tarefas para serem executadas, sendo necess ario que haja um escalonador de tarefas para decidir a ordem de execuc a o. Foi escolhida a pol tica de escalonamento cooperativa, na qual as tarefas, quando de posse do processador, decidem AT quando liber a-lo para a execuc a o de outras. No caso espec co do Y OS , isso ocorre quando a tarefa encerra sua execuc a o em resposta a um dado evento. O escalonamento cooperativo foi escolhido devido a ` s suas seguintes vantagens em relac a o ao modo preemptivo:

uma tarefa nunca e interrompida inesperadamente;

Figura 3: Consumo de corrente nos diferentes modos de operac ao.

 implementac a o mais simples, pois n ao h a salvamento de contexto, economizandose energia, mem oria e processamento.
AT OY dirigido por eventos. Isso signica que as tarefas criadas pelo prograOS e mador v ao executar em resposta a eventos do sistema e este estar a em modo de operac a o ativo. Quando o escalonador de tarefas estiver vazio, o sistema entrar a no modo de economia de energia.

4.3. Eventos Eventos s ao interrupc o es que, quando tratadas por um manipulador, colocar ao as tarefas que aguardam sua ocorr encia no escalonador de tarefas, para serem executadas em orAT dem decrescente de prioridade. Os eventos v alidos do Y ao eventos que identicam OS s a recepc a o de dados via r adio, noticac a o de t ermino de convers ao da leitura do sensor ligado em ADC, noticac a o do sensor de ultrapassagem de limiar e temporizadores. AT Cabe salientar que o Y S e um SO de requisitos de tempo real fracos (soft real-time O requirements). 4.4. Per odos de eventos
AT Eventos no Y ue ncia com que s ao OS podem ser classicados, de acordo com a freq executados, em 3 tipos:

Aperi odicos: ocorrem sem o uso de temporizadores, atrav es do disparo de interrupc o es pelo hardware. Peri odicos: ocorrem em intervalos de tempo denidos, sendo necess ario o uso de temporizac a o. Tiro unico: s ao eventos programados para ocorrer uma u nica vez, sendo posteriormente removidos da lista de eventos do sistema. Tamb em necessitam de temporizac a o. 4.5. Lista de tarefas A lista de tarefas e um tipo abstrato de dados (TAD) respons avel por armazenar todas as tarefas declaradas pelo programador. Atrav es dela podem ser criadas novas tarefas, efetuar buscas por uma tarefa, alterar seus dados, e por m destruir tarefas. 4.6. Lista de eventos A lista de eventos e um TAD que cont em listas de tarefas para cada evento v alido do sistema. Quando s ao atribu dos eventos a ` uma tarefa, esta e copiada para a lista de tarefas do evento correspondente. Ap os ocorrer um certo evento, todos as tarefas na lista correspondente s ao ent ao copiadas para o escalonador de tarefas. 4.7. Escalonador de tarefas O escalonador de tarefas e um TAD implementado com uma la de prioridades. As tarefas s ao executadas em ordem decrescente de prioridade, uma de cada vez, at e seu m (escalonamento cooperativo), sendo ent ao removidas do escalonador. Associado a cada evento, existe um conjunto de tarefas que podem ser postas na la do escalonador quando o evento ocorre, confome mostra a gura 4. 4.8. Rotinas para o programador Foram desenvolvidas diferentes APIs de servic os para uso do microcontrolador e seus recursos, al em de seus perif ericos. A API Tarefas e respons avel pela criac a o de tarefas, sua postagem e atribuic a o de eventos a elas. Ra a o de dados dio permite o envio e a recepc

Tarefas T1 Lista de Eventos Ei Evento Interrupo Hardware Ei Ti T2 T3

Figura 4: Lista de tarefas associadas a eventos.

atrav es do r adio, congurar seu alcance e modo de operac a o. A API Sensor permite a obtenc a o de leituras dos sensores dispon veis no n o. Memo ria possibilita o apagamento, leitura e escrita da mem oria Flash. Por m, a API Microcontrolador prov e os seguintes servic os: iniciar componentes de hardware do n o e o sistema operacional; congurar seu modo de operac a o; iniciar e fechar sec o es cr ticas (regi oes onde as interrupc o es s ao desabilitadas); congurar temporizadores; informar o identicador de cada n o sensor.

4.9. Exemplo de uso

AT O c odigo 1 exibe um exemplo de aplicac a o em C utilizando o Y a o do OS . A inicializac hardware, declarac a o de eventos, declarac a o de tarefas, associac a o de eventos a tarefas e inicializac a o do SO e feita utilizando a API desenvolvida. Nesse c odigo exemplo s ao criadas duas tarefas: a primeira executar a apenas quando chamada pela segunda tarefa; a segunda executar a em resposta a recepc a o de mensagens via r adio ou a eventos de temporizac a o.

o 4.10. Estado atual de implementac a

AT OY OS foi implementado em C, linguagem difundida entre os desenvolvedores de sisteAT mas embutidos. O espac o ocupado em mem oria da vers ao atual do Y mostrado na OS e tabela 1, tendo sido calculado sem considerar otimizac o es que o compilador pode efetuar.

Mem oria de c odigo 3.144 bytes Mem oria de dados 1.984 bytes Mem oria de constantes 530 bytes
AT Tabela 1: Tabela com consumo de memoria do Y OS .

5. Conclus oes
Este artigo apresenta como maior contribuic a o a especicac a o de requisitos e o desenvolvimento de um sistema operacional especico para RSSF. Diferentes SOs voltados para AT RSSFs foram analisados e e desenvolvido o Y OS , usando um escalonador de tarefas com pol tica de escalonamento cooperativa. No paradigma de RSSFs, os componentes integrantes do n o e suas respectivas restric o es computacionais foram respons aveis por moldar as escolhas de implementac a o das diferentes funcionalidades.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

#include "SO.h" // APIs e rotinas do SO. void rotina1(evento_t evento){ /* C odigo da rotina (nao mostrado) */ return; } void rotina2(evento_t evento){ /* C odigo da rotina (nao mostrado) */ switch(evento){ case evRADIO: // dado recebido via r adio. /* C odigo (nao mostrado) */ break; case evTEMPORIZADOR0: // evento de temporizac a o. /* C odigo (nao mostrado) */ if(condicao) Tarefa_Posta("RotinaA"); // Postagem de tarefa. break; } return; } void main(){ /* Declaracao de vari aveis.*/ id_t id1, id2; // Inicia dispositivos de hardware. Microcontrolador_IniciaHardware(); /* Declaracao de tarefas.*/ id1 = Tarefa_Declara(&rotina1, 28, "RotinaA"); id2 = Tarefa_Declara(&rotina2, 1, ""); // tarefa an onima. /* Atribuicao de eventos.*/ // aperiodica. Tarefa_AtribuiEventos(id2, evRADIO, tpdNULO, pdNULO); // periodica: 200 ms. Tarefa_AtribuiEventos(id2, evTEMPORIZADOR0, tpdPERIODICO, 200); Microcontrolador_IniciaSO(); // Inicia o sistema operacional. }

AT C odigo 1: Exemplo de aplicac a o usando o Y OS .

Aa rea de pesquisa em RSSFs e uma a rea muito nova, sendo amplamente pesquisada por instituic o es de pesquisa no mundo todo. No caso desse projeto, muito trabalho ainda pode ser feito para extend e-lo e melhor a-lo. Dentre essas melhorias, podem-se citar as seguintes:
AT Otimizar a alocac a o de mem oria no Y a o OS , minimizando o uso de alocac din amica, a m de usar mais mem oria Flash e menos mem oria RAM para arA mazenar estruturas do Y TOS . Recurso shell: usando a interface JTAG do n o conectada a um computador pessoal, um programador poderia digitar comandos e receber respostas a esses comandos a partir do n o, tais como: tarefa em execuc a o, n os reconhecidos em sua vizinhanc a, etc. Mobilidade de c odigo: possibilidade de envio/recepc a o de c odigo para reprogramac a o via r adio dos n os.

6. Agradecimentos
Este trabalho foi parcialmente apoiado pelo CNPq, processos 55.2111/2002-3, 18.0381/2003-2, 18.0380/2003-6 e 830107/2002-9.

Refer encias
[1] A. Boulis and M. B. Srivastava. A framework for efcient and programmable sensor networks. In Proceedings of OPENARCH 2002, Junho 2002.

[2] M. Broxton, J. Lifton, D. Seetharam, and J. Paradiso. Pushpin computing system overview: a platform for distributed, embedded, ubiquitous sensor networks. In Pervasive Computing 2002, Agosto 2002. [3] Alberto Cerpa, Jeremy Elson, Michael Hamilton, Jerry Zhao, Deborah Estrin, and Lewis Girod. Habitat monitoring: application driver for wireless communications technology. In Workshop on Data communication in Latin America and the Caribbean, pages 2041. ACM Press, 2001. [4] Chipcon. Smartrf cc1000 preliminary datasheet http://www.chipcon.com/les/CC1000 Data Sheet 2 1.pdf, 2002. (rev. 2.1),

[5] S. Dulman and P. Havinga. Operating system fundamental for the eyes distributed sensor network. In Progress 2002, Utrecht - Netherlands, Outubro 2002. [6] Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David E. Culler, and Kristofer S. J. Pister. System architecture directions for networked sensors. In Architectural Support for Programming Languages and Operating Systems, pages 93104, 2000. [7] J. Kahn, R. Katz, and K. Pister. Next century challenges: Mobile networking for smart dust. In ACM MobiCom99, Agosto 1999. [8] J. Lifton, D. Seetharam, M. Seltzer, and J. Paradiso. Bertha: The os for pushpin computers. Technical Report, Maio 2002. [9] Job Mulder. Peeros - preemptive eyes real-time operating system. Technical report, University of Twente, Abril 2003. [10] L. B. Ruiz, L. H. A. Correia, L. F. Vieira, D. F. Macedo, E. F. Nakamura, C. M. S. Figueiredo, M. A. M. Vieira, E. H. Bechelane, D. C amara, A. A. F. Loureiro, J. M. S. Nogueira, L. B. Ruiz, D. C. da Silva Jr., and A. O. Fernandes. Arquitetura para redes de sensores sem o. In Minicursos do XXII Simpo sio Brasileiro de Redes de Computadores, Gramado/RS, Maio 2004. [11] Roy Sutton Suet-Fei Li and Jan Rabaey. Low power operating system for heterogeneous wireless communication systems. In Workshop on Compilers and Operating Systems for Low Power 2001, Setembro 2001. [12] Texas Instruments. Mixed signal s.ti.com/sc/ds/msp430f149.pdf, 2003. microcontroller (rev. e), http://wwwhttp://www-

Msp430x1xx family users [13] Texas Instruments. s.ti.com/sc/psheets/slau049d/slau049d.pdf, 2004.

guide,

[14] Luiz Filipe Menezes Vieira. YATOS e WISDOM: Plataforma de Software para Redes de Sensores sem Fio. Masters thesis, DCC-UFMG, Belo Horizonte-MG, Brasil, Abril 2004. [15] Marcos Augusto Menezes Vieira. BEAN: Uma Plataforma Computacional para Redes de Sensores sem Fio. Masters thesis, DCC-UFMG, Belo Horizonte-MG, Brasil, Abril 2004.