Adriano Francisco Branco. Um modelo de programação para RSSF com. Dissertação de Mestrado

Transcrição

1 Adriano Francisco Branco Um modelo de programação para RSSF com suporte à reconfiguração dinâmica de aplicações Dissertação de Mestrado Dissertação apresentada ao Programa de Pós graduação em Informática do Departamento de Informática do Centro Técnico Científico da PUC Rio como requisito parcial para obtenção do grau de Mestre em Informática. Orientador : Prof. Noemi de La Rocque Rodriguez Co Orientador: Prof. Silvana Rossetto Rio de Janeiro Abril de 2011

2 Adriano Francisco Branco Um modelo de programação para RSSF com suporte à reconfiguração dinâmica de aplicações Dissertação apresentada ao Programa de Pós graduação em Informática do Departamento de Informática do Centro Técnico Científico da PUC Rio como requisito parcial para obtenção do grau de Mestre em Informática. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Noemi de La Rocque Rodriguez Orientador Departamento de Informática PUC Rio Prof. Silvana Rossetto Co Orientador Departamento de Ciência da Computação UFRJ Prof. Luci Pirmez UFRJ Prof. Renato Fontoura de Gusmão Cerqueira Departamento de Informática PUC-Rio Dr. Renato Figueiró Maia Pesquisador PUC-Rio Prof. José Eugenio Leal Coordenador Setorial do Centro Técnico Científico PUC Rio Rio de Janeiro, 6 de Abril de 2011

3 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Adriano Francisco Branco Graduou se em Engenharia Eletrônica pelo Centro Federal de Educação Tecnológica Celso Suckow da Fonseca (CEFET/RJ). Trabalhou mais de 12 anos em consultoria de projetos de integração de sistemas, principalmente nas áreas de automação industrial e telecomunicações. Também tem passagem pela área de P&D, com trabalhos no CERN (Suíça) e CBPF/CNPq. Teve oportunidade de trabalhar em projetos de eletrônica digital de interfaces de comunicação, computadores 8 e 32 bits com CPUs CISC e RISC, sistemas de controles e aquisição de dados. Têm experiência em sistemas operacionais como CP/M, DOS, Windows, VMS e diversas variações de Unix. Trabalhou com integração de sistemas desenvolvendo ferramentas customizadas ou utilizando ferramentas comerciais para integração em tempo real, síncronas e assíncronas. Também tem grande experiência em gerência de projetos e coordenação de equipes de desenvolvimento de sistemas. Branco, Adriano Francisco Ficha Catalográfica Um modelo de programação para RSSF com suporte à reconfiguração dinâmica de aplicações / Adriano Francisco Branco; orientador: Noemi de La Rocque Rodriguez; co orientador: Silvana Rossetto f. : il. (color); 30 cm 1. Dissertação (mestrado) - Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Inclui bibliografia. 1. Informática Teses. 2. Rede de Sensores sem Fio (RSSF). 3. Sistemas Distribuídos. 4. Modelo de Programação. 5. Funções parametrizáveis. 6. Máquina de Estados Finitos (FSM). 7. Reconfiguração Dinâmica. I. Rodriguez, Noemi de La Rocque. II. Rossetto, Silvana. III. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. IV. Título. CDD: 004

4 Agradecimentos Aos meus orientadores Professores Noemi Rodriguez e Silvana Rossetto pelo apoio e incentivo para a realização deste trabalho. Ao CNPq e à PUC Rio, pelos auxílios concedidos, sem os quais este trabalho não poderia ter sido realizado. À minha esposa, que me acompanhou todo esse tempo com apoio direto e indireto. Aos meus pais, irmãos, família e amigos, que me apoiaram mesmo com minha ausência na vida familiar. A todos os colegas, professores e funcionários do Departamento de Informática da PUC-Rio, pelo companheirismo, aprendizado e auxílio.

5 Resumo Branco, Adriano Francisco; Rodriguez, Noemi de La Rocque; Rossetto, Silvana. Um modelo de programação para RSSF com suporte à reconfiguração dinâmica de aplicações. Rio de Janeiro, p. Dissertação de Mestrado Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. Algumas características básicas das redes de sensores sem fio (RSSF) dificultam as tarefas de criação e reconfiguração de aplicações. Nesse trabalho apresentamos um modelo de programação que pretende simplificar essas tarefas. O modelo se baseia no uso conjunto de funções parametrizáveis e de máquinas de estados finitos, e permite a implementação de diferentes tipos de aplicações para redes de sensores sem fio e a configuração remota dessas aplicações. Descrevemos alguns testes para avaliar o quanto esse modelo pode facilitar o desenvolvimento de novas aplicações, o quanto é fácil aplicar novas alterações sobre as aplicações em execução, e o impacto na quantidade de mensagens na rede por conta do uso da configuração remota. Palavras chave Rede de Sensores sem Fio (RSSF); Sistemas Distribuídos; Modelo de Programação; Funções parametrizáveis; Máquina de Estados Finitos (FSM); Reconfiguração Dinâmica.

6 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, p. MSc Dissertation Departamento de Informática, Pontifícia Universidade Católica 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.

7 Sumário 1 Introdução Abordagem Objetivos e contribuições Trabalhos relacionados Organização do documento 15 2 TinyOS e NesC NesC TinyOS 17 3 O modelo de programação proposto Padrões de interação para aplicações em RSSF Conjunto das funcionalidades básicas Controle de fluxo baseado em FSM Exemplo simplificado de aplicação do modelo de programação Reconfiguração 33 4 Implementação Visão operacional geral Etapas de operação Padrão de implementação para as camadas funcionais Exemplo de um fluxo de execução Experiências no desenvolvimento e novas funcionalidades 47 5 Avaliação Implementação das aplicações de referência Avaliação da facilidade de programação e do impacto da configuração remota 57 6 Conclusão Trabalhos futuros 67 7 Referências Bibliográficas 69 A Detalhamento dos padrões de interação 72 B Diagramas das FSMs e Parâmetros de Configuração 78 B.1 Aplicação utilizada nos testes 78 B.2 Aplicações de Referência 80 C Ambiente de execução para os testes 92 D Interfaces e Componentes NesC do sistema 94 E Formatação dos arquivos de configuração XML 97

