Este documento describe un framework basado en DEVS para simular redes de sensores inalámbricas que utilizan TinyOS. El framework permite modelar formalmente los componentes de un nodo sensor y el medio de radio, y desarrollar simulaciones que incluyan nuevos modelos o reemplacen los existentes. El framework implementa modelos atómicos y acoplados de acuerdo al formalismo DEVS para representar los componentes de hardware y software de un nodo, y simular la interacción entre nodos a través del medio de radio.

1. DEVS-TOSSIM
Un framework DEVS para simular redes de sensores
inalámbricas que utilizan el sistema operativo TinyOS
TESISTA: Ricardo Guido Marelli
DIRECTORA: C.C. María Feldgen
TESIS DE GRADO EN INGENIERÍA INFORMÁTICA
ORIENTACIÓN EN SISTEMAS DISTRIBUIDOS
Abril 2016

2. Objetivo
● DEVS es el estándar de facto para simular sistemas de eventos discretos
● La característica principal de las redes inalámbricas de sensores es que son
orientadas a eventos
Objetivo: Demostrar la factibilidad de aplicar el formalismo DEVS al
desarrollo de un simulador para redes de sensores inalámbricas cuyos
nodos corren el sistema operativo TinyOS
○ Modelar formalmente los componentes de un nodo sensor y del medio de radio
○ Desarrollar un framework que permita la inclusión de nuevos modelos y/o reemplazo de
los modelos existentes
○ Eliminar limitaciones del simulador de TinyOS “TOSSIM”
2

3. TinyOS
Motivación
● Lab. de control
posee dispositivos
iMote2
● Abstracción del
hardware
● Mayor difusión
que Contiki
● Documentación
● Estándar de facto
para modelos y
simular sistemas
de eventos
discretos
● Se ha aplicado
para modelar
redes de sensores
inalámbricas
● Gran escala:
cientos de miles
de nodos
● Orientación a
eventos que son
discretos
● Grado de control
elevado
● Probar
condiciones de
difícil
reproducción
● Mayor cantidad
de dispositivos
que en ambientes
reales de prueba
3
Simuladores
Redes de
sensores
inalámbricas
DEVS
DEVS

4. Redes de sensores inalámbricas
● Red inalámbrica de sensores: conjunto de nodos
que cooperan para interactuar con el entorno
sensando y para controlar parámetros físicos
● Nodo (mote)
○ Está equipado con un componente sensor/actuador y
comunicación inalámbrica
○ Tiene escasos recursos de comunicación,
procesamiento y energía
● Estación base o nodo recolector (sink)
○ Recolecta la información de sensado que envían los
nodos de la red de sensores
○ Está conectada a una computadora que procesa la
información recibida
4
nodo
recolector
Servidor 1 Servidor 2 BD

5. Campos de aplicación
● Monitoreo del medio ambiente
○ Seguimiento de vida salvaje
● Prevención de desastres
○ Prevención de incendios forestales
○ Detección de eventos sísmicos y
erupciones volcánicas
● Agricultura de precisión
○ Aplicación de fungicida solamente
cuando es necesario y en las zonas
que así lo requieran
● Salud
○ Monitoreo de los signos vitales de los
pacientes
5
● Militar
○ Detección y seguimiento de intrusos
● Domótica (edificios inteligentes)
○ Control de sistemas de aire
acondicionado y regulación de luces
● Industrial
○ Recolección de datos y detección de
fallas, en lugares inaccesibles o
peligrosos en los que el cableado es
impráctico
○ Navegación de robots móviles, control
de inventario en tiempo real y
monitoreo de procesos

6. Características de las redes inalámbricas de sensores
● Orientación a eventos
● Limitadas en energía
● Tolerancia a fallos
● Esfuerzo cooperativo
● Centradas en los datos
● Red de gran escala
● Auto-organización
● Comunicación multisalto (multi-hop)
6
Características únicas que imponen restricciones de diseño y determinan
los ensayos necesarios para una operación exitosa

7. Hardware de los nodos
Transceiver Procesador Sensores
Memoria
Suministro de energía
7
● Procesador
○ Microcontroladores (MCU) debido a su
bajo consumo de energía y facilidad de
interconexión
● Memoria
○ SRAM (4KB - 256KB)
○ Flash programable (128KB - 32MB)
● Transceiver (transceptor)
○ Encargado del envío y recepción de
datos a través del medio de radio
● Sensor
○ Conectado mediante conversor A/D
● Suministro de energía:
○ Baterías no recargables (AA o AAA)

8. El estándar IEEE 802.15.4
● Define la capa física y la subcapa
MAC para dispositivos
inalámbricos
○ De bajo costo, tasas bajas de
transferencia de datos y bajo
consumo de energía
● Admite dos tipos de dispositivos:
○ Dispositivos de funcionalidad
reducida
○ Dispositivos de funcionalidad
completa
● Permite topologías de red punto
a punto y en estrella
8
[802.15.4]

