Um modelo de programação para RSSF com suporte a reconfiguração dinâmica de aplicações

Um modelo de programac¸˜ ao para RSSF com suporte a reconfigurac¸˜ ao dinˆ amica de aplicac¸ ˜ oes ∗ Adriano Branco1, Noemi Rodriguez1, Silvana Rossetto2 1Dep. de Inform´ atica – Pontif´ ıcia Universidade Cat´ olica do Rio de Janeiro (PUC-RJ) R. Marques de S.Vicente, 225 – G´ avea – CEP:22453-900 – Rio de Janeiro, RJ–Brasil 2Dep. de Ciˆ encia da Computac¸˜ ao – Universidade Federal do Rio de Janeiro (UFRJ) Caixa-Postal:68530 – CEP:21941-590 – Rio de Janeiro, RJ–Brasil {abranco,noemi}@inf.puc-rio.br, [email protected] Abstract. Programming and maintaining WSN applications is typically a tedious and error-prone task. We discuss a model to minimize the difficulties of development and reconfiguration of such applications. This model is based on a set of parametrized components and on a Finite State Machine, and allows the remote configuration of different applications over the same set of installed components. To evaluate this idea, we built a component library based on the requirements of different WSN applications. In this paper, we describe this library and, using a typical WSN application, evaluate its impact on the development process, and the ease of applying modifications to a running application. We also measure the additional impact of remote configuration on network activity. Resumo. Neste trabalho descrevemos um modelo de programac¸ ˜ ao para redes de sensores sem fio que pretende simplificar as tarefas de criac¸˜ ao e reconfigurac¸ ˜ ao de aplicac¸ ˜ oes. O modelo se baseia no uso conjunto de componentes parametriz´ aveis e de m´ aquinas de estados finitos, e permite a implementac¸ ˜ ao de diferentes tipos de aplicac¸ ˜ oes para redes de sensores sem fio e a configurac¸ ˜ ao remota dessas aplicac¸ ˜ oes. Para avali´ a-lo, criamos uma biblioteca de componentes a partir de um levantamento de requisitos de diferentes classes de aplicac¸ ˜ oes. Realizamos alguns testes para avaliar o quanto essa biblioteca de componentes pode facilitar o desenvolvimento de novas aplicac¸ ˜ oes, o quanto ´ e f´ acil aplicar novas alterac¸ ˜ oes sobre as aplicac¸ ˜ oes em execuc¸ ˜ ao, e o impacto na quantidade de mensagens na rede por conta do uso da configurac¸ ˜ ao remota. 1. Introduc¸˜ ao No cen´ ario de Redes de Sensores Sem Fio (RSSF), vˆ em ganhando especial atenc¸˜ ao os dispositivos com tamanhos e recursos limitados (motes). Esses dispositivos podem ser utilizados em diversos tipos de aplicac¸ ˜ oes, principalmente em aplicac¸ ˜ oes que necessitam de uma distribuic¸˜ ao em grandes ´ areas ou mesmo em ´ areas de dif´ ıcil acesso. O trabalho de desenvolvimento de aplicac¸ ˜ oes para RSSF ´ e impactado pelos mesmos desafios encontrados no desenvolvimento de aplicac¸ ˜ oes para sistemas distribu´ ıdos ∗Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento Cient´ ıfico e Tecnol´ ogico (CNPq) sob os processos 135882/2009-5 e 308192/2007-9. XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 411 que utilizam plataformas tradicionais. Por´ em alguns desses desafios s˜ ao aumentados pela escassez de recursos computacionais dos motes, por um modelo de programac¸˜ ao fortemente orientado a eventos e pela tecnologia de comunicac¸˜ ao sem fio com caracter´ ısticas de redes ad-hoc. Al´ em disso, a programac¸˜ ao feita na ´ otica de cada n´ o sensor dificulta o desenvolvimento nos casos em que as aplicac¸ ˜ oes utilizam os dispositivos em grande escala e onde o desenvolvedor precisa ter uma vis˜ ao da rede como um todo. Associado aos desafios t´ ıpicos da computac¸˜ ao distribu´ ıda, uma demanda comum no cen´ ario de RSSF ´ e a necessidade de realizar ajustes na aplicac¸˜ ao ap´ os a sua implantac¸˜ ao. Esses ajustes podem ser uma simples alterac¸˜ ao no per´ ıodo de monitorac¸˜ ao, uma correc¸˜ ao no fluxo de processamento ou at´ e a ativac¸˜ ao ou desativac¸˜ ao de pequenas funcionalidades. A plataforma de software de uso mais comum para o desenvolvimento de aplicac¸ ˜ oes em RSSF n˜ ao disponibiliza, de forma nativa, opc¸ ˜ oes para reconfigurac¸˜ ao remota ap´ os a implantac¸˜ ao da aplicac¸˜ ao e, na maioria dos casos, ´ e invi´ avel recuperar todos os motes para aplicar novas alterac¸ ˜ oes. As alternativas mais comuns para reprogramac¸˜ ao dos n´ os sensores envolvem a carga remota e substituic¸˜ ao de componentes inteiros, dessa forma, indo muito al´ em de uma simples reconfigurac¸˜ ao e podendo consumir mais recursos da rede do que o necess´ ario. Uma soluc¸˜ ao intermedi´ aria seria disponibilizar para o desenvolvedor um conjunto de componentes parametriz´ aveis e que possam ter a sua execuc¸˜ ao definida atrav´ es de um controle de fluxo simplificado. Aliado ` a opc¸˜ ao para reconfigurac¸˜ ao remota, tanto do fluxo de processamento quanto dos parˆ ametros dos componentes, esse esquema ´ e suficiente em muitos cen´ arios e envolve menos gastos de energia. O objetivo principal do nosso trabalho ´ e investigar um modelo de programac¸˜ ao que minimize as dificuldades de desenvolvimento e reconfigurac¸˜ ao dinˆ amica das aplicac¸ ˜ oes em RSSF. Um caminho para alcanc¸ar essas duas metas ´ e permitir o uso das mesmas t´ ecnicas de programac¸˜ ao, tanto no processo de desenvolvimento de uma nova aplicac¸˜ ao, como na etapa seguinte de reconfigurac¸˜ ao em tempo de execuc¸˜ ao. Para facilitar a criac¸˜ ao de novas aplicac¸ ˜ oes, identificamos um conjunto de componentes de alto n´ ıvel que se combinam para formar diferentes aplicac¸ ˜ oes. Atrav´ es de um controle de fluxo baseado em m´ aquinas de estados finitos (Finite State Machine) (FSM), o desenvolvedor indica quais componentes ir´ a utilizar e qual ser´ a a sequˆ encia de operac¸˜ ao dos mesmos. Tanto o fluxo da FSM quanto o comportamento funcional dos componentes s˜ ao definidos atrav´ es de parˆ ametros. O modelo de controle de fluxo proposto permite a criac¸˜ ao de v´ arias m´ aquinas de estado dentro de uma mesma aplicac¸˜ ao e ainda possibilita a dependˆ encia entre estados de diferentes m´ aquinas, facilitando a construc¸˜ ao de aplicac¸ ˜ oes mais complexas, ou a vis˜ ao de uma mesma RSSF usada para diferentes finalidades. A possibilidade de configurac¸˜ ao dinˆ amica ´ e alcanc¸ada simplesmente permitindo que esses parˆ ametros sejam alterados remotamente. Como exemplo, em uma aplicac¸˜ ao de coleta peri´ odica de temperatura, pode-se alterar o per´ ıodo de coleta ou alterar o fluxo operacional para calcular a m´ edia da temperatura dos n´ os do mesmo grupo. Tamb´ em ´ e poss´ ıvel adicionar, em tempo de execuc¸˜ ao, um novo fluxo para esta aplicac¸˜ ao, como um alarme de temperatura alta, mantendo o fluxo anterior inalterado. Este texto est´ a organizado da seguinte forma: na pr´ oxima sec¸˜ ao (2), apresentamos os trabalhos relacionados; na sec¸˜ ao 3, apresentamos o nosso sistema, abordando os 412 Anais componentes propostos e o modelo de transic¸˜ ao para a FSM; na sec¸˜ ao 4, apresentamos alguns cen´ arios de teste para nossa an´ alise experimental; finalizamos com a sec¸˜ ao 5, na qual apresentamos nossas considerac¸ ˜ oes e abordamos as melhorias e os trabalhos futuros. 2. Trabalhos Relacionados Um dos primeiros trabalhos a propor simplificac¸˜ ao para programac¸˜ ao de plataformas no estilo motes foi o TinyDB [Madden et al. 2005]. Apesar de n˜ ao utilizar o conceito de biblioteca de componentes, o TinyDB disponibiliza um conjunto de func¸ ˜ oes para agregac¸ ˜ oes simples e permite reconfigurar a coleta de dados da rede atrav´ es de comandos remotos baseados numa linguagem simplificada do estilo SQL. O TinyDB limita-se ` as aplicac¸ ˜ oes com caracter´ ısticas de coleta de dados, com possibilidade de agregac¸ ˜ oes em uma topologia hier´ arquica de roteamento e sem interac¸˜ ao local entre os n´ os da rede. Um conjunto de trabalhos mais recentes, com foco em modelos de programac¸˜ ao mais adequados para RSSF, est´ a ligado ao conceito de macroprogramac¸ ˜ ao. O argumento principal para a macroprogramac¸˜ ao em RSSF ´ e que toda aplicac¸˜ ao para essas redes requer naturalmente a interac¸˜ ao entre os n´ os individuais, ent˜ ao, ao inv´ es de projetar as aplicac¸ ˜ oes a partir do c´ odigo de cada n´ o, prop˜ oe-se o inverso, que a aplicac¸˜ ao seja projetada considerando a rede como um todo e que, em uma etapa seguinte, o c´ odigo necess´ ario seja instanciado em cada n´ o individual. Dentre os representantes dessa linha, destacamos Regiment [Newton et al. 2007], Pleiades [Kothari et al. 2007], Cosmos [Awan et al. 2007], WADL [Cervantes et al. 2008] e ATaG [Bakshi et al. 2005]. Uma dificuldade encontrada nessas soluc¸ ˜ oes ´ e que embora a vis˜ ao de programac¸˜ ao da rede como um todo seja mais adequada, em geral, os componentes b´ asicos que devem ser executados nos n´ os individuais ainda precisam ser implementados diretamente pelo desenvolvedor, desviando a atenc¸˜ ao para os n´ os individuais em uma etapa seguinte ao projeto da aplicac¸˜ ao. Dentre os trabalhos que abordam a reprogramac¸˜ ao remota, temos os que utilizam um modelo de m´ aquina virtual simplificado, como Mat´ e [Levis and Culler 2002], ou os trabalhos baseados no DELUGE [Hui and Culler 2004], que carregam o programa original na linguagem nativa. A linguagem utilizada por Mat´ e´ e bem simples e permite acesso apenas aos recursos b´ asicos do mote, n˜ ao disponibilizando uma biblioteca de componentes de alto n´ ıvel que facilite a construc¸˜ ao de novas aplicac¸ ˜ oes. Os trabalhos que utilizam o DELUGE normalmente precisam fazer a carga completa da aplicac¸˜ ao em conjunto com o sistema operacional. Abordagens mais recentes possibilitam a recarga em separado de componentes originais da aplicac¸˜ ao [Munawar et al. 2010], permitindo reduzir o custo da reprogramac¸˜ ao remota. No trabalho de Kasten e Romer ´ e proposto um modelo de programac¸˜ ao baseado em m´ aquinas de estados para RSSF, chamado OSM [Kasten and R¨ omer 2005], cujo objetivo ´ e simplificar a programac¸˜ ao dos motes. OSM utiliza um processo de compilac¸˜ ao para gerar c´ odigo na linguagem nativa dos n´ os sensores e n˜ ao aplica o conceito de reprogramac¸˜ ao. Como outros trabalhos, OSM tamb´ em considera que o desenvolvedor deve construir os componentes mais b´ asicos na linguagem de programac¸˜ ao do n´ os sensores. O modelo de programac¸˜ ao para RSSF que propomos neste trabalho integra um mecanismo para configurac¸˜ ao do fluxo de processamento da aplicac¸˜ ao com uma biblioteca de componentes parametriz´ aveis, a partir do qual, na maioria dos casos, o desenXXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 413 volvedor n˜ ao precisar´ a construir nenhum componente adicional. Comparando com as opc¸ ˜ oes de carga de software remota, temos um modelo de programac¸˜ ao de mais alto n´ ıvel e simplificado do que as soluc¸ ˜ oes que utilizam m´ aquina virtual ou carga de c´ odigo nativo. Comparando com o TinyDB, o nosso modelo disponibiliza mais funcionalidades e ainda permite interac¸ ˜ oes locais. Aproveitamos a ideia do modelo de FSM utilizado por OSM e implementamos um modelo de programac¸˜ ao que permite a reconfigurac¸˜ ao remota de aplicac¸ ˜ oes. 3. Sistema para reconfigurac¸ ˜ ao dinˆ amica de aplicac¸˜ oes baseado em FSM e componentes parametriz´ aveis Propomos um sistema que permite a configurac¸˜ ao remota de aplicac¸ ˜ oes por meio da definic¸˜ ao dos parˆ ametros de alguns componentes e de um ou mais fluxos de execuc¸˜ ao. O controle da aplicac¸˜ ao ´ e definido por uma m´ aquina de estados finitos (FSM) na qual o desenvolvedor define o fluxo de processamento dos componentes atrav´ es da combinac¸˜ ao de estados, eventos e ac¸ ˜ oes. O comportamento funcional dos componentes ´ e definido atrav´ es de um conjunto de parˆ ametros. As poss´ ıveis combinac¸ ˜ oes entre o controle de fluxo e as parametrizac¸ ˜ oes dos componentes permitem a construc¸˜ ao de diferentes tipos de aplicac¸ ˜ oes para RSSF. Nesta sec¸˜ ao, descrevemos os elementos b´ asicos do sistema proposto. 3.1. Biblioteca de componentes parametriz´ aveis Para a identificac¸˜ ao dos componentes da nossa biblioteca, utilizamos trˆ es abordagens. Primeiro, identificamos os diferentes comportamentos de comunicac¸˜ ao numa RSSF, considerando a necessidade de interac¸˜ ao entre os n´ os e o roteamento de/para a estac¸˜ ao base. Em seguida, a partir de casos levantados na literatura, especificamos trˆ es diferentes aplicac¸ ˜ oes para RSSF e identificamos as diferentes ac¸ ˜ oes que cada aplicac¸˜ ao utilizou. Essas aplicac¸ ˜ oes est˜ ao detalhadas na tabela 1. Finalmente, revisitamos alguns modelos de programac¸˜ ao e listamos os diferentes tipos de elementos que cada modelo propˆ os. Selecionamos alguns modelos de programac¸˜ ao espec´ ıficos para macroprogramac¸˜ ao em RSSF ou que trabalhassem com abstrac¸ ˜ oes de mais alto n´ ıvel de uma rede de sensores, os modelos avaliados foram: Regiment [Newton et al. 2007], Pleiades [Kothari et al. 2007], Cosmos [Awan et al. 2007], WADL [Cervantes et al. 2008], TinyDB [Madden et al. 2005] e ATaG [Bakshi et al. 2005]. A partir dessa avaliac¸˜ ao geral, identificamos as similaridades e oportunidades de parametrizac¸ ˜ oes e, com isso, obtivemos uma lista de componentes parametriz´ aveis, muitos dos quais s˜ ao utilizados em mais de uma aplicac¸˜ ao. Na ´ otica da aplicac¸˜ ao, nossa biblioteca fornece funcionalidades para acesso local ao mote e tamb´ em para operac¸ ˜ oes em grupos de motes. Assim, algumas das dificuldades t´ ıpicas de programac¸˜ ao em RSSF ficaram transparentes para a camada de aplicac¸˜ ao. Como exemplos, podemos citar as operac¸ ˜ oes para agregac¸˜ ao de valores, a eleic¸˜ ao de l´ ıder de grupo e o roteamento de mensagens pela rede. Os parˆ ametros da nossa biblioteca est˜ ao divididos em Parˆ ametros Gerais e num conjunto de parˆ ametros que definem at´ e trˆ es Operac¸ ˜ oes de Coleta distintas. Os Parˆ ametros Gerais definem os valores utilizados para identificac¸˜ ao dos grupos de motes, a definic¸˜ ao do tempo dos temporizadores gen´ ericos disponibilizados para a aplicac¸˜ ao e o per´ ıodo para 414 Anais Tabela 1. Caracter´ısticas das aplicac¸ ˜ oes de referˆ encia Aplicac¸˜ ao 1 - Alarme de incˆ endio florestal Descric¸˜ ao: Quando um n´ o identifica uma situac¸˜ ao de alarme, ele consulta seus vizinhos para confirmar o alarme e envia uma mensagem para a estac¸˜ ao servidora. Trabalho origem Regiment [Newton et al. 2007] Tipo de Agrupamento Comunicac¸˜ ao com os vizinhos imediatos. Agrupamento por alcance do r´ adio. Tipo de Comunicac¸˜ ao Propagac¸˜ ao 1 hop com retorno. Roteamento para a estac¸˜ ao servidora. Aplicac¸˜ ao 2 - Monitor de temperatura e Alarme de incˆ endio predial Descric¸˜ ao Essa aplicac¸˜ ao combina monitorac¸˜ ao de temperatura e alarme de incˆ endio para um pr´ edio. Para monitorac¸˜ ao de cada ambiente, um n´ o centralizador do ambiente calcula periodicamente a temperatura m´ edia entre os n´ os do ambiente e envia a informac¸˜ ao para a estac¸˜ ao servidora. Para o alarme, o n´ o que identificar a situac¸˜ ao irregular deve enviar uma mensagem para estac¸˜ ao servidora. Trabalho origem WADL [Cervantes et al. 2008] Tipo de Agrupamento Comunicac¸˜ ao com os vizinhos nsaltos. Agrupamento por posicionamento do n´ o (andar e sala). Tipo de Comunicac¸˜ ao Propagac¸˜ ao n hops com retorno seletivo. Roteamento para a estac¸˜ ao servidora. Aplicac¸˜ ao 3 - Estacionamento urbano e Monitorac¸˜ ao de vagas Descric¸˜ ao Essa aplicac¸˜ ao tem um processo de reserva de vagas de estacionamento combinado com uma monitorac¸˜ ao das vagas por regi˜ ao. Para monitorac¸˜ ao, os n´ os centralizadores de cada regi˜ ao sumarizam periodicamente a situac¸˜ ao das vagas e enviam esses dados para a estac¸˜ ao servidora. No processo de reserva, um n´ o m´ ovel solicita aos n´ os vizinhos uma vaga dispon´ ıvel e em seguida confirma a reserva de uma das vagas. Trabalho origem Pleiades [Kothari et al. 2007] Tipo de Agrupamento Comunicac¸˜ ao com os vizinhos nsaltos. Agrupamento por regi˜ ao do n´ o. Tipo de Comunicac¸˜ ao Propagac¸˜ ao n hops com retorno seletivo. Roteamento para a estac¸˜ ao servidora. reeleic¸˜ ao do n´ o coordenador. Para as Operac¸ ˜ oes de Coleta, pode-se definir o per´ ıodo da coleta, as regras para formac¸˜ ao de grupos e a func¸˜ ao de coleta. A operac¸˜ ao de coleta pode ser uma simples leitura de um sensor local ou uma agregac¸˜ ao de valor entre os motes de um mesmo grupo, incluindo tamb´ em a possibilidade de operac¸ ˜ oes comparativas de resultados contra valores de referˆ encia tamb´ em parametrizados. Criamos uma arquitetura em camadas em que o desenvolvedor pode controlar o fluxo dos componentes do n´ ıvel mais alto e pode parametrizar os componentes dessa e de outras camadas. Na Figura 1, apresentamos uma vis˜ ao das camadas funcionais da nossa arquitetura. Nas camadas superiores, temos os componentes que podem ser acessados diretamente pelo controle de fluxo, por exemplo, temos as operac¸ ˜ oes locais no mote e as operac¸ ˜ oes de agregac¸˜ ao entre motes do mesmo grupo. As camadas intermedi´ arias e inferiores est˜ ao isoladas do controle de fluxo, mas os principais componentes podem ser parametrizados conforme a necessidade da aplicac¸˜ ao. Essa separac¸˜ ao ´ e obtida utilizando XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 415 Figura 1. Camadas da arquitetura de execuc¸ ˜ ao o conceito de grupo de motes, no qual a aplicac¸˜ ao opera o objeto “Grupo” enquanto que outros componentes trabalham, de forma transparente ` a aplicac¸˜ ao, para efetivar essas operac¸ ˜ oes. A identificac¸˜ ao dos grupos ´ e feita atrav´ es de parˆ ametros registrados em cada mote. Um determinado grupo ´ e definido pelos motes que contˆ em os mesmos valores para determinados parˆ ametros. O m´ odulo de agregac¸˜ ao cont´ em os principais componentes disponibilizados diretamente para o desenvolvedor, como as func¸ ˜ oes para agregac¸˜ ao que incluem func¸ ˜ oes b´ asicas como SUM (soma dos valores coletados) e MAX (valor m´ aximo coletado), e func¸ ˜ oes mais complexas, como Reserva de Recurso e Sumarizac¸˜ ao de dados. O m´ odulo de Func¸ ˜ oes Locais disponibiliza acesso aos sensores do dispositivo. O m´ odulo Agrupamento ´ e respons´ avel pela validac¸˜ ao dos grupos, tanto para as solicitac¸ ˜ oes provenientes da aplicac¸˜ ao do mote, como para as solicitac¸ ˜ oes externas de outros motes. O m´ odulo de comunicac¸˜ ao controla os protocolos de comunicac¸˜ ao disparando operac¸ ˜ oes ou reagindo a solicitac¸ ˜ oes externas. Esse m´ odulo implementa trˆ es protocolos b´ asicos: propagac¸˜ ao e retorno de valores de forma radial a partir de um n´ o da rede (NHops), roteamento de mensagens de/para a estac¸˜ ao base e difus˜ ao dos dados da FSM pela rede. Essa camada tamb´ em processa o recebimento dos dados de configurac¸˜ ao enviados pela estac¸˜ ao base, possibilitando a reconfigurac¸˜ ao dinˆ amica da aplicac¸˜ ao. A partir desse conjunto inicial de componentes b´ asicos foi poss´ ıvel implementar as trˆ es aplicac¸ ˜ oes de referˆ encia da tabela 1. O resultado est´ a dispon´ ıvel no link: http://www.inf.puc-rio.br/˜abranco/files/SBRC2011 3.2. Controle do fluxo de processamento baseado em FSM Para permitir combinac¸ ˜ oes diferentes de um dado conjunto de componentes, implementamos um controle de fluxo de operac¸˜ ao baseado no modelo de FSM. Esse modelo ´ e facilmente adapt´ avel ao modelo t´ ıpico de eventos utilizado em RSSF. Nossa implementac¸˜ ao considera que a FSM ser´ a definida por uma tabela de transic¸ ˜ oes. De forma simplificada, cada transic¸˜ ao cont´ em um estado de entrada, um evento v´ alido para esse estado, uma ac¸˜ ao de sa´ ıda e o estado de sa´ ıda da transic¸˜ ao. O Controle da FSM, ao receber um novo evento, verifica se existe uma transic¸˜ ao v´ alida para o estado corrente. Se sim, muda o estado corrente para o estado de sa´ ıda e dispara a ac¸˜ ao de sa´ ıda. Na Figura 2.a, apresentamos um diagrama simplificado da arquitetura do controle de FSM e, na Figura 2.b, temos uma exemplo de configurac¸˜ ao da tabela de transic¸ ˜ oes. 416 Anais Figura 2. Arquitetura de controle da FSM e exemplo de tabela de transic¸ ˜ oes A definic¸˜ ao dos estados ´ e livre e de responsabilidade do desenvolvedor, mas as poss´ ıveis ac¸ ˜ oes e eventos dependem dos componentes disponibilizados no sistema. Por exemplo, a solicitac¸˜ ao de leitura de um sensor ´ e uma ac¸˜ ao, enquanto que a resposta da leitura ´ e um evento. Outro exemplo de evento ´ e o disparo do timer peri´ odico de coleta. Na tabela 2, apresentamos um resumo das principais ac¸ ˜ oes e eventos disponibilizados na vers˜ ao atual da nossa implementac¸˜ ao. Esse conjunto pequeno de ac¸ ˜ oes, combinado com as diversas opc¸ ˜ oes de parametrizac¸ ˜ oes, permite o desenvolvimento de uma grande gama de aplicac¸ ˜ oes. Como exemplo, na subsec¸˜ ao 4.2, apresentaremos a implementac¸˜ ao da aplicac¸˜ ao esboc¸ada na Figura 4. Tabela 2. Principais ac¸ ˜ oes e eventos dispon´ıveis Componente Ac¸ ˜ ao Evento Timer Peri´ odico – Disparo para uma nova Coleta (TimerFired) Sensor Local Inicia leitura (readSensor()) Resultado da leitura (sensorDone) Comparar resultado com parˆ ametro (testValue()) Resultado da comparac¸˜ ao (testValueDone) Mote Infos Verifica se ´ e coordenador (testCoord()) Resultado da verificac¸˜ ao (testCoordDone) Agregac¸˜ ao Disparar a agregac¸˜ ao indicada nos parˆ ametros (startAggreg()) Resultado da agregac¸˜ ao (AggregDone) Comparar resultado com parˆ ametro (testAggreg()) Resultado da comparac¸˜ ao (testAggregDone) Timer customizado Iniciar contagem (startTimerX()) Timer finalizado (timerXFired) Comunicac¸˜ ao Enviar comando para os motes do mesmo grupo (sendComm()) Recebimento de comando de outro mote (recComm) Enviar dados para o servidor (sendBS()) Confirmac¸˜ ao do envio (sendDone) XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 417 3.3. Implementac¸ ˜ ao A nossa implementac¸˜ ao foi realizada usando a linguagem nesC [Gay et al. 2003] e o sistema operacional TinyOS [Levis et al. 2004]. Para os testes reais, usamos a plataforma de hardware MICAz [Crossbow 2004]. Os testes mais exaustivos e monitorados foram executados no simulador TOSSIM [Levis et al. 2003], que acompanha o TinyOS. O nosso protocolo de formac¸˜ ao de grupo de motes (NHops) foi implementado atrav´ es da difus˜ ao de uma mensagem que se propaga por uma quantidade pr´ e-definida de saltos e retorna o valor solicitado, caso o n´ o fac¸a parte do mesmo grupo do n´ o originador. A difus˜ ao dos dados da FSM pela rede foi implementada utilizando o protocolo DIP [Lin and Levis 2008]. O roteamento de/para a estac¸˜ ao base foi implementado utilizando uma customizac¸˜ ao baseada no protocolo CTP [Fonseca et al. 2007]. Utilizamos o DIP e o CTP por j´ a fazerem parte do TinyOS, o que simplificou a nossa implementac¸˜ ao. 4. Avaliac¸˜ ao Avaliamos o nosso sistema sob dois aspectos: (i) primeiro observamos as facilidades de configurac¸˜ ao e reconfigurac¸˜ ao de uma nova aplicac¸˜ ao; (ii) depois avaliamos o impacto adicional em termos de comunicac¸˜ ao e quantidade de bytes requeridas para a reconfigurac¸˜ ao de uma aplicac¸˜ ao em execuc¸˜ ao. No primeiro caso, as m´ etricas utilizadas foram a quantidade de linhas na tabela de transic¸ ˜ oes para a FSM e o n´ umero de parˆ ametros necess´ arios para a implementac¸˜ ao da aplicac¸˜ ao. No segundo caso, a m´ etrica utilizada foi a quantidade de mensagens enviadas na rede. Conforme [Shnayder et al. 2004] podemos considerar o envio de uma mensagem como a operac¸˜ ao de maior custo em relac¸˜ ao ao consumo de bateria e, consequentemente, a operac¸˜ ao que mais afeta o tempo de vida ´ util de um n´ o. Para podermos contabilizar os envios, executamos a aplicac¸˜ ao no simulador TOSSIM habilitando os logs das func¸ ˜ oes de comunicac¸˜ ao. Apresentamos a seguir o modelo de rede utilizado como referˆ encia para nossos testes. Em seguida, abordamos cada teste e apresentamos os resultados espec´ ıficos. 4.1. Modelo de rede para os testes Definimos uma aplicac¸˜ ao e uma rede de referˆ encia para podermos simular os nossos testes em um ambiente controlado. Vamos assumir uma aplicac¸˜ ao de monitorac¸˜ ao predial, em que o motes est˜ ao distribu´ ıdos de forma equidistante em trˆ es ambientes, sendo que a estac¸˜ ao base se comunica somente com o mote central. Em cada ambiente h´ a um grupo de nove motes. Cada mote s´ o consegue se comunicar com os vizinhos no raio de alcance do r´ adio, independentemente de estarem ou n˜ ao no mesmo grupo. Para conseguir formar os grupos tivemos que configurar o parˆ ametro de salto m´ aximo (n Hops Max) igual a dois. A estac¸˜ ao servidora (fonte de reconfigurac¸˜ ao da aplicac¸˜ ao) est´ a conectada ao n´ o central (25) atrav´ es da estac¸˜ ao base (EB). Essa configurac¸˜ ao requer, propositalmente, que os protocolos utilizados precisem rotear a maioria das mensagens. A Figura 3 apresenta a nossa rede de referˆ encia. As setas cinzas indicam o alcance da comunicac¸˜ ao entre os motes. 418 Anais Figura 3. Rede de referˆ encia 4.2. Primeiro Teste: Desenvolvendo uma nova aplicac¸ ˜ ao O primeiro teste teve o objetivo de exercitar a criac¸˜ ao de uma nova aplicac¸˜ ao no nosso sistema. Para isso, definimos uma aplicac¸˜ ao de “Coleta peri´ odica de dados”. A nossa aplicac¸˜ ao de teste calcula periodicamente a temperatura m´ edia de cada grupo de n´ os da nossa rede de referˆ encia e, em seguida, envia esse valor para a estac¸˜ ao servidora. O n´ o centralizador de cada grupo ´ e definido num processo de eleic¸˜ ao de l´ ıder em que o n´ o com a maior disponibilidade de bateria ´ e eleito. Com o objetivo de distribuir o consumo, periodicamente ´ e executado um processo para reeleic¸˜ ao do l´ ıder. Como citado na sec¸˜ ao 3, a configurac¸˜ ao da aplicac¸˜ ao utiliza uma estrutura de parˆ ametros e uma tabela de transic¸ ˜ oes como definic¸˜ ao do fluxo de funcionamento da aplicac¸˜ ao. Para essa aplicac¸˜ ao foi preciso definir apenas seis parˆ ametros, que incluem o per´ ıodo da coleta, o tipo de operac¸˜ ao de agregac¸˜ ao e a definic¸˜ ao do grupo. J´ a em relac¸˜ ao ` a FSM, foi necess´ ario definir 15 transic¸ ˜ oes, sendo oito para a inicializac¸˜ ao obrigat´ oria do mote e sete para o controle da aplicac¸˜ ao de coleta. Na tabela 3, apresentamos um resumo da quantidade de parˆ ametros utilizados e o respectivo tamanho em bytes. A Figura 4.a apresenta a FSM para controle da coleta e a Figura 4.b mostra a estrutura de dados com os parˆ ametros usados. Figura 4. (a) FSM para controle de uma aplicac¸ ˜ ao de coleta e (b) Definic¸ ˜ ao dos respectivos parˆ ametros. Executamos essa aplicac¸˜ ao no simulador do TinyOS para contabilizar a quantidade de envios em cada etapa de funcionamento da aplicac¸˜ ao. No caso da Coleta, os valores correspondem a uma operac¸˜ ao de coleta. Na tabela 4, apresentamos a quantidade de mensagens enviadas em cada etapa, com o cuidado de separar os valores para o CTP. Esses valores foram obtidos numa execuc¸˜ ao equivalente a 20 minutos, com coleta de dois XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 419