8 Lista de figuras 3.1 Camadas da arquitetura de execução Arquitetura com as funcionalidades básicas Arquitetura de controle da FSM Sintaxe FSM e exemplo de tabela de transições Aplicação exemplo - coleta periódica de temperatura Módulos utilizados na estação servidora Arquitetura básica das camadas funcionais Configuração para uma aplicação de monitoração de temperatura FSM para monitoração periódica da temperatura média Exemplo de fluxo de execução para uma aplicação de agregação Aplicação 1 - FSM para inicialização do mote e controle geral da aplicação Aplicação 1 - FSM para geração do alarme Rede de referência (a) FSM para controle de uma aplicação de coleta e (b) Definição dos respectivos parâmetros Distribuição no tempo de cada etapa de operação (a) FSM para controle de uma aplicação de alarme e (b) Definição dos respectivos parâmetros 62 B.1 Aplicação 1 - FSM para Inicialização do Mote e controle geral 80 B.2 Aplicação 1 - FSM para geração do alarme 80 B.3 Aplicação 2 - FSM para Inicialização do Mote e controle geral 81 B.4 Aplicação 2 - FSM para geração do alarme 81 B.5 Aplicação 2 - FSM para monitoração periódica 82 B.6 Aplicação 3 - FSM para Inicialização do Mote e controle geral 82 B.7 Aplicação 3 - FSM para monitoração periódica 82 B.8 Aplicação 3 - FSM para reserva de vagas 83 C.1 Módulos utilizados para execução dos testes no simulador 92

9 Lista de tabelas 3.1 Padrões de interação identificados Estrutura dos parâmetros de configuração Campos de um registro da tabela de transições Principais ações e eventos disponíveis para a aplicação Biblioteca de funções parametrizáveis Transições utilizadas para o exemplo de fluxo Primeiro Teste: Resultado para as métricas da implementação no modelo proposto Sumarização da quantidade de mensagens enviadas para cada etapa e os respectivos contadores Quantidade de mensagens enviadas para cada tipo de operação Primeiro Teste: Resultado para as métricas da implementação alternativa em NesC Segundo Teste: Resultado para as métricas da implementação no modelo proposto Quantidade de envios para a operação de reconfiguração remota Segundo Teste: Resultado para as métricas da implementação alternativa em NesC Resumo comparativo entre as duas implementações 65 A.1 Distribuição dos Padrões de interação X Suporte de comunicação 73 A.2 Padrões Identificados 74 B.1 Configuração da primeira FSM do primeiro teste 78 B.2 Configuração da segunda FSM do primeiro teste 79 B.3 Configuração da terceira FSM utilizada no segundo teste 79 B.4 Estrutura dos parâmetros de configuração para Aplicação 1 83 B.5 Estrutura dos parâmetros de configuração para Aplicação 2 84 B.6 Estrutura dos parâmetros de configuração para Aplicação 3 85 B.7 Aplicação 1 - Máquina de estados 1 (Inicialização) 86 B.8 Aplicação 1 - Máquina de estados 2 (Alarme) 87 B.9 Aplicação 2 - Máquina de estados 1 (Inicialização) 88 B.10 Aplicação 2 - Máquina de estados 2 (Alarme) 89 B.11 Aplicação 2 - Máquina de estados 3 (Monitoração) 90 B.12 Aplicação 3 - Máquina de estados 1 (Inicialização) 90 B.13 Aplicação 3 - Máquina de estados 2 (Monitoração) e 3 (Reserva) 91 D.1 Interfaces das Camadas Funcionais 94 D.2 Novos componentes NesC 96

10 1 Introdução As Redes de Sensores Sem Fio (RSSF) são constituídas por pequenos dispositivos computacionais (chamados motes) com capacidade de sensoreamento físico e severas restrições em termos de capacidade de processamento, armazenamento e consumo de energia. Essas redes são usadas em aplicações de monitoramento e requerem normalmente um grande número de nós implantados diretamente no meio físico. Algumas aplicações necessitam que os nós sejam distribuídos em grandes espaços geográficos ou em regiões de difícil acesso. O trabalho de desenvolvimento de aplicações para RSSF é impactado pelos mesmos desafios encontrados no desenvolvimento de aplicações para sistemas distribuídos que utilizam plataformas tradicionais. Porém, alguns desses desafios são aumentados pela escassez de recursos computacionais dos motes, pelo modelo de programação tipicamente adotado que é orientado a eventos e pela tecnologia de comunicação sem fio com características de redes ad-hoc. Por outro lado, em boa parte dos casos, as aplicações que executam nas RSSF seguem uma estrutura comum de execução, permitindo identificar funcionalidades que se repetem em diferentes cenários. Por exemplo, funcionalidades locais, como a leitura periódica de sensores e o envio dos dados coletados para uma estação base; ou funcionalidades distribuídas, como a fusão ou agregação das medidas coletadas por nós vizinhos. Um dos desafios típicos da computação distribuída que tem a sua complexidade aumentada no cenário de RSSF é a necessidade de realizar ajustes na aplicação após a sua implantação. Esses ajustes podem ser uma simples alteração no período de monitoração, uma correção no fluxo de processamento ou até a ativação ou desativação de pequenas funcionalidades. A plataforma de software de uso mais comum para o desenvolvimento de aplicações em RSSF não disponibiliza, de forma nativa, opções para reconfiguração remota após a implantação da aplicação e, na maioria dos casos, é inviável recuperar todos os motes para aplicar novas alterações. As alternativas mais comuns para reprogramação dos nós sensores envolvem a carga remota e substituição de componentes inteiros, dessa forma, indo muito além de uma simples reconfi-