9. Pila de protocolos
● IEEE 802.15.4 no es una solución completa
○ Completar la pila de protocolos
○ Disponer de funciones tradicionales de los sistemas
operativos (ej. scheduling)
● Alternativas posibles:
○ Sistemas operativos libres (Contiki, TinyOS)
○ Implementaciones comerciales del estándar ZigBee
● ZigBee es una especificación diseñada para
cubrir las necesidades de las redes de
sensores
○ Define una pila de protocolos (red, aplicación)
○ No cubre las funciones tradicionales de los sistemas
operativos
9
Capa física
Control de acceso al
medio
Capa de red
Capa de aplicación
Sistema
Operativo
IEEE802.15.4

10. Sistemas operativos Contiky y TinyOS
10
Contiky TinyOS
Arquitectura
● Sistema operativo de tiempo real
● Programado en lenguaje C
● Arquitectura modular y orientada a
eventos
● Sistema operativo de tiempo real
● Programado en lenguaje nesC
● Arquitectura monolítica, orientada a
componentes y eventos
● Tres capas para abstracción de hardware
○ Presentación (HPL), Adaptación
(HAL), Independiente (HIL)
●
Planificación o Scheduling
● Orden FIFO
● Eventos originados en interrupciones de
acuerdo a su prioridad
● Orden FIFO donde las tareas son
prioritarias sobre los threads
● Scheduler es un componente

11. Sistemas operativos Contiky y TinyOS (cont.)
11
Contiky TinyOS
Protocolos de comunicación
● IEEE 802.15.4, 6LoWPAN y CoAP
● RIME (capa de red básica), uIP
● IEEE 802.15.4, 6LoWPAN y CoAP
● ActiveMessageC (capa de red básica)
● No provee ningún mecanismo, debe
implementarse para cada aplicación
● Provee soporte para duty-cycling de
transceiver
● Distingue entre periféricos (on/off) y
controladores (múltiples estados de
energía)
● Provee soporte para duty-cycling de
transceiver
Administración del consumo de energía

12. Simulación
12
Análisis y resolución de
problemas no posible
sobre el sistema real
Modelos que se simulan
Modelo: representación de un sistema con el objeto de resolver un
problema concreto
Simulación: reproducción del comportamiento de un sistema utilizando
para ello un modelo
Estado del sistema
Un modo de cambiar el
estado del sistema
Representación del
tiempo

13. Tipos de simuladores
13
○ Sin interacción con personas o
dispositivos
○ Ejecución: tiempo virtual, tan
rápido como sea posible
Fuente:
http://appel.nasa.gov/2009/03/01/plan-train-and-fly-mission-operations-from-apollo-to-shuttle/
Analíticos
○ Interacción con personas o
dispositivos:
■ human-in-the-loop
■ hardware-in-the-loop
■ software-in-the-loop
○ Ejecución: tiempo real
Entornos virtuales

14. Niveles de simulación en redes de sensores
14
Nivel de sistema operativo
Ejecutar el sistema operativo de los nodos de la red de sensores y
simular el hardware subyacente.
Nivel de red o aplicación
Ejecutar alguna aplicación del usuario y simular nodos con
determinadas características.
Nivel de instrucción
Simular el hardware del nodo a nivel de instrucción.
El simulador ejecuta exactamente el mismo código binario que el nodo.
Simulaciónmultinivel

15. Simuladores para redes de sensores
15
Cooja Avrora TOSSIM
Sistema operativo Contiky TinyOS TinyOS
Nivel de simulación Multinivel Instrucción Sistema operativo
Modelo de ejecución Dirigido por el tiempo Dirigido por eventos Dirigido por eventos
Distintos tipos de nodo Si Diferente software No
Interfaz de usuario Interfaz gráfica Línea de comandos,
interfaz gráfica limitada
No, es un framework
Modelos de radio Basado en ecuación de
Friis o definición de
probabilidad de recepción
exitosa
Basado en ecuación de
Friis, no simula
interferencia
Ganancia y conexiones
para cada nodo,
modelo de interferencia
basado en análisis
estadístico

16. Ecuación de transmisión de Friis
16
Pt
y Pr
son las potencias de transmisión y de recepción
Gt
y Gr
son las ganancias de las antenas
λ es la longitud de onda
R es la distancia entre las dos antenas
La potencia de la señal se atenúa
con el cuadrado de la distancia
entre el nodo que transmite y los
potenciales receptores

