Rssf com TinyOS

Estudo sobre o TinyOS em aplicações de redes sensoriais sem fio

Universidade Federal do Ceará Engenharia de Teleinformática – Sistemas de Tempo Real Professor: Helano Castro Aluno: Tiago Augusto da Silva Bencardino 2011.1

}  Redes de sensoriamento sem fio §  Definição §  Exemplo §  Conceitos §  Motes §  Motivação para SO

}  TinyOS •  Histórico •  Arquitetura •  Gerenciamento de processos e eventos •  Active messages •  Aplicações

}  O que é? ◦  Conjunto de nós com capacidade de sensoriamento,

processamento e comunicação sem fio

}  Para quê? ◦  Monitorar variáveis de interesse ou detectar evento em

uma região

}  Controle: monitoramento industrial }  Meio ambiente: florestas, oceanos }  Segurança: alarmes de residências, prédios, fábricas }  Tráfego: monitoramento de vias, estacionamentos,

fotos sensores

}  Medicina: monitorar funcionamento de órgãos como o coração

}  Militar: vigilância monitoramento, rastreamento, segurança, controle e manutenção

}  Monitoramento das forças amigas }  Processo de vigilância – áreas críticas, rotas de

aproximação e caminhos estreitos }  Estudos sobre a tropa inimiga e o terreno de

batalha – ataques surpresa e métodos de defesa }  Sistemas modernos de mira automática }  Controlar um elemento da tropa: pressão

cardíaca, temperatura, infecção }  Guerra biológica/química: detecção de agentes

contaminadores

}  Ponteiro: detecção de alvos – acústicos, sísmicos, magnéticos

}  Localização e reconhecimento: fusão dos dados }  C2: nós “sink” móveis

}  Baixo custo e baixo consumo de energia }  Limitação de memória e capacidade de

processamento. }  Nós simples podem mudar de posição ou falhar

devido a influência do meio. }  Variáveis de ambiente precisam ser processadas

rapidamente para evitar perda de deadlines.

}  Precisam coletar informação, processar parcialmente e transmitir dados.

}  Fluxo de dados predominantemente unidimensional – nós intermediários como multi-hop / ad-hoc

}  Energia consumida ~ distância² }  Sink: nós especiais que processam ou consomem

dados

}  Auto-organização: organizar em grupos }  Auto-configuração: adaptar-se a mudanças do

ambiente e topologia }  Auto-diagnóstico: detectar problemas (baixa

densidade ou desperdício de energia) }  Auto-cura: recuperar-se dos problemas.

Tolerância a falhas }  Auto-proteção: detectar, identificar, proteger

contra ameaças internas e externas }  Auto-conhecimento: conhecer o ambiente e a si

próprio

}  Escalabilidade: grande número de nós distribuídos

}  Tolerância a falhas: grandes quantidades de nós podem falhar e o sistema deve, automaticamente, reconfigurar-se

}  Redundância de informação: algumas aplicações podem multiplicar a informação para aumentar a precisão.

}  Overhead mínimo para outras aplicações

}  Grande número de nós distribuídos

}  Restrição de energia

}  Rede autônoma, com alto grau de cooperação

}  Protocolos de comunicação e eleição de líder devem levar em conta topologia física da rede

}  Muito sujeita a falhas devido a perda de nós e interrupção de comunicação (meio hostil)

}  Funções de um mote: ◦  Capturar informações sensoriais do meio ◦  Processar, mesmo que limitadamente ◦  Comunicar com outros nós na rede

}  Objetivos principais (Goals)

◦  Prover o maior alcance possível (dezenas de km) ◦  Baixíssimo consumo de energia (uA) ◦  Fácil processo de desenvolvimento para os usuários

}  Funções principais:

◦  Executar tarefas

◦  Processar informação

◦  Controlar funcionalidades de outros componentes

}  Meios de transmissão wireless:

◦  Laser: consome menos energia, porém muito sensível a mudanças climáticas ◦  Infra-Red: também não precisam de antena, mas

possui limitações broadcasting ◦  ISM/RF: Mais relevante e mais usado; tendem a usar

freqüências fixas: 173,433,868 MHz e 2.4GHz.

}  Estados operacionais: transmit, receive, idle e sleep.

}  Tipos de memória ◦  RAM: raramente usada devido ao seu consumo ◦  Flash: Bom custo e boa capacidade de

armazenamento

}  Assim como em desktops, duas categorias de memórias: ◦  User memory: derivadas da aplicação/pessoal ◦  Program memory: usada para programar o

dispositivo. Pode conter uma id do dispositivo.

}  Gasto para monitorar, comunicar e processar. }  Maior gasto: comunicação. ◦  Exemplo: o gasto energético para transmitir 1Kb

por 100 metros é o mesmo de executar 3mi de instruções em um processador de 100 MHz

}  Pode ser armazenado em baterias ou capacitores. ◦  baterias comuns: NiCd, NiZn, niMh, lithium-ion.

}  Podem também captar energia por fonte solar, diferença de temperatura, indução EM ou vibrações.

}  Dispositivos de hardware que medem uma condição física como temperatura, som, pressão, etc.

}  Sinal analógico convertido em digital por um A/D e enviado para o controlador para ser processado.