11 Capítulo 1. Introdução 11 guração e podendo consumir mais recursos da rede do que o necessário. Uma solução para esses desafios é disponibilizar para o desenvolvedor um conjunto de funcionalidades básicas que possam ter a sua execução definida por meio de alguns parâmetros, e de um controle de fluxo simplificado. Esse conjunto de funcionalidades representaria alguns padrões de interação típicos de RSSF e pode ser visto como uma biblioteca de funções pronta para uso, atendendo a diversos tipos de aplicações. Essa biblioteca atenderia basicamente as aplicações de monitoração e alarme, incluindo o controle de roteamento de mensagens pela rede. Alguns componentes mais específicos poderiam ser adicionados em tempo de projeto. Essa solução permite a simplificação do desenvolvimento de novas aplicações, minimizando as dificuldades da programação distribuída e evitando a necessidade de escrever códigos na linguagem nativa da plataforma. Também possibilita a implementação de um processo de reconfiguração remota em ponto pequeno, por meio do envio de parâmetros de configuração dos componentes da aplicação, ao invés da abordagem de substituição de componentes inteiros. Tudo isso permite uma mudança no perfil do desenvolvedor. O novo desenvolvedor não precisa conhecer os detalhes de programação no nível mais baixo e poderá direcionar os esforços para o entendimento e configuração da aplicação. O foco principal do nosso trabalho é baseado nessa ideia, e visa minimizar as dificuldades de desenvolvimento e reconfiguração de aplicações para RSSF incorporando no próprio modelo de programação a capacidade de reconfiguração das aplicações em tempo de execução e a possibilidade de reutilizar padrões de interação comuns entre os nós da rede. 1.1 Abordagem Para a identificação do conjunto básico de funcionalidades que irão compor a nossa biblioteca de funções, tomamos como referência padrões de interação típicos das aplicações para RSSF. Esses padrões são identificáveis, pois, de forma geral, as aplicações em RSSF executam operações semelhantes, como por exemplo a leitura periódica de sensores, a fusão de dados envolvendo grupos de nós vizinhos e o roteamento de mensagens até a estação base. Para obtermos uma gama razoável de padrões, procuramos diferentes fontes, incluindo exemplos de aplicações para RSSF e propostas de modelos para macroprogramação em RSSF. A ideia de macroprogramação em RSSF toma como base que toda aplicação requer naturalmente a interação entre os nós individuais, então, ao invés de projetar as aplicações a partir do código de cada nó, propõe-se o inverso, que a aplicação seja projetada considerando a

12 Capítulo 1. Introdução 12 rede como um todo e que em uma etapa seguinte o código necessário seja instanciado em cada nó individual. Por isso os modelos de macroprogramação, normalmente, incluem alguns padrões de interação típicos. Para definir o controle de fluxo usamos a ideia de máquinas de estados finitos (Finite State Machine) (FSM). No modelo de FSM temos um motor de execução que, de acordo com o estado corrente, dispara ações de saída a partir de eventos de entrada. Com isso o desenvolvedor pode indicar quais funcionalidades irá utilizar e qual será a sequência de operação das mesmas. O controle de fluxo proposto permite a criação de várias máquinas de estado dentro de uma mesma aplicação e ainda possibilita a dependência entre estados de diferentes máquinas, facilitando a construção de aplicações mais complexas, ou a visão de uma mesma RSSF usada para diferentes finalidades. Tanto o fluxo da FSM quanto o comportamento funcional de cada componente da aplicação são definidos por parâmetros. A possibilidade de configuração dinâmica é alcançada simplesmente permitindo que esses parâmetros sejam alterados remotamente. Como exemplo, em uma aplicação de coleta periódica de temperatura, pode-se alterar o período de coleta ou alterar o fluxo operacional para calcular a média da temperatura dos nós do mesmo grupo. Também é possível adicionar, em tempo de execução, um novo fluxo para essa aplicação, como um alarme de temperatura alta, mantendo o fluxo anterior inalterado. 1.2 Objetivos e contribuições Nesta seção apresentamos os objetivos do nosso trabalho e detalhamos as principais etapas para alcançar esses objetivos. Também identificamos as principais contribuições geradas ao término do trabalho Objetivo Geral O nosso objetivo principal é estudar um modelo de programação que facilite a construção de novas aplicações e que permita, de forma simples, a reconfiguração remota dessas aplicações Objetivo Detalhado Para alcançarmos o objetivo proposto, dividimos o trabalho em etapas. A seguir, identificamos essas etapas e descrevemos o objetivo de cada uma.

13 Capítulo 1. Introdução 13 Identificação do conjunto de funcionalidades básicas - O objetivo dessa etapa é identificar e definir um conjunto de funcionalidades básicas que possam suportar a construção de diversos tipos de aplicações para RSSF. Complementando o conjunto de funcionalidades, incluímos a definição do conjunto de parâmetros que permitirão ajustes no comportamento dessas funcionalidades. Definição do controle de fluxo - Nessa etapa definimos um mecanismo de controle de fluxo das aplicações baseado em máquinas de estados finitos, assim como o conjunto de eventos e ações básicas que serão usados pelas aplicações. Implementação - Nessa etapa implementamos a nossa biblioteca de funções parametrizáveis, que representam o conjunto de funcionalidades básicas definidas. Também implementamos a infraestrutura para o controle de fluxo e os módulos de suporte para reconfiguração remota. Avaliação - Essa etapa teve o objetivo de avaliar o quanto é simples a programação de aplicações para RSSF usando o modelo proposto, e qual é o impacto da reconfiguração remota na vida útil da rede. 1.3 Trabalhos relacionados Um dos primeiros trabalhos a propor simplificação para programação de plataformas de sensores no estilo motes foi o TinyDB[1]. O TinyDB disponibiliza um conjunto de funções para agregações simples e permite reconfigurar a coleta de dados da rede por meio de comandos remotos baseados numa linguagem simplificada do estilo SQL. O TinyDB limita-se às aplicações com características de coleta de dados, com possibilidade de agregações em uma topologia hierárquica de roteamento e sem interação local entre os nós da rede. A nossa proposta disponibiliza um conjunto maior de funções para agregações com a possibilidade de reconfiguração, mas, diferentemente do TinyDB, a agregação é feita a partir de grupos locais de nós e enviada para o nó raiz. O nosso modelo de agregação não fica restrito à topologia da árvore de roteamento. Um conjunto de trabalhos mais recentes, com foco em modelos de programação mais adequados para RSSF, está ligado ao conceito de macroprogramação. Dentre os representantes dessa linha, destacamos Regiment[2] e Cosmos[3]. A macroprogramação em RSSF visa simplificar o processo de construção de novas aplicações, disponibilizando ao desenvolvedor abstrações