17. Simulador Simulador
Sistemas de eventos discretos
Dos enfoques para ejecutar la simulación
Sistema de Eventos Discretos: el estado del sistema cambia en instantes
discretos de tiempo y solo ante la ocurrencia de eventos
● Dirigido por el tiempo
(time-stepped)
S1
T
S0
t1
t2
t3
S3
S2
● Dirigido por eventos
(event-driven)
17
S1
T
S0
S3
S2
e1
e2
e3
en...

18. El formalismo DEVS
● El modelo cambia de estado solo ante la ocurrencia de eventos
● Los eventos pueden ser de dos tipos:
○ Transiciones internas: debido al paso del tiempo
○ Transiciones externas: mensajes entre modelos
● Los mensajes entre modelos se generan antes de realizar una transición
interna
● Los modelos básicos del formalismo se denominan: atómicos
● Los modelos atómicos se combinan para formar un modelo acoplado
○ Construcción jerárquica
18
Discrete Event System Specification (DEVS): formalismo para especificar
modelos de sistemas de eventos discretos
DEVS

19. Especificación de modelos atómicos
19
I interfaz del modelo, puertos de entrada y
salida
X es el conjunto de eventos externos de
entrada
S es el conjunto de estados que puede
tener un modelo
Y es el conjunto de eventos externos
generados para salida
δint es la función de transición interna
δext es la función de transición externa que
define cambios de estado por causa de
eventos externos (X)
λ es la función de salida (Y) y depende del
estado previo a la transición interna
ta es la función de duración de un estado y
representa el tiempo que el modelo se
queda en un determinado estado si no
ocurren eventos externos
M = < I, X, S, Y, δint, δext, λ, ta >
DEVS

20. Especificación de modelos acoplados
20
I, X, e Y mismo significado que para modelos
atómicos
D es el conjunto de índices de modelos, donde Mi
es un modelo componente básico
Ii
es el conjunto de modelos influenciados por Mi
Zij
es la función de traducción de salida de Mi
a Mj
select es la función de selección ante eventos
simultáneos
DN = < I, X, Y, D, {Mi}, {Ii}, {Zij}, select >
M1
M2
X2
X1
Z12
Y1
select
I1
= {M2
}
Modelo acoplado
DEVS

21. Descripción del simulador diseñado y desarrollado
● Es un simulador de nivel de red y de sistema operativo para TinyOS
○ Es un entorno virtual: framework que permite ejecutar aplicaciones del usuario sobre el
sistema operativo TinyOS
○ Puede ser extendido para interactuar con dispositivos de hardware
● Usa nodos y entornos modelados utilizando DEVS
○ Framework extensible que permite nuevos modelos o reemplazar los existentes
○ Componentes de hardware requieren tener una contraparte en TinyOS
● Admite diferentes tipos de nodos
○ Requerido por características de las redes de sensores inalámbricas
○ TOSSIM carece de esta funcionalidad
● Puede conectarse a las mismas herramientas que se utilizan para
controlar y monitorear redes de sensores desplegadas
● Tiene una interfaz de usuario para el control de la simulación
21
DEVS

22. Arquitectura de la implementación
22
DEVS framework
Interfaz de usuario del
simulador
Herramientas de monitoreo
para redes reales
(no simuladas)
Capa de mensajes
Modelos DEVS para Motes
TinyOS
DEVS

23. Clases básicas del framework DEVS
23
DEVS

24. Implementación de distribución con DEVS
24
● Se requiere que nodos diferentes
corran en procesos separados
○ IEEE 802.15.4 define que existen
diferentes tipos de nodos
○ En una red de sensores coexisten nodos
con diferente software (ej. estación base)
○ TinyOS utiliza variables estáticas
● Se implementó una capa de mensajes
para comunicar estos procesos
● Se diseñó un protocolo tipo solicitud-
respuesta
○ Mensajes para: Conexión, Transición
interna, Transición externa
DEVS

25. Interacción con sistemas externos
25
● La información generada por la red de sensores es
procesada por un sistema externo a la misma
○ El framework de simulación debe soportar esta característica
○ La funcionalidad resulta útil para crear modelos que tomen datos
de una fuente externa (ej. placa adquisidora)
● La recepción de información se desacopló de la
ejecución del modelo
○ No es viable recibir información en forma directa al realizar una
transición del modelo DEVS
■ Impacto de performance al bloquearse a la espera de
información o realizar polling para recibir la misma
○ Se resolvió con un thread que obtiene información en forma
constante y la disponibiliza para su lectura posterior
DEVS

26. Modelos DEVS para nodos e integración con TinyOS
26
● Integración con TinyOS
○ Se creó una plataforma de hardware devs
○ Modelos tienen contraparte a nivel capa HIL
● Modelos atómicos desarrollados:
○ AbstractProcessor y TinyOSProcessor
○ Sensor, OscillationSensor y DataSensor
○ Serial y ConnectedSerial
○ Timer
○ Transceiver
● Modelos acoplados desarrollados:
○ Mote
○ RadioMedium: Integrado por todos los nodos
■ Modelo de radio: ecuación de Friis en
función de traducción de la salida
DEVS

