Providing over-the-web access to the Sun SPOTs

Project Details:

Goal: This project aims to implement a solution for remote web access to the Sun SPOTs. The web server (e.g. NanoHTTPD should reside on the SPOT itself, and provide access to the sensor readings. More advanced logging and presentation should also be implemented, if possible, and maybe feature access control. The computer supporting the base station must run a gateway application that bridges the connections, and some kind of web proxy to allow the outside world to access any of the (dinamically registered) nodes. Furthermore, data should be periodically collected offline using Yggdrasil and submitted to the sensor.network repository.

Assigned to: Pedro Moscoso

Project Website: Sun Spot Web access

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

HTTP Server para SunSpots

O objectivo do trabalho consistiu em desenvolver um servidor HTTP para os Sensores SunSpot bem como todos os mecanismos envolventes do sistema.

Arquitectura

Para cumprir com estes requisitos estruturou-se o projecto para ser dividido em várias componentes.

SunSPOTs:

  • HTTPD Server (Radio Data Stream sockets)
  • Discovery service
  • Sensors Applications (CGI)

Network Proxy:

  • Discovery service
  • TCP/IP to RadioStream Http Proxy

HTTP Server with Proxy

  • Interface with proxy

Application Server:

  • Pooling and analysis
architecture.png: 499x419, 40k (February 15, 2010, at 05:40 PM)
Network architecture

A arquitectura divide-se em cinco blocos principais, SunSpots que inclui o Servidor HTTP, o Sistema de descoberta de nós e as aplicações do tipo CGI. O componente Network Proxy, ficará responsável por fazer toda a tradução do protocolo de TCP para Radiogram, bem como incluir os mecanismos de configuração e descoberta dos nós. HTTP Server foi pensado como a aplicação que implementa os mecanismos oferecidos pelos resto do sistema. Finalmente o Application Server que, sendo uma parte externa, servirá para fazer a recolha de dados provenientes da rede de sensores via http.

SunSpots

Discovery Service: Para se registar no proxy server foi desenvolvido um sistema de descoberta. O sistema de descoberta consiste na troca de duas mensagens, uma primeira mensagem de registo do sensor no proxy, constituída apenas por um byte a "1" e enviada em broadcast. Uma segunda mensagem de 2 bytes é de seguida enviada pelo proxy para o sensor e inclui os parâmetros de configuração relativos ao duty cycle. Ocorrida esta primeira fase o Proxy guarda o estado do sensor como activo durante aproximadamente o tempo equivalente a dois DutyCycles. Caso o registo não seja renovado, entretanto, o sensor deixa de fazer parte da lista de nós activos e deixa de poder ser contactado até que seja feito um novo registo.

HTTP Server: Foi desenvolvido uma aplicação que implementa parte (GET) do protocolo HTTP sobre Radiogram. O servidor HTTP foi projectado para implementar aplicações dinâmicas (CGI). A estrutura de uma aplicação dinâmica deverá seguir o seguinte estrutura:

GET.png: 621x146, 18k (February 15, 2010, at 05:50 PM)
Estrutura de uma aplicação dinâmica

Os argumentos recebidos na função execute representam os argumentos passados no endereço HTTP. O resultado da função deverá ser uma string com o HTML de resposta. Caso ocorra algum erro poderá ser passada uma excepção que em resultado prático origina uma mensagem de erro "404 Not found".

Sensor Applications (CGI)

Para o âmbito do projecto foram desenvolvidas as seguintes aplicações que permitem aceder aos sensores existentes nos SunSpot disponíveis.

  • accelerometer - Devolve a aceleração actual do sensor. O valor pode variar de -2 a 2. Os parâmetros aceites são x,y,z.
  • battery -Devolve o estado da bateria. Sem parâmetros retorna uma vista geral sobre o estado da bateria. Os parâmetros que podem ser passados são: level, available, maximum e cycles.
  • light - Devolve a intensidade de luz medida pelo sensor. Os valores podem variar de 0 a 740.
  • lights - Permite controlar os leds do sensor. os parametros são /numeroDoLed/on ou off/r/g/b para acender um led.
  • temperature - Leitura da temperatura.

Poupança de bateria

Para reduzir a utilização da bateria o sistema foi projectado para ao mesmo tempo optimizar o consumo de bateria e causar o menor impacto a quem acede ao servidor. Desta forma assumiu-se por parte do sensor dois tempos. O Sleeping Time que representa o tempo em que o sensor está completamente desligado e o Service time que representa o tempo em que o sensor responde aos pedidos HTTP. De forma a poder responder a todos pedidos foi desenvolvido um sistema de contenção de pedidos que recorrendo ao atraso na visualização das páginas consegue fornecer a quem tenta aceder ao Spot a sensação que o servidor http está sempre activo e que nenhum pedido é perdido.

A imagem seguinte ilustra o modo de funcionamento do sensor.

sensor.png: 724x30, 3k (February 15, 2010, at 05:50 PM)
Modo de funcionamento do sensor

Consumos prático de energia do Sun Spot: O consumo de energia por parte dos Spots pode variar entre 5 modos de operação, como se pode ver na tabela.

Modo Consumos Deep Sleep 31 uA Idle/Shallow sleep, radio off 23 mA Idle/Shallow sleep, radio on 44 mA ARM running, radio off 80 mA ARM running, radio on 105 mA

O ideal seria que o Sleeping Time fosse sempre em modo Deep Sleep, no entanto, tal não é possível já que as operações do sistema impedem que tal aconteça de uma forma muito regular. Para diminuir o impacto de um Sleep Time em modo Idle (no caso de valores de tempo alto) passou-se a gestão dos modos de sleep para o sistema operativo do sensor.

Network Proxy

O sistema de descoberta recebe pedidos dos vários nós e regista numa base de dados temporária, tal como foi referido inicialmente. Após a troca inicial o servidor responde com o valor de configuração dos tempos. Além do um Sleeping Time pré-definido (60 segundos) e de um Service time (2 segundos), existe a possibilidade de serem configurados dinamicamente ao longo do tempo através de uma configuração manual que pode ser feita no proxy.

As funções de configuração podem ser acedidas em http://proxyaddr/sensoraddr/config/timeout/value e http://proxyaddr/sensoraddr/config/dutycycle/value que respectivamente correspondem ao tempo em que o nó está acordado (Service time) e ao tempo em que o nó está em modo poupança (Sleeping Time).

TCP/IP to RadioStream HTTP Proxy

Responsável por fazer a ponte entre a rede TCP/IP e a rede de sensores baseada em "datagramas". A ideia inicial passou por criar um único proxy que fosse capaz de suportar múltiplos nós de uma forma transparente ao invés de um proxy para cada sensor. Para isso, além do mecanismo de descoberta, foram desenvolvidos mecanismos intermédios que processam os pedidos HTTP e os modificam consoante o sensor, ao contrário de uma outra abordagem também pensada inicialmente que reencaminharia directamente os pedidos para o nó, o que exigiria um proxy por cada sensor. Um dos primeiros problemas que surgiu estava relacionado com o nível fiabilidade que é garantida com TCP/IP e que não existe em redes de sensores. O método adoptado para ultrapassar esta barreira passou por enviar pedidos para o sensor até ser recebida a resposta. Esta abordagem, utilizada inicialmente no projecto, apresentou alguns problemas. Primeiro com "dutycycles" superiores a cerca de 30 segundos o sistema deixa de saber a rota para o nó, por outro lado a rede era inundada com pedidos, no caso do sensor não estar acordado, o que em casos de multihop se traduzia por um gasto significativo de bateria dos nós circundantes. A solução final, passou por através dos tempos de registo do nó e dos tempos de serviço, disponíveis no proxy, fazer os pedidos numa janela de tempo em que existe grande probabilidade de o sensor estar em Service Time. Desta forma reduziu-se drásticamente o numero de pedidos lançados a rede de sensores.

HTTP Server Interface e Application Server

  • O HTTP Server é o interface desenvolvido em PHP com recurso a SVG para facilitar e simplificar o acesso aos nós e ao proxy.
  • O Application Server é uma aplicação que através do Proxy efectua e guarda em CSV diversas medidas efectuadas nos sensores.

Deployment

O deployment da rede foi feito no IST Taguspark nas salas 1.62, 1.64 e na oficina de electrónica. A configuração do servidor proxy foi feita numa máquina com o sistema operativo windows xp.

Dados do deployment:

Testes

  • Consumo de bateria: Realizaram-se alguns testes de forma a saber qual o impacto do Dyty Cycle no consumo da bateria. Na primeira amostra efectuou-se uma recolha de sensivelmente 6 horas, em que a cada minuto era feita uma leitura nos diversos sensores disponíveis num nó. Neste gráfico pode-se ver o consumo de bateria para um Duty Cycle de 15 s e um Service Time de 2s.
bateria.png: 760x367, 24k (February 15, 2010, at 06:04 PM)
Consumo de bateria com Duty Cycle=30s e service time=2s

No caso seguinte a configuração feita foi com Duty Cycle de 60 Segundos e Service Time de 2s

bateria2.png: 1672x780, 55k (February 15, 2010, at 06:04 PM)
Consumo de bateria com Duty Cycle=60s e service time=2s

Planeamento

Descrição Data Estado

Discovery system 28 Maio - 4 Junho done

Httpd Proxy (Proxy) 4 Junho - 8 Junho done

Httpd Server (Spot) 8 Junho -15 Junho done

Aplicações para o sensor 15 Junho - 25 Junho done

Proxy Interface 20 Junho - 25 Junho done

Application Server 5 Julho - 13 Julho done

Testes e ajustes 14 Julho - 30 Julho done