14 Capítulo 1. Introdução 14 simplificadas para operações mais complexas, principalmente operações distribuídas entre grupos de nós. No conceito de macroprogramação, o programador é habilitado a trabalhar com uma abstração em que a rede é um sistema composto por grupos de sensores. Essa abstração permite a geração de programas de uma forma mais simples. Uma dificuldade encontrada nessas soluções é que, embora a visão de programação da rede como um todo seja mais adequada, em geral os componentes básicos que devem ser executados nos nós individuais ainda precisam ser implementados diretamente pelo desenvolvedor, desviando a atenção para os nós individuais em uma etapa seguinte ao projeto da aplicação. O foco do nosso trabalho é justamente o desenvolvimento desses componentes básicos, incluindo algumas soluções que facilitam o processamento distribuído, como agregações de valores e roteamento de mensagens. Dentre os trabalhos que abordam a reprogramação remota, temos os que utilizam um modelo de máquina virtual simplificado, como Maté [4], ou os trabalhos baseados no DELUGE [5] que carregam o programa original na linguagem nativa. A linguagem utilizada por Maté é bem simples e permite acesso apenas aos recursos básicos do mote, não disponibilizando uma biblioteca de componentes de alto nível que facilite a construção de novas aplicações. Os trabalhos que utilizam o DELUGE precisam fazer a carga completa da aplicação em conjunto com o sistema operacional. Abordagens mais recentes possibilitam a recarga em separado de componentes originais da aplicação [6], permitindo reduzir o custo da reprogramação remota. O nosso modelo permite a reconfiguração do controle de fluxo e dos parâmetros de funcionamento dos componentes. Dessa forma, o desenvolvedor pode reconfigurar as operações mais complexas, não necessitando recarregar o código executável da aplicação e do sistema operacional. O trabalho de Kasten e Romer propõe um modelo de programação baseado em máquinas de estados para RSSF, chamado OSM [7], cujo objetivo é simplificar a programação dos motes. OSM utiliza um processo de compilação para gerar código na linguagem nativa dos nós sensores e não aplica o conceito de reprogramação. Como outros trabalhos, OSM também considera que o desenvolvedor deve construir os componentes mais básicos na linguagem de programação dos nós sensores. Como OSM, o nosso modelo utiliza o conceito de FSM para o controle de fluxo. No nosso caso, a configuração da FSM é interpretada, enquanto que em OSM, é compilada para a plataforma de execução. Inspirado em sistemas multiagentes e inteligência artificial distribuída, temos RuleCaster [8]. RuleCaster usa a linguagem RCAL, um compilador e

15 Capítulo 1. Introdução 15 um ambiente de execução. Com RCAL o programador especifica as regras das transições entre estados e as possíveis ações. O compilador converte o programa RCAL em atividades que são distribuídas aos nós. O sistema de execução interpreta essas atividades, reagindo aos eventos e atuando com ações. Essas atividades geradas pelo compilador funcionam como uma linguagem intermediária e, associadas ao interpretador do sistema de execução, permitem a reconfiguração remota. O conceito de FSM utilizado no nosso modelo é equivalente ao conceito de linguagem intermediária de RCAL. A diferença é que disponibilizamos previamente um conjunto de funcionalidades para serem utilizadas pela nossa linguagem intermediária. Com foco específico num modelo para Finite State Machine (FSM) temos Statecharts[9] e Statemate[10]. O modelo de Statecharts propõe uma notação gráfica para configuração de máquinas de estados, permitindo combinações complexas como paralelismo e hierarquias. Statemate define uma semântica para o modelo de Statecharts. O nosso modelo de programação foi inspirado no mesmo modelo de Statecharts. No nosso caso, as atividades são definidas por uma tabela de transição de estados que representa uma FSM. O nosso principal diferencial em relação aos trabalhos citados acima é a combinação de um mecanismo para configuração do fluxo de processamento da aplicação com uma biblioteca de funções parametrizáveis, a partir da qual, em boa parte dos casos, o desenvolvedor não precisará construir nenhum componente adicional. Essa abordagem permitiu combinar no nosso modelo os principais pontos atendidos de forma isolada em outros trabalhos. 1.4 Organização do documento No capítulo 2, apresentamos, para contextualizar a leitura dos capítulos seguintes, o ambiente de desenvolvimento do TinyOS/NesC. Os três capítulos seguintes apresentam a execução do trabalho. O capítulo 3 apresenta o modelo de programação proposto. O capítulo 4 apresenta a implementação do sistema utilizando os recursos do TinyOS. No capítulo 5 mostramos o processo e a execução dos testes de avaliação do nosso trabalho. Para finalizar, o capítulo 6 apresenta as conclusões do trabalho em função dos objetivos iniciais. Nos apêndices é possível encontrar algumas informações complementares citadas durante o texto principal.