27. Caso de estudio: Modelo de Sensor
27
X = { Read }
S = { Hold, Sensing }
Y = { ReadDone }
δint : Sensing -> Hold
δext : Hold * Read -> Sensing
λ : Sensing -> ReadDone
ta : ∞ : si S = Hold
T : si S = Sensing
DEVS

28. Caso de estudio: Modelo de Transceiver
28
Simulación de
interferencia
Estado espurio
para generar
salida
Nada es
instantáneo!!!
duty-cycling
DEVS

29. Validación del simulador desarrollado
● No es posible comparar resultados contra TOSSIM debido a que el modelo
de radio es sustancialmente diferente
● TinyOS incluye varias aplicaciones que pueden utilizarse para validar que
un nodo funcione correctamente
● DEVS-TOSSIM fue validado con las siguientes aplicaciones:
○ Blink, enciende y apaga los leds utilizando tres temporizadores
■ Prueba secuencia de inicio y timers
○ MultihopOscilloscope, recolecta información de sensado y la muestra en una herramienta
■ Prueba completa del framework
■ Protocolo de árbol de recolección para rutear información desde el nodo sensor a la
estación base
○ RadioSenseToLeds, lecturas periódicas del sensor y difusión de la información
■ Prueba comunicación de radio, sensor y timers
○ MViz, similar a MultihopOscilloscope
29
DEVS

30. Validación con MultihopOscilloscope
30
DEVS

31. Validación con MViz
31
DEVS

32. Comparación con otros simuladores
Cooja TOSSIM 2.x Avrora 1.6 DEVS-TOSSIM
S.O Contiky 2.x TinyOS 2.x TinyOS 2.x TinyOS 2.x
Estándar de modelado NO NO NO SI
Sim. a nivel de red SI NO NO SI
Sim. a nivel de instrucción SI NO SI NO
Sim. a nivel del S.O SI SI NO SI
Modelo de ejecución
Dirigido por el
tiempo
Dirigido por eventos Dirigido por eventos Dirigido por eventos
Control de tiempo
Intervalos entre
pasos
NO NO
Paso a paso,
tiempo virtual y real
Distintos tipos de nodo SI NO SI SI
32
DEVS

33. Comparación con otros simuladores (cont.)
Cooja TOSSIM 2.x Avrora 1.6 DEVS-TOSSIM
Noción de posición SI NO Parcial SI
Modelo de radio SI NO SI NO
Consumo de energía SI NO SI NO
Interfaz de usuario Interfaz gráfica
Scripting Python o
C++
Línea de
comandos, interfaz
gráfica limitada
Línea de comandos
Extensibilidad SI NO Parcial SI
Integración con otros
simuladores y sistemas
SI NO NO SI
Depuración
El proceso entero
(todos los nodos)
El proceso entero
(todos los nodos)
El proceso entero
(todos los nodos)
Nodos en forma
individual
DEVS
33

34. Conclusión: Limitaciones encontradas
● DEVS no permite realizar comunicación sincrónica entre componentes
○ Esto introduce la necesidad de disponer de información de estado local
○ En TinyOS no es un problema ya que los componentes se invocan mediante comandos
que deberían limitarse a almacenar información en un buffer
● DEVS no permite generar mensajes de salida tras una transición
○ Aparición de transiciones internas de duración cero (estados artificiales)
○ Modelado menos claro
● La depuración de comandos de fase dividida resulta compleja
○ Comandos de fase dividida: la finalización de la operación se indica mediante un evento
○ Si el evento no se genera, el componente se bloquea dando lugar a un comportamiento
cuya depuración no es trivial
■ En componentes reales de hardware (no simulados) ocurre el mismo problema
34
DEVS

35. Conclusión: Principales ventajas
● El modelado de todos los componentes de hardware de un nodo sensor y
el medio de radio resulta claro y es relativamente simple
● El transceiver y modelo de radio son extremadamente simples
○ DEVS realiza la mayor parte del trabajo
○ El modelo de interferencia está basado en estados y no en probabilidades
○ La simulación es más realista al depender de los patrones de comunicación particulares
de la aplicación o algoritmo bajo prueba
● El acoplamiento entre los componentes del nodo es bajo
○ Facilidad para reemplazar una implementación por otra diferente
○ Facilidad para incorporar nuevos modelos
● El modelado formal es información
○ Permite conocer qué está haciendo el programa al observar las transiciones de estado y
mensajes intercambiados
35
DEVS

36. 36
Más información:
http://rgmarelli.github.io/devs-tossim/
rgmarelli@gmail.com