Improving Environmental Interaction Application on Spot Sensornet

Project Details:

Goal: This project builds on the previous project SunSpot Web Access and aims to improve the Web-based access to SunSpot readings so that a true Environmental Interaction application can be built. The idea is to provide a solution for gathering different measurements from the sensor field, not only at individual level, as it was provided by the previous project, but capable of implementing a true programable set of functions which can be set-up by registered users. Ordinary users should be only able to retrieve the instantaneous data provided by the application, over the internet. Furthermore, data should be periodically collected offline and made available to a community of interested clients (e.g. by using Yggdrasil and submitted to the sensor.network repository).

Assigned to: Ricardo Nunes

Project Website:

Project test-bed: SunSpot.Proxy (intranet DEEC)

Project Code: (Proxy Server) (HTTP Server) (Web Page)

Project Report: (pdf)

Project Report (HTML):

Desenvolvimento de aplicação interactiva para a rede sensores SunSpot

Resumo: Este projecto foi construído com base no anterior sistema “SunSpot Web Access” introduzindo novas funcionalidades de programação e configuração. Foi desenvolvido um módulo de comunicação entre SunSpots, tornando cada nó de um simples ponto de recolha de dados para agregador de informação consoante as funções definidas. Foi desenvolvido um sistema de representação da rede, permitindo a rápida visualização da forma como os nós estão organizados e o caminho percorrido para a comunicação para a basestation. Introduziu-se um novo módulo de logs que periodicamente obtém os valores medidos pelos SunSpot e regista numa base de dados para posterior pesquisa e análise. Foi implementado algum controlo sobre o sistema, limitando as funções de agregação apenas a utilizadores registados.

Índice

  • 1. Introdução
  • 2. Objectivos
  • 3. Trabalho relacionado
  • 3.1 Visão geral do sistema
  • 3.2 Sistema de descoberta
  • 3.3 SunSpot
  • 3.4 Sensores
  • 4. Arquitectura do sistema
  • 4.1 Agregação
  • 4.2 Representação da Rede
  • 4.3 Logs
  • 4.4 Limitação de acesso
  • 5. Conclusão
  • 6. Referências
  • Anexo 1 - Manual de instalação
  • Anexo 2- Manual de utilização
  • Anexo 3 - Reset ao sistema
  • Anexo 4 - Diagrama de eventos do processo de agregação

1. Introdução

Avanços tecnológicos nos campos da microelectrónica e comunicações móveis permitiram o aparecimento de um novo tipo de sensores caracterizados por serem de baixo custo, baixo consumo energético, de dimensão reduzida e com capacidade de comunicarem a curtas distâncias. Estas características permitiram a implementação de redes de sensores que não dependem de uma infra-estrutura física para funcionar, sendo que, são os próprios nós constituintes que trabalham colaborativamente tanto para a monitorização/detecção de eventos como para a retransmissão de informação.

Os protocolos de comunicação utilizados em redes de sensores deverão ser autónomos e não hierarquizadas, ou seja, não devem depender de um nó específico para ser o responsável da organização. Como os nós apresentam grandes limitações a nível de energia disponível devem ser eficientes em termos de tipo e frequência de mensagens trocadas. Além disso deverão suportar um protocolo de encaminhamento que seja suficientemente flexível para que a falha de um ou vários elementos não seja impeditivo da transmissão da mensagem.

Assim as redes de sensores são redes passíveis de serem instaladas em diversos ambientes sendo que as suas aplicações vão desde aplicações militares para controlo de elementos operacionais num campo de batalha, a monitorização de condições ambientais em edifícios, detecção de incêndios em grandes áreas florestais ou detecção de movimento numa determinada área geográfica.

Um exemplo de aplicação deste tipo de rede de sensores é a que se encontra implementada no campus do Instituto Superior Técnico – Tagus Park e que efectua a monitorização das condições ambientais (luz e temperatura) e detecção de movimento em salas de aulas, laboratórios e oficinas. A rede implementada utiliza sensores SunSpot desenvolvidos pela Sun Microsystems que apresentam capacidades de processamento e memória superiores ao que seria espectável de encontrar em dispositivos desta natureza. Esta capacidade permitiu que fosse possível a instalação de um servidor HTTP em cada nó e assim gerar páginas dinâmicas para interagir com o sensor através de uma convencional rede IP, disponível em qualquer localização com acesso à internet.