16 2 TinyOS e NesC O framework de programação mais utilizado em redes de sensores sem fio é composto pelo sistema operacional TinyOS [11] e pela linguagem de programação NesC [12]. A linguagem NesC foi definida em resposta a alguns desafios encontrados na programação em ambientes de redes de sensores sem fio. Para isso seu modelo seguiu alguns princípios, um deles é suportar o desenho do TinyOS. O TinyOS foi todo escrito em NesC e apresenta um modelo de execução específico para dispositivos de baixa potência como os utilizados em redes de sensores sem fio. Apesar de NesC ser uma linguagem de programação e TinyOS um sistema operacional, alguns dos seus objetivos se misturam e outros se complementam. Do ponto de vista do usuário, a programação de uma aplicação é uma extensão do sistema operacional. 2.1 NesC Seguem alguns dos principais desafios impostos à linguagem NesC: Ser orientado a interações com o ambiente - as aplicações devem reagir a mudanças do ambiente, como a leitura de um sensor, e estar preparadas para a concorrência de atividades, como a chegada de um evento durante o processamento de dados; Recursos limitados - Os motes têm recursos físicos limitados devido aos objetivos de tamanho pequeno, baixo custo e baixo consumo de energia; Confiabilidade - A aplicação deve funcionar por longos períodos sem apresentar defeitos, por exemplo uma aplicação de monitoração ambiental deve funcionar meses sem interação humana; Flexibilização do requisito de tempo real - Apesar de algumas atividades serem críticas, como o gerenciamento do rádio ou a amostragem dos sensores, a experiência mostra que é possível atingir essas restrições de tempo com um bom controle da aplicação e limitando o uso de recursos. A concepção de NesC utilizou os seguintes princípios básicos:

17 Capítulo 2. TinyOS e NesC 17 Ser uma extensão de C - C produz código eficiente para todos os microcontroladores normalmente utilizados em dispositivos para redes de sensores sem fio; Ser uma linguagem estática - Não tem alocação dinâmica e o grafo de chamadas é conhecido em tempo de compilação, facilitando a análise citada no item anterior; Suportar e refletir o desenho do TinyOS - Suporta os conceitos de TinyOS para componentes e concorrência. Finalmente, o modelo de programação de NesC expõe ao usuário os seguintes itens: Execução orientada a eventos - As interações internas à aplicação utilizam comandos (actions) e funções de retorno (signals); Modelo flexível de concorrência - provê ferramentas para postar tarefas (tasks) e controlar seções atômicas; Desenho da aplicação orientado a componentes - utiliza um modelo de componentes onde os módulos (modules) implementam as interfaces dos componentes e as configurações (configurations) interligam os módulos. Na prática um programa NesC é composto por um conjunto de componentes (modules) que implementam serviços definidos por interfaces (interfaces). Esses componentes podem ser interligados (wired), via interfaces, pelas definições dos arquivos de configurações (configurations). Esse modelo permite que se tenha diferentes implementações para a mesma interface, onde o arquivo de configuração é que vai indicar qual será a implementação utilizada. Tudo isso facilita a definição de aplicações para diferentes plataformas, necessitando somente criar novos componentes de acesso à nova plataforma e manter a definição da interface original. 2.2 TinyOS TinyOS procura atender algumas características típicas das aplicações em rede de sensores sem fio que diferem das características dos sistemas convencionais. Essas aplicações normalmente operam de forma autônoma por longo tempo, sendo feitas para coletar dados, responder a um ambiente imprevisível e são sem fio. Para endereçar essas características, TinyOS usa uma arquitetura baseada em componentes, um modelo de execução baseado em eventos e tarefas e permite operações em duas fases (split-phase).

18 Capítulo 2. TinyOS e NesC 18 TinyOS provê um ambiente de desenvolvimento composto por uma biblioteca de componentes e algumas ferramentas que simplificam o procedimento de construção de novas aplicações. Por se tratar de um sistema operacional para plataformas com recursos limitados, o TinyOS não funciona como um sistema operacional convencional, acima do qual se executam as aplicações do usuário, mas sim como uma biblioteca que deve ser ligada com essas aplicações para construir um único programa executável e que deve ser carregado em cada nó sensor. Uma das principais características do TinyOS é facilitar a utilização de diversas plataformas de hardware. A utilização do modelo de componentes de NesC possibilita grande modularidade, permitindo que o TinyOS contenha componentes prontos para acessar diferentes tipos de hardwares. A seleção dos componentes adequados para cada hardware é feita durante o processo de compilação e de forma transparente para o usuário. Uma outra característica importante que o TinyOS usa de NesC é o modelo orientado a eventos. Esse modelo segue o funcionamento natural das interfaces de hardware que normalmente integram esses dispositivos. Também possibilita uma operação de baixo consumo de energia, pois o processamento só 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ção é quebrado em duas fases. Primeiro uma função é chamada para iniciar a conversão, essa função tem retorno imediato. Quando a conversão é finalizada, é disparada a execução de uma função de callback que então deverá processar o resultado da leitura. Esse tipo de operação, as vezes chamada de split-phase, é amplamente utilizada nos outros componentes como a interface de rádio ou o temporizador interno. O modelo de execução do TinyOS gerencia as tarefas (tasks) NesC numa fila de execução para serem executadas oportunamente. As tarefas são executadas até o final e só podem ser interrompidas para execução de uma função de tratamento de interrupção de hardware. Isso exclui possíveis condições de corrida entre tarefas, mas não exclui a possibilidade de acontecer com uma função de tratamento de interrupção de hardware. Para os casos em que possam acontecer condições de corrida, sugere-se a quebra do código em tarefas, explicitando os pontos de possíveis interferências. Ainda assim, NesC permite marcar seções do código para execução atômica. Durante a execução de uma seção atômica, o sistema desliga as interrupções. Resumimos os principais pontos fortes do TinyOS em uma grande biblioteca de componentes para vários tipos de hardwares e em um código robusto e seguro, consequência de cinco anos de amadurecimento do modelo,

