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

Adriano Francisco Branco Um modelo de programa¸c˜ao para RSSF com suporte `a reconfigura¸c˜ao dinˆamica de aplica¸c˜oes Disserta¸c˜ao de Mestrado Disserta¸c˜ao apresentada ao Programa de P´os–gradua¸c˜ao em Inform´atica do Departamento de Inform´atica do Centro T´ecnico Cient´ıfico da PUC–Rio como requisito parcial para obten¸c˜ao do grau de Mestre em Inform´atica. Orientador : Prof. Noemi de La Rocque Rodriguez Co–Orientador: Prof. Silvana Rossetto Rio de Janeiro Abril de 2011 Adriano Francisco Branco Um modelo de programa¸c˜ao para RSSF com suporte `a reconfigura¸c˜ao dinˆamica de aplica¸c˜oes Disserta¸c˜ao apresentada ao Programa de P´os–gradua¸c˜ao em Inform´atica do Departamento de Inform´atica do Centro T´ecnico Cient´ıfico da PUC–Rio como requisito parcial para obten¸c˜ao do grau de Mestre em Inform´atica. Aprovada pela Comiss˜ao Examinadora abaixo assinada. Prof. Noemi de La Rocque Rodriguez Orientador Departamento de Inform´atica — PUC–Rio Prof. Silvana Rossetto Co–Orientador Departamento de Ciˆencia da Computa¸c˜ao — UFRJ Prof. Luci Pirmez UFRJ Prof. Renato Fontoura de Gusm˜ao Cerqueira Departamento de Inform´atica — PUC-Rio Dr. Renato Figueir´o Maia Pesquisador — PUC-Rio Prof. Jos´e Eugenio Leal Coordenador Setorial do Centro T´ecnico Cient´ıfico — PUC–Rio Rio de Janeiro, 6 de Abril de 2011 Todos os direitos reservados. ´ E proibida a reprodu¸c˜ao total ou parcial do trabalho sem autoriza¸c˜ao da universidade, do autor e do orientador. Adriano Francisco Branco Graduou–se em Engenharia Eletrˆonica pelo Centro Federal de Educa¸c˜ao Tecnol´ogica Celso Suckow da Fonseca (CEFET/RJ). Trabalhou mais de 12 anos em consultoria de projetos de integra¸c˜ao de sistemas, principalmente nas ´areas de automa¸c˜ao industrial e telecomunica¸c˜oes. Tamb´em tem passagem pela ´area de P&D, com trabalhos no CERN (Su´ı¸ca) e CBPF/CNPq. Teve oportunidade de trabalhar em projetos de eletrˆonica digital de interfaces de comunica¸c˜ao, computadores 8 e 32 bits com CPUs CISC e RISC, sistemas de controles e aquisi¸c˜ao de dados. Tˆem experiˆencia em sistemas operacionais como CP/M, DOS, Windows, VMS e diversas varia¸c˜oes de Unix. Trabalhou com integra¸c˜ao de sistemas desenvolvendo ferramentas customizadas ou utilizando ferramentas comerciais para integra¸c˜ao em tempo real, s´ıncronas e ass´ıncronas. Tamb´em tem grande experiˆencia em gerˆencia de projetos e coordena¸c˜ao de equipes de desenvolvimento de sistemas. Ficha Catalogr´afica Branco, Adriano Francisco Um modelo de programa¸c˜ao para RSSF com suporte `a reconfigura¸c˜ao dinˆamica de aplica¸c˜oes / Adriano Francisco Branco; orientador: Noemi de La Rocque Rodriguez; co– orientador: Silvana Rossetto. — 2011. 98 f. : il. (color); 30 cm 1. Disserta¸c˜ao (mestrado) - Pontif´ıcia Universidade Cat´olica do Rio de Janeiro, Departamento de Inform´atica, 2011. Inclui bibliografia. 1. Inform´atica – Teses. 2. Rede de Sensores sem Fio (RSSF). 3. Sistemas Distribu´ıdos. 4. Modelo de Programa¸c˜ao. 5. Fun¸c˜oes parametriz´aveis. 6. M´aquina de Estados Finitos (FSM). 7. Reconfigura¸c˜ao Dinˆamica. I. Rodriguez, Noemi de La Rocque. II. Rossetto, Silvana. III. Pontif´ıcia Universidade Cat´olica do Rio de Janeiro. Departamento de Inform´atica. IV. T´ıtulo. CDD: 004 Agradecimentos Aos meus orientadores Professores Noemi Rodriguez e Silvana Rossetto pelo apoio e incentivo para a realiza¸c˜ao deste trabalho. Ao CNPq e `a PUC–Rio, pelos aux´ılios concedidos, sem os quais este trabalho n˜ao poderia ter sido realizado. ` A minha esposa, que me acompanhou todo esse tempo com apoio direto e indireto. Aos meus pais, irm˜aos, fam´ılia e amigos, que me apoiaram mesmo com minha ausˆencia na vida familiar. A todos os colegas, professores e funcion´arios do Departamento de Inform´atica da PUC-Rio, pelo companheirismo, aprendizado e aux´ılio. Resumo Branco, Adriano Francisco; Rodriguez, Noemi de La Rocque; Rossetto, Silvana. Um modelo de programa¸c˜ao para RSSF com suporte `a reconfigura¸c˜ao dinˆamica de aplica¸c˜oes. Rio de Janeiro, 2011. 98p. Disserta¸c˜ao de Mestrado — Departamento de Inform´atica, Pontif´ıcia Universidade Cat´olica do Rio de Janeiro. Algumas caracter´ısticas b´asicas das redes de sensores sem fio (RSSF) dificultam as tarefas de cria¸c˜ao e reconfigura¸c˜ao de aplica¸c˜oes. Nesse trabalho apresentamos um modelo de programa¸c˜ao que pretende simplificar essas tarefas. O modelo se baseia no uso conjunto de fun¸c˜oes parametriz´aveis e de m´aquinas de estados finitos, e permite a implementa¸c˜ao de diferentes tipos de aplica¸c˜oes para redes de sensores sem fio e a configura¸c˜ao remota dessas aplica¸c˜oes. Descrevemos alguns testes para avaliar o quanto esse modelo pode facilitar o desenvolvimento de novas aplica¸c˜oes, o quanto ´e f´acil aplicar novas altera¸c˜oes sobre as aplica¸c˜oes em execu¸c˜ao, e o impacto na quantidade de mensagens na rede por conta do uso da configura¸c˜ao remota. Palavras–chave Rede de Sensores sem Fio (RSSF); Sistemas Distribu´ıdos; Modelo de Programa¸c˜ao; Fun¸c˜oes parametriz´aveis; M´aquina de Estados Finitos (FSM); Reconfigura¸c˜ao Dinˆamica. Abstract Branco, Adriano Francisco; Rodriguez, Noemi de La Rocque (Advisor); Rossetto, Silvana (Co-Advisor). A WSN programming model with a dynamic reconfiguration support. Rio de Janeiro, 2011. 98p. MSc Dissertation — Departamento de Inform´atica, Pontif´ıcia Universidade Cat´olica do Rio de Janeiro. Some basic characteristics of wireless sensor networks (WSN) make application creation and reconfiguration difficult tasks. A programming model is presented to simplify these tasks. 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. We describe some tests to 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. Keywords Wireless Sensor Network (WSN); Distributed Systems; Programming Model; Parametrized functions; Finite State Machine (FSM); Dynamic reconfiguration. Sum´ario 1 Introdu¸c˜ao 10 1.1 Abordagem 11 1.2 Objetivos e contribui¸c˜oes 12 1.3 Trabalhos relacionados 13 1.4 Organiza¸c˜ao do documento 15 2 TinyOS e NesC 16 2.1 NesC 16 2.2 TinyOS 17 3 O modelo de programa¸c˜ao proposto 21 3.1 Padr˜oes de intera¸c˜ao para aplica¸c˜oes em RSSF 21 3.2 Conjunto das funcionalidades b´asicas 25 3.3 Controle de fluxo baseado em FSM 30 3.4 Exemplo simplificado de aplica¸c˜ao do modelo de programa¸c˜ao 32 3.5 Reconfigura¸c˜ao 33 4 Implementa¸c˜ao 35 4.1 Vis˜ao operacional geral 35 4.2 Etapas de opera¸c˜ao 39 4.3 Padr˜ao de implementa¸c˜ao para as camadas funcionais 42 4.4 Exemplo de um fluxo de execu¸c˜ao 44 4.5 Experiˆencias no desenvolvimento e novas funcionalidades 47 5 Avalia¸c˜ao 52 5.1 Implementa¸c˜ao das aplica¸c˜oes de referˆencia 52 5.2 Avalia¸c˜ao da facilidade de programa¸c˜ao e do impacto da configura¸c˜ao remota 57 6 Conclus˜ao 66 6.1 Trabalhos futuros 67 7 Referˆencias Bibliogr´aficas 69 A Detalhamento dos padr˜oes de intera¸c˜ao 72 B Diagramas das FSMs e Parˆametros de Configura¸c˜ao 78 B.1 Aplica¸c˜ao utilizada nos testes 78 B.2 Aplica¸c˜oes de Referˆencia 80 C Ambiente de execu¸c˜ao para os testes 92 D Interfaces e Componentes NesC do sistema 94 E Formata¸c˜ao dos arquivos de configura¸c˜ao XML 97 Lista de figuras 3.1 Camadas da arquitetura de execu¸c˜ao 26 3.2 Arquitetura com as funcionalidades b´asicas 30 3.3 Arquitetura de controle da FSM 31 3.4 Sintaxe FSM e exemplo de tabela de transi¸c˜oes 32 3.5 Aplica¸c˜ao exemplo - coleta peri´odica de temperatura 33 4.1 M´odulos utilizados na esta¸c˜ao servidora 36 4.2 Arquitetura b´asica das camadas funcionais 42 4.3 Configura¸c˜ao para uma aplica¸c˜ao de monitora¸c˜ao de temperatura 44 4.4 FSM para monitora¸c˜ao peri´odica da temperatura m´edia 45 4.5 Exemplo de fluxo de execu¸c˜ao para uma aplica¸c˜ao de agrega¸c˜ao 46 5.1 Aplica¸c˜ao 1 - FSM para inicializa¸c˜ao do mote e controle geral da aplica¸c˜ao 53 5.2 Aplica¸c˜ao 1 - FSM para gera¸c˜ao do alarme 54 5.3 Rede de referˆencia 58 5.4 (a) FSM para controle de uma aplica¸c˜ao de coleta e (b) Defini¸c˜ao dos respectivos parˆametros. 59 5.5 Distribui¸c˜ao no tempo de cada etapa de opera¸c˜ao 59 5.6 (a) FSM para controle de uma aplica¸c˜ao de alarme e (b) Defini¸c˜ao dos respectivos parˆametros 62 B.1 Aplica¸c˜ao 1 - FSM para Inicializa¸c˜ao do Mote e controle geral 80 B.2 Aplica¸c˜ao 1 - FSM para gera¸c˜ao do alarme 80 B.3 Aplica¸c˜ao 2 - FSM para Inicializa¸c˜ao do Mote e controle geral 81 B.4 Aplica¸c˜ao 2 - FSM para gera¸c˜ao do alarme 81 B.5 Aplica¸c˜ao 2 - FSM para monitora¸c˜ao peri´odica 82 B.6 Aplica¸c˜ao 3 - FSM para Inicializa¸c˜ao do Mote e controle geral 82 B.7 Aplica¸c˜ao 3 - FSM para monitora¸c˜ao peri´odica 82 B.8 Aplica¸c˜ao 3 - FSM para reserva de vagas 83 C.1 M´odulos utilizados para execu¸c˜ao dos testes no simulador 92 Lista de tabelas 3.1 Padr˜oes de intera¸c˜ao identificados 24 3.2 Estrutura dos parˆametros de configura¸c˜ao 29 3.3 Campos de um registro da tabela de transi¸c˜oes 32 4.1 Principais a¸c˜oes e eventos dispon´ıveis para a aplica¸c˜ao 40 4.2 Biblioteca de fun¸c˜oes parametriz´aveis 43 4.3 Transi¸c˜oes utilizadas para o exemplo de fluxo 45 5.1 Primeiro Teste: Resultado para as m´etricas da implementa¸c˜ao no modelo proposto 59 5.2 Sumariza¸c˜ao da quantidade de mensagens enviadas para cada etapa e os respectivos contadores 60 5.3 Quantidade de mensagens enviadas para cada tipo de opera¸c˜ao 60 5.4 Primeiro Teste: Resultado para as m´etricas da implementa¸c˜ao alternativa em NesC 61 5.5 Segundo Teste: Resultado para as m´etricas da implementa¸c˜ao no modelo proposto 62 5.6 Quantidade de envios para a opera¸c˜ao de reconfigura¸c˜ao remota 62 5.7 Segundo Teste: Resultado para as m´etricas da implementa¸c˜ao alternativa em NesC 63 5.8 Resumo comparativo entre as duas implementa¸c˜oes 65 A.1 Distribui¸c˜ao dos Padr˜oes de intera¸c˜ao X Suporte de comunica¸c˜ao 73 A.2 Padr˜oes Identificados 74 B.1 Configura¸c˜ao da primeira FSM do primeiro teste 78 B.2 Configura¸c˜ao da segunda FSM do primeiro teste 79 B.3 Configura¸c˜ao da terceira FSM utilizada no segundo teste 79 B.4 Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 1 83 B.5 Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 2 84 B.6 Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 3 85 B.7 Aplica¸c˜ao 1 - M´aquina de estados 1 (Inicializa¸c˜ao) 86 B.8 Aplica¸c˜ao 1 - M´aquina de estados 2 (Alarme) 87 B.9 Aplica¸c˜ao 2 - M´aquina de estados 1 (Inicializa¸c˜ao) 88 B.10 Aplica¸c˜ao 2 - M´aquina de estados 2 (Alarme) 89 B.11 Aplica¸c˜ao 2 - M´aquina de estados 3 (Monitora¸c˜ao) 90 B.12 Aplica¸c˜ao 3 - M´aquina de estados 1 (Inicializa¸c˜ao) 90 B.13 Aplica¸c˜ao 3 - M´aquina de estados 2 (Monitora¸c˜ao) e 3 (Reserva) 91 D.1 Interfaces das Camadas Funcionais 94 D.2 Novos componentes NesC 96 2 TinyOS e NesC O framework de programa¸c˜ao mais utilizado em redes de sensores sem fio ´e composto pelo sistema operacional TinyOS [11] e pela linguagem de programa¸c˜ao NesC [12]. A linguagem NesC foi definida em resposta a alguns desafios encontrados na programa¸c˜ao em ambientes de redes de sensores sem fio. Para isso seu modelo seguiu alguns princ´ıpios, um deles ´e suportar o desenho do TinyOS. O TinyOS foi todo escrito em NesC e apresenta um modelo de execu¸c˜ao espec´ıfico para dispositivos de baixa potˆencia como os utilizados em redes de sensores sem fio. Apesar de NesC ser uma linguagem de programa¸c˜ao e TinyOS um sistema operacional, alguns dos seus objetivos se misturam e outros se complementam. Do ponto de vista do usu´ario, a programa¸c˜ao de uma aplica¸c˜ao ´e uma extens˜ao do sistema operacional. 2.1 NesC Seguem alguns dos principais desafios impostos `a linguagem NesC: – Ser orientado a intera¸c˜oes com o ambiente - as aplica¸c˜oes devem reagir a mudan¸cas do ambiente, como a leitura de um sensor, e estar preparadas para a concorrˆencia de atividades, como a chegada de um evento durante o processamento de dados; – Recursos limitados - Os motes tˆem recursos f´ısicos limitados devido aos objetivos de tamanho pequeno, baixo custo e baixo consumo de energia; – Confiabilidade - A aplica¸c˜ao deve funcionar por longos per´ıodos sem apresentar defeitos, por exemplo uma aplica¸c˜ao de monitora¸c˜ao ambiental deve funcionar meses sem intera¸c˜ao humana; – Flexibiliza¸c˜ao do requisito de tempo real - Apesar de algumas atividades serem cr´ıticas, como o gerenciamento do r´adio ou a amostragem dos sensores, a experiˆencia mostra que ´e poss´ıvel atingir essas restri¸c˜oes de tempo com um bom controle da aplica¸c˜ao e limitando o uso de recursos. A concep¸c˜ao de NesC utilizou os seguintes princ´ıpios b´asicos: Cap´ıtulo 2. TinyOS e NesC 17 – Ser uma extens˜ao de C - C produz c´odigo eficiente para todos os microcontroladores normalmente utilizados em dispositivos para redes de sensores sem fio; – Ser uma linguagem est´atica - N˜ao tem aloca¸c˜ao dinˆamica e o grafo de chamadas ´e conhecido em tempo de compila¸c˜ao, facilitando a an´alise citada no item anterior; – Suportar e refletir o desenho do TinyOS - Suporta os conceitos de TinyOS para componentes e concorrˆencia. Finalmente, o modelo de programa¸c˜ao de NesC exp˜oe ao usu´ario os seguintes itens: – Execu¸c˜ao orientada a eventos - As intera¸c˜oes internas `a aplica¸c˜ao utilizam comandos (actions) e fun¸c˜oes de retorno (signals); – Modelo flex´ıvel de concorrˆencia - provˆe ferramentas para postar tarefas (tasks) e controlar se¸c˜oes atˆomicas; – Desenho da aplica¸c˜ao orientado a componentes - utiliza um modelo de componentes onde os m´odulos (modules) implementam as interfaces dos componentes e as configura¸c˜oes (configurations) interligam os m´odulos. Na pr´atica um programa NesC ´e composto por um conjunto de componentes (modules) que implementam servi¸cos definidos por interfaces (interfaces). Esses componentes podem ser interligados (wired), via interfaces, pelas defini¸c˜oes dos arquivos de configura¸c˜oes (configurations). Esse modelo permite que se tenha diferentes implementa¸c˜oes para a mesma interface, onde o arquivo de configura¸c˜ao ´e que vai indicar qual ser´a a implementa¸c˜ao utilizada. Tudo isso facilita a defini¸c˜ao de aplica¸c˜oes para diferentes plataformas, necessitando somente criar novos componentes de acesso `a nova plataforma e manter a defini¸c˜ao da interface original. 2.2 TinyOS TinyOS procura atender algumas caracter´ısticas t´ıpicas das aplica¸c˜oes em rede de sensores sem fio que diferem das caracter´ısticas dos sistemas convencionais. Essas aplica¸c˜oes normalmente operam de forma autˆonoma por longo tempo, sendo feitas para coletar dados, responder a um ambiente imprevis´ıvel e s˜ao sem fio. Para endere¸car essas caracter´ısticas, TinyOS usa uma arquitetura baseada em componentes, um modelo de execu¸c˜ao baseado em eventos e tarefas e permite opera¸c˜oes em duas fases (split-phase). Cap´ıtulo 2. TinyOS e NesC 18 TinyOS provˆe um ambiente de desenvolvimento composto por uma biblioteca de componentes e algumas ferramentas que simplificam o procedimento de constru¸c˜ao de novas aplica¸c˜oes. Por se tratar de um sistema operacional para plataformas com recursos limitados, o TinyOS n˜ao funciona como um sistema operacional convencional, acima do qual se executam as aplica¸c˜oes do usu´ario, mas sim como uma biblioteca que deve ser ligada com essas aplica¸c˜oes para construir um ´unico programa execut´avel e que deve ser carregado em cada n´o sensor. Uma das principais caracter´ısticas do TinyOS ´e facilitar a utiliza¸c˜ao de diversas plataformas de hardware. A utiliza¸c˜ao do modelo de componentes de NesC possibilita grande modularidade, permitindo que o TinyOS contenha componentes prontos para acessar diferentes tipos de hardwares. A sele¸c˜ao dos componentes adequados para cada hardware ´e feita durante o processo de compila¸c˜ao e de forma transparente para o usu´ario. Uma outra caracter´ıstica importante que o TinyOS usa de NesC ´e o modelo orientado a eventos. Esse modelo segue o funcionamento natural das interfaces de hardware que normalmente integram esses dispositivos. Tamb´em possibilita uma opera¸c˜ao de baixo consumo de energia, pois o processamento s´o ocorre quando solicitado. Por exemplo, uma leitura de sensor deve disparar o conversor A/D que, depois de finalizada, deve retornar o valor lido. O programa que implementada essa opera¸c˜ao ´e quebrado em duas fases. Primeiro uma fun¸c˜ao ´e chamada para iniciar a convers˜ao, essa fun¸c˜ao tem retorno imediato. Quando a convers˜ao ´e finalizada, ´e disparada a execu¸c˜ao de uma fun¸c˜ao de callback que ent˜ao dever´a processar o resultado da leitura. Esse tipo de opera¸c˜ao, as vezes chamada de split-phase, ´e amplamente utilizada nos outros componentes como a interface de r´adio ou o temporizador interno. O modelo de execu¸c˜ao do TinyOS gerencia as tarefas (tasks) NesC numa fila de execu¸c˜ao para serem executadas oportunamente. As tarefas s˜ao executadas at´e o final e s´o podem ser interrompidas para execu¸c˜ao de uma fun¸c˜ao de tratamento de interrup¸c˜ao de hardware. Isso exclui poss´ıveis condi¸c˜oes de corrida entre tarefas, mas n˜ao exclui a possibilidade de acontecer com uma fun¸c˜ao de tratamento de interrup¸c˜ao de hardware. Para os casos em que possam acontecer condi¸c˜oes de corrida, sugere-se a quebra do c´odigo em tarefas, explicitando os pontos de poss´ıveis interferˆencias. Ainda assim, NesC permite marcar se¸c˜oes do c´odigo para execu¸c˜ao atˆomica. Durante a execu¸c˜ao de uma se¸c˜ao atˆomica, o sistema desliga as interrup¸c˜oes. Resumimos os principais pontos fortes do TinyOS em uma grande biblioteca de componentes para v´arios tipos de hardwares e em um c´odigo robusto e seguro, consequˆencia de cinco anos de amadurecimento do modelo, Cap´ıtulo 2. TinyOS e NesC 19 e utilizado por milhares de desenvolvedores. Como consequˆencia do modelo adotado no TinyOS, podemos identificar algumas dificuldades encontradas pelo programador: – Uma longa curva de aprendizado tanto para o modelo de programa¸c˜ao orientado a eventos (split-phase) quanto para o modelo de interface/- componentes do NesC. – A recomenda¸c˜ao de manter as tarefas curtas tamb´em aumenta a dificuldade para escrever programas que requerem computa¸c˜ao intensiva. – A manuten¸c˜ao da aplica¸c˜ao ap´os a implanta¸c˜ao em campo pode ser inviabilizada pela dificuldade de recuperar os motes para uma carga via cabo ou pelo custo de energia para carregar, remotamente via r´adio, todo o execut´avel. 2.2.1 Tecnologia O TinyOS pode ser executado em uma variedade de dispositivos que combinam diversos microcontroladores, chips de r´adios e de armazenamento. A referˆencia [13] apresenta uma lista com as caracter´ısticas de v´arios motes comerciais e prot´otipos, incluindo os suportados pelo TinyOS. Nessa lista o TinyOS ´e o sistema operacional mais utilizado, sendo utilizado por 60% dos motes. O processo de compila¸c˜ao no ambiente TinyOS ´e disparado pelo comando ncc que invoca o compilador NesC, que por sua vez invoca o compilador GCC. O comando ncc ´e espec´ıfico do TinyOS e converte alguns parˆametros para os dois procedimentos de compila¸c˜ao seguintes, selecionando tamb´em os componentes da biblioteca do TinyOS adequados ao hardware indicado. O compilador NesC - nescc - gera, a partir do c´odigo NesC do usu´ario e do TinyOS, um c´odigo C que cont´em o sistema operacional e a parte da aplica¸c˜ao do usu´ario. O compilador C - gcc - gera o c´odigo execut´avel. Nesse procedimento ´e indicado o microprocessador utilizado pelo hardware. Al´em das ferramentas para compila¸c˜ao e carga, o TinyOS disponibiliza a ferramenta TOSSIM[14] que permite a simula¸c˜ao de uma rede de n´os executando a aplica¸c˜ao do usu´ario. Para a execu¸c˜ao da simula¸c˜ao deve-se criar um script em Python ou um programa em C++ que, por meio de fun¸c˜oes da biblioteca do TOSSIM, ativam n´os e definem quais n´os podem se comunicar via r´adio. Cap´ıtulo 2. TinyOS e NesC 20 Principais funcionalidades As principais APIs oferecidas pelo TinyOS s˜ao Booting - Controla a inicializa¸c˜ao do componente; Communication - Implementa diversos protocolos como Single-hop, Multihop collection, Multihop dissemination e Binary reprogramming; Time - Suporte para cria¸c˜ao de temporizadores; Sensing - Suporte para acesso aos sensores; Storage - Suporte para acesso a FlashMemory; Data Structures - Suporte para Filas e Vetor de Bits; Utilities - Suporte para n´umeros randˆomicos, acesso aos Leds e c´alculo de CRC; LowPower - Suporte para opera¸c˜ao em baixa potˆencia. 3 O modelo de programa¸c˜ao proposto O modelo de programa¸c˜ao proposto utiliza como base um conjunto de funcionalidades b´asicas que podem ser combinadas por meio de um controle de fluxo baseado em m´aquinas de estados finitos (FSM). Conforme dito na se¸c˜ao 1.1, esse conjunto de funcionalidades representa padr˜oes de intera¸c˜ao t´ıpicos de aplica¸c˜oes para RSSF. Podemos dizer que os padr˜oes de intera¸c˜ao est˜ao no n´ıvel da execu¸c˜ao de uma linguagem de macroprograma¸c˜ao em RSSF citado na se¸c˜ao 1.3, enquanto que o conjunto de funcionalidades b´asicas equivalem ao n´ıvel de uma linguagem que ´e executada em cada mote. Esse conjunto de funcionalidades b´asicas pode ser visto como uma biblioteca de a¸c˜oes e eventos. Com isso o controle de fluxo da m´aquina de estado pode comandar a¸c˜oes e reagir a eventos dessa biblioteca. Para completar o nosso modelo de programa¸c˜ao, possibilitamos que o comportamento de algumas funcionalidades b´asicas possa ser configurado por meio de parˆametros. Nas pr´oximas se¸c˜oes vamos, primeiramente, apresentar o nosso conjunto de padr˜oes de intera¸c˜ao e a respectiva biblioteca de fun¸c˜oes. Em seguida vamos descrever o funcionamento do controle de fluxo baseado em FSM para depois apresentar um pequeno exemplo de utiliza¸c˜ao do nosso modelo. 3.1 Padr˜oes de intera¸c˜ao para aplica¸c˜oes em RSSF Entendemos que o requisito de facilidade de programa¸c˜ao depende diretamente do conjunto de padr˜oes de intera¸c˜ao proposto. Esses padr˜oes de intera¸c˜ao devem representar funcionalidades gen´ericas e ao mesmo tempo devem ser suficientemente expressivos para poder atender diferentes tipos de aplica¸c˜oes em RSSF, i.e., deve ser poss´ıvel construir diversas aplica¸c˜oes a partir da combina¸c˜ao desses padr˜oes. Optamos por consolidar a lista de padr˜oes de intera¸c˜ao a serem oferecidos a partir da an´alise de duas diferentes fontes de informa¸c˜ao. A primeira fonte foi um conjunto de aplica¸c˜oes encontradas na literatura e a segunda fonte foi a demanda gerada pelos modelos de macroprograma¸c˜ao. Os modelos de macroprograma¸c˜ao considerados foram analisados em [15]. Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 22 A seguir apresentamos cada fonte analisada e o resultado final com a lista consolidada. No apˆendice A apresentamos, com mais detalhes, o procedimento utilizado e os padr˜oes identificados para cada fonte. 3.1.1 Opera¸c˜oes t´ıpicas das aplica¸c˜oes em RSSF Para identificar as opera¸c˜oes t´ıpicas das aplica¸c˜oes escolhemos trˆes aplica¸c˜oes para RSSF com diferentes comportamentos funcionais. Essas aplica¸c˜oes foram inspiradas em alguns exemplos retirados da literatura sobre RSSF, principalmente de [2], [16] e [17]. A partir das opera¸c˜oes necess´arias para cada aplica¸c˜ao foi poss´ıvel identificar alguns padr˜oes de intera¸c˜ao. A seguir apresentamos cada aplica¸c˜ao. Aplica¸c˜ao 1 - Alarme de incˆendio florestal O objetivo da aplica¸c˜ao ´e detectar rapidamente focos de incˆendio em florestas. Para isso os sensores s˜ao distribu´ıdos em regi˜oes da floresta de forma que se possa identificar a regi˜ao do alarme. Os n´os ficam executando periodicamente uma leitura do sensor de temperatura. Caso um n´o detecte uma leitura de temperatura maior que um valor predefinido, este deve verificar se as temperaturas dos n´os vizinhos est˜ao pr´oximas da temperatura de alarme. A condi¸c˜ao de alarme ser´a confirmada se pelo menos dois n´os vizinhos estiverem com o valor de temperatura maior que um valor percentual do valor de alarme. Nesse caso ser´a enviada uma mensagem para a esta¸c˜ao servidora. Essa mensagem deve conter a temperatura medida e o identificador do n´o. O n´o ativado deve notificar os n´os vizinhos que um alarme j´a foi enviado. Um n´o s´o pode gerar um novo alarme para sua regi˜ao caso j´a tenham se passado pelo menos 60 minutos da ´ultima notifica¸c˜ao de alarme. Aplica¸c˜ao 2 - Monitor de temperatura e Alarme de incˆendio predial Essa aplica¸c˜ao usa um conjunto de sensores com capacidade de leitura de temperatura com duplo objetivo: monitorar a temperatura m´edia dos ambientes do pr´edio (controle do conforto ambiental) e gerar alarmes em caso de incˆendio. Os n´os s˜ao distribu´ıdos pelo edif´ıcio e cada ambiente define um grupo de n´os. Para a monitora¸c˜ao, cada n´o faz uma leitura peri´odica do sensor de temperatura e envia o valor para o coordenador do grupo. O coordenador do grupo calcula a m´edia das temperaturas de todos os n´os do grupo, e, em seguida, envia para a central de controle uma mensagem com o valor calculado. Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 23 Uma outra leitura peri´odica ´e usada para o alarme de incˆendio. Se o valor estiver acima do valor de alarme predefinido, o n´o deve consultar os n´os vizinhos do mesmo grupo e verificar quantos n´os est˜ao com valores acima de 90% do valor de alarme. Independentemente dos valores respondidos, o n´o ativo deve enviar uma mensagem de alarme com o quorum da consulta para a central de controle. Sempre que um alarme ´e gerado, o n´o ativado deve notificar os n´os vizinhos que esse alarme j´a foi enviado. Um n´o s´o pode gerar um novo alarme para seu ambiente caso j´a tenha passado pelo menos um minuto da ´ultima notifica¸c˜ao de alarme. Aplica¸c˜ao 3 - Estacionamento urbano e Monitora¸c˜ao de vagas Essa aplica¸c˜ao auxilia motoristas na reserva de uma vaga de estacionamento. Tamb´em informa para uma central de controle a situa¸c˜ao das vagas em cada regi˜ao. Para isso usa um conjunto de sensores distribu´ıdos pelas vagas de estacionamento da rua. Esses sensores indicam se a vaga est´a ocupada ou n˜ao. Os n´os sensores s˜ao agrupados por regi˜ao (CEP, bairro ou Rua). Para a busca de vagas, o ve´ıculo, tamb´em equipado com um n´o sem fio, envia uma mensagem para os n´os vizinhos solicitando a reserva de uma vaga dispon´ıvel. Todos os n´os respondem com a situa¸c˜ao da respectiva vaga e os n´os com vaga n˜ao ocupada fazem uma pr´e-reserva com a identifica¸c˜ao do n´o solicitante. O n´o solicitante seleciona um dos n´os dispon´ıveis e responde para os vizinhos a sua escolha, de forma a confirmar a vaga selecionada e liberar o restante das vagas. Ent˜ao o n´o selecionado responde a confirma¸c˜ao da sele¸c˜ao para o n´o solicitante. Se ocorrer a situa¸c˜ao de mais de uma solicita¸c˜ao durante o processo de negocia¸c˜ao, os n´os das vagas dispon´ıveis devem responder de acordo com a ordem do recebimento. Na monitora¸c˜ao, cada n´o envia periodicamente para o n´o coordenador do grupo a informa¸c˜ao da sua vaga. O n´o coordenador sumariza a situa¸c˜ao da regi˜ao e envia uma mensagem com os contadores de vagas para a central de controle. 3.1.2 Elementos utilizados nos modelos de macroprograma¸c˜ao Os modelos de macroprograma¸c˜ao s˜ao uma fonte natural para identifica¸c˜ao dos padr˜oes de intera¸c˜ao de interesse. No nosso caso analisamos os modelos de macroprograma¸c˜ao apresentados em [15]: Regiment[2, 18]; Pleiades[17]; Cosmos[3]; TinyDB[1]; WADL[16]; ATaG[19]. Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 24 Os principais padr˜oes encontrados foram relativos `a comunica¸c˜ao. Identificamos padr˜oes para diferentes forma¸c˜oes de grupos de n´os e a possibilidade de aplicar fun¸c˜oes agregadoras nesses grupos. Tamb´em identificamos padr˜oes para comunica¸c˜ao com a esta¸c˜ao servidora. 3.1.3 Padr˜oes de intera¸c˜ao identificados Na Tabela 3.1 apresentamos o resultado final da consolida¸c˜ao para os padr˜oes de intera¸c˜ao. No apˆendice A apresentamos com mais detalhes a an´alise utilizada para a identifica¸c˜ao e consolida¸c˜ao dos padr˜oes. Tabela 3.1: Padr˜oes de intera¸c˜ao identificados Elemento Descri¸c˜ao Grupo: Comunica¸c˜ao Envia EB Envia uma mensagem do n´o em execu¸c˜ao para a Esta¸c˜ao Servidora. Envia N´o Envia uma mensagem do n´o em execu¸c˜ao para um n´o espec´ıfico dentro do grupo. Envia Pai Envia uma mensagem do n´o em execu¸c˜ao para o n´o Pai na hierarquia topol´ogica. Envia Filhos Envia uma mensagem do n´o em execu¸c˜ao para os n´os Filhos na hierarquia topol´ogica. Grupo: Fun¸c˜oes de agrega¸c˜ao M´edia Grupo Calcula o valor m´edio de valores distribu´ıdos pelos n´os do grupo. Somat´orio Grupo Calcula a soma de valores distribu´ıdos pelos n´os do grupo. M´aximo Grupo Calcula o valor m´aximo dentre os valores distribu´ıdos pelos n´os do grupo. M´ınimo Grupo Calcula o valor m´ınimo dentre os valores distribu´ıdos pelos n´os do grupo. Sum´ario Grupo Sumariza os estados dos n´os distribu´ıdos num grupo. Reserva Recurso Grupo Reserva de um determinado recurso dos n´os do grupo. Baseado na negocia¸c˜ao entre o n´o ativo e o n´os do grupo. Agrega Grupo Gera um vetor de dados com os respectivos valores dos n´os de um grupo. Grupo: Fun¸c˜oes Locais Evento Timer Configura um temporizador para execu¸c˜ao de um procedimento. Evento Condi¸c˜ao de leitura sensor Configura uma condi¸c˜ao de leitura de sensor para execu¸c˜ao de um procedimento. Evento Condi¸c˜ao de c´alculo de agrega¸c˜ao Configura uma condi¸c˜ao de um c´alculo de agrega¸c˜ao para execu¸c˜ao de um procedimento. Continua na pr´oxima p´agina. . . Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 25 Tabela 3.1: Padr˜oes de intera¸c˜ao – continua¸c˜ao Elemento Descri¸c˜ao Evento Condi¸c˜ao de mensagem recebida Configura uma condi¸c˜ao de um c´odigo de mensagem recebida para execu¸c˜ao de um procedimento. Grupo: Agrupamentos Vizinhos 1-hop Define um grupo de n´os vizinhos do n´o em execu¸c˜ao ao alcance do sinal de r´adio. Implementado com mensagem broadcast. Vizinhos n-hops Define um grupo de n´os vizinhos do n´o em execu¸c˜ao ao alcance de at´e nsaltos. Implementado com mensagem broadcast e subsequentes reencaminhamentos de mensagens pelos n´os vizinhos. Parˆametros Est´aticos Define um grupo de n´os da rede que atendam uma determinada condi¸c˜ao que n˜ao varia no tempo. Parˆametros Dinˆamicos Define um grupo de n´os da rede que atendam uma determinada condi¸c˜ao que pode variar no tempo. Filhos Define um grupo de n´os imediatamente abaixo na hierarquia topol´ogica da rede. Filhos ncamadas Define um grupo de n´os imediatamente abaixo ncamadas na hierarquia topol´ogica da rede. Rede Define o grupo de todos os n´os da rede. 3.2 Conjunto das funcionalidades b´asicas Nessa se¸c˜ao vamos identificar e detalhar o conjunto das fun¸c˜oes oferecidas para disponibilizar os padr˜oes de intera¸c˜ao identificados. Na pr´oxima subse¸c˜ao (3.2.1), apresentamos a arquitetura proposta com a abordagem que estamos considerando para a implementa¸c˜ao da nossa biblioteca. Na subse¸c˜ao 3.2.2, discutimos as opera¸c˜oes que dependem da comunica¸c˜ao na rede. Em seguida, na subse¸c˜ao 3.2.3, propomos um conjunto de parˆametros que permitem a simplifica¸c˜ao da quantidade de fun¸c˜oes e ao mesmo tempo facilitam a implementa¸c˜ao do procedimento de reconfigura¸c˜ao remota. Finalmente apresentamos a biblioteca de fun¸c˜oes na se¸c˜ao 3.2.4. 3.2.1 Arquitetura da biblioteca de fun¸c˜oes Para uma melhor identifica¸c˜ao das fun¸c˜oes, utilizamos uma arquitetura em camadas. Essa arquitetura divide as funcionalidades b´asicas em diferentes fun¸c˜oes, mas que colaboram entre si para atender aos requisitos dos padr˜oes de intera¸c˜ao. Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 32 Figura 3.4: Sintaxe FSM e exemplo de tabela de transi¸c˜oes Tabela 3.3: Campos de um registro da tabela de transi¸c˜oes Campo bits Descri¸c˜ao MachineID 3 Id da m´aquina CurrState 5 Estado corrente ParentMachine 3 Id da m´aquina “pai” ParentState 5 Estado corrente da m´aquina “pai” Event 6 Evento Action 5 A¸c˜ao NewState 5 Novo estado A defini¸c˜ao dos estados ´e livre e de responsabilidade do desenvolvedor, mas as poss´ıveis a¸c˜oes e eventos dependem dos componentes disponibilizados no sistema. A quantidade de estados depende da aplica¸c˜ao. Por exemplo, uma aplica¸c˜ao para coleta de temperatura de cada n´o s´o precisa de trˆes estados: aguardando disparo da coleta, aguardando leitura do sensor e aguardando envio de dados. Uma aplica¸c˜ao de alarme vai precisar de quatro estados: aguardando disparo da monitora¸c˜ao, aguardando leitura do sensor, aguardando resultado do teste de alarme e aguardando envio de dados. 3.4 Exemplo simplificado de aplica¸c˜ao do modelo de programa¸c˜ao Na Figura 3.5 apresentamos um exemplo simplificado do nosso modelo de programa¸c˜ao para uma aplica¸c˜ao de coleta peri´odica de temperatura. Essa aplica¸c˜ao envia periodicamente para a esta¸c˜ao base o valor do sensor de temperatura. A solu¸c˜ao utilizou o temporizador peri´odico, o sensor de temperatura e o servi¸co para envio da dados para a esta¸c˜ao base. Por meio de parˆametros, Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 33 definimos o per´ıodo de 10 minutos para o temporizador e indicamos a utiliza¸c˜ao do sensor de temperatura. Figura 3.5: Aplica¸c˜ao exemplo - coleta peri´odica de temperatura A m´aquina de estados cont´em trˆes estados. O estado Waiting Timer que fica aguardando um evento do temporizador peri´odico -PeriodicTimer0. O estado Reading sensor que aguarda um evento de leitura do sensor - sensorDone. O estado Sending que aguarda um evento de envio finalizado -sendDone. As a¸c˜oes consideradas s˜ao readSensor para leitura do sensor e sendData para envio da temperatura para a esta¸c˜ao base. No nosso exemplo o sensor configurado ´e o de temperatura. No cap´ıtulo 5 e no apˆendice B apresentamos a utiliza¸c˜ao do nosso modelo para aplica¸c˜oes mais complexas. 3.5 Reconfigura¸c˜ao O nosso modelo de programa¸c˜ao trata a tabela de transi¸c˜oes da FSM de forma equivalente a um interpretador restrito, permitindo, dessa forma, certo grau de reconfigura¸c˜ao dinˆamica. Adicionalmente os parˆametros de configura¸c˜ao dos componentes tamb´em contribuem para a reconfigura¸c˜ao dinˆamica. A reconfigura¸c˜ao de uma aplica¸c˜ao ´e obtida com o envio de dois tipos de tabelas para cada dispositivo. O primeiro tipo acomoda as transi¸c˜oes da FSM que ´e disseminada igualmente para toda rede. O segundo tipo acomoda os parˆametros de configura¸c˜ao dos componentes que s˜ao aplicados individualmente para cada n´o. Cap´ıtulo 3. O modelo de programa¸c˜ao proposto 34 A vers˜ao atual do protocolo de controle de reconfigura¸c˜ao suspende a execu¸c˜ao da aplica¸c˜ao em cada n´o durante uma reconfigura¸c˜ao. O nosso protocolo de controle utiliza um protocolo de dissemina¸c˜ao que privilegia a convergˆencia da dissemina¸c˜ao, mas n˜ao garante o sincronismo da mesma. Essa vers˜ao do protocolo de controle n˜ao tem a inten¸c˜ao de prevenir poss´ıveis inconsistˆencias na execu¸c˜ao concorrente entre n´os com diferentes vers˜oes. 4 Implementa¸c˜ao Neste cap´ıtulo vamos apresentar nossa implementa¸c˜ao para um sistema que suporta a biblioteca de fun¸c˜oes parametriz´aveis e a engrenagem da FSM definidas no cap´ıtulo 3. Vamos apresentar na se¸c˜ao 4.1 uma vis˜ao geral para a arquitetura de execu¸c˜ao e os protocolos b´asicos de comunica¸c˜ao. Em seguida, na se¸c˜ao 4.2, abordaremos a nossa implementa¸c˜ao atrav´es de diferentes opera¸c˜oes na rede de sensores sem fio. Na se¸c˜ao 4.3 vamos apresentar o padr˜ao de implementa¸c˜ao utilizado no nosso modelo de camadas. Para exemplificar o uso do modelo e a respectiva implementa¸c˜ao, vamos descrever o fluxo de execu¸c˜ao de uma opera¸c˜ao simples de agrega¸c˜ao. No final do cap´ıtulo, discutimos a nossa experiˆencia no desenvolvimento do sistema utilizando o TinyOS/NesC e abordarmos o procedimento para adicionar novos eventos e a¸c˜oes. 4.1 Vis˜ao operacional geral De forma geral, a opera¸c˜ao das aplica¸c˜oes em rede de sensores sem fio assume a existˆencia de uma esta¸c˜ao servidora para recebimento de informa¸c˜oes coletadas. A nossa arquitetura considera que esta esta¸c˜ao servidora tamb´em ser´a usada para gerenciar as opera¸c˜oes de reconfigura¸c˜ao da aplica¸c˜ao. Executamos na esta¸c˜ao servidora um processo JAVA para controle das opera¸c˜oes e troca de mensagens com a rede de sensores sem fio. Essa troca de mensagens utiliza um mote especial conectado com a esta¸c˜ao servidora via interface serial (USB) e que acessa a rede de sensores via r´adio. Esse mote ´e chamado de esta¸c˜ao base (Base Station). A nossa implementa¸c˜ao considera que o mesmo c´odigo execut´avel ser´a executado em todos os motes da rede. A diferen¸ca de comportamento ´e definido com a carga dos parˆametros de configura¸c˜ao e da tabela de transi¸c˜oes da FSM. A informa¸c˜ao a ser carregada no mote ´e armazenada na esta¸c˜ao servidora no formato de arquivo XML. Na Figura 4.1, temos o diagrama com os m´odulos utilizados no servidor. Cap´ıtulo 4. Implementa¸c˜ao 36 Figura 4.1: M´odulos utilizados na esta¸c˜ao servidora Os testes mais exaustivos e monitorados foram executados num ambiente simulado baseado na ferramenta TOSSIM[14]. Para realiza-los foi necess´ario construir, al´em do nosso sistema e do m´odulo de controle em JAVA, alguns m´odulos auxiliares. Esses m´odulos est˜ao descritos no apˆendice C. 4.1.1 Protocolos de comunica¸c˜ao A comunica¸c˜ao entre os motes ´e a base para as principais opera¸c˜oes nas redes de sensores sem fio. Normalmente as aplica¸c˜oes necessitam de alguma intera¸c˜ao entre motes vizinhos e na maioria das vezes ´e necess´ario encaminhar alguma informa¸c˜ao para a esta¸c˜ao servidora. A implementa¸c˜ao dos protocolos de comunica¸c˜ao ´e parte fundamental do nosso modelo de programa¸c˜ao, pois ´e onde implementamos as fun¸c˜oes b´asicas para a maior parte das simplifica¸c˜oes oferecidas. A partir da an´alise do cap´ıtulo 3, implementamos protocolos para roteamento de mensagens, dissemina¸c˜ao de dados e forma¸c˜ao de grupos de n´os. O foco principal no nosso trabalho n˜ao ´e a implementa¸c˜ao da melhor solu¸c˜ao de comunica¸c˜ao. Ent˜ao optamos por simplificar ao m´aximo o trabalho de implementa¸c˜ao e procuramos utilizar recursos j´a implementados no TinyOS. Para isso utilizamos os protocolos de dissemina¸c˜ao de dados DIP [20] e o de coleta de dados CTP [21]. Troca de mensagens entre a rede e a esta¸c˜ao servidora O roteamento de/para a esta¸c˜ao base foi implementado utilizando uma adapta¸c˜ao do protocolo CTP-Collection Tree Protocol [21]. O CTP disponibiliza uma interface para envio de mensagens de qualquer n´o da rede para um n´o definido como n´o raiz. Esse processo de roteamento ´e transparente ao usu´ario do protocolo. Na inicializa¸c˜ao do CTP s˜ao trocadas mensagens espec´ıficas entre os motes para definir, com base na intensidade do sinal de r´adio, quais Cap´ıtulo 4. Implementa¸c˜ao 37 motes ser˜ao os n´os roteadores. No nosso caso o mote esta¸c˜ao base funciona como n´o raiz da hierarquia para o protocolo de coleta. Como o CTP s´o resolve o roteamento no sentido da rede para a esta¸c˜ao base, implementamos uma extens˜ao que permite o roteamento no sentido inverso. Com o intuito de reduzir a utiliza¸c˜ao de mem´oria RAM do mote, a nossa extens˜ao assume que o processo de roteamento sempre ´e disparado de um n´o da rede para a esta¸c˜ao base, quando ent˜ao, uma resposta, poder´a ser roteada no sentido inverso. Isso permite trabalharmos com um tabela m´ınima de roteamento, onde s´o s˜ao armazenadas as informa¸c˜oes das ´ultimas solicita¸c˜oes. Utilizamos a implementa¸c˜ao do CTP para rotear a mensagem de solicita¸c˜ao at´e o n´o raiz e implementamos uma interface para o envio de mensagens no sentido inverso. A nossa extens˜ao intercepta o CTP e registra em cada n´o roteador as informa¸c˜oes necess´arias para efetuar o roteamento de retorno. Dissemina¸c˜ao da tabela FSM A dissemina¸c˜ao da FSM pela rede foi implementada utilizando o protocolo DIP[20]. O DIP dissemina automaticamente um pequena quantidade de dados pela rede de sensores sem fio, garantindo a entrega da informa¸c˜ao. Como existe um limite na quantidade de dados em uma mensagem via r´adio, tivemos que executar essa distribui¸c˜ao em v´arias partes. O sistema atual est´a preparado para uma tabela FSM com no m´aximo 40 transi¸c˜oes. Essa tabela ´e sempre difundida com 5 blocos/mensagens, sendo que n˜ao ´e garantida a sequˆencia da entrega. O processo de dissemina¸c˜ao mant´em um controle de vers˜ao para a tabela FSM. Esse controle de vers˜ao permite identificar o in´ıcio de uma nova dissemina¸c˜ao com a chegada do primeiro bloco do DIP. O final da dissemina¸c˜ao ´e identificado quando todos blocos estiverem com a nova vers˜ao. Forma¸c˜ao de grupos de n´os (NHops) O protocolo de forma¸c˜ao de grupo de motes (NHops) foi implementado utilizando a fun¸c˜ao b´asica de comunica¸c˜ao do TinyOS Active Message(AM). Essa fun¸c˜ao permite o envio de uma mensagem para um n´o espec´ıfico ao alcance do r´adio (1-hop) ou o envio de uma mensagem broadcast para todos os n´os vizinhos ao alcance do r´adio. A forma¸c˜ao do grupo ´e feita por meio da difus˜ao de uma mensagem broadcast que se propaga por uma quantidade predefinida de saltos (hops). Quando receber uma mensagem desse tipo, o mote verifica o contador de saltos e, se necess´ario, reenvia a mensagem incrementando esse contador. Essa mensagem tem um identificador ´unico composto por um n´umero sequencial e o ID do mote origem. Tamb´em carrega alguns parˆametros, como Cap´ıtulo 4. Implementa¸c˜ao 38 o ID do mote que repassou a mensagem, a quantidade m´axima de saltos, a quantidade de saltos atual, a informa¸c˜ao requisitada e o identificador do grupo. Cada mote s´o considera v´alida a primeira mensagem recebida para cada identifica¸c˜ao ´unica (Sequencial + IdOrigem), e ao recebˆe-la registra esses valores em uma lista. Isso permite a cria¸c˜ao da rota de retorno para o mote que iniciou o processo de difus˜ao. Para cada pedido recebido, caso o mote fa¸ca parte do mesmo grupo do n´o originador, o mote retorna o valor solicitado utilizando a informa¸c˜ao de roteamento. Um n´o intermedi´ario, mesmo que n˜ao fa¸ca parte do grupo identificado na mensagem, deve rotear a mensagem de retorno. A seguir, apresentamos uma vis˜ao resumida do pseudo-c´odigo do nosso algoritmo para forma¸c˜ao do grupo. Todos os n´os executam o mesmo c´odigo. O processo ´e iniciado com a execu¸c˜ao do procedimento RequestValues() em um dos n´os do grupo. RequestValues(ReqNum): Enviar mensagem broadcast NHops. Recebimento da msg NHops: Se sequencial j´a recebido ou a msg ´e sua, ent~ao descartar msg e retornar. Fazer n´o pai igual ao n´o origem. Se n~ao alcan¸cou limite de saltos, ent~ao enviar a mensagem broadcast NHops. Se n~ao for do mesmo grupo, ent~ao descartar msg e retornar. Executar a leitura do sensor identificado pela mensagem. Enviar mensagem NHopsReturn para o n´o pai. Recebimento da msg NHopsReturn: Se a msg for para mim, ent~ao encaminhar para a aplica¸c~ao o valor recebido; sen~ao encaminhar a msg para o n´o pai. A implementa¸c˜ao atual utiliza duas filas de eventos, uma de sa´ıda e outra de entrada. Essas filas permitem a concorrˆencia entre diferentes opera¸c˜oes e ao mesmo tempo compatibilizam o c´odigo com o modelo split-phase de nesC/TinyOS. Cap´ıtulo 4. Implementa¸c˜ao 39 4.2 Etapas de opera¸c˜ao Para a implementa¸c˜ao do sistema atual, identificamos um conjunto de opera¸c˜oes necess´arias para o funcionamento completo de uma aplica¸c˜ao na rede de sensores sem fio. Descrevemos a implanta¸c˜ao de uma aplica¸c˜ao considerando que ela ocorre em trˆes etapas: Inicializa¸c˜ao, Configura¸c˜ao e Execu¸c˜ao da Aplica¸c˜ao. Opcionalmente temos ainda uma etapa de Elei¸c˜ao. A seguir descrevemos essas etapas. 4.2.1 Etapa: Inicializa¸c˜ao Essa etapa ´e respons´avel pela inicializa¸c˜ao da rede de sensores sem fio. Tem como principais fun¸c˜oes a inicializa¸c˜ao interna (local) do mote e a forma¸c˜ao da topologia hier´arquica para o protocolo de coleta CTP. A inicializa¸c˜ao do mote ´e equivalente a um procedimento de “boot”, onde o TinyOS e os componentes do sistema s˜ao inicializados. O c´odigo execut´avel do nosso sistema ´e o mesmo em todos os motes, ent˜ao ´e necess´ario inicializar o mote conforme os parˆametros de configura¸c˜ao e a tabelas FSM previamente carregados. Para formar a topologia hier´arquica do CTP, os n´os trocam mensagens entre si, identificando as rotas mais curtas para alcan¸car o n´o raiz, isto ´e, identificando em cada mote quem ´e o mote imediato na hierarquia (mote pai). O nosso sistema requer, independentemente do tipo de aplica¸c˜ao, uma m´aquina de estados m´ınima para controle da inicializa¸c˜ao do mote. Essa m´aquina pode ter seu uso estendido para a aplica¸c˜ao do usu´ario. 4.2.2 Etapa: Configura¸c˜ao Essa etapa implementa o controle da reconfigura¸c˜ao remota em duas fases. Primeiro uma ´unica tabela FSM ´e disseminada e depois s˜ao enviados os parˆametros individuais de cada mote. O processo de configura¸c˜ao inicia a partir da esta¸c˜ao servidora, que carrega os dados da tabela FSM na esta¸c˜ao base. Esses dados s˜ao distribu´ıdos para todos os motes da rede pelo protocolo de dissemina¸c˜ao DIP. Quando um mote recebe a primeira notifica¸c˜ao da dissemina¸c˜ao, imediatamente suspende a execu¸c˜ao da aplica¸c˜ao do usu´ario. Cada mote, ao completar o recebimento da tabela, solicita ao servidor os seus parˆametros individuais de configura¸c˜ao atrav´es de um protocolo de comunica¸c˜ao para carga de parˆametros. A estrutura de dados dos parˆametros de Cap´ıtulo 4. Implementa¸c˜ao 40 configura¸c˜ao est´a dividida em quatro mensagens. Nesse protocolo o mote envia uma mensagem solicitando um bloco de parˆametros e aguarda a esta¸c˜ao servidora enviar os dados. Ao receber uma mensagem com parte dos parˆametros, o mote solicita o pr´oximo bloco. Se ap´os um tempo o mote n˜ao receber os dados, ele reenvia a mesma solicita¸c˜ao. Ao final da carga dos parˆametros, o mote libera a execu¸c˜ao da aplica¸c˜ao do usu´ario, agora com a nova configura¸c˜ao. 4.2.3 Etapa: Execu¸c˜ao da Aplica¸c˜ao Uma execu¸c˜ao sempre deve ser iniciada por um evento. Normalmente esse evento ´e o disparo de um temporizador peri´odico. A partir desse evento, pode-se disparar a¸c˜oes que retornam outros eventos. A sequˆencia entre eventos e a¸c˜oes s˜ao definidas pela tabela de transi¸c˜oes da FSM da aplica¸c˜ao. O comportamento das a¸c˜oes ´e definido pelos parˆametros. As principais a¸c˜oes e eventos dispon´ıveis na nossa biblioteca est˜ao definidos na Tabela 4.1. Tabela 4.1: Principais a¸c˜oes e eventos dispon´ıveis para a aplica¸c˜ao Componente A¸c˜ao Evento Timer Peri´odico – Disparo para uma nova Coleta (TimerFired) Sensor Local Iniciar leitura (readSensor()) Resultado da leitura (sensorDone) Comparar resultado com parˆametro (testValue()) Resultado da compara¸c˜ao (testValueDone) Mote Infos Verificar se ´e coordenador (testCoord()) Resultado da verifica¸c˜ao (testCoordDone) Agrega¸c˜ao Disparar a agrega¸c˜ao indicada nos parˆametros (startAggreg()) Resultado da agrega¸c˜ao (AggregDone) Timer customizado Iniciar contagem (startTimerX()) Timer finalizado (timerXFired) Comunica¸c˜ao Enviar comando para os motes do mesmo grupo (sendComm()) Recebimento de comando de outro mote (recComm) Enviar dados para o servidor (sendBS()) Confirma¸c˜ao do envio (sendDone) A implementa¸c˜ao atual permite a configura¸c˜ao de at´e trˆes opera¸c˜oes de coleta simultˆaneas, que denominamos de Coleta 1, Coleta 2 e Coleta 3. Para isso disponibiliza trˆes conjuntos de parˆametros que tornam poss´ıvel configurar de forma independentes essas opera¸c˜oes, incluindo o temporizador peri´odico. Com isso ´e poss´ıvel definir diferentes m´aquinas de estados para cada opera¸c˜ao de coleta com diferentes per´ıodos. Por exemplo, a Coleta 1 pode enviar a cada Cap´ıtulo 4. Implementa¸c˜ao 41 30 minutos o valor m´edio da temperatura de um grupo de n´os, enquanto que a coleta 2 pode monitorar a cada 5 segundos a temperatura para gerar um alarme de incˆendio. Apesar de permitirmos o disparo de at´e trˆes temporizadores, o sistema s´o executa uma opera¸c˜ao de coleta de cada vez. Para n˜ao perdermos poss´ıveis disparos concorrentes, implementamos uma fila de tarefas e transferimos para a FSM da aplica¸c˜ao a responsabilidade de buscar a pr´oxima tarefa ao final da execu¸c˜ao da tarefa corrente. Basta a FSM executar a a¸c˜ao “endCollection()” ao final de uma opera¸c˜ao de coleta e esperar o evento “nextColl” para iniciar uma nova coleta. A execu¸c˜ao da aplica¸c˜ao pode utilizar dois tipos de protocolos de comunica¸c˜ao. O principal ´e o protocolo NHops, que ´e utilizado em todas opera¸c˜oes que requerem comunica¸c˜ao entre os motes do mesmo grupo. O outro protocolo utilizado ´e o de envio de dados para a esta¸c˜ao servidora. 4.2.4 Etapa opcional: Elei¸c˜ao O processo de elei¸c˜ao de coordenador de grupo ´e opcional e deve ser configurado explicitamente. Quando configurado, ´e disparado automaticamente ap´os a etapa de inicializa¸c˜ao do mote. Caso ainda n˜ao exista um mote eleito para o grupo, ´e executada uma elei¸c˜ao completa. Caso exista um coordenador, esse ser´a informado ao mote rec´em inicializado. A implementa¸c˜ao atual elege o mote com mais energia (voltagem da bateria). Pode-se definir o per´ıodo em que o mote coordenador deve solicitar uma nova elei¸c˜ao, dessa forma permitindo o revezamento dos motes coordenadores. A reelei¸c˜ao do mote com mais energia permite uma melhor distribui¸c˜ao do uso de energia na rede de sensores sem fio. Podemos dividir o protocolo de elei¸c˜ao em fases. Na primeira fase um mote sem coordenador solicita aos motes do mesmo grupo quem ´e o coordenador atual. Se o mote receber uma mensagem de retorno indicando o coordenador, o processo ´e interrompido e o mote armazena o ID do coordenador. Se o mote n˜ao receber um retorno, ent˜ao dispara a segunda fase. Na segunda fase, um mote sem coordenador envia, para os motes do mesmo grupo, uma mensagem solicitando o in´ıcio de uma elei¸c˜ao. Cada mote deve responder ao mote solicitante o seu voto com o respectivo valor de voltagem da bateria. O mote solicitante identifica qual ´e o mote do grupo com maior voltagem e, em seguida, informa a este mote que ele dever´a ser o novo coordenador. O novo coordenador deve informar aos demais elementos do grupo que ele ser´a o novo coordenador. Para o caso em que mais de um Cap´ıtulo 4. Implementa¸c˜ao 48 4.5.1 Experiˆencias no desenvolvimento O processo inicial de desenvolvimento foi feito utilizando somente o ambiente simulado do TOSSIM. Esse ambiente n˜ao limita a mem´oria utilizada pela aplica¸c˜ao. Inicialmente, assumimos uma linha de implementa¸c˜ao que permitia grande flexibilidade na opera¸c˜ao da aplica¸c˜ao. Como exemplo de flexibilidade temos a execu¸c˜ao de mais de uma opera¸c˜ao de agrega¸c˜ao disparada simultaneamente no mesmo mote. Para isso a nossa implementa¸c˜ao utilizou v´arias filas de dados como forma de isolar as camadas funcionais e permitir o processamento concorrente entre diferentes opera¸c˜oes de coleta. A utiliza¸c˜ao dessas filas tamb´em permitiu que uma a¸c˜ao fosse dividida em v´arias partes. Possibilitando dessa forma atender um requisito do modelo de execu¸c˜ao do TinyOS que recomenda a quebra do c´odigo em pequenas atividades. Com a linha adotada no in´ıcio da implementa¸c˜ao somada `a caracter´ıstica do TinyOS de aloca¸c˜ao de mem´oria de forma est´atica, o sistema acabou atingindo cinco vezes o limite de mem´oria RAM dispon´ıvel em um mote do tipo MICAz. Os maiores ofensores foram a multiplica¸c˜ao das filas para diferentes protocolos de comunica¸c˜ao e diferentes opera¸c˜oes. Por exemplo, quatro filas com uma estrutura de dados com 5 itens de 20 bytes vai ocupar um pouco mais que 400 bytes, o que representa 10% dos 4kB dispon´ıveis no MICAz. Outro ponto investigado foi a forma que o compilador trata as constantes do programa. No caso espec´ıfico do compilador para processadores AVR (utilizado no MICAz) essas constantes s˜ao mantidas em mem´oria RAM, pois a mem´oria de programa (ROM) tem modo de acesso diferenciado da RAM. Foi necess´ario utilizar fun¸c˜oes espec´ıficas desses processadores para alocar algumas tabelas de constantes em mem´oria ROM e liberar mais espa¸co na mem´oria RAM. Ap´os uma minuciosa an´alise do uso de mem´oria, tivemos que rever a estrat´egia de isolamento entre camadas por meio de filas, restringir a concorrˆencia de algumas opera¸c˜oes e rever o tamanho e uso de alguns vetores utilizados no programa. Ent˜ao reescrevemos parte do c´odigo utilizando uma fila na camada de aplica¸c˜ao e duas filas centrais (recebimento e envio) para os protocolos de comunica¸c˜ao. Na nova vers˜ao, se ocorrer o disparo concorrente entre duas agrega¸c˜oes, a segunda opera¸c˜ao s´o ´e processada ap´os o termino da primeira. Para teste da vers˜ao atual do sistema, implantamos uma aplica¸c˜ao exemplo em sensores MICAz e executamos alguns testes simples em uma rede com trˆes motes desse tipo. O mote MICAz[22] da Crossbow Technology usa um microcontrolador Atmel ATmega128L 8-bit, com 4kB de RAM, 128kB para Cap´ıtulo 4. Implementa¸c˜ao 49 mem´oria de programa, utiliza o chip de r´adio CC2420 e ´e alimentado por um par de baterias do tipo AA. O r´adio opera na frequˆencia de 2.4GHz no padr˜ao IEEE 802.15.4/ZigBee com taxa de transmiss˜ao de dados de 250kbps. O nosso sistema ocupa atualmente 3.666 bytes de mem´oria RAM e 50.436 bytes de mem´oria ROM. A configura¸c˜ao da aplica¸c˜ao do usu´ario ocupa um espa¸co de mem´oria j´a reservada no sistema, dessa forma n˜ao aumentando o uso de mem´oria. O objetivo principal dessa avalia¸c˜ao foi confirmar que o modelo de programa¸c˜ao proposto ´e adequado `as limita¸c˜oes de mem´oria dos dispositivos usados nas RSSF. 4.5.2 Inclus˜ao de novas funcionalidades Podem existir situa¸c˜oes em que o conjunto de funcionalidades disponibilizadas n˜ao consigam atender alguma aplica¸c˜ao. Nessas situa¸c˜oes, ´e necess´ario alterar o c´odigo existente e carregar todo os sistema no mote. Como essa carga n˜ao ´e uma a¸c˜ao de reconfigura¸c˜ao remota da aplica¸c˜ao, ´e preciso conectar cada mote, via cabo, ao sistema de desenvolvimento. A arquitetura em camadas funcionais e o modelo de configura¸c˜ao permite um grande reaproveitamento do c´odigo existente. Para cada nova funcionalidade, ´e necess´ario avaliar os pontos de impacto no sistema para garantir uma interven¸c˜ao coordenada e que n˜ao impacte o funcionamento da parte existente. Como identificado no item 4.5.1 sobre a nossa experiˆencia no desenvolvimento, o desenvolvedor deve ter muita aten¸c˜ao na cria¸c˜ao ou altera¸c˜ao das estruturas de dados. Facilmente uma lista de valores pode estourar a capacidade de mem´oria do mote ou uma inclus˜ao de novos parˆametros pode ultrapassar o limite de bytes de uma mensagem via r´adio. Como poss´ıveis altera¸c˜oes podemos ter a inclus˜ao de uma nova a¸c˜ao/evento, a inclus˜ao de um novo c´alculo de agrega¸c˜ao e inclus˜ao ou troca de algum protocolo de comunica¸c˜ao. A seguir, detalhamos essas altera¸c˜oes e explicitamos o respectivo impacto no sistema. Inclus˜ao de uma nova a¸c˜ao/evento As a¸c˜oes e eventos dispon´ıveis para utiliza¸c˜ao pela m´aquina de estado da aplica¸c˜ao do usu´ario s˜ao predefinidas no c´odigo execut´avel carregado inicialmente no mote. Para disponibilizar uma nova a¸c˜ao para a FSM da aplica¸c˜ao ´e necess´ario criar um novo identificador de a¸c˜ao e incluir a chamada da nova fun¸c˜ao na estrutura “switch/case” de controle das a¸c˜oes. O identificador da a¸c˜ao deve ser inclu´ıdo no arquivo “AppMain.h” e o controle das a¸c˜oes ´e feito pela fun¸c˜ao Cap´ıtulo 4. Implementa¸c˜ao 50 “FSM.execAction()” do arquivo “AppMainC.nc”. A entrada da nova a¸c˜ao deve estar neste ´ultimo arquivo. A implementa¸c˜ao da nova a¸c˜ao pode estar distribu´ıda pelas v´arias camadas do sistema ou simplesmente na camada de aplica¸c˜ao no arquivo “AppMainC.nc”. Para o caso de um novo evento, provavelmente gerado a partir de uma nova a¸c˜ao, deve-se tamb´em criar um novo identificador de evento no arquivo “AppMain.h” e executar uma chamada `a fun¸c˜ao “FSM.enqueueEvt()” de dentro do arquivo “AppMainC.nc”. Deve-se tamb´em incluir os novos identificadores na ferramenta de configura¸c˜ao disponibilizada para o usu´ario, no nosso caso basta incluir a nova defini¸c˜ao na planilha de configura¸c˜ao. A nova funcionalidade pode reutilizar as fun¸c˜oes das camadas inferiores ou aplicar pequenas modifica¸c˜oes nas mesmas. Deve-se ter aten¸c˜ao especial para os casos que necessitem alterar a estrutura dos parˆametros de configura¸c˜ao. Se necess´aria a inclus˜ao de um novo parˆametro, esse deve refletir na mensagem de configura¸c˜ao e consequentemente na ferramenta de configura¸c˜ao disponibilizada para o usu´ario. A estrutura de dados dos parˆametros fica no arquivo “WSNDyn.h” e as altera¸c˜oes devem ser refletidas no componente “MoteDataC.nc” que ´e respons´avel pelo acesso a esses dados. Inclus˜ao de um novo c´alculo de agrega¸c˜ao A inclus˜ao de um novo c´alculo de agrega¸c˜ao ´e uma opera¸c˜ao bastante simples, basta criar um novo identificador para o c´alculo e incluir a nova fun¸c˜ao na camada de agrega¸c˜ao. O novo identificador deve ser criado no arquivo “WSNDyn.h”, na se¸c˜ao “AO-Aggregation Operation”. A nova fun¸c˜ao de agrega¸c˜ao deve ser criada no arquivo “AggregMainP.nc”. Pode-se utilizar as fun¸c˜oes j´a existentes como template para a nova fun¸c˜ao. Inclus˜ao ou troca de algum protocolo de comunica¸c˜ao As altera¸c˜oes nos protocolos devem ser muito bem avaliadas, pois impactam o funcionamento da maioria das opera¸c˜oes do sistemas. Essas altera¸c˜oes podem ser bastante complexas sendo necess´ario que o desenvolvedor conhe¸ca a fundo o funcionamento do sistema. De forma geral, deve-se alterar as estruturas de dados das mensagens de comunica¸c˜ao e a l´ogica de controle do respectivo protocolo. A arquitetura em camadas facilita essas altera¸c˜oes, sendo poss´ıvel fazer uma altera¸c˜ao na camada de comunica¸c˜ao e n˜ao impactar o funcionamento do restante do sistema. Aqui vale o coment´ario anterior sobre a estrutura dos parˆametros de configura¸c˜ao. Cap´ıtulo 4. Implementa¸c˜ao 51 Os principais componentes envolvidos s˜ao “CommunicationP” e “CommMainP”. A estrutura de dados das mensagens est´a no arquivo “WSNDyn.h”. 5 Avalia¸c˜ao A nossa avalia¸c˜ao foi dividida em duas partes. Na primeira exercitamos nosso modelo de programa¸c˜ao com a implementa¸c˜ao das trˆes aplica¸c˜oes de referˆencia definidas na subse¸c˜ao 3.1.1. Na segunda parte, fazemos uma avalia¸c˜ao preliminar da facilidade de programa¸c˜ao utilizando o modelo de programa¸c˜ao proposto e o impacto no tempo de vida ´util da rede com a utiliza¸c˜ao da configura¸c˜ao remota. 5.1 Implementa¸c˜ao das aplica¸c˜oes de referˆencia Nessa se¸c˜ao aplicamos o modelo de programa¸c˜ao proposto na constru¸c˜ao das trˆes aplica¸c˜oes de referˆencia descritas na se¸c˜ao 3.1.1. Usamos a primeira aplica¸c˜ao de referˆencia para explicar em mais detalhes a utiliza¸c˜ao do modelo de programa¸c˜ao. No apˆendice B.2 apresentamos os diagramas e as tabelas de configura¸c˜ao para as trˆes aplica¸c˜oes. Conforme a necessidade da aplica¸c˜ao, pode-se definir uma ou mais m´aquinas de estados para cada opera¸c˜ao de coleta. A separa¸c˜ao entre a configura¸c˜ao dos componentes e a configura¸c˜ao da FSM permitiu um grande reaproveitamento das defini¸c˜oes das FSMs. Com isso, temos a mesmas FSMs de inicializa¸c˜ao e alarme para as aplica¸c˜oes 1 e 2, e a mesma FSM de monitora¸c˜ao para as aplica¸c˜oes 2 e 3. 5.1.1 Aplica¸c˜ao 1 - Alarme de incˆendio florestal Essa aplica¸c˜ao foi definida na subse¸c˜ao 3.1.1 e tem como objetivo detectar rapidamente focos de incˆendio em florestas. A sua implementa¸c˜ao utilizou duas m´aquinas de estados. A primeira ´e a extens˜ao da m´aquina de estados da inicializa¸c˜ao para controle da suspens˜ao do alarme. A segunda m´aquina executa as opera¸c˜oes de monitora¸c˜ao e alarme utilizando os parˆametros de configura¸c˜ao da Coleta 1. Para comandar a suspens˜ao do alarme utilizamos a a¸c˜ao sendCustom01 que envia uma mensagem gen´erica para os motes do mesmo grupo. O retorno Cap´ıtulo 5. Avalia¸c˜ao 53 para a situa¸c˜ao normal ´e disparado por um temporizador tamb´em gen´erico CustomTimer01. Para a opera¸c˜ao efetiva do alarme, configuramos o temporizador da Coleta 1 com o per´ıodo de leitura do sensor local de temperatura. O resultado da leitura de temperatura ´e comparado com o respectivo parˆametro de compara¸c˜ao. Quando o resultado dessa compara¸c˜ao for verdadeiro, ´e disparada uma opera¸c˜ao de agrega¸c˜ao para contabilizar os valores de temperatura dos motes do mesmo grupo. Essa contabiliza¸c˜ao num primeiro est´agio sumariza a quantidade de valores que atendam ou n˜ao uma determinada condi¸c˜ao de compara¸c˜ao. Em um segundo est´agio compara o resultado dessa sumariza¸c˜ao com outro valor parametrizado. Em seguida, se o resultado da agrega¸c˜ao for verdadeiro, s˜ao enviados o alarme para a esta¸c˜ao base e a mensagem gen´erica para os motes do mesmo grupo. Primeira m´aquina de estados Na Figura 5.1, apresentamos o diagrama com as transi¸c˜oes da primeira m´aquina de estado. Figura 5.1: Aplica¸c˜ao 1 - FSM para inicializa¸c˜ao do mote e controle geral da aplica¸c˜ao Podemos dividir essa m´aquina nas etapas Inicializa¸c˜ao, Ocioso, Coletando e Suspenso. Na Inicializa¸c˜ao ´e executado um procedimento interno padr˜ao para inicializa¸c˜ao sistˆemica (estados Initializing e Initiating Collections). No estado Ocioso (Idle), o mote estar´a pronto para executar uma nova coleta. O estado Coletando (Collecting) indica que o mote est´a executando uma opera¸c˜ao de coleta. O estado Suspenso (Suspended) indica que o mote recebeu um comando para inibir a execu¸c˜ao das pr´oximas coletas. Os principais eventos considerados nessa m´aquina s˜ao TimerFired que indica que um temporizador peri´odico de uma coleta foi disparado; startCol- Cap´ıtulo 5. Avalia¸c˜ao 54 lection que indica que uma nova coleta foi disparada; endCollection que indica que uma coleta foi finalizada; CustomComm01 que indica que a mensagem gen´erica 01 foi recebida pelo mote. Essa mensagem gen´erica ´e usada para colocar o mote no estado Suspenso; CustomTimer01 que indica que o temporizador gen´erico 01 foi disparado. Esse temporizador gen´erico ´e usado para retirar o mote do estado Suspenso. As a¸c˜oes utilizadas s˜ao startCustomTimer01 para iniciar a contagem de tempo para o temporizador gen´erico 01; nextColl para disparar o pr´oximo evento startCollection;lostColl para cancelar o pr´oximo evento startCollection, ´e utilizado quando o temporizador dispara antes da finaliza¸c˜ao de uma coleta. No apˆendice B.2, a Tabela B.4 apresenta todos os parˆametros de configura¸c˜ao e a Tabela B.7 apresenta a configura¸c˜ao para a tabela de transi¸c˜oes da FSM. Segunda m´aquina de estados Na Figura 5.2, apresentamos o diagrama com as transi¸c˜oes da segunda m´aquina de estado. Figura 5.2: Aplica¸c˜ao 1 - FSM para gera¸c˜ao do alarme O diagrama pode ser dividido nas etapas de Alarme Local, C´alculo do Sum´ario, Envio de Dados e Suspens˜ao dos Vizinhos. Na etapa de Alarme Local, temos os estados Waiting Start que fica aguardando um evento para in´ıcio de uma coleta, Reading Sensor que fica aguardando a resposta do sensor de temperatura e Testing Trigger que aguarda a resposta do teste de valor do alarme. Na etapa para C´alculo do Sum´ario, o estado Aggregating indica que Cap´ıtulo 5. Avalia¸c˜ao 55 est´a sendo executada uma opera¸c˜ao de agrega¸c˜ao para calcular o sum´ario dos valores de temperatura do grupo de n´os. Na etapa Envio de Dados, o estado Sending BS indica que o mote est´a aguardando a finaliza¸c˜ao do comando para envio de dados para a esta¸c˜ao base. Na etapa Suspens˜ao dos vizinhos, o estado Sending Custom indica que o mote est´a aguardando a finaliza¸c˜ao do comando enviado para os motes vizinhos. Os principais eventos utilizados s˜ao nextColl que indica que existe um evento de coleta dispon´ıvel na fila; readSensorDone que indica que a leitura do sensor foi finalizada; testTriggerDone que retorna verdadeiro ou falso para o teste de compara¸c˜ao do valor de alarme; AggregDone que retorna o resultado da opera¸c˜ao de agrega¸c˜ao; sendBSDone que indica a finaliza¸c˜ao da a¸c˜ao de envio de dados para a esta¸c˜ao base; CustomCommDone que indica a finaliza¸c˜ao da a¸c˜ao de envio do comando gen´erico. As a¸c˜oes utilizadas s˜ao readSensor para disparar uma leitura do sensor de temperatura; testTrigger para disparar a compara¸c˜ao do resultado do sensor com o parˆametro de alarme; startAggreg para iniciar a opera¸c˜ao de agrega¸c˜ao; sendBSAggSummary para enviar os dados do c´alculo do sum´ario para a esta¸c˜ao base. sendCustom01 para enviar o comando gen´erico 01 para os motes do mesmo grupo. endColection retira o evento de coleta da fila para poder processar o pr´oximo evento. Nessa aplica¸c˜ao utilizamos o recurso de dependˆencia entre m´aquinas para inibir uma coleta quando o mote estiver no estado Suspenso. Note no diagrama da Figura 5.2 que algumas condi¸c˜oes de transi¸c˜oes foram definidas por [(FSM1=Collecting)] ou por [(FSM1=Suspended)]. Isso indica que essas transi¸c˜oes s´o ocorrem quando o estado da m´aquina 1 (FSM1) for o estado indicado na condi¸c˜ao. No apˆendice B.2, a Tabela B.4, apresenta todos os parˆametros de configura¸c˜ao e, as Tabelas B.7 e B.8, apresentam as configura¸c˜oes para as tabelas de transi¸c˜oes das FSMs. 5.1.2 Aplica¸c˜ao 2 - Monitor de temperatura e Alarme de incˆendio predial Essa aplica¸c˜ao foi definida na subse¸c˜ao 3.1.1 e tem como objetivos monitorar a temperatura m´edia dos ambientes do pr´edio e gerar alarmes em caso de incˆendio. A sua implementa¸c˜ao utilizou trˆes m´aquinas de estados. Na primeira m´aquina estendemos, da mesma forma que na aplica¸c˜ao anterior, a m´aquina de estados da inicializa¸c˜ao para controle da suspens˜ao do alarme. Para a opera¸c˜ao efetiva do alarme, definimos uma segunda m´aquina de estados que utiliza os parˆametros da Coleta 1. Para a opera¸c˜ao de monitora¸c˜ao peri´odica, Cap´ıtulo 5. Avalia¸c˜ao 56 definimos uma terceira m´aquina de estados que utiliza os parˆametros da Coleta 2. As duas primeiras m´aquinas operam da mesma forma que a aplica¸c˜ao 1, diferindo apenas quanto aos parˆametros de configura¸c˜ao. Na terceira m´aquina, o temporizador peri´odico da Coleta 2 dispara a a¸c˜ao para verificar se o mote ´e um mote coordenador. Caso o resultado da compara¸c˜ao seja verdadeiro, ´e disparada uma opera¸c˜ao de agrega¸c˜ao para calcular a temperatura m´edia dos motes do mesmo grupo. Em seguida o resultado da agrega¸c˜ao ´e enviado para a esta¸c˜ao base. No apˆendice B.2, as figuras B.3, B.4 e B.5, apresentam os diagramas das m´aquinas de estados dessa aplica¸c˜ao. Na Tabela B.5, temos todos os parˆametros de configura¸c˜ao e, nas Tabelas B.9,B.10 e B.11, temos a configura¸c˜ao para as tabelas de transi¸c˜oes. 5.1.3 Aplica¸c˜ao 3 - Estacionamento urbano e Monitora¸c˜ao de vagas Essa aplica¸c˜ao foi definida na subse¸c˜ao 3.1.1 e tem como objetivos auxiliar motoristas na reserva de uma vaga de estacionamento e informar para uma central de controle a situa¸c˜ao das vagas em cada regi˜ao. A sua implementa¸c˜ao tamb´em utilizou trˆes m´aquinas de estados. Na primeira m´aquina estendemos a m´aquina de estados da inicializa¸c˜ao para simplesmente controlar a a¸c˜ao de reserva. Esse controle ´e disparado manualmente a partir do acionamento de uma chave local (solicita¸c˜ao de vaga), onde ´e gerado um evento de in´ıcio de coleta. Para a opera¸c˜ao de monitora¸c˜ao peri´odica, vamos definir uma segunda m´aquina de estados que utiliza os parˆametros da Coleta 1. O funcionamento ´e similar ao monitoramento da Aplica¸c˜ao 2. Para a opera¸c˜ao de reserva de vaga, vamos definir uma terceira m´aquina de estados que utiliza os parˆametros da Coleta 2. Essa coleta ´e disparada por um evento gerado pela chave na primeira m´aquina de estado, que dispara uma opera¸c˜ao de agrega¸c˜ao. Essa opera¸c˜ao de agrega¸c˜ao executa todos os passos necess´arios para a reserva e confirma¸c˜ao de um recurso num grupo de motes. Ap´os uma reserva, um novo evento de disparo da coleta vai gerar uma opera¸c˜ao de finaliza¸c˜ao da reserva que vai providenciar o cancelamento da reserva atual. No apˆendice B.2, as figuras B.6, B.7 e B.8, apresentam os diagramas das m´aquinas de estados dessa aplica¸c˜ao. Na Tabela B.6, temos todos os parˆametros de configura¸c˜ao utilizados e, nas Tabelas B.12 e B.13, temos as configura¸c˜oes para as tabelas de transi¸c˜oes. Cap´ıtulo 5. Avalia¸c˜ao 57 5.2 Avalia¸c˜ao da facilidade de programa¸c˜ao e do impacto da configura¸c˜ao remota Para a segunda parte dos testes, avaliamos o nosso sistema sob dois aspectos: (i) facilidades de configura¸c˜ao e reconfigura¸c˜ao de aplica¸c˜oes; (ii) impacto adicional em termos de comunica¸c˜ao para a reconfigura¸c˜ao de uma aplica¸c˜ao em execu¸c˜ao. No primeiro aspecto, as m´etricas utilizadas foram a quantidade de linhas na tabela de transi¸c˜oes para a FSM e o n´umero de parˆametros necess´arios para a implementa¸c˜ao da aplica¸c˜ao. Tamb´em fizemos uma implementa¸c˜ao alternativa diretamente em NesC para uma compara¸c˜ao relativa. Nesse caso utilizamos a quantidade de linhas dos arquivos fontes e a quantidade de opera¸c˜oes representadas pelo caractere “;”. Apesar de n˜ao serem m´etricas semelhantes, a interpreta¸c˜ao desses valores apoia a nossa compara¸c˜ao. Adicionalmente apresentamos o espa¸co utilizado de mem´oria RAM e ROM para cada implementa¸c˜ao. No segundo aspecto, a m´etrica utilizada foi a quantidade de mensagens enviadas na rede. Conforme [23] podemos considerar o envio de uma mensagem como a opera¸c˜ao de maior custo em rela¸c˜ao ao consumo de bateria e, consequentemente, a opera¸c˜ao que mais afeta o tempo de vida ´util de um n´o. Para contabilizar o n´umero de mensagens enviadas, executamos a aplica¸c˜ao no simulador TOSSIM habilitando os logs das fun¸c˜oes de comunica¸c˜ao. No pr´oximo item apresentamos a aplica¸c˜ao utilizada como referˆencia para nossos testes. Em seguida, abordamos cada teste e apresentamos os resultados espec´ıficos. 5.2.1 Aplica¸c˜ao de referˆencia Em nossos testes, vamos considerar uma aplica¸c˜ao de monitora¸c˜ao predial, em que o motes est˜ao distribu´ıdos de forma equidistante em trˆes ambientes. 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 configuramos o parˆametro de salto m´aximo (n hops max) igual a dois. A esta¸c˜ao servidora (fonte de reconfigura¸c˜ao da aplica¸c˜ao) est´a conectada ao n´o central (25) atrav´es da esta¸c˜ao base (EB). Essa configura¸c˜ao requer, propositalmente, que os protocolos utilizados precisem rotear a maioria das mensagens. A Figura 5.3 apresenta a nossa rede de referˆencia. As setas indicam o alcance da comunica¸c˜ao entre os motes. Cap´ıtulo 5. Avalia¸c˜ao 64 Supondo uma aplica¸c˜ao funcionando por trˆes meses com coleta a cada 10 minutos, o custo de uma reconfigura¸c˜ao remota equivale 110 minutos de opera¸c˜ao ou 0,083% do per´ıodo de trˆes meses. (3 meses = 131.760 minutos) Adicionalmente aos nossos testes originais, vamos supor um novo protocolo de dissemina¸c˜ao da FSM para reduzir ao m´aximo o valor de DIP Residual. Dessa forma, reduz-se a interferˆencia do protocolo DIP, que ´e utilizado na reconfigura¸c˜ao, no c´alculo do total de mensagens de coleta. A equa¸c˜ao 5-2 mostra o resultado para esse novo c´alculo: Reconf =(DIPInic +P aramInic) Coleta =552 + 1267 145 = 12,5Coletas (5-2) Para esse caso, o impacto ser´a de 125 minutos com percentual de 0,095%. ´ E importante ressaltar que essa proje¸c˜ao considera o comportamento da rede como um todo. Quando olhamos a quantidade de envios para cada n´o, identificamos valores maiores para n´os roteadores e n´os coordenadores. A nossa proje¸c˜ao n˜ao se altera muito, pois a diferen¸ca para os n´os roteadores ´e equivalente tanto na reconfigura¸c˜ao remota como na opera¸c˜ao normal. J´a para os n´os coordenadores, o processo de reelei¸c˜ao garante o revezamento em fun¸c˜ao da carga da bateria. 5.2.5 Discuss˜ao Para subsidiar a nossa discuss˜ao, apresentamos na Tabela 5.8 um comparativo entre as implementa¸c˜oes utilizando o modelo proposto e em NesC. Essa tabela mostra as diferen¸cas entre a vers˜ao do primeiro teste (v1) e a vers˜ao incluindo a nova funcionalidade do segundo teste (v2). Tamb´em inclu´ımos um valor aproximado do tempo gasto na constru¸c˜ao e teste para cada implementa¸c˜ao. A vers˜ao NesC foi simplificada e os n´umeros relativos ao tamanho de c´odigo seriam bem maiores caso implement´assemos funcionalidades equivalentes `a vers˜ao no modelo proposto. Esses valores refletem uma situa¸c˜ao espec´ıfica da nossa avalia¸c˜ao. Tivemos somente um usu´ario que j´a tinha experiˆencia no modelo de programa¸c˜ao proposto e no pr´oprio NesC/TinyOS. Comparando a nossa experiˆencia com a implementa¸c˜ao no modelo proposto e a utilizando NesC, podemos afirmar que uma solu¸c˜ao parametriz´avel reduz o esfor¸co necess´ario para reconfigurar uma aplica¸c˜ao. A quantidade de elementos alterados ´e pequena perto de uma interven¸c˜ao em um programa NesC. O desenvolvimento em NesC tende a ser mais suscept´ıvel a erros de programa¸c˜ao do que a configura¸c˜ao de m´odulos j´a prontos. A facilidade introduzida pelo nosso modelo de programa¸c˜ao acaba re- Cap´ıtulo 5. Avalia¸c˜ao 65 Tabela 5.8: Resumo comparativo entre as duas implementa¸c˜oes item Tipo Implementa¸c˜ao Modelo Proposto NesC/TinyOS Quant. v1 6 parˆametros e 366 linhas ou 15 transi¸c˜oes. 188 opera¸c˜oes Quant. v2 11 parˆametros e 446 linhas ou 22 transi¸c˜oes. 231 opera¸c˜oes Diferen¸ca Parˆametros: altera 1 e inclui 5. Linhas: remove 14 e Transi¸c˜oes: inclui 7 inclui 94 Esfor¸co (v1+v2) 0,5 dia 2 dias Mem´oria utilizada ROM: 50.436 bytes ROM: 25.438 bytes RAM: 3.666 bytes RAM: 1.688 bytes fletindo na quantidade de mem´oria utilizada. No nosso sistema, a utiliza¸c˜ao de mem´oria ´e definida pelos componentes do sistema previamente carregado e independe da configura¸c˜ao da aplica¸c˜ao. J´a na implementa¸c˜ao em NesC, o uso de mem´oria tende a ser mais econˆomico, principalmente por carregar somente os componentes necess´arios para a vers˜ao espec´ıfica da aplica¸c˜ao. 6 Conclus˜ao Neste trabalho, implementamos um modelo de programa¸c˜ao para rede de sensores sem fio que facilita a constru¸c˜ao de novas aplica¸c˜oes e tamb´em permite a reconfigura¸c˜ao remota dessas aplica¸c˜oes. O modelo de programa¸c˜ao utiliza um controle de fluxo baseado em M´aquinas de Estados Finitos (FSM) combinado com uma biblioteca de fun¸c˜oes parametriz´aveis. As fun¸c˜oes dessa biblioteca foram definidas a partir de um levantamento de padr˜oes de intera¸c˜ao t´ıpicos das aplica¸c˜oes para RSSF. A utiliza¸c˜ao desses padr˜oes permitiu construir um modelo que abstrai a maioria das dificuldades de programa¸c˜ao em RSSF, incluindo as dificuldades de sistemas distribu´ıdos. A utiliza¸c˜ao do conceito de FSM para a programa¸c˜ao do fluxo de processamento permitiu uma maior flexibilidade e melhor aproveitamento do conceito de fun¸c˜oes reutiliz´aveis, al´em de se adequar bem ao modelo de opera¸c˜ao baseado em eventos, t´ıpico das aplica¸c˜oes para RSSF. Com o modelo de programa¸c˜ao apresentado foi poss´ıvel implementar facilmente trˆes aplica¸c˜oes com diferentes comportamentos (aplica¸c˜oes de referˆencia) e ainda outras aplica¸c˜oes utilizadas nos cen´arios de testes. Para isso, basta que o usu´ario tenha dom´ınio do modelo de programa¸c˜ao proposto para escrever a aplica¸c˜ao desejada no formato das FSM e definir os parˆametros de configura¸c˜ao. Mostramos tamb´em que associando o modelo de programa¸c˜ao baseado em m´aquinas de estados com uma biblioteca de fun¸c˜oes parametriz´aveis ´e poss´ıvel alcan¸car duas metas importantes em termos de reconfigura¸c˜ao de aplica¸c˜oes em RSSF: (i) realizar a reconfigura¸c˜ao remota de aplica¸c˜oes em ponto pequeno, i.e., sem a necessidade de substituir componentes inteiros da aplica¸c˜ao, e com impacto no tempo de vida da rede aceit´avel; e (ii) permitir que em uma mesma RSSF possam coexistir v´arios fluxos de execu¸c˜ao independentes, e ao mesmo tempo com possibilidade de troca de informa¸c˜oes entre eles. Identificamos algumas limita¸c˜oes desse trabalho, como: – A avalia¸c˜ao da facilidade de programa¸c˜ao foi limitada por ter sido executada por somente um usu´ario. Cap´ıtulo 6. Conclus˜ao 67 – O foco da nossa solu¸c˜ao foi em dispositivos motes com poucos recursos computacionais. Como consequˆencia os padr˜oes de intera¸c˜ao identificados s˜ao mais apropriados para os tipos de aplica¸c˜oes as quais a rede fornece informa¸c˜oes b´asicas e o processamento mais complexo ´e feito fora da rede. Podemos citar como principais contribui¸c˜oes deste trabalho: – Identifica¸c˜ao de padr˜oes de intera¸c˜ao mais comuns para programa¸c˜ao em RSSF que utilizam dispositivos motes com poucos recursos computacionais. Essa padr˜oes suportam aplica¸c˜oes de monitora¸c˜ao, aquisi¸c˜ao peri´odica, alarmes e alguns tipos de intera¸c˜oes eventuais. – Constru¸c˜ao de uma biblioteca de fun¸c˜oes que implementam esses padr˜oes; – Especifica¸c˜ao e constru¸c˜ao de um sistema que suporta a constru¸c˜ao de diferentes aplica¸c˜oes para RSSF, contemplando algumas facilidades de reconfigura¸c˜ao dinˆamica. – Avalia¸c˜ao da facilidade de programa¸c˜ao de aplica¸c˜oes para RSSF utilizando um modelo baseado em FSM e funcionalidades parametriz´aveis; 6.1 Trabalhos futuros Podemos dividir os trabalhos futuros em dois grupos. O primeiro grupo est´a relacionado aos trabalhos complementares ao trabalho atual. Por exemplo a utiliza¸c˜ao da nossa implementa¸c˜ao como suporte para o desenvolvimento de novas linguagens de macroprograma¸c˜ao, uma vez que j´a temos implementadas as principais abstra¸c˜oes de comunica¸c˜ao e intera¸c˜ao entre n´os utilizadas em aplica¸c˜oes de RSSF. No segundo grupo inclu´ımos os trabalhos que aproveitam da modularidade da solu¸c˜ao e evoluam a nossa implementa¸c˜ao atual. Como exemplo citamos a aplica¸c˜ao de novos protocolos de comunica¸c˜ao. O primeiro grupo ´e o nosso principal objetivo, mas entendemos que os trabalhos do segundo grupo s˜ao importantes para que se possa disponibilizar uma solu¸c˜ao completa e ´util para desenvolvimento de aplica¸c˜oes reais. A continuidade do nosso trabalho prevˆe o desenvolvimento de uma linguagem para especifica¸c˜ao de aplica¸c˜oes para RSSF (macroprograma¸c˜ao) e um compilador para essa linguagem. Esse compilador deve gerar a descri¸c˜ao das aplica¸c˜oes, no modelo proposto neste trabalho, definindo a tabela de transi¸c˜oes e os parˆametros de configura¸c˜ao dos componentes. Complementando essa atividades pretendemos avaliar a necessidade de estender o conjunto inicial de componentes parametriz´aveis, assim como o conjunto de a¸c˜oes e eventos permitidos, para atender aos requisitos de aplica¸c˜oes mais espec´ıficas. Cap´ıtulo 6. Conclus˜ao 68 Dentre poss´ıveis trabalhos do segundo grupo podemos citar o desenvolvimento de outros algoritmos distribu´ıdos e que consideram a opera¸c˜ao em baixa energia (quando o funcionamento do r´adio intercala per´ıodos ligado e desligado). Isso inclui algoritmos para sincroniza¸c˜ao de dados, forma¸c˜ao de grupos, elei¸c˜ao e manuten¸c˜ao de l´ıder e roteamento de mensagens na rede. Na ´otica da codifica¸c˜ao e visando a opera¸c˜ao da aplica¸c˜ao por longo prazo, temos espa¸co para trabalhos em padr˜oes e otimiza¸c˜oes do c´odigo, an´alise est´atica e dinˆamica da pilha de mem´oria e seguran¸ca do c´odigo. Ainda no segundo grupo pode-se avaliar a substitui¸c˜ao do controle FSM por alguma linguagem simplificada, de preferˆencia baseada no conceito de m´aquina virtual para facilitar a carga remota. 7 Referˆencias Bibliogr´aficas [1] MADDEN, S. R. et al. Tinydb: an acquisitional query processing system for sensor networks. ACM Trans. Database Syst., ACM, New York, NY, USA, v. 30, n. 1, p. 122–173, 2005. ISSN 0362-5915. 1.3, 3.1.2 [2] NEWTON, R.; MORRISETT, G.; WELSH, M. The regiment macroprogramming system. In: IPSN ’07: Proceedings of the 6th international conference on Information processing in sensor networks. New York, NY, USA: ACM, 2007. p. 489–498. ISBN 978-1-59593-638-X. 1.3, 3.1.1, 3.1.2 [3] AWAN, A.; JAGANNATHAN, S.; GRAMA, A. Macroprogramming heterogeneous sensor networks using cosmos. In: Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007. New York, NY, USA: ACM, 2007. (EuroSys ’07), p. 159–172. ISBN 978-1-59593-636-3. Dispon´ıvel em: <http://doi.acm.org/10.1145/1272996.1273014>. 1.3, 3.1.2 [4] LEVIS, P.; CULLER, D. Mat´e: a tiny virtual machine for sensor networks. In: ASPLOS-X: Proceedings of the 10th international conference on Architectural support for programming languages and operating systems. New York, NY, USA: ACM, 2002. p. 85–95. ISBN 1-58113-574-2. 1.3 [5] HUI, J. W.; CULLER, D. The dynamic behavior of a data dissemination protocol for network programming at scale. In: Proceedings of the 2nd international conference on Embedded networked sensor systems. New York, NY, USA: ACM, 2004. (SenSys ’04), p. 81–94. ISBN 1-58113879-2. Dispon´ıvel em: <http://doi.acm.org/10.1145/1031495.1031506>. 1.3 [6] MUNAWAR, W. et al. Dynamic tinyos: Modular and transparent incremental code-updates for sensor networks. In: Proceedings of the IEEE International Conference on Communications (ICC). Cape Town, South Africa, May 23-27: [s.n.], 2010. 1.3 Cap´ıtulo 7. Referˆencias Bibliogr´aficas 70 [7] KASTEN, O.; R¨oMER, K. Beyond event handlers: programming wireless sensors with attributed state machines. In: IPSN ’05: Proceedings of the 4th international symposium on Information processing in sensor networks. Piscataway, NJ, USA: IEEE Press, 2005. p. 7. ISBN 0-78039202-7. 1.3 [8] BISCHOFF, U.; KORTUEM, G. A state-based programming model and system for wireless sensor networks. In: PERCOMW ’07: Proceedings of the Fifth IEEE International Conference on Pervasive Computing and Communications Workshop. Washington, DC, USA: IEEE Computer Society, 2007. p. 261 –266. ISBN 0-7695-2788-4. 1.3 [9] HAREL, D. Statecharts: A visual formalism for complex systems. Sci. Comput. Program., Elsevier North-Holland, Inc., Amsterdam, The Netherlands, The Netherlands, v. 8, n. 3, p. 231–274, 1987. ISSN 0167-6423. 1.3 [10] HAREL, D.; NAAMAD, A. The statemate semantics of statecharts. ACM Trans. Softw. Eng. Methodol., ACM, New York, NY, USA, v. 5, n. 4, p. 293–333, 1996. ISSN 1049-331X. 1.3 [11] LEVIS, P. et al. Tinyos: An operating system for sensor networks. In: in Ambient Intelligence. [S.l.]: Springer Verlag, 2004. 2, 3.2.1, 4.3 [12] GAY, D. et al. The nesc language: A holistic approach to networked embedded systems. ACM, New York, NY, USA, p. 1–11, 2003. 2, 4.3 [13] WIKIPEDIA. List of wireless sensor nodes — Wikipedia, The Free Encyclopedia. February 2011. [Online; accessed 13-March-2011]. Dispon´ıvel em: <http://en.wikipedia.org/w/index.php?title=List_ of_wireless_sensor_nodes&oldid=414463291>. 2.2.1 [14] LEVIS, P. et al. Tossim: accurate and scalable simulation of entire tinyos applications. In: Proceedings of the 1st international conference on Embedded networked sensor systems. New York, NY, USA: ACM, 2003. (SenSys ’03), p. 126–137. ISBN 1-58113-707-9. Dispon´ıvel em: <http://doi.acm.org/10.1145/958491.958506>. 2.2.1, 4.1, 4.3, C [15] BRANCO, A.; RODRIGUEZ, N. Macroprograma¸c˜ao em rede de sensores sem fio. In: Monografias em Ciˆencia da Computa¸c˜ao. [S.l.]: PUC-Rio, 2010. v. 02/2010. 3.1, 3.1.2 [16] CERVANTES, H.; DONSEZ, D.; TOUSEAU, L. An architecture description language for dynamic sensor-based applications. In: Consumer Communi- Cap´ıtulo 7. Referˆencias Bibliogr´aficas 71 cations and Networking Conference, 2008. CCNC 2008. 5th IEEE. [S.l.: s.n.], 2008. p. 147–151. ISSN 0197-2618. 3.1.1, 3.1.2 [17] KOTHARI, N. et al. Reliable and efficient programming abstractions for wireless sensor networks. PLDI ’07: Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation, ACM, New York, NY, USA, p. 200–210, 2007. 3.1.1, 3.1.2 [18] NEWTON, R.; WELSH, M. Region streams: functional macroprogramming for sensor networks. In: DMSN ’04: Proceeedings of the 1st international workshop on Data management for sensor networks. New York, NY, USA: ACM, 2004. p. 78–87. 3.1.2 [19] BAKSHI, A. et al. The abstract task graph: a methodology for architectureindependent programming of networked sensor systems. In: Proceedings of the 2005 workshop on End-to-end, sense-and-respond systems, applications and services. Berkeley, CA, USA: USENIX Association, 2005. (EESR ’05), p. 19–24. ISBN 1-931971-32-3. Dispon´ıvel em: <http://dl.acm.org/citation.cfm?id=1072530.1072535>. 3.1.2 [20] LIN, K.; LEVIS, P. Data discovery and dissemination with dip. In: IPSN ’08: Proceedings of the 7th international conference on Information processing in sensor networks. Washington, DC, USA: IEEE Computer Society, 2008. p. 433–444. ISBN 978-0-7695-3157-1. 4.1.1 [21] FONSECA, R. et al. The Collection Tree Protocol (CTP) - TEP 123. http://www.tinyos.net/tinyos-2.1.0/doc/html/tep123.html, 02 2007. Dispon´ıvel em: <http://www.tinyos.net/tinyos-2.1.0/doc/html/tep123.html>. 4.1.1 [22] CROSSBOW. MICAz datasheet. 2004. Product folder. Dispon´ıvel em: <http://www.xbow.com/asset-tracking/support/knowledge-base.html>. 4.3, 4.5.1 [23] SHNAYDER, V. et al. Simulating the power consumption of large-scale sensor network applications. In: Proceedings of the 2nd international conference on Embedded networked sensor systems. New York, NY, USA: ACM, 2004. (SenSys ’04), p. 188–200. ISBN 1-58113-879-2. Dispon´ıvel em: <http://doi.acm.org/10.1145/1031495.1031518>. 5.2 A Detalhamento dos padr˜oes de intera¸c˜ao Ap´os uma an´alise da lista completa de Padr˜oes de intera¸c˜ao, foi poss´ıvel identificar elementos comuns e reduzir o conjunto para uma lista consolidada. Na Tabela A.2, apresentamos todos Padr˜oes de intera¸c˜ao identificados. Na coluna “Padr˜oes de intera¸c˜ao Propostos” temos os padr˜oes refinados j´a com a inten¸c˜ao de simplificar o conjunto. Tamb´em criamos uma classifica¸c˜ao adicional para agrupar os tipos de fun¸c˜oes de comunica¸c˜ao disponibilizados para a aplica¸c˜ao. Essas fun¸c˜oes de suporte de comunica¸c˜ao s˜ao disponibilizados pela camada de comunica¸c˜ao da biblioteca de execu¸c˜ao ou pelo sistema operacional. O forma de funcionamento e o fluxo de dados da comunica¸c˜ao depende diretamente da topologia da rede e do m´etodo de roteamento escolhido. A Tabela A.2 inclui uma coluna para identificar o “Suporte de Comunica¸c˜ao” utilizado pela aplica¸c˜ao do respectivo padr˜ao de intera¸c˜ao . A seguir descrevemos os trˆes grupos que comp˜oem a classifica¸c˜ao de suporte de comunica¸c˜ao: 1. Sem Topologia - A aplica¸c˜ao n˜ao enxerga a topologia da rede. A topologia de suporte `a comunica¸c˜ao implementa o envio de mensagem de qualquer n´o para a esta¸c˜ao base. A comunica¸c˜ao com os vizinhos 1-hop ´e disponibilizada com uma mensagem broadcast. Em alguns casos tamb´em ´e disponibilizada a comunica¸c˜ao com os vizinhos n-hops. 2. Topologia Hier´arquica - A aplica¸c˜ao enxerga e pode fazer uso da comunica¸c˜ao atrav´es de uma topologia hier´arquica. S˜ao disponibilizadas fun¸c˜oes de envio de mensagens para o n´o Pai e para os n´os Filhos. A comunica¸c˜ao com os vizinhos 1-hop ´e disponibilizada com uma mensagem broadcast. Em alguns casos tamb´em ´e disponibilizada a comunica¸c˜ao com os vizinhos n-hops. 3. Topologia Livre - A aplica¸c˜ao define a topologia atrav´es de canais de comunica¸c˜ao. A distribui¸c˜ao da rede e a capacidade de comunica¸c˜ao dos n´os ir˜ao limitar as possibilidades de interliga¸c˜ao dos n´os. Em alguns casos pode n˜ao fazer sentido a comunica¸c˜ao com os vizinhos n-hops. Apˆendice A. Detalhamento dos padr˜oes de intera¸c˜ao 73 A partir da consolida¸c˜ao obtida, podemos resumir os padr˜oes de intera¸c˜ao conforme a Tabela A.1. Nessa tabela temos uma distribui¸c˜ao de cada padr˜ao de intera¸c˜ao pelos tipos de suporte de comunica¸c˜ao (topologias) . Os campos marcados com Xindicam que o respectivo padr˜ao se aplica no dom´ınio de uma determinado tipos de suporte de comunica¸c˜ao. Observando a Tabela A.1, nota-se que ao combinarmos a coluna “STSem Topologia” com a coluna “TH-Topologia Hier´arquica”, vamos obter um resultado que considera quase a totalidade dos padr˜oes consolidados. A diferen¸ca final fica por conta dos padr˜oes adicionais para implementa¸c˜ao de um modelo de comunica¸c˜ao baseado em canais. Na Tabela 3.1 do cap´ıtulo 3, apresentamos a nossa proposta final de padr˜oes de intera¸c˜ao para o modelo de programa¸c˜ao proposto. Tabela A.1: Distribui¸c˜ao dos Padr˜oes de intera¸c˜ao XSuporte de comunica¸c˜ao Tipo Nome ST TH ST+TH TL Comunica¸c˜ao Envia EB X X X Envia N´o X X Recebe EB X X Envia Pai X X Envia Filhos X X Cria¸c˜ao de Canal X Assinatura de canal X Publica¸c˜ao no canal X Fun¸c˜ao Agregadora Sum´ario (Grupo) X X Reserva Recurso (Grupo) X X M´edia (Grupo) X X M´edia (Hierarq.) X X Somat´orio (Hierarq.) X X M´aximo (Hierarq.) X X M´ınimo (Hierarq.) X X Fun¸c˜ao Local Evento Local X X Grupo Vizinhos 1-hop X X X Vizinhos n-hops X X X Vizinhos n-hops Condicional X X Parˆametros dinˆamicos X X X X Parˆametros est´aticos X X X X Topologia hier´arquica X X Rede X X X Distribui¸c˜ao proporcional X Suporte Agrega¸c˜ao Suporte Agrega¸c˜ao X X X X ST=Sem Topologia; TH=Topologia Hier´arquica; TL=Topologia Livre Na Tabela A.2 apresentamos a lista completa dos Padr˜oes de intera¸c˜ao identificados. Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 80 B.2 Aplica¸c˜oes de Referˆencia B.2.1 Diagramas das FSMs Aplica¸c˜ao 1 Apresentamos os diagramas das m´aquinas de estado da aplica¸c˜ao 1 nas figuras B.1 e B.2. Figura B.1: Aplica¸c˜ao 1 - FSM para Inicializa¸c˜ao do Mote e controle geral Figura B.2: Aplica¸c˜ao 1 - FSM para gera¸c˜ao do alarme Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 81 Aplica¸c˜ao 2 Apresentamos os diagramas das m´aquinas de estado da aplica¸c˜ao 2 nas figuras B.3, B.4 e B.5. Figura B.3: Aplica¸c˜ao 2 - FSM para Inicializa¸c˜ao do Mote e controle geral Figura B.4: Aplica¸c˜ao 2 - FSM para gera¸c˜ao do alarme Aplica¸c˜ao 3 Apresentamos os diagramas das m´aquinas de estado da aplica¸c˜ao 3 nas figuras B.6, B.7 e B.8. Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 82 Figura B.5: Aplica¸c˜ao 2 - FSM para monitora¸c˜ao peri´odica Figura B.6: Aplica¸c˜ao 3 - FSM para Inicializa¸c˜ao do Mote e controle geral Figura B.7: Aplica¸c˜ao 3 - FSM para monitora¸c˜ao peri´odica B.2.2 Parˆametros de configura¸c˜ao Apresentamos nas Tabelas B.4, B.5 e B.6, as configura¸c˜oes dos parˆametros para as trˆes aplica¸c˜oes de referˆencia. Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 83 Figura B.8: Aplica¸c˜ao 3 - FSM para reserva de vagas Tabela B.4: Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 1 Campo Value Descri¸c˜ao Parˆametros Gerais CTimer01Delay 70 Custom Timer 1 Delay (segundos) ElectionPeriod 60 Per´ıodo para reelei¸c˜ao de coordenador (minutos) Configura¸c˜ao da Coleta 1 - Alarme GroupDef 0x0101 Defini¸c˜ao da forma¸c˜ao do grupo MaxHops 1 Max hops do grupo TimerPeriod 30000 Per´ıodo da coleta do grupo LocalStage InputCompOper 0x03 Opera¸c˜ao Local: Identifica o sensor e a opera¸c˜ao de compara¸c˜ao LocalStage RefValue 29 Opera¸c˜ao Local: Valor de referˆencia para compara¸c˜ao AggregOper 4 Define a opera¸c˜ao de agrega¸c˜ao utilizada AggregStage1 InputCompOper 0x03 Agrega¸c˜ao Est´agio 1: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage1 RefValue 26 Agrega¸c˜ao Est´agio 1: Valor de referˆencia para compara¸c˜ao AggregStage2 InputCompOper 0x03 Agrega¸c˜ao Est´agio 2: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage2 RefValue 2 Agrega¸c˜ao Est´agio 2: Valor de referˆencia para compara¸c˜ao Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 84 Tabela B.5: Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 2 Campo Value Descri¸c˜ao Parˆametros Gerais GroupA 10 Parˆametro A utilizados na defini¸c˜ao de grupos CTimer01Delay 70 Custom Timer 1 Delay (segundos) ElectionPeriod 60 Per´ıodo para reelei¸c˜ao de coordenador (minutos) Configura¸c˜ao da Coleta 1 GroupDef 0x0101 Defini¸c˜ao da forma¸c˜ao do grupo MaxHops 3 Max hops do grupo TimerPeriod 30000 Per´ıodo da coleta do grupo LocalStage InputCompOper 0x03 Opera¸c˜ao Local: Identifica o sensor e a opera¸c˜ao de compara¸c˜ao LocalStage RefValue 29 Opera¸c˜ao Local: Valor de referˆencia para compara¸c˜ao AggregOper 4 Define a opera¸c˜ao de agrega¸c˜ao utilizada AggregStage1 InputCompOper 0x03 Agrega¸c˜ao Est´agio 1: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage1 RefValue 29 Agrega¸c˜ao Est´agio 1: Valor de referˆencia para compara¸c˜ao AggregStage2 InputCompOper 0x04 Agrega¸c˜ao Est´agio 2: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage2 RefValue 0 Agrega¸c˜ao Est´agio 2: Valor de referˆencia para compara¸c˜ao Configura¸c˜ao da Coleta 2 GroupDef 0x0109 Defini¸c˜ao da forma¸c˜ao do grupo MaxHops 3 Max hops do grupo TimerPeriod 1000 Per´ıodo da coleta do grupo AggregOper 0 Define a opera¸c˜ao de agrega¸c˜ao utilizada Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 85 Tabela B.6: Estrutura dos parˆametros de configura¸c˜ao para Aplica¸c˜ao 3 Campo Value Descri¸c˜ao Parˆametros Gerais GroupA 10 Parˆametro A utilizados na defini¸c˜ao de grupos ElectionPeriod 60 Per´ıodo para reelei¸c˜ao de coordenador (minutos) Configura¸c˜ao da Coleta 1 GroupDef 0x0109 Defini¸c˜ao da forma¸c˜ao do grupo MaxHops 7 Max hops do grupo TimerPeriod 30000 Per´ıodo da coleta do grupo LocalStage InputCompOper 0x00 Opera¸c˜ao Local: Identifica o sensor e a opera¸c˜ao de compara¸c˜ao LocalStage RefValue 0 Opera¸c˜ao Local: Valor de referˆencia para compara¸c˜ao AggregOper 4 Define a opera¸c˜ao de agrega¸c˜ao utilizada AggregStage1 InputCompOper 0x11 Agrega¸c˜ao Est´agio 1: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage1 RefValue 1 Agrega¸c˜ao Est´agio 1: Valor de referˆencia para compara¸c˜ao AggregStage2 InputCompOper 0x04 Agrega¸c˜ao Est´agio 2: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage2 RefValue 0 Agrega¸c˜ao Est´agio 2: Valor de referˆencia para compara¸c˜ao Configura¸c˜ao da Coleta 2 GroupDef 0x0001 Defini¸c˜ao da forma¸c˜ao do grupo MaxHops 3 Max hops do grupo TimerPeriod 0 Per´ıodo da coleta do grupo LocalStage InputCompOper 0x00 Opera¸c˜ao Local: Identifica o sensor e a opera¸c˜ao de compara¸c˜ao LocalStage RefValue 0 Opera¸c˜ao Local: Valor de referˆencia para compara¸c˜ao AggregOper 5 Define a opera¸c˜ao de agrega¸c˜ao utilizada AggregStage1 InputCompOper 0x11 Agrega¸c˜ao Est´agio 1: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage1 RefValue 0 Agrega¸c˜ao Est´agio 1: Valor de referˆencia para compara¸c˜ao AggregStage2 InputCompOper 0x00 Agrega¸c˜ao Est´agio 2: Identifica a entrada e a opera¸c˜ao de compara¸c˜ao AggregStage2 RefValue 0 Agrega¸c˜ao Est´agio 2: Valor de referˆencia para compara¸c˜ao Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 86 B.2.3 Tabelas FSM Apresentamos nas Tabelas B.7, B.8, B.9, B.10, B.11, B.12, B.13, as transi¸c˜oes das FSMs para as trˆes aplica¸c˜oes de referˆencia. Tabela B.7: Aplica¸c˜ao 1 - M´aquina de estados 1 (Inicializa¸c˜ao) Id Current State Parent Id Parent State Event Param Action New State Startup and General control 7 Begin 7 Begin booted S init() Initializing 7 Initializing 7 Initializing initDone S CollInit() Initiating Collections 7 Initiating Collections 7 Initiating Collections CollInitDone S dummy() Idle 7 Idle 7 Idle TimerFired S nextColl() Idle 7 Idle 7 Idle startCollection S dummy() Collecting 7 Idle 7 Idle CustomComm01 S startCustomTimer01() Suspended 7 Collecting 7 Collecting TimerFired S lostColl() Collecting 7 Collecting 7 Collecting endCollection S nextColl() Idle 7 Collecting 7 Collecting CustomComm01 S startCustomTimer01() Suspended 7 Suspended 7 Suspended CustomTimer01 S dummy() Idle 7 Suspended 7 Suspended TimerFired S nextColl() Suspended 7 Suspended 7 Suspended CustomComm01 S startCustomTimer01() Suspended 7 Suspended 7 Suspended endCollection S nextColl() Suspended 7 Suspended 7 Suspended startCollection S dummy() Suspended Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 87 Tabela B.8: Aplica¸c˜ao 1 - M´aquina de estados 2 (Alarme) Id Current State Parent Id Parent State Event Param Action New State Alarm - Lˆe valor local, se a compara¸c˜ao for T, agrega e sempre envia para EB 0 Begin 0 Begin CollInitDone S dummy() Waiting Start 0 Waiting Start 7 Collecting nextColl S readSensor() Reading Sensor 0 Waiting Start 7 Suspended nextColl S endCollection() Waiting Start 0 Reading Sensor 0 Reading Sensor readSensorDone S testTrigger() Testing Trigger 0 Reading Sensor 0 Testing Trigger readSensorDone E endCollection() Waiting Start 0 Testing Trigger 0 Testing Trigger testTriggerDone F endCollection() Waiting Start 0 Testing Trigger 0 Testing Trigger testTriggerDone T startAggreg() Aggregating 0 Aggregating 0 Aggregating AggregDone T sendBSAggSummary() Sending BS 0 Aggregating 0 Aggregating AggregDone F endCollection() Waiting Start 0 Sending BS 7 Collecting sendBSDone S sendCustom01() Sendind Custom 0 Sending BS 7 Suspended sendBSDone S endCollection() waiting Start 0 Sending BS 7 Collecting sendBSDone E sendCustom01() Sendind Custom 0 Sending BS 7 Suspended sendBSDone E endCollection() Waiting Start 0 Sendind Custom 0 Sendind Custom CustomCommDone S endCollection() Waiting Start Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 88 Tabela B.9: Aplica¸c˜ao 2 - M´aquina de estados 1 (Inicializa¸c˜ao) Id Current State Parent Id Parent State Event Param Action New State Startup and General control 7 Begin 7 Begin booted S init() Initializing 7 Initializing 7 Initializing initDone S CollInit() Initiating Collections 7 Initiating Collections 7 Initiating Collections CollInitDone S dummy() Idle 7 Idle 7 Idle TimerFired S nextColl() Idle 7 Idle 7 Idle startCollection S dummy() Collecting 7 Idle 7 Idle CustomComm01 S startCustomTimer01() Suspended 7 Collecting 7 Collecting TimerFired S lostColl() Collecting 7 Collecting 7 Collecting endCollection S nextColl() Idle 7 Collecting 7 Collecting CustomComm01 S startCustomTimer01() Suspended 7 Suspended 7 Suspended CustomTimer01 S dummy() Idle 7 Suspended 7 Suspended TimerFired S nextColl() Suspended 7 Suspended 7 Suspended CustomComm01 S startCustomTimer01() Suspended 7 Suspended 7 Suspended endCollection S nextColl() Suspended 7 Suspended 7 Suspended startCollection S dummy() Suspended Apˆendice B. Diagramas das FSMs e Parˆametros de Configura¸c˜ao 89 Tabela B.10: Aplica¸c˜ao 2 - M´aquina de estados 2 (Alarme) Id Current State Parent Id Parent State Event Param Action New State Alarm - Lˆe valor local, se a compara¸c˜ao for T, agrega, se resultado for verdadeiro envia para EB 0 Begin 0 Begin CollInitDone S dummy() Waiting Start 0 Waiting Start 7 Collecting nextColl S readSensor() Reading Sensor 0 Waiting Start 7 Suspended nextColl S endCollection() Waiting Start 0 Reading Sensor 0 Reading Sensor readSensorDone S testTrigger() Testing Trigger 0 Reading Sensor 0 Reading Sensor readSensorDone E endCollection() Waiting Start 0 Testing Trigger 0 Testing Trigger testTriggerDone F endCollection() Waiting Start 0 Testing Trigger 0 Testing Trigger testTriggerDone T startAggreg() Aggregating 0 Aggregating 0 Aggregating AggregDone T sendBSAggSummary() Sending BS 0 Aggregating 0 Aggregating AggregDone F endCollection() Waiting Start 0 Sending BS 7 Collecting sendBSDone S sendCustom01() Sendind Custom 0 Sending BS 7 Suspended sendBSDone S endCollection() waiting Start 0 Sending BS 7 Collecting sendBSDone E sendCustom01() Sendind Custom 0 Sending BS 7 Suspended sendBSDone E endCollection() Waiting Start 0 Sendind Custom 0 Sendind Custom CustomCommDone S endCollection() Waiting Start Apˆendice D. Interfaces e Componentes NesC do sistema 96 Tabela D.2: Novos componentes NesC Configura¸c˜ao M´odulo Interface AggregMainC.nc AggregMainP.nc AggregMainExt.nc AppMainAppC.nc AppMainC.nc BaseStationC.nc BaseStationP.nc BaseStation.nc CommMainC.nc CommMainP.nc CommMainExt.nc CommunicationC.nc CommunicationP.nc Communication.nc, CommunicationAux.nc dataQueueC.nc dataQueueP.nc dataQueue.nc FSMC.nc FSMP.nc FSM.nc FSMTable AggregC.nc, FSMTable AppC.nc, FSMTable CommC.nc, FSMTable GroupC.nc FSMTable.nc GroupMainC.nc GroupMainP.nc GroupMainExt.nc. GroupMainAux.nc LocalNodeC.nc LocalNodeP.nc LocalNode.nc, LocalNodeKey.nc MoteDataC.nc MoteData.nc, MoteDataLoad.nc, MoteDataOper.nc RTimerC.nc, RTimerP.nc VTimerC.nc VTimer.nc RTimerSecC.nc, RTimerSecP.nc VTimerSecC.nc VTimerSec.nc WSNDynBSAppC.nc WSNDynBSC.nc E Formata¸c˜ao dos arquivos de configura¸c˜ao XML Formato para o arquivo de Parˆametros <?xml version="1.0"?> <AppConfig> <Header> <StaticA>10</StaticA> <StaticB>20</StaticB> <StaticC>30</StaticC> <Ctimer01Delay>70</Ctimer01Delay> <Ctimer02Delay>70</Ctimer02Delay> <Ctimer03Delay>70</Ctimer03Delay> <Ctimer04Delay>70</Ctimer04Delay> <ElectionPeriod>8</ElectionPeriod> </Header> <CollConfig0> <GroupDef>0x0101</GroupDef> <MaxHops>10</MaxHops> <TimerPeriod>30000</TimerPeriod> <LocalStage_Input_CompOper>0x03</LocalStage_Input_CompOper> <LocalStage_RefValue>29</LocalStage_RefValue> <AggregOper>4</AggregOper> <AggregStage1_Input_CompOper>0x03</AggregStage1_Input_CompOper> <AggregStage1_RefValue>26</AggregStage1_RefValue> <AggregStage2_Input_CompOper>0x03</AggregStage2_Input_CompOper> <AggregStage2_RefValue>2</AggregStage2_RefValue> </CollConfig0> <CollConfig1> <GroupDef>0x0000</GroupDef> <MaxHops>0</MaxHops> <TimerPeriod>0</TimerPeriod> <LocalStage_Input_CompOper>0x00</LocalStage_Input_CompOper> <LocalStage_RefValue>0</LocalStage_RefValue> Apˆendice E. Formata¸c˜ao dos arquivos de configura¸c˜ao XML 98 <AggregOper>0</AggregOper> <AggregStage1_Input_CompOper>0x00</AggregStage1_Input_CompOper> <AggregStage1_RefValue>0</AggregStage1_RefValue> <AggregStage2_Input_CompOper>0x00</AggregStage2_Input_CompOper> <AggregStage2_RefValue>0</AggregStage2_RefValue> </CollConfig1> <CollConfig2> <GroupDef>0</GroupDef> <MaxHops>0</MaxHops> <TimerPeriod>0</TimerPeriod> <LocalStage_Input_CompOper>0x00</LocalStage_Input_CompOper> <LocalStage_RefValue>0</LocalStage_RefValue> <AggregOper>0</AggregOper> <AggregStage1_Input_CompOper>0x00</AggregStage1_Input_CompOper> <AggregStage1_RefValue>0</AggregStage1_RefValue> <AggregStage2_Input_CompOper>0x00</AggregStage2_Input_CompOper> <AggregStage2_RefValue>0</AggregStage2_RefValue> </CollConfig2> </AppConfig> Formato para o arquivo com a tabela FSM A seguir representamos a formata¸c˜ao para somente um registro de transi¸c˜ao. Uma configura¸c˜ao normal pode conter at´e 40 registros de transi¸c˜oes. <?xml version="1.0"?> <TranList> <TranReg> <MachineID>9</MachineID> <CurrState>1</CurrState> <ParentMachine>9</ParentMachine> <ParentState>1</ParentState> <Event>1</Event> <Param>0</Param> <Action>1</Action> <NewState>2</NewState> </TranReg> </TranList>