Departamento de Engenharia Electrotécnica REDES AD HOC E DE SENSORES 2011 / 2012 Mestrado Integrado em Engenharia Electrotécnica e Computadores 4º/5º ano 7º/9º semestre 2º Trabalho Prático: Aplicação anti-roubo para sensores sem fios IRIS a correr TinyOS 2.1.1 http://tele1.dee.fct.unl.pt Luis Bernardo
1. Objectivos Familiarização com o ambiente TinyOS e com o desenvolvimento de aplicações utilizando sensores sem fios IRIS, o sistema operativo TinyOS, a linguagem nesc e o ambiente de desenvolvimento Eclipse para TinyOS. Pretende-se também a ligação a aplicações Java de interface para o utilizador. O trabalho consiste no desenvolvimento de uma aplicação anti-roubo de sensores, em que um roubo é detetado e pode ser reportado para uma aplicação gráfica. O sistema inclui três tipos de elementos: Motes sensores que pretendemos proteger e que se ligam através do rádio 802.15.4; Um mote raiz (estação base), que se liga a um computador pela porta USB, e suporta a comunicação com a rede de sensores sem fios; Uma aplicação cliente, no computador, que realiza a configuração da aplicação a correr nos motes, e recebe e apresenta os alertas. Os motes sensores detetam as situações de roubo através de dois métodos: falha na iluminação (e.g. colocar num bolso); aumento da distância até ao mote raiz acima de um valor limite. São fornecidos três projetos, que já realizam parcialmente as funcionalidades pretendidas, consistindo o trabalho no completar dos projetos para ter todas as funcionalidades previstas. Mote sensor A Mote sensor B Mote raiz 2. Especificações A aplicação anti-roubo pode-se decompor em três elementos complementares: um protocolo para suportar a medição periódica da distância entre os motes sensores e o mote raiz; um protocolo de sinalização de roubo; e, um protocolo de configuração remota dos motes. Pretendese ainda que possam coexistir vários motes raiz no mesmo espaço i.e. ter motes sensores associados a diferentes motes raiz com diferentes zonas de proteção sobrepostas. Desta forma, cada mote raiz vai estar associado a um identificador de aplicação (AppID=DEFAULT_APPID) distinto. Durante o desenvolvimento do trabalho, cada grupo deve usar valores distintos para o identificador de aplicação e para os endereços MAC dos motes. 2.1. Protocolo de monitorização da distância para o mote raiz A monitorização da distância até ao nó raiz é realizada através da medição da potência recebida nos motes sensores para os pacotes enviados pelo mote raiz, obtida através da medição do RSSI (Relative Signal Strength Indication) durante a recepção de um pacote. Para permitir uma monitorização contínua, o mote raiz envia periodicamente uma mensagem do tipo beacon_t, com a seguinte estrutura:
typedef nx_struct beacon { nx_uint8_t AppID; } beacon_t; // Application ID A mensagem beacon_t contém o identificador de aplicação, permitindo distinguir qual foi o mote raiz que o enviou. As mensagens são enviadas com o tipo AM_BEACON=99 através de componentes de ligação do tipo AMReceiverC e AMSenderC. 2.2. Protocolo de sinalização de evento Os motes sensores monitorizam a luz e o RSSI, podendo detetar dois tipos de eventos: DETECT_DARK = 1 luminosidade abaixo do limiar; DETECT_RSSI = 2 potência de sinal abaixo do limiar. A comunicação entre os motes sensores e o mote raiz é assegurada através do serviço de recolha de mensagens, utilizando o número de tipo de mensagem (COL_ALERTS= DEFAULT_APPID) igual ao sucessor do identificador de aplicação. Os alertas de assalto são enviados com a estrutura alert_t, onde se inclui o endereço do mote roubado (stolenid), o que foi detetado (detect), e o nível de RSSI recebido (rssi), apenas usado quando o evento é DETECT_RSSI. typedef nx_struct alert { nx_uint8_t AppID; nx_uint16_t stolenid; nx_uint8_t detect; nx_int16_t rssi; } alert_t; // Application ID // -1 used to ping the root // DETECT_DARK or DETECT_RSSI // Carries received RSSI O mote raiz envia todas as mensagens de alerta que recebe à aplicação a correr no computador, através da porta USB, para que os eventos sejam visualizados. Deve ser usado o tipo de mensagem (AM_ALERT = 22) quando as mensagens são enviadas através da porta série. 2.3. Protocolo de configuração remota dos motes O programa cliente, residente no computador, para além de receber os eventos, também pode configurar vários parâmetros no sistema: detect o que é monitorizado: pode ser a luminosidade (DETECT_DARK), a distância (DETECT_RSSI), ou ambas (DETECT_DARK DETECT_RSSI); alert que tipo de alerta de roubo é usado: pode ser através de um LED do mote (ALERT_LEDS), do envio de uma mensagem para o mote raiz (ALERT_ROOT), ou ambos (ALERT_ROOT ALERT_LEDS); checkinterval o período de verificação da luminosidade e também de envio dos beacon no mote raiz; t_power a potência com que os beacons são transmitidos; rssi_threshold o nível limiar de RSSI a partir do qual se deteta o afastamento de um mote sensor. Estes campos são enviados numa estrutura do tipo settings_t, definida abaixo: typedef nx_struct settings { nx_uint8_t AppID; // Application ID nx_uint8_t alert, detect; // Define methods to alert and detect theft nx_uint16_t checkinterval; // Period for sending periodic empty alert // message, to force RSSI check nx_int16_t rssi_threshold; // RSSI threshold to start a theft alarm nx_int8_t t_power; // MAX: 0 = +3dBm ; MIN: 15 = -17.2dBm } settings_t; 3
As mensagens de configuração são geradas pela aplicação de controlo no computador, e são enviadas pela porta série USB para o mote raiz, em mensagens do tipo AM_SETTINGS=54. Depois, o mote raiz usa o serviço de disseminação para distribuir a configuração por todos os motes no sistema, com o tipo de mensagem igual ao identificador de aplicação mais uma unidade (DIS_SETTINGS=DEFAULT_APPID+1). Cada mote deverá atualizar a sua configuração local após a recepção da mensagem. 3. Desenvolvimento da aplicação A aplicação é desenvolvida a partir de um conjunto de programas de teste totalmente funcionais (AntiTheft_Node, AntiTheft_Root, AntiTheft_GUI), que realizam respetivamente, os motes sensores (nesc), o mote raiz (nesc) e a aplicação gráfica de controlo da rede (Java). A aplicação gráfica realiza a interface gráfica representada abaixo, que permite seleccionar: o identificador de aplicação; a porta série que é usada para comunicar com o mote; o período usado para verificar a luminosidade e para gerar beacons; o valor de limiar para o RSSI a partir do qual se considera que está fora de alcance; a potência de transmissão dos beacons, mais um conjunto de check buttons, onde se define os métodos de deteção de roubo ativos nos motes (luminosidade ou alcance rádio) e o método de reporte do roubo (ligar LED ou enviar mensagem para o mote raiz, para ser apresentada na aplicação Java). Cada grupo pode fazer todas as modificações que quiser aos programas base. No entanto, recomenda-se que invistam o tempo na correta realização da aplicação proposta. ID de aplicação, Porta USB do mote e período de verificação luz e envio Beacon Atualização da configuração na rede RSSI limiar e potência transmissão Seleção método deteção e de reporte Limpar janela de Log Botão de arranque Janela de Log O código nesc dos motes sensores está organizado em quatro ficheiros: AntiTheftC.nc Módulo que monitoriza o sensor de luminosidade e a recepção de beacons, gerando os alertas. Este módulo está incompleto faltam a funcionalidades de recepção de beacons e de geração do alerta associado, e de controlo do identificador de aplicação; AntiTheftAppC.nc Módulo de ligação que instancia os componentes dos motes sensores e define as ligações. Este módulo está incompleto faltam os componentes relativos à recepção de beacons e de medição de RSSI; antitheft.h Ficheiro comum às três aplicações, com a definição das constantes e dos tipos de dados; 4
Makefile Ficheiro de configuração da compilação, que define alguns parâmetros do sistema (tipo de placa de sensor, se usa o MAC com Low Power Listening, etc.). O identificador de aplicação (AppID) dos motes sensores é definido durante a compilação, através da constante DEFAULT_APID, que deverá ser única na rede para cada mote raiz. O endereço MAC de cada sensor também deve ser único. O código nesc do mote raiz está organizado em quatro ficheiros: AntiTheftRootC.nc Módulo que realiza a interligação ao PC pela porta USB, e que gera os beacons periódicos. Este módulo está incompleto falta o controlo da potência de transmissão dos beacons e do identificador de aplicação; AntiTheftRootAppC.nc Módulo de ligação que instancia os componentes dos motes sensores e define as ligações. Este módulo está incompleto faltam os componentes relativos ao controlo de potência de transmissão; antitheft.h Ficheiro comum às três aplicações, com a definição das constantes e dos tipos de dados; Makefile Ficheiro de configuração da compilação, que define alguns parâmetros do sistema (se usa o MAC com Low Power Listening, etc.). O código Java da aplicação de controlo está completo, e está organizado em três ficheiros: gui_t2.java Ficheiro com a classe principal que define a interface gráfica (desenvolvida com o Netbeans) e comunicação através da porta série com o mote raiz; antitheft.h Ficheiro comum às três aplicações, com a definição das constantes e dos tipos de dados; Makefile Ficheiro de configuração da compilação do ficheiro antitheft.h com os comandos mig e ncg para gerar as classes de interface para mensagens e com as constantes. O trabalho deve ser desenvolvido em várias fases distintas: 1. Modificar o código dos motes sensores, para apenas receberem configurações quando o identificador de aplicação é igual ao valor DEFAULT_APPID, definido no ficheiro antitheft.h; 2. Acrescentar um componente ao programa dos motes sensores, para receberem os pacotes de beacon; 3. Realizar a medição do RSSI nos motes sensores, gerando um erro caso o valor de RSSI dos pacotes de beacon recebido com o identificador de aplicação correto seja inferior ao valor de limiar; 4. Modificar o código do mote raiz, de forma a regular a potência de transmissão de acordo com o que foi configurado pelo utilizador; 5. Modificar os motes sensores para passarem a reportar a perda total do sinal de beacon, após cinco períodos de medição sem receber um beacon. Embora o trabalho não seja complexo, para a sua completa realização recomenda-se uma realização faseada do trabalho, com os seguintes objetivos intermédios: concluir a fase (1) na primeira semana; a fase (3) na segunda semana; ter iniciado a fase (5) na terceira semana; concluir a fase (5) na última semana. 5
Postura dos Alunos Cada grupo deve ter em consideração o seguinte: Não perca tempo com a estética de entrada e saída de dados Programe de acordo com os princípios gerais de uma boa codificação (utilização de indentação, apresentação de comentários, uso de variáveis com nomes conformes às suas funções...) e Proceda de modo a que o trabalho a fazer fique equitativamente distribuído pelos dois membros do grupo. 6