19 Capítulo 2. TinyOS e NesC 19 e utilizado por milhares de desenvolvedores. Como consequência do modelo adotado no TinyOS, podemos identificar algumas dificuldades encontradas pelo programador: Uma longa curva de aprendizado tanto para o modelo de programação orientado a eventos (split-phase) quanto para o modelo de interface/- componentes do NesC. A recomendação de manter as tarefas curtas também aumenta a dificuldade para escrever programas que requerem computação intensiva. A manutenção da aplicação após a implantação 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ádio, todo o executável Tecnologia O TinyOS pode ser executado em uma variedade de dispositivos que combinam diversos microcontroladores, chips de rádios e de armazenamento. A referência [13] apresenta uma lista com as características de vários motes comerciais e protótipos, incluindo os suportados pelo TinyOS. Nessa lista o TinyOS é o sistema operacional mais utilizado, sendo utilizado por 60% dos motes. O processo de compilação no ambiente TinyOS é disparado pelo comando ncc que invoca o compilador NesC, que por sua vez invoca o compilador GCC. O comando ncc é específico do TinyOS e converte alguns parâmetros para os dois procedimentos de compilação seguintes, selecionando também os componentes da biblioteca do TinyOS adequados ao hardware indicado. O compilador NesC - nescc - gera, a partir do código NesC do usuário e do TinyOS, um código C que contém o sistema operacional e a parte da aplicação do usuário. O compilador C - gcc - gera o código executável. Nesse procedimento é indicado o microprocessador utilizado pelo hardware. Além das ferramentas para compilação e carga, o TinyOS disponibiliza a ferramenta TOSSIM[14] que permite a simulação de uma rede de nós executando a aplicação do usuário. Para a execução da simulação deve-se criar um script em Python ou um programa em C++ que, por meio de funções da biblioteca do TOSSIM, ativam nós e definem quais nós podem se comunicar via rádio.

20 Capítulo 2. TinyOS e NesC 20 Principais funcionalidades As principais APIs oferecidas pelo TinyOS são Booting - Controla a inicialização do componente; Communication - Implementa diversos protocolos como Single-hop, Multihop collection, Multihop dissemination e Binary reprogramming; Time - Suporte para criação 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úmeros randômicos, acesso aos Leds e cálculo de CRC; Low- Power - Suporte para operação em baixa potência.

21 3 O modelo de programação proposto O modelo de programação proposto utiliza como base um conjunto de funcionalidades básicas que podem ser combinadas por meio de um controle de fluxo baseado em máquinas de estados finitos (FSM). Conforme dito na seção 1.1, esse conjunto de funcionalidades representa padrões de interação típicos de aplicações para RSSF. Podemos dizer que os padrões de interação estão no nível da execução de uma linguagem de macroprogramação em RSSF citado na seção 1.3, enquanto que o conjunto de funcionalidades básicas equivalem ao nível de uma linguagem que é executada em cada mote. Esse conjunto de funcionalidades básicas pode ser visto como uma biblioteca de ações e eventos. Com isso o controle de fluxo da máquina de estado pode comandar ações e reagir a eventos dessa biblioteca. Para completar o nosso modelo de programação, possibilitamos que o comportamento de algumas funcionalidades básicas possa ser configurado por meio de parâmetros. Nas próximas seções vamos, primeiramente, apresentar o nosso conjunto de padrões de interação e a respectiva biblioteca de funções. Em seguida vamos descrever o funcionamento do controle de fluxo baseado em FSM para depois apresentar um pequeno exemplo de utilização do nosso modelo. 3.1 Padrões de interação para aplicações em RSSF Entendemos que o requisito de facilidade de programação depende diretamente do conjunto de padrões de interação proposto. Esses padrões de interação devem representar funcionalidades genéricas e ao mesmo tempo devem ser suficientemente expressivos para poder atender diferentes tipos de aplicações em RSSF, i.e., deve ser possível construir diversas aplicações a partir da combinação desses padrões. Optamos por consolidar a lista de padrões de interação a serem oferecidos a partir da análise de duas diferentes fontes de informação. A primeira fonte foi um conjunto de aplicações encontradas na literatura e a segunda fonte foi a demanda gerada pelos modelos de macroprogramação. Os modelos de macroprogramação considerados foram analisados em [15].

22 Capítulo 3. O modelo de programação proposto 22 A seguir apresentamos cada fonte analisada e o resultado final com a lista consolidada. No apêndice A apresentamos, com mais detalhes, o procedimento utilizado e os padrões identificados para cada fonte Operações típicas das aplicações em RSSF Para identificar as operações típicas das aplicações escolhemos três aplicações para RSSF com diferentes comportamentos funcionais. Essas aplicações foram inspiradas em alguns exemplos retirados da literatura sobre RSSF, principalmente de [2], [16] e [17]. A partir das operações necessárias para cada aplicação foi possível identificar alguns padrões de interação. A seguir apresentamos cada aplicação. Aplicação 1 - Alarme de incêndio florestal O objetivo da aplicação é detectar rapidamente focos de incêndio em florestas. Para isso os sensores são distribuídos em regiões da floresta de forma que se possa identificar a região do alarme. Os nós ficam executando periodicamente uma leitura do sensor de temperatura. Caso um nó detecte uma leitura de temperatura maior que um valor predefinido, este deve verificar se as temperaturas dos nós vizinhos estão próximas da temperatura de alarme. A condição de alarme será confirmada se pelo menos dois nós vizinhos estiverem com o valor de temperatura maior que um valor percentual do valor de alarme. Nesse caso será enviada uma mensagem para a estação servidora. Essa mensagem deve conter a temperatura medida e o identificador do nó. O nó ativado deve notificar os nós vizinhos que um alarme já foi enviado. Um nó só pode gerar um novo alarme para sua região caso já tenham se passado pelo menos 60 minutos da última notificação de alarme. Aplicação 2 - Monitor de temperatura e Alarme de incêndio predial Essa aplicação usa um conjunto de sensores com capacidade de leitura de temperatura com duplo objetivo: monitorar a temperatura média dos ambientes do prédio (controle do conforto ambiental) e gerar alarmes em caso de incêndio. Os nós são distribuídos pelo edifício e cada ambiente define um grupo de nós. Para a monitoração, cada nó faz uma leitura periódica do sensor de temperatura e envia o valor para o coordenador do grupo. O coordenador do grupo calcula a média das temperaturas de todos os nós do grupo, e, em seguida, envia para a central de controle uma mensagem com o valor calculado.