O presente projecto pretende implementar novas funcionalidades sobre esta rede aumentando a interactividade com o sistema, permitindo além da simples consulta de medições, a configurações de um conjunto de funções de agregação entre os nós constituintes.

O capítulo 2 apresenta uma lista detalhada dos objectivos deste projecto. De seguida apresenta-se o trabalho relacionado com a descrição do projecto anterior e algumas informações sobre os SunSpots. O capítulo 4 apresenta o sistema desenvolvido e uma descrição das várias funcionalidades acrescentadas. Por último são retiradas as principais conclusões do projecto e as referências utilizadas para a execução do presente relatório.

2. Objectivos

O objectivo deste trabalho é introduzir novas funcionalidades à aplicação de rede de sensores SunSpot implementada no campus IST Tagus Park, que vai permitir:

  • Configurar cada sensor para se tornar não só um elemento de recolha de dados individuais mas também que seja possível a agregação de dados de outros nós e posterior cálculo de valores consoante a função de agregação escolhida.
  • Implementar alguma segurança no sistema, de forma a que operações de configuração deverão apenas ser disponibilizadas a elementos registados, sendo que o utilizador comum apenas poderá consultar informação recolhida em tempo real ou que se encontra guardada nos logs.
  • Apresentar uma representação da rede e de como os nós estão organizados entre si e qual o caminho definido pelo protocolo de encaminhamento para a estação base.
  • Desenvolver o sistema de recolha de dados já existentes, tornando-o parte integrante do processo e que periodicamente irá obter os dados presentes em cada sensor e guardar numa base de dados para posterior consulta.

3. Trabalho relacionado

Como trabalho relacionado apresenta-se um resumo do projecto desenvolvido anteriormente e algumas propriedades técnicas dos SunSpots que constituem a rede.

3.1 Visão geral do sistema

Tal com foi referido o projecto anterior pretendeu aproveitar a capacidade de processamento acrescida dos SunSpot e instalar em cada nó um servidor HTTP que seja capaz de apresentar páginas dinâmicas com o resultado dos valores medidos pelos sensores. Estes valores podem ser consultados online através de aplicações CGI disponibilizadas pelos SunSpot.

O sistema é constituído pelos seguintes elementos:

1.png: 499x419, 40k (July 07, 2011, at 06:35 PM)

Figura 1 - Visão geral do sistema

  • Sensores SunSpot encontram-se instalados nas vários salas em monitorização e contêm um servidor HTTP, um sistema de descoberta de nós e aplicações tipo CGI para representar os valores medidos.
  • HTTP Proxy efectua a tradução do protocolo TCP/IP para Radiogram utilizado pelos SunSpots. Também é parte integrante do processo de descoberta dos vários sensores.
  • HTTP Server que disponibiliza as páginas visualizadas pelos utilizadores do sistema. Efectua os pedidos dos utilizadores e apresenta os valores medidos pelos sensores após a tradução efectuada pelo Proxy Server.
  • Application Server que comunica com o Proxy periodicamente para efectuar pedidos a cada um dos SunSpot e obter individualmente cada medida de cada sensor, utilizando as funções já existentes no HTTP Server. Os resultados são guardados em ficheiros CSV.

3.2 Sistema de descoberta

Para que o nó seja reconhecido com activo e para prevenir que sejam efectuados pedidos a nós que já tenham sido desactivados ou que perderam comunicação com a rede encontra-se implementado um sistema de descoberta e registo que se processa da seguinte forma:

  • Spot periodicamente envia em broadcast uma mensagem constituída apenas por um byte “1” no porto 33
  • O proxy está permanentemente à escuta neste porto e após a recepção desta uma mensagem abre nova ligação (agora directamente para o spot em questão) e envia uma mensagem composta por um byte “2” e dois números inteiros que contêm o período de dutycycle e timeout.

Após o envio o proxy guarda a informação do spot com estando activo durante aproximadamente 2 dutycycle. Passado esse tempo se o registo não for renovado será retirado da lista de nós activos e deixará de estar contactável.

3.3 SunSpot

