Macroprogramação em Redes de Sensores Sem Fio

ISSN 0103-9741 Monografias em Ciˆ encia da Computac¸ ˜ ao no02/10 Macroprogramac¸ ˜ ao em Rede de Sensores Sem Fio Adriano Branco Noemi Rodriguez Departamento de Inform´ atica PONTIF´ ICIA UNIVERSIDADE CAT ´ OLICA DO RIO DE JANEIRO RUA MARQU ˆ ES DE S ˜ AO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL Monografias em Ciˆ encia da Computac¸ ˜ ao, No. 02/10 ISSN: 0103-9741 Editor: Prof. Carlos Jos´ e Pereira de Lucena Abril, 2010 Macroprogramac¸ ˜ ao em Rede de Sensores Sem Fio Adriano Branco Noemi Rodriguez {abranco , noemi}@inf.puc-rio.br Resumo. A evoluc¸˜ ao tecnol´ ogica dos dispositivos sensores sem fio, associada ` a reduc¸˜ ao do custo dos mesmos, est´ a permitindo um crescimento de aplicac¸ ˜ oes para rede de sensores sem fio (WSN). Essas aplicac¸ ˜ oes cada vez mais tendem a utilizar redes complexas e de grandes dimens˜ oes. Com isso, torna-se mais evidente a necessidade de ferramentas que facilitem a programac¸˜ ao, possibilitando abstrac¸ ˜ oes no n´ ıvel de grupo de n´ os ou de rede, em oposic¸˜ ao ` a trabalhosa programac¸˜ ao no n´ ıvel dos n´ os sensores. Esses modelos de programac¸˜ ao s˜ ao chamados de macroprogramac¸˜ ao. O objetivo deste trabalho ´ e avaliar diferentes modelos de programac¸˜ ao em rede de sensores sem fio. Apesar do interesse especial pelas abordagens que executam em plataformas com recursos limitados denominados motes, estaremos avaliando alguns outros modelos que n˜ ao se encaixam nessa vis˜ ao. A nossa avaliac¸˜ ao aborda algumas caracter´ ısticas dos modelos de forma a podermos comparar crit´ erios que v˜ ao desde a complexidade de programac¸˜ ao at´ e os tipos de aplicac¸ ˜ oes beneficiadas por cada modelo. Palavras-chave: macroprogramac¸˜ ao, sistemas distribu´ ıdos, rede de sensores sem fio, RSSF Abstract. The area of Wireless Sensors Networks (WSN) has experienced in the last years an increase in applications due to the technological evolution and cost reduction of sensor devices. These new applications tend to use larger and more complex networks. The development of these new applications needs tools that facilitate the programming work. These tools must allow new programming abstractions for group and network as opposed to programming at the level of individual sensor nodes. Such models are being called macroprogramming models. This work evaluates different programming models for wireless sensors network. Although we focus on platforms with limited resources like Berkeley-Style Motes, we also evaluate some other models that do not fit into that description. The evaluation criteria range from the programming complexity to the application types that benefit from each model. Keywords: macroprogramming, distributed systems, wireless sensor network, WSN Respons´ avel por publicac¸ ˜ oes: Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentac¸ ˜ ao e Informac¸ ˜ ao PUC-Rio Departamento de Inform´ atica Rua Marquˆ es de S˜ ao Vicente, 225 - G´ avea 22453-900 Rio de Janeiro RJ Brasil Tel. +55 21 3114-1516 Fax: +55 21 3114-1530 E-mail: [email protected] Web site: http://bib-di.inf.puc-rio.br/techreports/ ii Sum´ ario 1 Introduc¸ ˜ ao 1 2 Redes de Sensores sem Fio 1 2.1 Definic¸ ˜ aoeArquitetura.............................. 1 2.2 SistemaOperacional............................... 2 3 Classificando os modelos de programac¸ ˜ ao 3 3.1 Classificac¸ ˜ aoGeral................................ 3 3.2 Classificac¸ ˜ ao por Plataforma de Execuc¸ ˜ ao................... 3 3.3 Escolha dos Modelos de Macroprogramac¸ ˜ ao ................. 5 4 Crit´ erios de Avaliac¸ ˜ ao 5 5 Descric¸ ˜ ao dos trabalhos escolhidos 6 5.1 Regiment ..................................... 6 5.2 Pleiades...................................... 8 5.3 Cosmos...................................... 11 5.4 WADL....................................... 15 5.5 TinyDB ...................................... 18 5.6 ATaG........................................ 21 6 Comparativo dos modelos 25 7 Considerac¸ ˜ oes Finais 25 Referˆ encias 28 iii 1 Introduc¸ ˜ ao Nos ´ ultimos anos, a evoluc¸˜ ao tecnol´ ogica na ´ area de rede de sensores sem fio (WSN - Wireless Sensor Network) gerou um grande crescimento nos estudos envolvendo esses tipos de rede. A tendˆ encia dessa evoluc¸˜ ao ´ e baratear o hardware e, ao mesmo tempo, prover dispositivos para v´ arios tipos de sensoriamento. Isso torna cada vez mais vi´ avel a construc¸˜ ao de redes de sensores de diferentes dimens˜ oes para variados tipos de aplicac¸ ˜ oes. Toda essa evoluc¸˜ ao representa novos desafios para a ´ area de programac¸˜ ao de sistemas distribu´ ıdos, impulsionando trabalhos de Sistemas Operacionais e Middlewares no n´ ıvel dos n´ os da rede, e tamb´ em trabalhos com ferramentas para programac¸˜ ao que abstraem o sistema no n´ ıvel de grupo de sensores ou no n´ ıvel de rede de sensores. O objetivo deste trabalho ´ e estudar modelos de programac¸˜ ao que aplicam o conceito de macroprogramac¸˜ ao em rede de sensores sem fio. No conceito de macroprogramac¸˜ ao, o programador ´ e habilitado a trabalhar com a abstrac¸˜ ao em que a rede ´ e um sistema composto por grupos de sensores. Essa abstrac¸˜ ao permite a gerac¸˜ ao de programas de uma forma mais simples, e que podem ser utilizados em uma grande gama de aplicac¸˜ oes. Como trabalho relacionado, podemos citar [1] que d´ a uma vis˜ ao ampla dos modelos de programac¸˜ ao para WSN, n˜ ao se restringindo somente aos modelos de macroprogramac¸ ˜ ao. O autor agrupa os modelos em Node-Level,Group-Level eNetwork-level, esse ´ ultimo divido em Database eMacroprogramming Language. Tamb´ em faz uma an´ alise comparativa identificando as caracter´ ısticas entre os modelos e considerando os principais requisitos: Energy-efficiency,Scalability,Failure-resilience eCollaboration. Na sec¸ ˜ ao 2, situamos o leitor acerca das redes de sensores e de suas caracter´ ısticas. J´ a na sec¸ ˜ ao 3, apresentamos uma classificac¸˜ ao dos modelos de programac¸˜ ao com o objetivo de explicitar os modelos que iremos detalhar. Na sec¸˜ ao 4, identificamos os crit´ erios que selecionamos para avaliar os modelos detalhados na sec¸˜ ao 5. Na sec¸˜ ao 6, apresentamos o resultado resumido da nossa comparac¸˜ ao. Finalmente, na sec¸˜ ao 7, apresentamos algumas considerac¸ ˜ oes finais. 2 Redes de Sensores sem Fio Uma rede de sensores ´e um grupo de pequenos sistemas autˆonomos denominados de N´os Sensores (sensor nodes). Estes n´os cooperam para resolver pelo menos um problema comum. Geralmente suas fun¸c˜oes incluem algum tipo de percep¸c˜ao de parˆametros f´ısicos. A seguir apresentamos a definic¸˜ ao e a arquitetura das WSNs e dos N´ os Sensores. Em seguida, citamos caracter´ ısticas dos Sistemas Operacionais espec´ ıficos para WSNs. Essas informac¸ ˜ oes foram baseadas na referˆ encia [2]. 2.1 Definic¸ ˜ ao e Arquitetura Um N´ o Sensor sem Fio (WSN - Wireless Sensor Network) ´ e um sistema que tem capacidade de comunicac¸˜ ao, computac¸˜ ao, sensoriamento e armazenagem. Esses n´ os miniaturizados operam com restric¸ ˜ oes severas em termos de recursos dispon´ ıveis, como a energia da bateria, mem´ oria RAM, largura de banda dispon´ ıvel e poder de processamento. A 1 figura 1 mostra um diagrama esquem´ atico dos componentes de um n´ o sensor. Cada n´ o´ e composto por um micro-controlador, fonte de alimentac¸˜ ao, transceptor de R´ adio Frequˆ encia (RF), mem´ oria externa e sensores. Figura 1: M´odulos de um N´o Sensor Centenas de milhares desses n´ os sensores s˜ ao implantados numa larga variedade de aplicac¸ ˜ oes, que v˜ ao desde campos vulcˆ anicos at´ e monitoramento ambiental. Esses n´ os sensores podem se comunicar uns com os outros numa rede ad-hoc usando caminhos de comunicac¸˜ ao multi-hop, assim formando uma rede de sensores (WSN). Em v´ arios tipos de aplicac¸ ˜ oes, ap´ os a implantac¸˜ ao, os n´ os sensores s˜ ao de dif´ ıcil acesso. Por esse motivo essas redes devem ser autˆ onomas e apresentar longa durac¸˜ ao. Quase sempre os n´ os sensores precisam sobreviver ` as duras condic¸ ˜ oes ambientais e conservar o m´ aximo de energia poss´ ıvel. 2.2 Sistema Operacional A funcionalidade b´ asica de um sistema operacional para WSN ´ e esconder, da aplicac¸˜ ao, os detalhes de uso e acesso aos componentes de hardware do n´ o sensor, proporcionando uma interface clara para os usu´ arios do mesmo. O Sistema Operacional deve fornecer servic¸os b´ asicos como gerenciamento do processador, gerenciamento de mem´ oria, gerenciamento de dispositivos, pol´ ıticas de escalonamento, multi-threading e multitasking. Al´ em dos servic¸os acima mencionados, o sistema operacional tamb´ em deve prover servic¸os espec´ ıficos, tais como mecanismos apropriados para concorrˆ encia, Application Programming Interface (API) para acesso ao hardware, e tamb´ em reforc¸ar as pol´ ıticas de boa gest˜ ao de energia. Embora alguns desses servic¸os sejam semelhantes aos servic¸os dos sistemas operacionais tradicionais, a realizac¸˜ ao destes servic¸os em WSN ´ e um problema n˜ ao-trivial, devido ` as limitac¸ ˜ oes das capacidades de recursos. A Figura 2 mostra onde o sistema operacional se situa nas camadas de software da WSN. O Core kernel do sistema operacional executa em cada n´ o individual. Em cima dele, s˜ ao executados o middleware e as aplicac¸˜ oes que interagem atrav´ es dos n´ os. H´ a uma distinc¸ ˜ ao clara entre os servic¸os que devem ser providos pelo sistema operacional e pelo middleware em sistemas tradicionais. Isso ´ e mascarado em WSN devido ` a necessidade de interac¸ ˜ oes entre camadas, caracter´ ıstica importante para esse tipo de sistemas. N´ os sensores em WSN s˜ ao de baixo acoplamento e algumas vezes implantados em uma grande ´ area geogr´ afica. A escala da rede, algumas vezes, ´ e da ordem de milhares de n´ os sensores. Cada n´ o individual tem seu pr´ oprio poder de processamento e um sistema de software para ser executado. N´ os cooperam entre si atrav´ es da troca de mensagens. Em um ambiente distribu´ ıdo, o objetivo de um sistema operacional deve ser o de gerir 2 Figura 2: Camadas de software os diferentes n´ os espalhados em regi˜ oes, fazendo o conjunto parecer como uma ´ unica entidade virtual. Isso envolve prover transparˆ encia de comunicac¸˜ ao, transparˆ encia de falhas, e suporte para aplicac¸ ˜ oes heterogˆ eneas e escal´ aveis. 3 Classificando os modelos de programac¸ ˜ ao 3.1 Classificac¸ ˜ ao Geral Vamos utilizar como referˆ encia a taxonomia proposta em [1] que apresenta uma classificac¸ ˜ ao para os modelos de programac¸˜ ao. Os autores apresentam na figura 3 uma divis˜ ao dos modelos de programac¸˜ ao aplicados em WSN dividindo em baixo-n´ ıvel (Platformcentric) e alto-n´ ıvel (Application-centric). O primeiro est´ a relacionado ao n´ ıvel de n´ os, enquanto que o segundo est´ a relacionado ` a programac¸˜ ao no n´ ıvel de grupo ou de rede. Dentro da divis˜ ao de programac¸˜ ao no n´ ıvel de rede s˜ ao identificados os subgrupos Database Abstraction eMacroprogramming language. Considerando que muitas vezes as redes de sensores s˜ ao utilizadas para coletar dados de sensoriamento remoto, a abstrac¸˜ ao de banco de dados (Database Abstraction)´ e intuitiva, embora essa abordagem em rede de sensores tenha problemas diferentes de uma aplicac¸˜ ao convencional de banco de dados. Um exemplo de problema ´ e que uma simples consulta gera um “afunilamento” de mensagens trafegadas pela rede at´ e o servidor central. A outra abordagem ´ e proporcionar novas linguagens de macroprogramac¸˜ ao (Macroprogramming language), que possuem uma cobertura de aplicac¸ ˜ oes mais ampla que a abordagem de dados. O objetivo das linguagens de macroprogramac¸˜ ao ´ e efetuar a programac¸˜ ao do ponto de vista macrosc´ opico em que cada n´ o e os respectivos dados podem ser acessados sem considerar as comunicac¸ ˜ oes de baixo n´ ıvel entre os n´ os. Linguagens de macroprogramac¸˜ ao s˜ ao uma abordagem complementar em relac¸˜ ao ` a abordagem de banco de dados e se destinam a proporcionar maior flexibilidade. 3.2 Classificac¸ ˜ ao por Plataforma de Execuc¸ ˜ ao Criamos uma classificac¸˜ ao adicional para identificar a plataforma de execuc¸˜ ao do modelo de macroprogramac¸˜ ao. Iremos dividir em trˆ es grupos. O primeiro grupo cont´ em os trabalhos que utilizam plataformas com recursos bem 3 Figura 3: Taxonomia proposta em [1] para Modelos de Programa¸c˜ao em RSSF. limitados e que s˜ ao dedicados para aplicac¸˜ oes de rede de sensores sem fio. Essas plataformas s˜ ao denominadas Motes1. O segundo grupo contempla os trabalhos que utilizam plataformas com mais recursos e com capacidade de execuc¸˜ ao de aplicac¸ ˜ oes gerais, aqui representado por HP-iPAQ2, MiniPCs3e Servidor de Aplicac¸˜ ao 4. O terceiro grupo contempla plataformas com recursos intermedi´ arios entre o primeiro e o segundo grupo, mas ainda com foco em rede de sensores. Esse grupo ´ e representado por plataformas do tipo Sun-SPOT5e Stargate6. Como exemplos de trabalhos do primeiro grupo, temos Regiment [3, 4], Kairos [5], Pleiades7[6] e TinyDB [7]. Os quatro utilizam o sistema operacional TinyOS [8] em plataformas do tipo Mote. Tamb´ em temos Cosmos [9], que executa em multiplataforma utilizando mOS em Mote. No segundo grupo, utilizando Linux no HP-iPAQ, temos Spatial Programming [10], SpatialViews [11] e DRN [12]. Utilizando MiniPC, temos Semantic Streams [13], e j´ a executando em Servidores de Aplicac¸˜ ao, teremos WADL8[14]. Para o terceiro grupo, temos ATaG9[15], utilizando JVM na plataforma Sun-SPOT. Tamb´ em consideramos Cosmos [9], que executa em multiplataforma podendo utilizar Linux no Stargate. 1Motes - Temos como exemplo o modelo MICA Estilo-Berkeley que ´ e fabricado pela empresa Crossbow Technology com os nomes Mica2 e MicaZ. 2HP-iPAQ - PDAs (Personal Digital Assistants) fabricados pela HP (Hewlett-Packard) 3MiniPC - Sistema ´ e centralizada num miniserver como o modelo “Upont Cappuccino TX-3 Mini PC” 4Servidor de Aplicac¸˜ ao - utilizac¸˜ ao de m´ aquinas mais gen´ ericas com maior capacidade de recursos de processamento. 5Sun-SPOT - Sun Small Programmable Object Technology ´ e um mote baseado em J2ME desenvolvido pela Sun Microsystems. 6Stargate - ´ E uma processador mais potente para ser utilizado como gateway numa rede de sensores do tipo mote. ´ E fabricado pela Crossbow e utiliza o processador PXA255 da Intel. 7Pleiades ´ e o sucessor de Kairos. 8Por ser mais recente, WADL n˜ ao ´ e listado na taxonomia proposta em [1] 9ATaG tamb´ em n˜ ao foi citado na taxonomia proposta em [1] 4 3.3 Escolha dos Modelos de Macroprogramac¸ ˜ ao Temos interesse especial em trabalhos aplicados diretamente em rede de sensores sem fio que utilizam motes. O primeiro crit´ erio de selec¸˜ ao dos modelos de programac¸˜ ao para nossa avaliac¸ ˜ ao foi a escolha de trabalhos inclu´ ıdos no primeiro grupo da classificac¸˜ ao das plataformas de execuc¸˜ ao. Inclu´ ımos nessa selec¸˜ ao mais alguns modelos fora do crit´ erio original de forma a aumentar a diversidade de modelos da nossa avaliac¸˜ ao. Com isso, estaremos avaliando os seguintes trabalhos: •Regiment [3,4] (TinyOS/Mote) •Pleiades [6] (TinyOS/Mote) •Cosmos [9] (mOS/Mote) •TinyDB [7] (TinyOS/Mote) •WADL [14] (Servidor de Aplicac¸˜ ao) •ATaG [15] (JVM/Sun-SPOT) 4 Crit´ erios de Avaliac¸ ˜ ao O objetivo principal deste trabalho ´ e identificar e comparar as principais caracter´ ısticas de alguns modelos de programac¸˜ ao aplicados em rede de sensores sem fio. Para isso, selecionamos os seguintes crit´ erios de avaliac¸˜ ao: Base do Modelo - Origem ou a base do modelo utilizado na linguagem de macroprogramac¸ ˜ ao. Estilo de programa¸c˜ao - Classificac¸˜ ao do estilo de programac¸˜ ao, podendo ser Imperativo ou Declarativo. Linguagem do usu´ario - Identifica qual ´ e a principal linguagem de programac¸˜ ao disponibilizada para o usu´ ario. Vis˜ao da Rede - A vis˜ ao que o usu´ ario tem da rede, identificando as abstrac¸ ˜ oes disponibilizadas. Pontos Positivos - Pontos positivos e benef´ ıcios do modelo proposto. Tipos de Aplica¸c˜oes - Para quais tipos de aplicac¸ ˜ oes o modelo ´ e mais adequado. Aqui dividimos em: 1. Envio peri´ odico de dados da rede para a estac¸˜ ao base - utilizado em aplicac¸ ˜ oes de coleta de dados. 2. Leitura eventual de dados - utilizado em aplicac¸ ˜ oes de controle. 3. Interac¸ ˜ ao dentro da rede - um exemplo de aplicac¸˜ ao ´ e o caso do carro procurando a vaga mais pr´ oxima. 4. Envio eventual de dados da rede para a estac¸˜ ao base - aplicac¸˜ ao do tipo alarme, por exemplo, o alarme de incˆ endio numa floresta. Aplica¸c˜ao Exemplo - Quais aplicac¸ ˜ oes foram usadas como exemplo na apresentac¸˜ ao do trabalho. 5 5.3.1 Arquitetura Na figura 6, apresentamos os m´ odulos que comp˜ oem a arquitetura Cosmos, indicando o fluxo de transformac¸˜ ao do c´ odigo escrito em mPL at´ e o bin´ ario para ser executado no Mote. Figura 6: Arquitetura Cosmos A arquitetura de Cosmos divide em 3 n´ ıveis o c´ odigo carregado no mote. No primeiro n´ ıvel, deve-se carregar o mOS, em seguida, os componentes funcionais e, finalmente, a informac¸ ˜ ao do sub-grafo da aplicac¸˜ ao mPL para o respectivo mote. Essa carga pode ser feita toda de uma vez na operac¸˜ ao de carga da mem´ oria flash, ou os motes podem estar previamente carregados com o mOS e se utilizarem dos recursos de carga via mensagens para as FCs e Sub-grafos. Os componentes funcionais podem ser dos seguintes tipos: SFCs - S˜ ao componentes que implementam servic¸os de sistema (por exemplo: servic¸os de rede), e existem independentemente da aplicac¸˜ ao. LFCs - S˜ ao abstrac¸ ˜ oes de programac¸˜ ao em alto n´ ıvel em mPL e n˜ ao s˜ ao vis´ ıveis ao programador. O compilador automaticamente seleciona as LFCs conforme as abstrac¸ ˜ oes utilizadas no programa mPL. FCs - S˜ ao os componentes criados ou reutilizados para a aplicac¸˜ ao mPL. 5.3.2 Linguagem A programac¸˜ ao em mPL ´ e feita de forma declarativa. Antes o programador cria em C os componentes funcionais. A codificac¸˜ ao dos componentes deve seguir algumas regras que possibilitam a integrac¸˜ ao com mPL. No programa mPL, o programador define as regras de instanciac¸˜ ao dos componentes funcionais e, em seguida, atrav´ es das IAs, define o fluxo de dados entre as instˆ ancias dos componentes. Um macroprograma em mPL ´ e composto pelos seguintes tipos de express˜ oes: Enumerations - Associac¸ ˜ ao de identificadores a valores inteiros. Normalmente utilizado para fornecer identificadores globais ´ unicos. Tˆ em a mesma sintaxe de enum de C e o compilador importa automaticamente dos arquivos de COSMOS. Declarations - Essas express˜ oes permitem declarac¸˜ oes de dispositivos e FCs. Tamb´ em s˜ ao importados diretamente dos arquivos de Cosmos. Instances - Muito parecido com a declarac¸˜ ao de objetos como instˆ ancias de classes, essas express˜ oes permitem a criac¸˜ ao de instˆ ancias l´ ogicas de FCs e dispositivos, fornecendo parˆ ametros de instanciac¸˜ ao. 12 Capability constraints - Instˆ ancias de FCs ou Dispositivos que herdam as restric¸ ˜ oes de capacidade das declarac¸ ˜ oes de FCs ou Dispositivos. IA description - Essa sec¸˜ ao descreve de forma compreensiva as conex˜ oes de entrada e sa´ ıda das instˆ ancias dos FCs e os Dispositivos utilizados no macroprograma. O compilador identifica erros de tipos e ligac¸ ˜ oes. Contract predicates - Permite a utilizac¸˜ ao de abstrac¸ ˜ oes de alto n´ ıvel nas descric¸ ˜ oes de IAs. A criac¸ ˜ ao de regi˜ oes ´ e poss´ ıvel com a utilizac¸˜ ao de express˜ oes que definem a comunicac¸ ˜ ao n-n para o grupo de vizinhos n-hops. 5.3.3 Programa Exemplo O programa exemplo utilizado pelos autores em [9] executa uma monitorac¸˜ ao estrutural. Esse programa exibe valores de acelerac¸˜ ao m´ axima e avalia a resposta de frequˆ encia do edif´ ıcio. Apresenta tamb´ em o espectrograma resultante caso a acelerac¸˜ ao esteja acima de um limite especificado. Um controlador (Ctrl) realimenta o valor limite, com base em dados agregados da rede. Isso economiza recursos do sistema at´ e que um evento interessante desencadeie a necessidade de uma vis˜ ao mais detalhada. Na figura 7, apresentamos o diagrama do fluxo de dados do programa exemplo. Cada bloco representado pela ´ area pontilhada ´ e instanciado nos respectivos tipos de motes ou no servidor. Figura 7: Programa exemplo - Diagrama do fluxo de dados A seguir apresentamos a listagem do programa exemplo mPL. // declarations (auto import) %accel_x : mcap = MCAP_ACCEL_SENSOR, device = ACCEL_X_SENSOR, out[raw_t]; %cpress_fc : { mcap = MCAP_ANY, fcid = FCID_CPRESS, in[raw_t], out[craw_t] }; %thresh_fc : { mcap = MCAP_ANY, fcid = FCID_THRESH, in[craw_t, ctrl_t], out[craw_t] }; %ctrl_fc : { mcap = MCAP_ANY, fcid = FCID_CTRL, in[max_t], out[ctrl_t] }; %max_fc : { mcap = MCAP_ANY, fcid = FCID_MAX, 13 in[craw_t, max_t], out[max_t]}; %disp : mcap = MCAP_UNIQUE_SERVER, device = DISPLAY, in[ * ]; %fft_fc : { mcap = MCAP_FAST_CPU, fcid = FCID_FFT, in[craw_t], out[freq_t] }; // logical instances accel_x : accel(12); disp : disp1, disp2; cpress_fc : cpress; thresh_fc : thresh(250); max_fc : max; fft_fc : fft; ctrl_fc : ctrl; // refining capability constraints @ on_mote = MCAP_ACCEL_SENSOR : thresh, cpress; @ on_srv = MCAP_UNIQUE_SERVER : ctrl; start_ia timer(30) -> accel; accel -> cpress[0]; cpress[0] -> thresh[0], max[0]; thresh[0] -> fft[0]; fft[0] -> disp1; max[0] -> ctrl[0], disp2 | max[1]; ctrl[0] --> thresh[1]; end_ia Para dar mais clareza, apresentamos as declarac¸ ˜ oes dos Dispositivos e FCs. De forma geral, essas declarac¸ ˜ oes n˜ ao s˜ ao escritas no arquivo de c´ odigo mPL. Ainda na parte das declarac¸ ˜ oes, mcap define as restric¸ ˜ oes para o FC ou Dispositivo. Por exemplo, para o componente fft (Fast Fourier Transform)´ e definido mcap = MCAP_FAST_CPU, o que significa que essa FC somente pode ser instanciada em m´ aquinas com CPU r´ apidas como os n´ os Stargate. Na parte da criac¸˜ ao das instˆ ancias l´ ogicas, note que algumas instanciac¸˜ oes passam parˆ ametros para inicializac¸˜ ao. Por exemplo, em “thresh_fc : thresh(250);”, cada instˆ ancia do componente Threshold ´ e inicializada com um valor inicial 250. Na parte de descric¸˜ ao da IA, temos a representac¸˜ ao do grafo IA. Lembramos que timer ´ e uma palavra chave em mPL e o seu parˆ ametro define um intervalo de disparo em milissegundos. Uma instˆ ancia FC ` a esquerda da seta precisa fornecer o ´ ındice do valor de sa´ ıda, enquanto que a instˆ ancia do FC ` a direita dever´ a fornecer o ´ ındice de entrada. No nosso exemplo, a primeira sa´ ıda de ctrl[0] ser´ a conectada na segunda entrada de thresh[1]. Dispositivos n˜ ao precisam desses ´ ındices porque eles tˆ em somente uma entrada e uma sa´ ıda. O uso de “->“ indica comunicac¸˜ ao local ou pela rede 1-1. A melhor escolha ´ e feita automaticamente pelo compilador. J´ a o uso de ”-->“ indica uma comunicac¸˜ ao 1-n. O uso de “|” permite mesclar e atualizar os dados. Na gerac¸˜ ao dos sub-grafos para diferentes tipos de n´ os, o compilador mPL verifica a localizac¸˜ ao dos FCs envolvidos na 14 operac¸ ˜ ao para estabelecer a comunicac¸˜ ao local ou via rede. 5.3.4 Pontos cr´ıticos A criac¸˜ ao de novas FCs est´ a fora do escopo do programador mPL, necessitando de um desenvolvedor mais especializado e que conhec¸a as regras e restric¸ ˜ oes impostas pela arquitetura de Cosmos. 5.4 WADL A linguagem declarativa WADL [14] ´ e uma variac¸˜ ao de uma linguagem de descric¸˜ ao de arquitetura (ADL-Architecture Description Language) com foco em aplicac¸ ˜ oes dinˆ amicas baseadas em sensores. A linguagem utiliza o conceito Produtor-Consumidor como padr˜ ao de comunicac¸˜ ao, no qual os sensores produzem dados e os m´ odulos de processamento consomem os dados produzidos. A caracter´ ıstica “dinˆ amica” de WADL ´ e permitir que os m´ odulos produtores e consumidores possam ser introduzidos ou retirados em tempo de execuc¸˜ ao. Para isso, utilizam o conceito de descoberta de servic¸os da arquitetura SOA. O programador WADL define o fluxo de dados entre os m´ odulos especificando as caracter´ ısticas dos m´ odulos, ao inv´ es de especificar um m´ odulo individual. Em tempo de execuc¸ ˜ ao, ´ e feita a “ligac¸˜ ao” dos m´ odulos instanciados, inclusive permitindo a reconfigurac¸˜ ao autom´ atica com a inserc¸˜ ao de novos m´ odulos ou a exclus˜ ao de m´ odulos existentes. O modelo produtor-consumidor de WADL favorece aplicac¸˜ oes t´ ıpicas de interac¸˜ ao dentro da rede ou de coleta de dados. 5.4.1 Arquitetura Na figura 8, apresentamos os m´ odulos que comp˜ oem a arquitetura WADL. Todo sistema est´ a baseado na especificac¸˜ ao OSGi (Open Services Gateway Initiative) [16]. O padr˜ ao OSGi especifica uma arquitetura de componentes dinˆ amicos para Java. Essa arquitetura funciona como um middleware orientado a servic¸o para desenvolvimento de aplicac¸ ˜ oes modulares em Java (SOA). As principais implementac¸ ˜ oes do OSGi s˜ ao para servidores de aplicac¸ ˜ oes. Figura 8: Arquitetura WADL 15 Na programac¸˜ ao WADL, ´ e assumido que os m´ odulos sensores e de processamento de dados s˜ ao m´ odulos aplicativos desenvolvidos na arquitetura OSGi. O programador WADL ent˜ ao define, no programa WADL, as regras de “ligac¸˜ ao” entre esses m´ odulos, isto ´ e, as regras para a criac¸˜ ao dos canais de comunicac¸˜ ao entres os m´ odulos. Para isso, foi desenvolvido especialmente um m´ odulo OSGi (WireAdminBinder) para a interpretac¸˜ ao do programa WADL e a criac¸˜ ao autom´ atica dos canais. A arquitetura OSGi prevˆ e a possibilidade de instanciac¸˜ ao dinˆ amica de novos m´ odulos ou de desativac¸˜ ao de m´ odulos existentes. O WireAdminBinder aproveita essa caracter´ ıstica para providenciar a manutenc¸˜ ao das “ligac¸ ˜ oes” (canais) em func¸˜ ao da manutenc¸˜ ao dos m´ odulos. 5.4.2 Linguagem Basicamente a linguagem WADL ´ e composta por trˆ es conceitos: •WireApp - Representa uma aplicac¸˜ ao composta pelos m´ odulos produtores (producers ), m´ odulos consumidores (consurmers) e as respectivas conex˜ oes (wires). •WireSet - Representa a definic¸˜ ao das conex˜ oes entre os produtores e consumidores. Essas definic¸ ˜ oes s˜ ao baseadas em filtros, permitindo que a identificac¸˜ ao de produtores e consumidores possa ser feita por atributos. •Property - Define as propriedades de QoS para Wires eProducers. Essas propriedades ajudam a controlar o fluxo de dados e a carga dos Consumidores. Por causa da caracter´ ıstica de instanciac¸˜ ao dinˆ amica, o ciclo de vida de uma aplicac¸˜ ao WADL est´ a em func¸ ˜ ao dos m´ odulos ativos e das respectivas conex˜ oes. Para o controle do ciclo de vida das conex˜ oes, deve-se definir pol´ ıticas de comportamento para quando um m´ odulo ´ e removido da aplicac¸˜ ao. As pol´ ıticas para destruic¸˜ ao de uma conex˜ ao (wire) s˜ ao: •IF DISCONNECTED - Destr´ oi uma conex˜ ao se um produtor ou consumidor ´ e removido. •WHILE PRODUCER - Destr´ oi uma conex˜ ao se somente o Produtor ´ e removido. •WHILE CONSUMER - Destr´ oi uma conex˜ ao se somente o Consumidor ´ e removido. •KEEP ALIVE - A conex˜ ao ser´ a persistente. 5.4.3 Programa Exemplo A seguir, apresentamos a listagem do programa exemplo utilizado pelos autores em [14]. Esse exemplo ´ e uma aplicac¸˜ ao de central de incˆ endio. O programa gera mensagens de alerta quando forem detectados valores anormais para os medidores de temperatura ou de n´ ıvel de fumac¸a de qualquer sala de um pr´ edio. <?xml version="1.0" encoding="UTF-8"?> <wireapp id="building.FireCentral" description="A Fire central wired application" 16 acyclic="true"> <!-- a many-to-one wireset without wire properties --> <!-- connects temperature sensors to the fire central --> <!-- + keepAlive remove policy --> <wireset id="temperature2central" description="temperatures consumed by the fire central" producers-filter="(&(|(wireadmin.producer.flavors= *org.osgi.util.measurement.Measurement) (wireadmin.producer.flavors= *javax.measure.Measure))(unit=SI.K))" consumers-filter="(service.pid=building.firecentral.temperature)" mandatory="false" removepolicy="KEEP_ALIVE" /> <!-- current rooms smoke level to the fire central --> <!-- + whileConsumer remove policy --> <wireset id="smoke2central" description="smoke level producers consumed by the fire central" producers-filter="(wireadmin.producer.flavors= *com.acme.data.SmokeLevel)" consumers-filter="(service.pid=building.firecentral.smoke)" removepolicy="WHILE_CONSUMER" mandatory="true" /> <property name="wireadmin.filter" value="(wirevalue.elapsed>=2000)" type="java.lang.String" /> </wireset> </wireapp> O programa WADL descreve a topologia da aplicac¸˜ ao, nesse exemplo o WireApp ´ e composto por dois WireSet. O primeiro WireSet (temperature2central) liga o consumidor building.firecentral.temperature aos produtores Measurement ou Measure com a unidade de temperatura kelvin (SI.K). Tamb´ em utiliza a pol´ ıtica KEEP_ALIVE para que a “ligac¸˜ ao” persista, mesmo havendo intermitˆ encia nos m´ odulos. O segundo WireSet (smoke2central) trata de forma semelhante os sensores de fumac¸a, com a diferenc¸a que a “ligac¸˜ ao” pode ser destru´ ıda se o m´ odulo consumidor for desativado (WHILE_CONSUMER). A propriedade utilizada (wirevalue.elapsed>=2000) forc¸a a atualizac¸˜ ao dos valores em pelo menos 2000 milissegundos. 5.4.4 Pontos cr´ıticos O sistema foi desenvolvido originalmente para aplicac¸ ˜ oes de sensores, n˜ ao necessariamente para aplicac¸˜ oes de redes de sensores sem fio. A programac¸˜ ao tem foco somente 17 nas conex˜ oes. O desenvolvimento dos m´ odulos tem que ser feito em Java diretamente sobre a arquitetura OSGi. As implementac¸ ˜ oes dispon´ ıveis da arquitetura OSGi s˜ ao, normalmente, para servidores de aplicac¸ ˜ oes utilizando Java. A complexidade desse tipo de implementac¸˜ ao inviabiliza a utilizac¸˜ ao em rede de sensores com dispositivos do tipo Mote. As caracter´ ısticas do OSGi s˜ ao dedicadas para aplicac¸˜ oes mais tradicionais em rede de computadores. Dessa forma, n˜ ao atende pontos cr´ ıticos espec´ ıficos para rede de sensores sem fio, principalmente para aplicac¸ ˜ oes mais densas e complexas. 5.5 TinyDB TinyDB [7] ´ e um sistema de processamento de queries para extrac¸˜ ao de dados de rede de sensores. TinyDB implementa uma vers˜ ao simplificada da linguagem SQL e adiciona algumas extens˜ oes para adaptac¸˜ ao ao contexto de rede de sensores sem fio. TinyDB abstrai a rede de sensores como se fosse uma tabela (sensors) composta por “tuplas” dos valores de cada n´ o para cada instante no tempo. Na realidade, esses valores somente ser˜ ao “materializados” quando for necess´ ario satisfazer uma consulta. O controle principal do TinyDB ´ e feito num servidor interligado a rede de sensores atrav´ es do n´ o raiz. As consultas s˜ ao disparadas no servidor e propagadas de forma hier´ arquica para cada n´ o da rede. Os resultados s˜ ao retornados na forma de streams pelo caminho inverso. No retorno dos dados, ´ e poss´ ıvel a utilizac¸˜ ao de filtros e func¸ ˜ oes agregadoras. ´ E poss´ ıvel parametrizar uma consulta para funcionar de forma pontual ou peri´ odica, ou ainda definir se vai ser disparada a partir de um evento customizado no mote. TinyDB inclui tamb´ em algoritmos para utilizac¸˜ ao eficiente de energia. Esses algoritmos otimizam o consumo dos dispositivos, influenciando o intervalo e o caminho da troca de mensagens. Uma das opc¸ ˜ oes na programac¸˜ ao da consulta ´ e permitir ao sistema determinar o melhor per´ ıodo de coleta, em func¸˜ ao da disponibilidade de energia e do tempo de funcionamento requerido para o sensor. 5.5.1 Arquitetura Na figura 9, apresentamos os m´ odulos que comp˜ oem a arquitetura TinyDB, indicando o fluxo de transformac¸˜ ao das consultas at´ e o bin´ ario para ser executado no Mote. Figura 9: Arquitetura TinyDB O TinyDB ´ e composto por um m´ odulo que ´ e executado no mote utilizando o TinyOS, 18 e por uma interface gr´ afica que ´ e executada no servidor para a construc¸˜ ao das consultas. A parte que ´ e executada no mote ´ e respons´ avel pelo roteamento das mensagens e pelo processamento local das consultas. Deve-se incluir nessa parte as func¸ ˜ oes e os eventos customizados para serem utilizados nas queries. A interface gr´ afica d´ a suporte para criac¸˜ ao das consultas, envio de comandos para os motes e recebimento dos resultados. Tamb´ em existem as opc¸ ˜ oes de criac¸˜ ao direta de scripts e utilizac¸˜ ao de API cliente para processamento e armazenamento de dados no servidor. 5.5.2 Linguagem A linguagem utilizada ´ e uma simplificac¸˜ ao do SQL tradicional utilizado em sistemas de banco de dados. Foram criadas algumas variac¸ ˜ oes para atender ao contexto de rede de sensores sem fio. Abaixo segue a definic¸˜ ao da sintaxe SQL do TinyDB. [ON [ALIGNED] EVENT event-type[{paramlist}] [boolop event-type{paramlist} ... ]] SELECT [NO INTERLEAVE] <expr>| agg(<expr>) | temporal agg(<expr>), ... FROM [sensors | storage-point], ... [WHERE {<pred>}] [GROUP BY {<expr>}] [HAVING {<pred>}] [OUTPUT ACTION [command | SIGNAL event({paramlist}) | (SELECT ... ) ] | [INTO STORAGE POINT bufname]] [SAMPLE PERIOD seconds [[FOR n rounds] | [STOP ON event-type [WHERE <pred>]]] [COMBINE { agg(<expr>)}] [INTERPOLATE LINEAR]] | [ONCE] | [LIFETIME seconds [MIN SAMPLE RATE seconds]] Os principais elementos do SQL utilizado no sistema TinyDB s˜ ao: •ON EVENT - Indica que a query ser´ a disparada por um evento de baixo n´ ıvel ou por um evento gerado por outra query. O c´ odigo do evento de baixo n´ ıvel dever´ a ser compilado no TinyOS. •SELECT-FROM-WHERE - Basicamente ´ e o mesmo que no SQL tradicional. A clausula FROM pode fazer referˆ encia ` a tabela sensors ou ` a alguma tabela local ao mote gerada por outra query (materialization point). •GROUP BY, HAVING - Cl´ ausulas para as func¸ ˜ oes de agregac¸˜ ao. 19 •OUTPUT ACTION - No lugar de retornar valores para o n´ o raiz, executa a chamada de uma func¸˜ ao de baixo n´ ıvel. Pode ser utilizado para acionamentos externos. •SIGNAL - Utilizado para uma query gerar um evento no mote. •INTO STORAGE POINT - Cria uma tabela local (materialization point) com o resultado da query. •SAMPLE PERIOD - Define o intervalo peri´ odico de coleta para uma query. •FOR - Define a durac¸˜ ao total de coleta para uma query. •STOP ON - Indica que uma query peri´ odica ser´ a parada por um evento. •COMBINE - Especifica uma func¸˜ ao de agregac¸˜ ao para os casos de Joins com diferentes taxas de coleta. Um Join somente pode ser feito entre uma query normal e uma tabela local. •ONCE - Utilizado no lugar de SAMPLE PERIOD para indicar uma coleta simples e n˜ ao peri´ odica. •LIFETIME - Utilizado no lugar de SAMPLE PERIOD para indicar que o per´ ıodo de coleta deve ser ajustado automaticamente em func¸˜ ao da energia dispon´ ıvel, de forma a durar o tempo de LIFETIME indicado. 5.5.3 Programa Exemplo A seguir, apresentamos alguns exemplos de queries para o TinyDB. Esses exemplos fora retirados de [7]. Query B´ asica SELECT nodeid, light, temp FROM sensors SAMPLE PERIOD 1s FOR 10s Criac¸ ˜ ao de tabela local (recentLight) CREATE STORAGE POINT recentlight SIZE 8 AS (SELECT nodeid, light FROM sensors SAMPLE PERIOD 10s) Join da tabela Sensors com a tabela local recentLight SELECT COUNT(*) FROM sensors AS s, recentLight AS rl WHERE rl.nodeid = s.nodeid AND s.light < rl.light SAMPLE PERIOD 10s 20 Agregac¸˜ ao calculando valor m´ edio SELECT AVG(volume),room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold SAMPLE PERIOD 30s Query disparada pelo evento bird-detect ON EVENT bird-detect(loc): SELECT AVG(light), AVG(temp), event.loc FROM sensors AS s WHERE dist(s.loc, event.loc) < 10m SAMPLE PERIOD 2 s FOR 30 s Query que dispara o evento hot SELECT nodeid,temp WHERE temp > thresh OUTPUT ACTION SIGNAL hot(nodeid,temp) SAMPLE PERIOD 10s Query com a opc¸˜ ao LIFETIME SELECT nodeid, accel FROM sensors LIFETIME 30 days 5.5.4 Pontos cr´ıticos As func¸ ˜ oes customizadas de agregac¸˜ ao e de eventos de baixo n´ ıvel devem ser escritas em NesC, dessa forma perdem-se as facilidades da linguagem SQL. Apesar da possibilidade de criac¸˜ ao de func¸ ˜ oes customizadas e da utilizac¸˜ ao de eventos locais, a arquitetura cliente-servidor baseada no modelo de banco de dados inviabiliza a construc¸˜ ao de aplicac¸˜ oes mais complexas que necessitem de processamento e interac¸˜ oes localizadas. O modelo de propagac¸˜ ao gen´ erico com a utilizac¸˜ ao de filtros locais imp˜ oe atividades desnecess´ arias em grupos de motes quando se utilizam queries seletivas. 5.6 ATaG ATaG (Abstract Task Graph) [15] ´ e um modelo de programac¸˜ ao orientada a dados. ATaG utiliza-se da programac¸˜ ao declarativa para facilitar a especificac¸˜ ao da aplicac¸˜ ao de forma macro, enquanto que as func¸ ˜ oes detalhadas s˜ ao implementadas na linguagem imperativa da plataforma de execuc¸˜ ao. 21 Referˆ encias [1] SUGIHARA, R.; GUPTA, R. K.. Programming models for sensor networks: A survey. ACM Trans. Sen. Netw., 4(2):1–29, 2008. [2] REDDY, A. M. V.; KUMAR, A. P.; JANAKIRAM, D. ; KUMAR, G. A.. Wireless sensor network operating systems: a survey. Int. J. Sen. Netw., 5(4):236–255, 2009. [3] 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, p. 489–498, New York, NY, USA, 2007. ACM. [4] 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, p. 78–87, New York, NY, USA, 2004. ACM. [5] GUMMADI, R.; GNAWALI, O. ; GOVINDAN, R.. Macro-programming wireless sensor networks using kairos. Distributed Computing in Sensor Systems, p. 126– 140, 2005. [6] KOTHARI, N.; GUMMADI, R.; MILLSTEIN, T. ; GOVINDAN, R.. Reliable and efficient programming abstractions for wireless sensor networks. PLDI ’07: Proceedings of the 2007 ACM SIGPLAN conference on Programming language design and implementation, p. 200–210, 2007. [7] MADDEN, S. R.; FRANKLIN, M. J.; HELLERSTEIN, J. M. ; HONG, W.. Tinydb: an acquisitional query processing system for sensor networks. ACM Trans. Database Syst., 30(1):122–173, 2005. [8] LEVIS, P.; MADDEN, S.; POLASTRE, J.; SZEWCZYK, R.; WHITEHOUSE, K.; WOO, A.; GAY, D.; HILL, J.; WELSH, M.; BREWER, E. ; CULLER, D.. Tinyos: An operating system for sensor networks. In: IN AMBIENT INTELLIGENCE. Springer Verlag, 2004. [9] AWAN, A.; JAGANNATHAN, S. ; GRAMA, A.. Macroprogramming heterogeneous sensor networks using cosmos. EuroSys ’07: Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007, p. 159–172, 2007. [10] BORCEA, C.; INTANAGONWIWAT, C.; KANG, P.; KREMER, U. ; IFTODE, L.. Spatial programming using smart messages: Design and implementation. In: ICDCS ’04: PROCEEDINGS OF THE 24TH INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS (ICDCS’04), p. 690–699, Washington, DC, USA, 2004. IEEE Computer Society. [11] NI, Y.; KREMER, U.; STERE, A. ; IFTODE, L.. Programming ad-hoc networks of mobile and resource-constrained devices. PLDI ’05: Proceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, p. 249–260, 2005. [12] INTANAGONWIWAT, C.; GUPTA, R. ; VAHDAT, A.. Declarative resource naming for macroprogramming wireless networks of embedded systems. in International Workshop on Algorithmic Aspects of Wireless Sensor Networks (ALGOSENSORS), 2005. 28 [13] WHITEHOUSE, K.; ZHAO, F. ; LIU, J.. Semantic streams: A framework for composable semantic interpretation of sensor data. Wireless Sensor Networks, p. 5–20, 2006. [14] CERVANTES, H.; DONSEZ, D. ; TOUSEAU, L.. An architecture description language for dynamic sensor-based applications. In: CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 2008. CCNC 2008. 5TH IEEE, p. 147– 151, Jan. 2008. [15] BAKSHI, A.; PRASANNA, V. K.; REICH, J. ; LARNER, D.. The abstract task graph: a methodology for architecture-independent programming of networked sensor systems. EESR ’05: Proceedings of the 2005 workshop on End-to-end, sense-andrespond systems, applications and services, p. 19–24, 2005. [16] OSGI-ALLIANCE. Osgi - the dynamic module system for java. http://www.osgi.org, October 2005. [17] PATHAK, A.; GOWDA, M. K.. Srijan: a graphical toolkit for sensor network macroprogramming. In: ESEC/FSE ’09: PROCEEDINGS OF THE 7TH JOINT MEETING OF THE EUROPEAN SOFTWARE ENGINEERING CONFERENCE AND THE ACM SIGSOFT SYMPOSIUM ON THE FOUNDATIONS OF SOFTWARE ENGINEERING ON EUROPEAN SOFTWARE ENGINEERING CONFERENCE AND FOUNDATIONS OF SOFTWARE ENGINEERING SYMPOSIUM, p. 301–302, New York, NY, USA, 2009. ACM. [18] LEDECZI, A.; MAROTI, M.; BAKAY, A.; KARSAI, G.; GARRETT, J.; THOMASON, C.; NORDSTROM, G.; SPRINKLE, J. ; VOLGYESI, P.. The generic modeling environment. In: WORKSHOP ON INTELLIGENT SIGNAL PROCESSING, 2001. 29