23 Capítulo 3. O modelo de programação proposto 23 Uma outra leitura periódica é usada para o alarme de incêndio. Se o valor estiver acima do valor de alarme predefinido, o nó deve consultar os nós vizinhos do mesmo grupo e verificar quantos nós estão com valores acima de 90% do valor de alarme. Independentemente dos valores respondidos, o nó ativo deve enviar uma mensagem de alarme com o quorum da consulta para a central de controle. Sempre que um alarme é gerado, o nó ativado deve notificar os nós vizinhos que esse alarme já foi enviado. Um nó só pode gerar um novo alarme para seu ambiente caso já tenha passado pelo menos um minuto da última notificação de alarme. Aplicação 3 - Estacionamento urbano e Monitoração de vagas Essa aplicação auxilia motoristas na reserva de uma vaga de estacionamento. Também informa para uma central de controle a situação das vagas em cada região. Para isso usa um conjunto de sensores distribuídos pelas vagas de estacionamento da rua. Esses sensores indicam se a vaga está ocupada ou não. Os nós sensores são agrupados por região (CEP, bairro ou Rua). Para a busca de vagas, o veículo, também equipado com um nó sem fio, envia uma mensagem para os nós vizinhos solicitando a reserva de uma vaga disponível. Todos os nós respondem com a situação da respectiva vaga e os nós com vaga não ocupada fazem uma pré-reserva com a identificação do nó solicitante. O nó solicitante seleciona um dos nós disponíveis e responde para os vizinhos a sua escolha, de forma a confirmar a vaga selecionada e liberar o restante das vagas. Então o nó selecionado responde a confirmação da seleção para o nó solicitante. Se ocorrer a situação de mais de uma solicitação durante o processo de negociação, os nós das vagas disponíveis devem responder de acordo com a ordem do recebimento. Na monitoração, cada nó envia periodicamente para o nó coordenador do grupo a informação da sua vaga. O nó coordenador sumariza a situação da região e envia uma mensagem com os contadores de vagas para a central de controle Elementos utilizados nos modelos de macroprogramação Os modelos de macroprogramação são uma fonte natural para identificação dos padrões de interação de interesse. No nosso caso analisamos os modelos de macroprogramação apresentados em [15]: Regiment[2, 18]; Pleiades[17]; Cosmos[3]; TinyDB[1]; WADL[16]; ATaG[19].

24 Capítulo 3. O modelo de programação proposto 24 Os principais padrões encontrados foram relativos à comunicação. Identificamos padrões para diferentes formações de grupos de nós e a possibilidade de aplicar funções agregadoras nesses grupos. Também identificamos padrões para comunicação com a estação servidora Padrões de interação identificados Na Tabela 3.1 apresentamos o resultado final da consolidação para os padrões de interação. No apêndice A apresentamos com mais detalhes a análise utilizada para a identificação e consolidação dos padrões. Elemento Tabela 3.1: Padrões de interação identificados Descrição Grupo: Comunicação Envia EB Envia uma mensagem do nó em execução para a Estação Servidora. Envia Nó Envia uma mensagem do nó em execução para um nó específico dentro do grupo. Envia Pai Envia uma mensagem do nó em execução para o nó Pai na hierarquia topológica. Envia Filhos Envia uma mensagem do nó em execução para os nós Filhos na hierarquia topológica. Grupo: Funções de agregação Média Grupo Calcula o valor médio de valores distribuídos pelos nós do grupo. Somatório Grupo Calcula a soma de valores distribuídos pelos nós do grupo. Máximo Grupo Calcula o valor máximo dentre os valores distribuídos pelos nós do grupo. Mínimo Grupo Calcula o valor mínimo dentre os valores distribuídos pelos nós do grupo. Sumário Grupo Sumariza os estados dos nós distribuídos num grupo. Reserva Recurso Grupo Reserva de um determinado recurso dos nós do grupo. Baseado na negociação entre o nó ativo e o nós do grupo. Agrega Grupo Gera um vetor de dados com os respectivos valores dos nós de um grupo. Grupo: Funções Locais Evento Timer Configura um temporizador para execução de um procedimento. Evento Condição de leitura sensor Configura uma condição de leitura de sensor para execução de um procedimento. Evento Condição Configura uma condição de um cálculo de agregação de cálculo de para execução de um procedimento. agregação Continua na próxima página...

25 Capítulo 3. O modelo de programação proposto 25 Elemento Evento Condição de mensagem recebida Grupo: Agrupamentos Vizinhos 1-hop Vizinhos n-hops Parâmetros Estáticos Parâmetros Dinâmicos Filhos Filhos n- camadas Rede Tabela 3.1: Padrões de interação continuação Descrição Configura uma condição de um código de mensagem recebida para execução de um procedimento. Define um grupo de nós vizinhos do nó em execução ao alcance do sinal de rádio. Implementado com mensagem broadcast. Define um grupo de nós vizinhos do nó em execução ao alcance de até n saltos. Implementado com mensagem broadcast e subsequentes reencaminhamentos de mensagens pelos nós vizinhos. Define um grupo de nós da rede que atendam uma determinada condição que não varia no tempo. Define um grupo de nós da rede que atendam uma determinada condição que pode variar no tempo. Define um grupo de nós imediatamente abaixo na hierarquia topológica da rede. Define um grupo de nós imediatamente abaixo n camadas na hierarquia topológica da rede. Define o grupo de todos os nós da rede. 3.2 Conjunto das funcionalidades básicas Nessa seção vamos identificar e detalhar o conjunto das funções oferecidas para disponibilizar os padrões de interação identificados. Na próxima subseção (3.2.1), apresentamos a arquitetura proposta com a abordagem que estamos considerando para a implementação da nossa biblioteca. Na subseção 3.2.2, discutimos as operações que dependem da comunicação na rede. Em seguida, na subseção 3.2.3, propomos um conjunto de parâmetros que permitem a simplificação da quantidade de funções e ao mesmo tempo facilitam a implementação do procedimento de reconfiguração remota. Finalmente apresentamos a biblioteca de funções na seção Arquitetura da biblioteca de funções Para uma melhor identificação das funções, utilizamos uma arquitetura em camadas. Essa arquitetura divide as funcionalidades básicas em diferentes funções, mas que colaboram entre si para atender aos requisitos dos padrões de interação.