Os sensores utilizados neste projecto são SunSpot (Sun Small Programmable Object Technology) produzidos pela Sun Microsystems. São baseados num CPU ARM920T 180MHz 32-bit com 512Kb memória RAM e 4Mb de memória Flash. Contêm uma antena integrada e um controlador TI CC2420 que disponibiliza comunicação via rádio segundo o protocolo 802.15.4.

2.png: 386x364, 135k (July 07, 2011, at 06:35 PM)

Figura 2 – Anatomia do SunSpot.

O dispositivo utiliza uma máquina virtual Java ME (micro edition) Squawk que corre directamente no processador sem recurso a sistema operativo. Esta VM escrita em Java, C/C++ e Assembler possibilita ao utilizador a criação de programas em linguagem de alto nível sem se preocupar em demasia com a tradução para baixo nível, utilizando um IDE standard como o NetBeans. Apresenta uma “memory footprint” de aproximadamente 80Kb, e cerca de 270Kb para bibliotecas de sistema que poderão ser executadas directamente da memória Flash.

3.png: 220x203, 13k (July 07, 2011, at 06:35 PM)

Figura 3 – Arquitectura da software stack nos SunSpot

Tal como pode ser verificado na figura no fundo da stack encontra-se a máquina Squawk a correr directamente no HW, sem recurso a sistema operativo. A SPOTlib desempenha as funções básicas de I/O e acesso a camadas mais básicas do protocolo MAC para funções de rádio. Acima encontra-se a multihoplib que disponibiliza o acesso aos protocolos rádio utilizados pelos SunSpot (Radiogram e RadioStream) e trata do encaminhamento de pacotes em caso de multihop. A ransducerlib executa a comunicação com a placa de sensores eDemo obtendo os valores registados pelo acelerómetro, LED, temperatura, etc. Por último encontra-se o código das aplicações criadas pelos programadores que estende a classe MIDlet presente na Java ME.

3.4 Sensores

Acelerómetro O sensor LIS3L02AQ consiste num sensor Micro-Electro-Mechanical System (MEMS) que é accionado quando uma aceleração linear é aplicada causando um desequilibrio eléctrico que é registado pelo conversor analógico digital. A tensão é então convertida para força g em escalas de ±2g ou ±6g.

4.png: 199x126, 11k (July 07, 2011, at 06:35 PM)

Figura 4 – Sistema de eixos do acelerómetro

Se o Spot estiver em repouso então o valor da aceleração devido à força gravitacional da Terra será 1g no eixo positivo Z (devido ao principio da força equivalente exercida pela superfície) e 0 nos restantes. Os métodos definidos para obtenção destes valores são:

EDemoBoard.getInstance().getAccelerometer().

getAccelX()– aceleração ao longo do eixo X

getAccelY() – aceleração ao longo do eixo Y

getAccelZ() – aceleração ao longo do eixo Z

getAccel() – norma da aceleração em todos os eixos

Além da aceleração também é possível obter a orientação do Spot através do valor da aceleração no eixo e a norma. Não tendo sido abordada neste projecto.

Sensor de temperatura

Através do sensor ADT4711 permite obter o valor aproximado da temperatura ambiente entre -40ª e +125º com uma resolução de 0,25º. Como o valor da temperatura é medido no conversor A/D verifica-se que quando ligado ao USB apresenta valores de temperatura superiores ao real com uma diferença de aproximadamente 10º. O método utilizado para obter o valor da temperatura é: EDemoBoard.getInstance().getADCTemperature();

Sensor de luminosidade

Este sensor apresenta valores inteiros entre 0 e 1023 representando as condições de luminosidade em cada momento. Para prevenir erros de medida perante fontes de luz que apresentam oscilações muito rápidas (como lâmpadas fluorescentes) o sensor efectua 17 medidas (configurável) em intervalos de 1ms e retorna a média de todas os valores obtidos. Para a obtenção deste valor é invocado o método: EDemoBoard.getInstance().getLightSensor().getAverageValues()

Bateria A bateria de iões de lítio com 3,6 V e 750mAh é recarregável por USB. Os consumos de energia variam entre modos de operação segundo a seguinte tabela:


Modo de OperaçãoConsumo
Deep Sleep31 μA
Idle/Shallow sleep, radio off23 mA
Idle/Shallow sleep, radio on44 mA
ARM running, radio off80 mA
ARM running, radio on105 mA

