Rssf com TinyOS

1,155 views

Published on

Estudo sobre redes de sensoriamento sem fio com o sistema operacional TinyOS.

Published in: Technology

Rssf com TinyOS

  1. 1. Estudo sobre o TinyOS em aplicações de redes sensoriais sem fioUniversidade Federal do CearáEngenharia de Teleinformática – Sistemas de Tempo RealProfessor: Helano CastroAluno: Tiago Augusto da Silva Bencardino2011.1
  2. 2. }  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
  3. 3. }  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
  4. 4. }  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
  5. 5. }  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
  6. 6. }  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
  7. 7. }  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.
  8. 8. }  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
  9. 9. }  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
  10. 10. }  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
  11. 11. }  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)
  12. 12. }  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
  13. 13. }  Funções principais: ◦  Executar tarefas ◦  Processar informação ◦  Controlar funcionalidades de outros componentes
  14. 14. }  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.
  15. 15. }  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.
  16. 16. }  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.
  17. 17. }  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.
  18. 18. Network Microcontroller Flash Storage Radio
  19. 19. }  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
  20. 20. Sistema Modelo ROM RAM Tipo de processoOperacionalTinyOS v1 Events 3.4 kB 336 B Tasks, commands, event handlersTinyOS v2 Events 3.4 kB 336 B Tasks, commands, event handlersContiki Events 3.8 kB 230 B ProtothreadsMantisOS Multithreading 14 kB 500 B ThreadsNano-RK Multithreading 10 kB 2000 B Tasks with priorityT-Kernel Multithreading 28 kB 2000 B ThreadsBertha Mobile agents 10 kB 1500 B Process FragmentsCORMO Events 5.5 kB 130 B Tasks and event handlersSOS Events 20 kB 1163 B Tasks defined as modulesSenOS State Machines ----- ------ Processes
  21. 21. “Hurry up and Sleep!”
  22. 22. }  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).
  23. 23. }  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.
  24. 24. }  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
  25. 25. }  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.
  26. 26. }  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
  27. 27. }  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
  28. 28. }  Características únicas: ◦  Arquitetura baseada em componentes ◦  Concorrência baseada em tarefas e eventos ◦  Operações divididas em fases
  29. 29. }  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 Main (includes Scheduler) Application (User Components) Actuating Sensing Communication
  30. 30. }  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
  31. 31. Messaging Component Internal Tasks Internal StateCommands Events
  32. 32. }  Comunicam-se com outros components}  São bi-direcionais e contém: ◦  Commands: implementadas pelos providers ◦  Events: implementadas pelos users
  33. 33. Interface DescriptionADC Sensor hardware interfaceClock Hardware clockEEPROMRead/Write EEPROM read and writeHardwareId Hardware ID accessI2C Interface to I2C busLeds Red/yellow/green LEDsMAC Radio MAC layerMic Microphone interfacePot Hardware potentiometer for transmit powerRandom Random number generatorReceiveMsg Receive Active MessageSendMsg Send Active MessageStdControl Init, start, and stop componentsTime Get current timeTinySec Lightweight encryption/decryptionWatchDog Watchdog timer control
  34. 34. }  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
  35. 35. }  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
  36. 36. }  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
  37. 37. }  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.
  38. 38. }  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.
  39. 39. }  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
  40. 40. }  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
  41. 41. }  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.
  42. 42. }  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
  43. 43. }  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
  44. 44. }  Emissor}  Receptor
  45. 45. }  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
  46. 46. }  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
  47. 47. }  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
  48. 48. }  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
  49. 49. }  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
  50. 50. }  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
  51. 51. }  http://www.mdpi.com/ 1424-8220/10/6/5809/pdf}  http://www.cs.berkeley.edu/~culler/AIIT/ papers/TinyOS/levis06tinyos.pdf

×