Microcontroller

Radio

Flash Storage

Network

}  Principal motivo para ter um SO: configurações flexíveis nos nós sensores

}  Limitação de memória: torna-se impossível armazenamento de todos os programas nos nós

}  Compartilhamento dos aplicativos entre os nós da rede

}  Customização para o projeto }  Baixo custo/processamento limitam

algoritmos complexos. Ex: alguns algoritmos de gerenciamento de processos

Sistema Operacional

Modelo ROM RAM Tipo de processo

TinyOS v1 Events 3.4 kB 336 B Tasks, commands, event handlers

TinyOS v2 Events 3.4 kB 336 B Tasks, commands, event handlers Contiki Events 3.8 kB 230 B Protothreads MantisOS Multithreading 14 kB 500 B Threads Nano-RK Multithreading 10 kB 2000 B Tasks with priority T-Kernel Multithreading 28 kB 2000 B Threads Bertha Mobile agents 10 kB 1500 B Process Fragments CORMO Events 5.5 kB 130 B Tasks and event handlers SOS Events 20 kB 1163 B Tasks defined as modules SenOS State Machines ----- ------ Processes

“Hurry up and Sleep!”

}  Sistema operacional baseado em componente }  Código livre (free) e aberto (open-source)

}  Linguagem de programação utilizada: nesC

}  Incorporado em Smartdusts (Wireless MEMS), como os nós RSSF

}  Recursos MUITO limitados (ex: 8KB de memória de programa, 512 bytes de RAM).

}  1999: iniciou-se como projeto em UC Berkeley como parte do DARPA NEST program, gerando a primeira plataforma (WeC);

}  2000: Associação com a Crossbow Inc., para produção de hardware específico;

}  2001: versão 0.6 com plataforma mica e mix entre C e Perl script;

}  2002: versão 1.0, com linguagem nesC, desenvolvida em parceria com a Intel.

}  2003: versão 1.1 lançada com algumas novidades em nesC, entre elas detecção de condições de corrida (data race)

}  2006: Versão 2.0 lançada no 3º TinyOS Technology Exchange em Stanford, CA

}  2007: 2.01 e 2.02 }  2008: 2.1.0 }  Abril de 2010: ultima versão, 2.1.1

}  Recursos limitados: ◦  motes são limitados ◦  não podemos parar e esperar por melhorias ◦  Embora exista a Lei de moore: ◦  ↑ processamento, ↓ tamanho

}  Concorrência reativa: ◦  monitorar o ambiente, rotear dados, processar

dados locais, etc. ◦  Alguns eventos exigem uma resposta em tempo

real. ◦  Abordagem que gerencie concorrencia e reduza

bugs potenciais enquanto respeite recursos e deadlines.

}  Flexibilidade: ◦  Altas taxas de inovação de Software e Hardware ◦  exigência um OS flexível para reduzir espaço, energia

e tempo de projeto

}  Baixo Consumo: ◦  Densidade de baterias não acompanham lei de moore ◦  Poucos motes utilizam captação de energia suficiente ◦  S.O. deve ter uma boa estratégia para o duty-cycle e

gerenciamento de energia

}  Propósito geral, muitas funcionalidades, API’s }  Proteção entre app’s não confiáveis ao kernel ◦  Overhead para definir fronteiras kernel/user e

controle de interrupção }  Arquitetura multi-thread ◦  Muitas threads == Muita memória ◦  Overhead de troca de contexto

}  Modelo I/O ◦  Bloqueio: memória sendo bloqueada ◦  Polling: gasto de ciclos de CPU, energia

}  Características únicas: ◦  Arquitetura baseada em componentes ◦  Concorrência baseada em tarefas e eventos

◦  Operações divididas em fases

}  Aplicação: escalonador + componentes ◦  Compilado em 1 (um) executável

}  Arquitetura orientada a eventos }  Stack única e compartilhada }  Sem diferença entre região do kernel/user

Actuating Sensing Communication

Application (User Components)

Main (includes Scheduler)

}  Um ou mais componentes são “acoplados de modo a personalizar o SO para a aplicação

}  Usados para abstrações comuns, como comunicação, roteamento, sensoriamento, atuação e armazenagem.

}  Utilizam interfaces com funcionalidades especiais

Messaging Component

Internal State Internal Tasks

Commands Events

}  Comunicam-se com outros components }  São bi-direcionais e contém: ◦  Commands: implementadas pelos providers ◦  Events: implementadas pelos users

Interface Description ADC Sensor hardware interface Clock Hardware clock EEPROMRead/Write EEPROM read and write HardwareId Hardware ID access I2C Interface to I2C bus Leds Red/yellow/green LEDs MAC Radio MAC layer Mic Microphone interface Pot Hardware potentiometer for transmit power Random Random number generator ReceiveMsg Receive Active Message SendMsg Send Active Message StdControl Init, start, and stop components Time Get current time TinySec Lightweight encryption/decryption WatchDog Watchdog timer control

}  Command ◦  Inter-component ◦  Requisição para um componente executar algum