Tabela 1 – Consumo de bateria de acordo com modo de operação. Retirado de [2]

Para obter os valores registados foram utilizados os seguintes métodos: Spot.getInstance().getPowerController().getBattery() getBatteryLevel()–capacidade restante em percentagem getAvailableCapacity()–capacidade restante em mAh getChargeCount()–número de ocorrências em que Spot esteve à capacidade máxima getState()–retorna o estado da bateria de entre os possíve valores: NO_BATTERY, DEAD_BATTERY, LOW_BATTERY, DISCHARGING, CHARGING, EXT_POWERED, TEMPERATURE_OUT_OF_RANGE

4. Arquitectura do sistema

Os desenvolvimentos efectuados não alteraram substancialmente a arquitectura do sistema existente, sendo que as principais alterações prendem-se com a inclusão de base de dados para utilizadores e para guardar os dados recebidos pelos SunSpots. Também o processo de aquisição dos logs foi integrado no ProxyServer para possibilitar a consulta dinâmica da lista de nós activos e as agregações configuradas.

5.png: 458x260, 26k (July 07, 2011, at 06:36 PM)

Figura 5 - Visão geral do sistema implementado

Proxy & Log Server

Aplicação Java que efectua a tradução dos pedidos TCP/IP/HTTP do WebServer para radiogram/HTTP utilizado pelos Spots. Mantém uma representação da organização da rede com todos os nós e respectivas agregações activas. Adicionalmente efectua periodicamente pedidos aos SunSpots para obtenção de todos os valores medidos pelos sensores que serão guardados numa base de dados.

MySQL Users Database

Base de dados onde estão registados os login e passwords de todos os utilizadores autorizados a efectuar alterações nas configurações de agregação dos SunSpot.

MySQL Sensor Log Database

Base de dados onde estão guardados os valores dos sensores obtidos através do processo de log executado pelo Proxy Server.

Web Server

Servidor das páginas visualizadas pelo utilizador, efectua a validação dos utilizadores para aceder a páginas de configuração e pesquisas na base de dados dos logs para apresentar ao utilizador.

4.1 Agregação

Funcionalidade adicionada aos SunSpot que paralelamente ao servidor HTTP vai efectuar pedidos a outros SunSpots para obter os seus valores actuais dos sensores e devolver o valor agregado segundo as funções de agregação implementadas.

As funções de agregação de um Spot são definidas por elemento, ou seja, é possível ter num binómio Spot agregador / agregado uma função diferente para cada um dos elementos medidos (temperatura, luminosidade e bateria). No entanto para todos os Spot que estiverem na lista de agregação de um elemento partilham a mesma função de agregação. Foi opção do projecto não incluir os valores do acelerómetro uma vez que dada as suas propriedades instantâneas, uma agregação deste elemento não terá significado.

Para o presente projecto foram implementadas 3 funções de agregação:

Average – retorna a média dos valores medidos Maximum – retorna o máximo dos valores Minimum – retorna o mínimo dos valores.

As funções de agregação estão implementadas no código do Spot, logo qualquer alteração/adição obrigará a um novo deployment em cada Spot.

O processo de agregação ocorre da seguinte forma:

O utilizador pela página web do projecto selecciona um Spot que será o agregador e acede à página de configuração. Nessa página é mostrado as agregações actuais e apresenta uma lista de nós candidatos onde exista actualmente ligação ao Spot agregador. Define um Spot alvo e o elemento que pretende agregar. O pedido é reencaminhado pelo Proxy Server para o Spot como se trata-se de um pedido HTTP (recebido no porto 80 do Spot). O Spot agregador ao receber o pedido vai adicionar o id e elemento à lista de agregação e preencher com os seus valores os do Spot alvo. Foi efectuada esta opção devido para manter um estado válido no período de tempo entre o Spot receber o comando para agregar e ser possível contactar o nó agregado. Para confirmar a alteração o Spot vai devolver a mesma mensagem que recebeu para o Proxy que por sua vez vai adicionar essa informação ao objecto ClientEntry que representa um nó activo.

