- Commands: solicitações de serviços - Events: notificações de eventos Client: - Commands: solicita serviços - Events: recebe notificações } Interface bem definida para acoplamento } Componentes são independentes e reutilizáveis } Tarefas são funções sem estado } Executadas em resposta a eventos } Não bloqueiam } Podem disparar outros eventos } Comandos são solicitações assíncronas de serviços para

1. 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

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. } 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. } 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. } 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. } 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

8. } 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.

9. } 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

11. } 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

12. } 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

13. } 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)

15. } 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

16. } Funções principais:
◦ Executar tarefas
◦ Processar informação
◦ Controlar funcionalidades de outros componentes

17. } 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.

18. } 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.

19. } 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.

20. } 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.

21. Network
Microcontroller
Flash Storage
Radio

22. } 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

23. Sistema Modelo ROM RAM Tipo de processo
Operacional
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

24. “Hurry up and Sleep!”

25. } 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).

26. } 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.

27. } 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

28. } 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.

29. } 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

30. } 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

31. } Características únicas:
◦ Arquitetura baseada em componentes
◦ Concorrência baseada em tarefas e eventos
◦ Operações divididas em fases

32. } 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

33. } 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

34. Messaging Component
Internal Tasks Internal State
Commands Events

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

36. 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

37. } 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

38. } 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

39. } 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

40. } 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.

41. } 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.

42. } 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

43. } 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

44. } 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.

46. } 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

47. } 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

48. } Emissor
} Receptor

49. } 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

50. } 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

51. } 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

52. } 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

53. } 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

55. } 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

56. } http://www.mdpi.com/
1424-8220/10/6/5809/pdf
} http://www.cs.berkeley.edu/~culler/AIIT/
papers/TinyOS/levis06tinyos.pdf