serviço, como iniciar a leitura de um sensor

}  Event ◦  Inter-component ◦  Sinal que representa o resultado de um serviço ou: ◦  Sinal assíncrono devido a uma interrupção de

hardware/chegada de mensagem

}  Comandos e eventos não podem ser bloqueados

}  O request de serviço é dividido de modo que: ◦  O comando retorna imediatamente ◦  O sinal de evento completa em seguida

}  são intra-component }  não interferem entre si, ou seja, não há

preempção entre as mesmas. }  Executam até terminar (Run to Completion) –

atômicas a outras tarefas }  Uitilizam a política FIFO para escalonamento }  Quando não há mais tasks na fila, o sistema

dorme

}  Tarefas são enviadas ao escalonador através do operador post

}  O escalonador pode executar tarefas em qualquer ordem, desde que obedeça o run-to-completion

}  O padrão do escalonador TinyOS é FIFO (first-in, first-out); porém, outras políticas já foram implementadas pela U. Berkeley, como a Earliest-deadline first.

}  Eventos podem chegar a qualquer momento }  Execução imediata para realizar “best-effort”

de tempo real }  Um evento gera uma interrupção por

hardware

}  Resumidamente: tarefas são atômicas entre si, mas não são atômicas em relação a comandos e eventos.

}  Tarefas: computar ◦  FIFO não-preemptável ◦  Número limitado de processos

}  Eventos: fluxo de dados simultâneo ◦  Oriundos de uma interrupção por hardware ◦  Preemptam tarefas ◦  Podem ser sinais de eventos, chamadas de

comandos ou posts de tarefas

}  Modos de operação: ◦  Síncrono (SC): devido as tarefas ◦  Assíncrono (AC): devido as interrupções por

hardware

}  Em SO comuns, o approach AC é evitado ao máximo; componentes usam RT hardware

}  Cabe ao programador construir

compartilhamento seguro de dados entre AC e SC

}  Embora não exista condição de corrida entre tarefas, podem existir entre SC/AC ou mesmo AC/AC

}  Soluções: ◦  Converter os códigos conflituosos para tarefas ◦  Usar seções atômicas para acesso de regiões

compartilhadas

}  Nas seções atômicas, as interrupções são desabilitadas.

}  Socket/TCP/IP? }  Muita memória para buffering e threads ◦  Informação é guardada em uma pilha antes da

thread ler ◦  Threads podem bloquear se não houver informação

a ser lida ainda }  Transmite MUITOS bits (sequence #, ack,

retransmissão) }  Adequado a arquitetura multi-thread }  Solução: Active Messages

}  Cada mensagem contém: ◦  Um nome de event handle ◦  Target node ◦  Data Payload para passar argumentos

}  Handler ◦  Extrair a mensagem ◦  Executar a informação ou enviar resposta

}  Objetivo da comunicação: ser magra }  Resposta deve ser rápida e assíncrona

}  Emissor

}  Receptor

}  Send Command ◦  Endereço de destino ◦  Handler ID ◦  Corpo da mensagem

}  AM componente: ◦  Checagem de endereço ◦  Despacho

}  Entrega confiável não é garantida, porém: ◦  Transmissão básica ◦  CRC checked packets component ◦  Forward error packets component

}  Normalmente iniciada por um nó gateway root

}  Cada root periodicamente envia uma mensagem com seu id e distância (0) para sua vizinhança

}  O handler checa se a fonte é o mais perto; caso seja: ◦  Guarda o source ID como parente multi-hop ◦  Incrementa a distância ◦  Retransmite a messagem com o seu próprio id

}  Rede Hierárquica (clusters) ◦  Seleção do nó líder de grupo ◦  Broadcast a partir do cluster-head ◦  Nós sensores entram no cluster-head mais próximo

}  Monitoramento de entidades de tempo real como temperatura, pressão, etc

}  Estudo de padrões científicos como migração de pássaros ou descongelamento de superfícies

}  Assistência em linhas de montagem

}  Muitos outros

}  Video 1 ◦  Sensores no corpo para detectar postura ◦  http://www.youtube.com/watch?v=tf87ZtCYjbs

}  Video 2 ◦  Boatgame ◦  http://www.youtube.com/watch?v=H7_pGXG8kmE

}  http://www.gta.ufrj.br/grad/08_1/rssf/index.html

}  http://www.marvinlemos.net/wp-content/uploads/2010/10/relatorio_tecnico_tinyos.pdf

}  http://homepages.dcc.ufmg.br/~loureiro/cm/docs/sbrc03.pdf

}  http://docs.tinyos.net/tinywiki/index.php/Main_Page

}  http://www.mdpi.com/1424-8220/10/6/5809/pdf

}  http://www.cs.berkeley.edu/~culler/AIIT/papers/TinyOS/levis06tinyos.pdf