A partir deste momento sempre que o Spot acordar do dutycycle vai iniciar um novo processo que contacta o(s) Spot agregados e efectua um pedido para obter os seus valores. Estes valores vão se manter activos até ser possível contactar novamente o Spot alvo.

A remoção de uma ligação de agregação apresenta a mesma metodologia.

No anexo 4 encontra-se um diagrama de evento com o processo de agregação.

4.2 Representação da Rede

A representação da rede é visualizada na página de entrada do projecto. Apresenta a lista de Spots com as respectivas agregações activas e qual o caminho percorrido para contactar a basestation. Adicionalmente também é possível visualizar quais as salas onde estão instalados cada um dos Spots.

6.png: 498x295, 19k (July 07, 2011, at 06:36 PM)

Figura 6 – Exemplo de sistema de representação da rede

Tal como pode ser verificado pela imagem exemplo da representação da rede, o Spot instalado na sala 1.64 encontra-se a agregar os valores de temperatura do Spot instalado na 1.62 com a função de agregação que devolve o mínimo dos dois valores. Por sua vez o Spot da sala 1.62 encontra-se a agregar os valores de luminosidade do Spot instalado na sala 1.64. Pode-se verificar também que o Spot da oficina encontra-se em multihop através do Spot da sala 1.64 para comunicar com a basestation.

Para apresentar esta representação e para manter uma listagem actualizada das ligações de agregação activa para cada nó foi efectuado uma alteração ao processo de descoberta descrito em 3.2, que agora é composto por três fases.

  • Spot periodicamente envia em broadcast uma mensagem constituída apenas por um byte “1” no porto 33
  • O proxy está permanentemente à escuta neste porto e após a recepção desta uma mensagem abre nova ligação (agora directamente para o spot em questão) e envia uma mensagem composta por um byte “2” e dois números inteiros que contêm o período de dutycycle e timeout
  • Após a recepção desta mensagem o Spot ainda devolve para o Proxy uma String contendo todas as ligações de agregação activas.

Esta alteração permite que se o Proxy Server for desligado após reinicialização irá retomar as últimas configurações efectuadas.

O processo de representação da rede é activado sempre que um utilizador acede à página principal do projecto e é constituído pelos seguintes passos:

Proxy Server obtém uma lista de nós activos da instância da classe “ActiveClients” com as respectivas ligações de agregação. Para cada um dos nós efectua um traceroute para o Id da basestation, obtendo a informação do número de hops necessários e qual o próximo Id.

Essa informação é guardada num vector e enviada para o objecto da classe “NetTree” desenvolvido unicamente para efectuar o processamento recursivo de uma árvore de nós. Após a construção da árvore é percorrida retornando uma string com todos os nós e agregações ordenados segundo o exemplo descrito na figura.

4.3 Logs

O processo de logs instalado anteriormente executava uma aplicação externa que com base num ficheiro de texto contendo uma lista de ids dos nós instalados no projecto, efectuava pedidos HTTP para o Proxy Server que reencaminhava para o respectivo nó. Para cada nó eram efectuados 4 pedidos (um por cada elemento) aumentando consideravelmente o número de mensagens a transitar na rede. Estes valores eram guardados em ficheiros CSV, existindo um ficheiro por dia e por elemento.

Esta abordagem apresentava algumas desvantagens dado que como referido aumentava o número de mensagens, caso ocorre-se alguma substituição, adição ou remoção de Spots obrigava a alterar o ficheiro de texto que contém a lista de nós. Se por exemplo um dos nós ficasse inactivo os pedidos continuariam a ser processados. A visualização dos logs para mais que um dia ou agregando mais do que um elemento implicava a algum processamento de texto.

Assim para colmatar estas desvantagens o processo de obtenção de Logs foi incluído na aplicação Proxy Server, aproveitando a manutenção da lista de nós activos através do processo de descoberta. Também foi configurada uma nova mensagem nos Spots/ProxyServer que apenas com um pedido retorna todos os valores a serem guardados. Caso haja agregação o valor retornado desse elemento já é afectado pela função de agregação configurada. O processo de manutenção dos dados foi alterado de ficheiros para uma base de dados MySQL constituída apenas por uma tabela que contém a data da medida, o id do Spot e os 4 valores dos elementos medidos. Toda esta informação pode ser consultada online pela página do projecto através do link “Logs”.