26 Capítulo 3. O modelo de programação proposto 26 Com essa arquitetura temos a maioria das operações disparadas pela aplicação local, mas também temos algumas operações disparadas por aplicações remotas via mensagens de comunicação. Isso é necessário para garantir o funcionamento de operações coordenadas a partir de um nó específico e que não dependam da aplicação local dos outros nós. A visão de camadas sugere que esse processamento de mensagens seja feito de forma hierárquica. Isto é, as camadas mais abaixo processam as suas mensagens e repassam as outras mensagens para as camadas acima. Figura 3.1: Camadas da arquitetura de execução A seguir descrevemos cada camada da arquitetura proposta na figura 3.1: Sistema Operacional - Essa camada provê as abstrações para acessar os dispositivos sensores e o rádio. Também gerencia a execução das diversas tarefas do próprio sistema operacional e das outras camadas. Nesse trabalho utilizamos o sistema operacional TinyOS[11]. Funções Locais - Essa camada disponibiliza abstrações para acesso a recursos locais, principalmente recursos de hardware do dispositivo. Funções de agregação - Essa camada contém a execução dos cálculos em cima da agregação dos valores de um grupo de nós. Interage com a camada de Agrupamento para obter os valores distribuídos em outros nós e com a camada de funções locais para obter os valores locais. Agrupamento - Essa camada é responsável pela definição e organização dos grupos de nós conforme a definição da aplicação. Interage com a camada de comunicação para a troca de mensagens entre os nós que compõem os grupos.

27 Capítulo 3. O modelo de programação proposto 27 Comunicação - Essa camada é responsável pela comunicação entre os nós e com a estação base. Essa camada provê, para a camada de Agrupamento, algumas facilidades de comunicação para a formação de grupos de nós. Também fornece algumas funções para Camada da Aplicação. Aplicação - Essa camada executa o programa responsável pelo comportamento da aplicação. É onde executamos o controle de fluxo que utiliza as funcionalidades básicas disponibilizadas pelas demais camadas Operações dependentes da comunicação A maioria das funcionalidades levantadas dependem da comunicação na rede de sensores sem fio. Por isso, primeiro identificamos os protocolos básicos necessários para comunicação para, em seguida, definir o comportamento das funções biblioteca. Analisando as características de comunicação para os padrões de interação levantados foi possível identificar a necessidade de três formas de comunicação descritas a seguir. Roteamento - Formação de uma topologia hierárquica de comunicação baseada na intensidade do sinal de rádio entre os nós. Considerando a estação base como nó raiz. Permite o roteamento de mensagens de qualquer nó da rede para a estação base e da estação base para qualquer nó da rede. Disseminação - Propagação do conteúdo de uma estrutura de dados pelos nós. Deve-se manter um controle de versão e garantir que todos os nós recebam a última versão dos dados. Formação de Grupos - Protocolo básico para formação de grupos. Uma mensagem, a partir de um nó origem, deve ser propagada em saltos pelos nós vizinhos. Cada nó poderá responder a essa mensagem, que deverá ser roteada no caminho inverso. O limite de saltos e os nós que devem responder são definidos nos parâmetros de formação do grupo. Parâmetros na formação de grupos Para garantir o reaproveitamento do protocolo de formação de grupos é necessário que a mensagem tenha parâmetros que permitam utilizar diferentes regras de formação de grupos. Esses mesmos parâmetros são utilizados diretamente pela aplicação como facilitadores na configuração da aplicação.

28 Capítulo 3. O modelo de programação proposto 28 A ideia básica é que cada grupo de nós seja definido pela combinação de um conjunto de parâmetros e o alcance máximo em saltos na comunicação via rádio (hops). O nó que disparar a comunicação deve colocar na mensagem os seus parâmetros. Cada nó que receber uma mensagem deverá comparar os parâmetros da mensagem com os parâmetros locais para verificar a necessidade de responder a mensagem. A mensagem deverá ser propagada até alcançar o limite de hops definido. Os parâmetros devem ser definidos de forma a atender todos os tipos de formação de grupos. Nos grupos hierárquicos, deve-se utilizar adicionalmente o parâmetro de nó pai definido na topologia do protocolo de roteamento. Cálculo de agregação O cálculo de agregação sempre será centralizado em um nó solicitante, podendo ser um nó coordenador de grupo (líder) ou um nó disparado por um evento interno como um alarme. O nó solicitante deverá utilizar o suporte de formação de grupos disponibilizado pela funcionalidade de agrupamento, o retorno da formação do grupo deve conter a informação requerida. A cada valor retornado, o nó solicitante deverá contabilizar parcialmente a função agregadora solicitada. Quando finalizar o tempo limite para efetuar a agregação, o nó solicitante deverá aplicar a finalização da função de agregação, e em seguida disparar um evento interno para indicar o final de agregação. A partir do evento com o resultado da agregação a aplicação pode, opcionalmente, efetuar uma operação de comparação do resultado com um valor constante préconfigurado. Para o caso da função de Sumário a operação é executada em dois estágios. O primeiro estágio executa a agregação totalizando a quantidade de valores acima e abaixo de um limite parametrizado. O segundo estágio retorna o resultado de uma nova comparação em cima de um dos totais do primeiro estágio, por exemplo compara se o total acima é maior que um outro limite parametrizado Definição dos parâmetros para configuração Com o objetivo de simplificar o desenvolvimento de novas aplicações e deixar as funções da nossa biblioteca mais genéricas, identificamos um conjunto de parâmetros que permitem configurar as diversas funcionalidades requeridas pelos padrões de interação. O modelo baseado em parâmetros também simplifica o processo de desenvolvimento e reconfiguração de aplicações.