Nessa página é apresentado um formulário HTML para definir a data de início e fim para a qual se pretende obter os dados. Se acedermos ao link através de uma página de um Spot obtemos os dados apenas do Spot seleccionado, se for acedido através da página principal são retornados os valores de todos os Spots.

7.png: 1138x230, 25k (July 07, 2011, at 06:36 PM)

Figura 7 – Exemplo de página de consulta de logs

Os resultados são apresentados efectuando uma query à base de dados e apresentados numa de tabela ordenada por tempo, através da aplicação phpreports.

8.png: 1138x804, 126k (July 07, 2011, at 06:36 PM)

Figura 8 – Exemplo de resultados da pesquisa na base de dados dos logs

Limitação de acesso

Outro requisito do projecto era que apenas utilizadores registados tenham acesso a páginas de configuração onde se efectua as alterações nas operações de agregação. Os restantes utilizadores apenas terão acesso à visualização de dados online e dos logs.

Este requisito foi efectuado através da criação de uma base de dados MySQL onde se encontra a lista de utilizadores e respectivas passwords. Para limitar o acesso é apresentado um formulário HTML na página de configuração de agregações a solicitar username e password que serão validadas com as existentes na base de dados.

9.png: 687x409, 42k (July 07, 2011, at 06:36 PM)

Figura 9 – Exemplo de página de configuração antes de validação do utilizador

Após validação o utilizador é automaticamente redireccionado para a página de configuração onde poderá efectuar as operações de agregação.

10.png: 605x492, 50k (July 07, 2011, at 06:36 PM)

Figura 10 – Exemplo de uma página de configuração

Para efectuar a manutenção de utilizadores activos que podem efectuar as operações de agregação foi criada uma página específica estas funções de administração cujo link se encontra disponível no topo de qualquer página do projecto.

11.png: 1115x198, 18k (July 07, 2011, at 06:36 PM)

Figura 11 – Página de administração de utilizadores antes de validação

Nesta página, que só pode ser acedida pelo utilizador “root”, pode-se verificar todos os utilizadores autorizados pelo username e password. Para efectuar qualquer alteração (seja de “Add” ou “Del”) deve-se sempre introduzir o username e password. Caso contrário o sistema não efectua qualquer alteração.

12.png: 632x263, 19k (July 07, 2011, at 06:36 PM)

Figura 12 – Página de administração de utilizadores após validação

5. Conclusão

As redes de sensores têm vindo nos últimos anos a apresentar grandes evoluções tecnológicas. Estes desenvolvimentos proporcionaram a criação de novas aplicações que nunca teriam sido consideradas devido às restrições associadas a estes dispositivos. Como tal têm sido alvo de vários estudos e projectos por parte da comunidade científica e empresarial.

Os SunSpots desenvolvidos pela Sun MicroSystems apresentam uma boa plataforma para a construção de aplicações para redes de sensores, permitindo ao programador abstrair-se de código de baixo nível, e concentrar-se na aplicação em causa. Adicionalmente verificou-se que as aplicações exemplo incluídas no SDK, o programa de simulação Solarium e a documentação disponibilizada facilitam a curva de aprendizagem necessária para o desenvolvimento de novas aplicações.

Apesar de não ser habitual a inclusão de servidores HTTP em redes de sensores verificou-se que se trata de uma boa forma de integração das redes de sensores com as redes TCP/IP. Como desvantagem verificou-se apenas que devido ao formato HTTP as mensagens trocadas entre os sensores e o Proxy Server apresentam bastante overhead, aumentando o tráfego cursado na rede.

Foram cumpridos com sucesso todos os objectivos propostos, que trouxeram grande valor ao projecto, mantendo no entanto a mesma filosofia de operação já implementada.

As funções de agregação representam uma funcionalidade fulcral para as redes de sensores. Com o desenvolvimento do código de comunicação entre sensores, facilita a introdução de novas funcionalidades que necessitem de cooperação entre os vários nós da rede.

A representação da rede aumenta o conhecimento de como a rede se encontra organizada e ajuda a identificar casos onde a comunicação entre sensores se encontra degradada. Com a inclusão na página principal das funções de agregação e da localização física dos SunSpot, permite efectuar um planeamento simplificado da rede e das suas funções de agregação.

As alterações efectuadas ao sistema de log apresentam grandes vantagens em relação às disponibilizadas anteriormente. O desenvolvimento de novas mensagens especificamente para logs permite a diminuição da quantidade de mensagens trocadas pelos elementos da rede. A alteração para base de dados permite que através de aplicações de Data Mining efectuar uma pesquisa aprofundada sobre os valores registados pelos SunSpot. Adicionalmente o sistema de logs encontra-se preparado para que a introdução ou substituição de SunSpots possa ser efectuada sem haver necessidade de alterar o código da aplicação.

A introdução de segurança permite um maior controlo sobre a aplicação e permite uma maior divulgação do projecto a um grupo mais vasto de utilizadores.

Como trabalho futuro sugere-se a introdução de novas funções de agregação, desenvolvimento de uma interface gráfica e a implementação de sensores externos aos SunSpot de forma a monitorizar novos elementos como por exemplo humidade, CO2, intrusão, etc.

6. Referências

  1. Slides da disciplina de Redes de Sensores
  2. Pedro Moscoso, HTTP Server for SunSpot, Redes Sensores 2008/2009
  3. Sun Micro Systems, Sun Spot Developer’s Guide, 7 May 2009
  4. Ron Goldman, Using LIS3L02AQ Accelerometer, Sun Micro Systems 2007
  5. Sun Labs, Sun Spot eDEMO Technical Datasheet rev 8.0, October 2010
  6. Sun Labs, Sun Spot Main Board Technical Datasheet rev 8.0, October 2010
  7. Sun Labs, Sun Spot Programmer’s Manual release v6.0 (Yellow), November 2010
  8. Sun SPOT Library API (Yellow)
  9. Sun SPOT Host Library API (Yellow)
  10. www.sunspotworld.com

Anexo 1 - Manual de instalação

Para futura referência descreve-se um exemplo de procedimento para a instalação de raiz do sistema com base no sistema operativo Linux Ubuntu 10.10.

  • Instalar o módulo PHP5+módulo phpreports
        o Sudo apt-get install php5
        o Sudo apt-get install phpreports
  • Instalar servidor HTTP Apache2 + módulo para PHP
        o Sudo apt-get install apache2
        o Sudo apt-get install libapache2-mod-php5
  • Download Java em www.java.com e instalar o Java Development Kit versão 6 + módulo Apache Ant + biblioteca de ligação a Base de Dados MySQL
        o Sudo apt-get install ant
        o Sudo apt-get install libmysql-java
  • Instalar servidor MySQL + aplicação de administração MySQL Administrator (opcional) + aplicação QueryBrowser (opcional)
        o Sudo apt-get install mysql-server
        o Sudo apt-get install mysql-admin
        o Sudo apt-get install mysql-query-browser
  • Download de IDE NetBeans
        o Sudo apt-get install Netbeans
  • Download da aplicação SunSpotManager
  • Verificar se existe a biblioteca/daemon HAL(Hardware Abstraction Layer) necessário para a detecção automática dos SunSpot ligados ao USB
        o Sudo apt-get install hal
  • Executar a aplicação SunSpotManager que deverá completar as restantes configurações.

Verificar propriedades da BaseStation

SunSpotManager instalou SunSpot sdk na home do utilizador que a executou e com base nessa instalação alterar/adicionar nos ficheiros

  • ~/SunSpot/sdk/default.properties
  • ~/.sunspot.properties

Definir as seguintes propriedades exemplo para a Basestation

  • BASESTATION.SHARED=FALSE (obrigatório)
  • DEFAULT.REMOTE.CHANNEL=25
  • DEFAULT.REMOTE.PAN.ID=4
  • DEFAULT.REMOTE.TRANSMIT.POWER=0

Instalação de novos Spots:

Em cada instalação do SunSpotManager é criada uma hash key de segurança que impede que outros Spots consigam comunicar ou ser efectuada a execução de MIDLets pertencentes a outros projectos. Assim antes de configurar o Spot deve-se actualizar o firmware através dos seguintes comandos numa directoria onde exista um projecto (ex. ~/Desktop/RS/HTTPServer) e com o Spot ligado ao USB

  • Cd ~/Desktop/RS/HTTPServer
  • Ant upgrade

Após o upgrade ter terminado deve-se efectuar o deployment da MIDLet a executar nos Spot. Assim com o Spot ligado ao USB efectuar o comando na directoria que tem o projecto HTTPServer

  • Ant deploy

Para haver comunicação entre cada Spot/Basestation estes devem estar na mesma “rede”, logo deve-se verificar em cada spot individual através dos comandos:

  • Ant info (se o Spot estiver ligado localmente)
  • Ant –DremoteId=0014.4F01.000.6CFB info (utilizando a basestation para comunicar com o spot remotamente)

Os seguintes parâmetros:

  • SPOT.RADIO.CHANNEL=25 (igual ao definido para a basestation)
  • SPOT.PAN.ID=4 (igual ao definido para a basestation)
  • SPOT.TRANSMIT.POWER=0 (não é obrigatório mas recomendável que o Spot esteja a emitir a potência máxima = 0dBm).
  • SPOT.MESH.ENABLE=TRUE
  • SPOT.MESH.MANAGEMENT=TRUE
  • SPOT.MESH.ROUTING.ENABLE=ALWAYS

As 3 últimas propriedades permitem que o Spot possa funcionar como retransmissor de outros Spot que não tenham contacto directo com a basestation (multihop) e permitir obter a configuração da rede/caminho percorrido (traceroute, tabela de routeamento e estatísticas de cada nó).

Executar a aplicação ProxyServer

Copiar o projecto ProxyServer para uma qualquer directoria (exemplo Desktop) e efectuar:

  • cd ~/Desktop/ProxyServer
  • ant

e o programa deverá iniciar automaticamente, tanto na funcionalidade do acesso online como a gravação dos logs para a base de dados MySQL.

Anexo 2 - Manual de utilização

Iniciar

O programa encontra-se configurado para executar automaticamente assim que o utilizador efectue o login no PC do ProxyServer, aparecendo um terminal com o output. Para terminar a execução deve-se efectuar CTRL+C no terminal.

Para reiniciar deve-se abrir um terminal e na directoria onde se encontra o projecto ProxyServer efectuar o comando: “ant”. O programa deverá compilar o código e executar a aplicação imediatamente.

Iniciando um browser e direccionando para o endereço loopback ou para o endereço atribuído (127.20.48.73) apresenta a representação da rede.

Efectuar configurações de agregação

A partir da representação da rede e seleccionando um Spot coloca-se as credenciais válidas no form apresentado.

15.png: 688x414, 42k (July 07, 2011, at 06:37 PM)

Após a validação do utilizador é apresentado as agregações activas (se existentes) e um novo form com a lista de spots que é possível agregar, os elementos (luz, temp e bateria) e as funções de agregação (max, min e average)

16.png: 688x414, 42k (July 07, 2011, at 06:37 PM)

Para eliminar deve-se seleccionar o Spot agregado da lista de spots e o elemento que se pretende eliminar. Não é necessário especificar a função de agregação na operação de eliminar.

O procedimento de adicionar uma agregação é trivial, apenas com a ressalva de só poder existir uma função de agregação por elemento.

Por exemplo: Considerando as agregações do Spot X.

  • Spot X agrega elemento (ex. luz) do Spot Y com função (ex. max)
  • Configuração de nova agregação para Spot Z no mesmo elemento (luz) com função de agregação (ex. min)
  • Todas as agregações do elemento (luz) são alteradas para a última função configurada (min).

Foi efectuada esta opção porque como só existe um output por elemento não faz sentido existirem mais do que uma função de agregação por cada elemento.

Anexo 3 - Reset ao sistema

Caso o programa apresente algum comportamento não espectável é aconselhável efectuar um reset ao sistema. Para tal deve-se parar o programa ProxyServer, seleccionando o terminal que está a executar e pressionar CTRL+C. Se após o reiniciar o problema se mantiver deve-se aceder no PC ao emulador “Solarium”

17.png: 767x225, 53k (July 07, 2011, at 06:37 PM)

No emulador efectuar undeploy e deploy da MidLet em cada um dos Spots. Caso não apareça todos os Spots do sistema deve-se efectuar o reset manual no Spot.

Anexo 4 - Diagrama de eventos do processo de agregação

18.png: 917x471, 61k (July 07, 2011, at 06:37 PM)