Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tesis PDF
Tesis PDF
FACULTAD DE INGENIERA
UNIVERSIDAD DE BUENOS AIRES
Noviembre 2015
Ricardo G. Marelli
Direcciones de contacto
Ricardo Guido Marelli
rgmarelli@gmail.com
Mara Feldgen
mfeldgen.fiuba@gmail.com
-1-
Ricardo G. Marelli
Resumen
En este trabajo se analiza y aplica el estndar de facto DEVS para disear e
implementar el framework DEVS-TOSSIM para probar y simular redes de sensores
inalmbricas que utilizan el sistema operativo TinyOS. El simulador diseado y
desarrollado elimina algunas limitaciones del simulador "TOSSIM" de TinyOS, tales
como la imposibilidad de correr nodos con diferente software, escalabilidad reducida y
complejidad en el modelado de diversidad de hardware y radio de los nodos. No
obstante, la diferencia principal es la aplicacin del formalismo DEVS para modelar
formalmente todos los componentes de hardware de un nodo y el medio de radio, lo
que permite realizar las pruebas de las aplicaciones desarrolladas para los distintos
tipos de nodos y su escalamiento. Este framework permite adems, reemplazar el
componente sensor de un nodo, agregar movilidad, implementar un nuevo modelo de
radio o modelar un ambiente complejo de sensado. Finalmente, se analizan las
limitaciones de DEVS y se compara la solucin desarrollada con los simuladores de la
industria: TOSSIM (TinyOS), Cooja (Contiki), y Avrora (Atmel / MICA2).
-2-
Ricardo G. Marelli
Abstract
In this work, the de facto standard DEVS is analyzed and applied to design and
implement the framework DEVS-TOSSIM to test and simulate wireless sensor
networks that use the TinyOS operating system. The simulator designed and
developed removes some limitations of the simulator "TOSSIM" of TinyOS, such as the
inability to run nodes with different software, limited scalability and complexity in
modeling diversity of node hardware and radio. However, the main difference is the
application of the DEVS formalism to formally model all hardware components of a
node and the radio medium, which allows testing the developed applications for the
different types of nodes and its scaling. This framework also allows the replacement of
the sensor component of a node, the addition of mobility, the implementation of a new
radio model or modeling a complex sensing environment. Finally, the limitations of
DEVS are analyzed and the developed solution is compared with the industry
simulators: TOSSIM (TinyOS), Cooja (Contiki) and Avrora (Atmel / MICA2).
Keywords: simulation, discrete event systems, DEVS, wireless sensor networks,
TinyOS.
-3-
Ricardo G. Marelli
Agradecimientos
A la Facultad de Ingeniera de la Universidad de Buenos por la excelente
formacin que me brind.
A mis padres, Ricardo y Celina, por todas las posibilidades que me dieron. Y a
mi familia toda.
-4-
Ricardo G. Marelli
ndice de contenidos
Lista de figuras ........................................................................................................... 7
1. Introduccin ............................................................................................................ 9
1.1. Introduccin y Objetivo ....................................................................................... 9
1.2. Estructura del trabajo ....................................................................................... 10
2. Redes de sensores inalmbricas ......................................................................... 12
2.1. Introduccin ...................................................................................................... 12
2.2. Caractersticas ................................................................................................. 15
2.3. Hardware.......................................................................................................... 17
2.4. Administracin del consumo de energa ........................................................... 19
2.5. El estndar IEEE 802.15.4 ............................................................................... 21
2.6. Plataformas de software ................................................................................... 25
2.7. ZigBee .............................................................................................................. 25
2.8. Sistemas operativos ......................................................................................... 27
2.9. El sistema operativo Contiki ............................................................................. 29
2.10. El sistema operativo TinyOS .......................................................................... 31
3. Simuladores para redes de sensores .................................................................. 36
3.1. Generalidades .................................................................................................. 36
3.2. Niveles de simulacin en redes de sensores inalmbricas ............................... 37
3.3. Avrora............................................................................................................... 39
3.4. Cooja 2.x .......................................................................................................... 42
3.5. TOSSIM 2.x ...................................................................................................... 46
4. Simulacin con el formalismo DEVS ................................................................... 49
4.1. El formalismo DEVS ......................................................................................... 49
4.2. DEVS aplicado a redes de sensores inalmbricas ........................................... 52
5. Definicin del problema y motivacin ................................................................. 55
6. Solucin propuesta .............................................................................................. 57
6.1. Descripcin de la solucin propuesta ............................................................... 57
6.2. Arquitectura de la implementacin.................................................................... 58
6.3. Implementacin DEVS ..................................................................................... 60
6.4. Implementacin de distribucin con DEVS ....................................................... 72
6.5. Capa de mensajes ........................................................................................... 80
6.6. Interaccin con sistemas externos.................................................................... 82
6.7. Modelos DEVS para nodos e integracin con TinyOS ...................................... 83
-5-
Ricardo G. Marelli
-6-
Ricardo G. Marelli
Lista de figuras
Figura 2-1. Componentes de un nodo sensor ............................................................ 17
Figura 2-2. Nodo MicaZ ............................................................................................. 18
Figura 2-3. Topologas de red definidas en el estndar IEEE 802.15.4 ...................... 22
Figura 2-4. Red tipo cluster-tree ................................................................................. 23
Figura 2-5. Stack ZigBee completo ............................................................................ 26
Figura 3-1. Ejecucin de una simulacin con Avrora .................................................. 40
Figura 3-2. Ejecucin de una simulacin con Avrora (interfaz grfica) ....................... 41
Figura 3-4. Cooja ejecutando una simulacin............................................................. 45
Figura 3-5. TOSSIM conectado a la aplicacin MultiHopOscilloscope. ...................... 48
Figura 3-6. TOSSIM conectado a la aplicacin MViz. ................................................. 48
Figura 4-1. Modelos acoplados CM Process y sensor................................................ 53
Figura 6-1. Arquitectura de la solucin desarrollada................................................... 59
Figura 6-2. El modelo hijo conoce al modelo padre. ................................................... 61
Figura 6-3. El modelo padre conoce al modelo hijo. ................................................... 62
Figura 6-4. Clases bsicas del framework .................................................................. 65
Figura 6-5. Clases para intercambio de mensajes DEVS ........................................... 67
Figura 6-6. Jerarqua de simuladores ......................................................................... 68
Figura 6-7. Las clases CoupledCompositeModel y CoupledCompositeSimulator....... 71
Figura 6-8. Distribucin para interoperabilidad en [Wutzler 2007] .............................. 72
Figura 6-9. Distribucin en DEVS/RMI ....................................................................... 73
Figura 6-10. Clases utilizadas para simuladores remotos .......................................... 74
Figura 6-11. Interaccin de modelos, simuladores, y simuladores remotos ................ 76
Figura 6-12. Mensajes entre simuladores remotos ..................................................... 79
Figura 6-13. Clases de la capa de mensajes.............................................................. 81
Figura 6-14. Clases para interaccin con sistemas externos ...................................... 82
Figura 6-15. Modelo DEVS. Transiciones de estado y puertos de entrada y salida .... 83
Figura 6-16. Las clases MoteManager, AbstractProcessor y TinyOSProcessor ......... 88
Figura 6-17. Modelo de procesador ........................................................................... 88
Figura 6-18. Modelo de timer ..................................................................................... 91
Figura 6-19. Modelo de sensor .................................................................................. 92
Figura 6-20. Modelo de transceiver ............................................................................ 93
Figura 6-21. Modelo serial.......................................................................................... 96
Figura 6-22. Nodo sensor como un modelo acoplado ................................................ 98
-7-
Ricardo G. Marelli
-8-
Ricardo G. Marelli
1. Introduccin
1.1. Introduccin y Objetivo
Una red inalmbrica de sensores es un conjunto de decenas de miles de nodos
relativamente pequeos que cooperan entre s, autnomos, distribuidos espacialmente
sin una topologa determinada y sin control central. Cada nodo est equipado con un
dispositivo sensor y/o actuador y la cooperacin se realiza mediante comunicacin
inalmbrica [Karl 2005]. Estos nodos tienen escasos recursos de procesamiento,
capacidad de comunicacin limitada y demandas de consumo de energa restringidas.
Estas caractersticas imponen restricciones en el diseo de estas redes, en especial la
reduccin del consumo de energa de las transmisiones para prolongar la vida til de
la batera. Adems, determinan los ensayos necesarios para lograr la eficiencia
necesaria para su operacin exitosa. Por consiguiente, los simuladores son muy
importantes para realizar las pruebas de laboratorio y la simulacin de miles de nodos
para determinar la eficiencia del sistema y de transmisin exitosa de la informacin
obtenida por los nodos. Adems, los simuladores permiten probar condiciones que son
de difcil reproduccin en un ambiente real y otorgan un grado de control elevado al
permitir reducir el tiempo de cada simulacin (simular tan rpido como sea posible),
pausar la simulacin, inspeccionarla y correrla nuevamente en forma inmediata [Tan
2006].
-9-
Ricardo G. Marelli
operativos
Contiki
TinyOS.
Pila
de
protocolos
- 10 -
Ricardo G. Marelli
Solucin propuesta
Detalle de la solucin desarrollada. Presenta la arquitectura del
simulador
se
analizan
implementaciones
DEVS
existentes
Resultados
Describe como fue validado el simulador desarrollado y compara la
solucin con los simuladores para redes de sensores que se estudiaron.
Conclusin
Resumen de los resultados explicando las ventajas y desventajas de la
aplicacin de DEVS a la construccin de un framework para simular
redes de sensores inalmbricas.
Futuros trabajos
Describe posibles lneas de trabajo futuro.
- 11 -
Ricardo G. Marelli
- 12 -
Ricardo G. Marelli
- 13 -
Ricardo G. Marelli
Estas aplicaciones tipo son posibles, y estn limitadas, por las caractersticas
nicas de las redes inalmbricas de sensores. Estas caractersticas, que se analizan
en la seccin siguiente, representan una serie de parmetros, restricciones, y desafos
- 14 -
Ricardo G. Marelli
que deben ser tenidos en cuenta al momento de desarrollar sistemas que utilicen esta
tecnologa.
2.2. Caractersticas
Como se mencion en la seccin precedente, las redes inalmbricas de
sensores tienen una serie de caractersticas clave que han dado lugar al surgimiento
de hardware, sistemas operativos de tiempo real y estndares especficos. Estas
caractersticas son las siguientes:
Orientacin a eventos
La tarea principal de un nodo sensor es la deteccin de eventos y la
transmisin de la informacin resultante de su procesamiento [Akyildiz
2002]. Ms an, una red inalmbrica de sensores es un sistema de
eventos discretos [Goti 2010]. Un sistema de eventos discretos es aquel
en el que el estado del sistema no cambia en forma continua sino que lo
hace en instantes discretos de tiempo y debido a la ocurrencia de
eventos [Wainer 2003].
Limitadas en energa
En muchos casos, la nica fuente de energa de un nodo es una batera
y su reemplazo no es posible. Esto conduce a la necesidad de que las
redes de sensores operen de un modo energticamente eficiente [Karl
2005].
Tolerancia a fallos
Debido a que la comunicacin entre dos nodos puede verse
interrumpida y a que un nodo puede daarse o quedarse sin batera es
necesario que la red de sensores sea tolerante a fallos, lo que implica
generalmente el despliegue redundante de nodos [Karl 2005].
- 15 -
Ricardo G. Marelli
Esfuerzo cooperativo
En algunas aplicaciones los nodos sensores realizan procesamiento en
forma
local
de
los eventos
detectados
envan
informacin
Auto-organizacin
Para lograr escalabilidad y robustez es necesario organizar en forma
cooperativa la red usando algoritmos y protocolos distribuidos [Karl
2005].
- 16 -
Ricardo G. Marelli
2.3. Hardware
Las redes inalmbricas de sensores requieren para su funcionamiento
hardware especfico y de bajo costo. Como se muestra en la Figura 2-1, un nodo est
formado por cinco componentes bsicos: Memoria, Procesador, Sensores,
Transceiver, y Suministro de energa [Karl 2005].
Memoria
Transceiver
Procesador
Sensores
Suministro de energa
Figura 2-1. Componentes de un nodo sensor
- 17 -
Ricardo G. Marelli
- 18 -
Ricardo G. Marelli
Por ejemplo, el MCU Atmel ATMega 128 provee seis modos de sleep
diferentes. Todos los modos de sleep detienen el CPU y pueden ser interrumpidos
mediante el temporizador del watchdog (watchdog timer). Los modos son los
siguientes [Atmel 2011]:
- 19 -
Ricardo G. Marelli
- 20 -
Ricardo G. Marelli
Tipos de dispositivos
El estndar distingue entre dos tipos de dispositivos a saber:
- 21 -
Ricardo G. Marelli
Topologas de red
Se admiten dos topologas de red: punto a punto y en estrella (figura 2-3). En
la topologa en estrella los dispositivos solo se comunican con el coordinador de la
PAN. Adems, todas las redes en estrella operan en forma independiente de otras
redes en estrella.
Figura 2-3. Topologas de red definidas en el estndar IEEE 802.15.4. La figura fue tomada de
[802.15.4].
- 22 -
Ricardo G. Marelli
Capa fsica
La capa fsica es responsable de la transmisin y recepcin de datos mediante
el canal fsico de radio. Adicionalmente, tiene por responsabilidades [802.15.4]:
- 23 -
Ricardo G. Marelli
El estndar define varias capas fsicas con el fin de soportar diferentes bandas
de frecuencia:
Subcapa MAC
La subcapa MAC gestiona el acceso al canal fsico de radio y tiene las
siguientes responsabilidades [802.15.4]:
- 24 -
Ricardo G. Marelli
2.7. ZigBee
ZigBee utiliza como fundamento las capas de enlace y MAC definidas por el
estndar IEEE 802.15.4 y agrega una capa de red, una capa de aplicacin y una capa
de seguridad [ZigBee]. La pila de protocolos completa puede apreciarse en la figura 25.
La capa de red (network layer) provee servicios para transmisin de datos entre
dispositivos de la misma red y soporta las topologas definidas en el estndar IEEE
802.15.4. Adicionalmente, provee servicios de ruteo, asignacin de direcciones,
descubrimiento de rutas y creacin y asociacin a redes [ZigBee].
- 25 -
ZigBee
Ricardo G. Marelli
Application layer
Application
framework
Security
services
ZigBee device
objects
Network layer
IEEE 802.15.4
Medium access control layer (MAC)
Physical layer
Figura 2-5. Stack ZigBee completo.
Application framework
Es el entorno en donde corren los objetos de aplicacin. Se pueden
definir hasta 240 objetos cada uno identificado por una direccin de 1 a
240 (endpoint address).
- 26 -
Ricardo G. Marelli
- 27 -
Ricardo G. Marelli
Arquitectura
La arquitectura del sistema operativo es la forma en la que este est
organizado y, en el caso de las redes inalmbricas de sensores, debe tener en cuenta
que se ejecutar sobre dispositivos con escasos recursos de procesamiento y
memoria.
Modelo de programacin
El desarrollo de aplicaciones para redes de sensores inalmbricas requiere
entender el o los modelos de programacin posibles en cada sistema operativo. En
general, se utilizan dos modelos: programacin orientada a eventos o programacin
multihilo (multithreading) [Farooq 2011].
Planificacin o Scheduling
El planificador o scheduler determina el orden en que se ejecutan las tareas del
sistema operativo. Los algoritmos de scheduling son relevantes, ya que deben estar
alineados a los requerimientos especficos de las aplicaciones que se ejecutan en los
nodos de la red de sensores [Farooq 2011].
- 28 -
Ricardo G. Marelli
cuenta las caractersticas de las redes inalmbricas de sensores [RFC7252]. Por otro
lado, los sistemas operativos libres implementan sus propias pilas de protocolos.
Arquitectura
Contiki est programado en lenguaje C. Presenta una arquitectura modular
[Farooq 2011] y orientada a eventos donde los procesos que manejan los mismos
corren hasta terminar [Dunkels 2004].
- 29 -
Ricardo G. Marelli
Modelo de programacin
Los
procesos
en
Contiki
estn
implementados
utilizando
protohilos
Scheduling
Los eventos asincrnicos de Contiki son ejecutados por el scheduler siguiendo
un orden FIFO; no obstante, los eventos que se originan en interrupciones tienen
asignada una prioridad y son ejecutados de acuerdo a esa prioridad [Dunkels 2004].
- 30 -
Ricardo G. Marelli
Arquitectura
TinyOS est programado en el lenguaje nesC que es un lenguaje de
programacin orientado a sistemas de red empotrados como ser las redes de
sensores. nesC es una extensin del lenguaje C que incorpora caractersticas como
ser la orientacin a eventos y a componentes, concurrencia y comunicacin. La
orientacin a componentes permite compilar el cdigo de TinyOS junto con el cdigo
de la aplicacin; ms an, permite utilizar solo componentes de sistema especficos,
en lugar de utilizar un sistema operativo de propsito general [Gay 2003]. Debido a
esto, TinyOS presenta una arquitectura monoltica [Farooq 2011].
- 31 -
Ricardo G. Marelli
A nivel diseo vale la pena mencionar que TinyOS presenta una arquitectura
de tres capas para abstraccin del hardware, lo que lo hace altamente portable. Las
capas son las siguientes [TEP02]:
- 32 -
Ricardo G. Marelli
Modelo de programacin
Las ltimas versiones de TinyOS, al igual que Contiki, soportan multitarea
apropiativa implementada a nivel de aplicacin (TOSThreads). La sincronizacin entre
threads se realiza utilizando primitivas estndar como ser mutexes (exclusin mutua),
semforos, barreras y variables de condicin. [TEP134]
Scheduling
En TinyOS el planificador (scheduler) es un componente y, por lo tanto, es
posible reemplazar el scheduler por uno especfico para una aplicacin en particular.
El scheduler predeterminado utiliza una poltica de tipo FIFO para las tareas [TEP106].
Las tareas tienen prioridad sobre los threads y, por lo tanto, solo se le cede el control
al scheduler de threads cuando la cola de tareas est vaca. El scheduler de threads
es de tipo round-robin con intervalos de tiempo (time slice) de 5 ms. [TEP134]
- 33 -
Ricardo G. Marelli
- 34 -
Ricardo G. Marelli
Respecto
al
transceiver,
la
interfaz
independiente
de
la
plataforma
- 35 -
Ricardo G. Marelli
Tiempo fsico
Es el tiempo en el sistema fsico.
Tiempo de simulacin
Es la representacin del tiempo en la simulacin. O sea, la forma en que
se modela el tiempo fsico.
- 36 -
Ricardo G. Marelli
Nivel de instruccin
Consiste en simular el hardware del nodo a nivel de instruccin. O sea,
que el simulador ejecuta exactamente el mismo cdigo binario que el
nodo propiamente dicho.
- 37 -
Ricardo G. Marelli
Se eligi estudiar estos simuladores debido a que son los ms adoptados para
realizar simulaciones utilizando los sistemas operativos de tiempo real Contiki y
TinyOS.
- 38 -
Ricardo G. Marelli
3.3. Avrora
Avrora [Titzer 2008] es un simulador a nivel de instruccin para redes de
sensores inalmbricas. Ms precisamente, simula la plataforma MICA2 y, por lo tanto,
el set de instrucciones de la arquitectura Atmel AVR [Titzer 2004].
( )
Pr =Pt G t Gr
4R
- 39 -
Ricardo G. Marelli
Por otro lado, Avrora permite especificar los valores sucesivos que devolvern
los sensores de los nodos durante la simulacin.
- 40 -
Ricardo G. Marelli
todas las opciones del simulador ya que, por ejemplo, no permite elegir la plataforma
de hardware simulada, sino que la misma debe ser especificada por lnea de
comandos.
- 41 -
Ricardo G. Marelli
- 42 -
Ricardo G. Marelli
En Cooja, el transceiver o radio est definido como un modelo que puede estar
en cualquiera de los siguientes cinco estados: transmitiendo, recibiendo, interferido,
escuchando y apagado.
como
atenuadores
bidimensional.
- 43 -
de
la
seal.
Supone
un
espacio
Ricardo G. Marelli
Rango de interferencia
Solo interferencia
NR2
Rango de
transmisin
NT
NR1
Recepcin o
interferencia
- 44 -
Ricardo G. Marelli
- 45 -
Ricardo G. Marelli
TOSSIM simula mltiples nodos reemplazando todas las variables por arreglos
y utilizando un ndice para representar cada nodo. No permite nodos corriendo
diferente software lo que es una limitacin si se desea simular, por ejemplo, la
interaccin entre la estacin base y el resto de los nodos.
- 46 -
Ricardo G. Marelli
para utilizar el simulador. A partir de estas clases se pueden generar mdulos para
Python. Como crtica a este esquema, debe mencionarse que TOSSIM no es un
simulador completo; termina siendo un framework y para utilizarlo es necesario realizar
un programa que se encargue de instanciar e inicializar los nodos y de ejecutar el
bucle principal de la simulacin. Esto conduce a una usabilidad baja.
- 47 -
Ricardo G. Marelli
Figura 3-5. TOSSIM conectado a la aplicacin MultiHopOscilloscope que se incluye con TinyOS.
Figura 3-6. TOSSIM conectado a la aplicacin MViz que se incluye con TinyOS.
- 48 -
Ricardo G. Marelli
- 49 -
Ricardo G. Marelli
se realiza por el simple paso del tiempo. Un modelo puede enviar un mensaje a otro
solamente antes de realizar su transicin interna.
- 50 -
Ricardo G. Marelli
- 51 -
Ricardo G. Marelli
El objetivo del trabajo fue, por un lado, mostrar la flexibilidad que otorga la
aplicacin de DEVS a redes de sensores inalmbricas y, por otro lado, probar el
modelo propuesto implementando el protocolo de ruteo Xmesh en el modelo atmico
AM-Net.
- 52 -
Ricardo G. Marelli
Figura 4-1. Arriba el modelo acoplado CM Process y abajo el modelo acoplado de sensor
[Antoine-Santoni 2007].
- 53 -
Ricardo G. Marelli
Por otro lado, en el trabajo de Qela et al. [Qela 2009] se aplic DEVS para
simular el consumo de energa en una red inalmbrica de sensores modelando los
nodos con tres estados posibles: activo, en espera (stand-by) e inactivo.
- 54 -
Ricardo G. Marelli
- 55 -
Ricardo G. Marelli
arquitectura claramente definida de tres capas para abstraccin del hardware [TEP02]
y est fuertemente orientado a componentes, lo que simplifica la implementacin. Por
otro lado, TinyOS cuenta con varias especificaciones denominadas TEP (TinyOS
Extension Proposal) que definen los requerimientos y caractersticas del sistema
operativo. Esta informacin necesaria para el diseo del simulador no est completa
en Contiki.
- 56 -
Ricardo G. Marelli
6. Solucin propuesta
6.1. Descripcin de la solucin propuesta
La solucin propuesta consiste en el diseo y desarrollo de un simulador a nivel
de red y del sistema operativo para TinyOS donde los diferentes componentes del
nodo y el entorno son modelados utilizando DEVS. El simulador desarrollado, en este
trabajo, es un entorno virtual debido a que provee un framework para que el usuario
ejecute sus aplicaciones sobre el sistema operativo TinyOS. Adicionalmente, el
simulador puede ser extendido para interactuar con dispositivos de hardware
(hardware-in-the-loop) [Li 2003].
- 57 -
Ricardo G. Marelli
Resumiendo, los objetivos perseguidos con este simulador son los siguientes:
- 58 -
Ricardo G. Marelli
Herramientas de
monitoreo para redes
reales (no simuladas)
Modelos DEVS
para Motes
Interfaz de usuario
del simulador
TinyOS
DEVS framework
Capa de mensajes
Capa de mensajes
Proporciona un servicio de intercambio confiable de mensajes entre
procesos.
DEVS framework
Implementacin de DEVS con las correspondientes interfaces para
modelado y simulacin y las extensiones necesarias para poder
distribuirlo usando mltiples procesos. Esto ltimo es necesario debido
a que TinyOS utiliza extensivamente funciones y variables estticas, lo
que impide correr aplicaciones distintas dentro de un mismo proceso.
Adicionalmente,
utilizar
mltiples
procesos
permite
mejorar
la
- 59 -
Ricardo G. Marelli
- 60 -
Ricardo G. Marelli
Modelo hijo
Modelo padre
1..*
Por otro lado, en las clases que representan modelos acoplados en ADEVS, en
DEVS++ y en la descripcin de Xiaolin & Zeigler [Xiaolin 2008] las relaciones de
acoplamiento se establecen mediante relaciones explicitas (asociacin) con las
- 61 -
Ricardo G. Marelli
Modelo hijo
Modelo padre
1..*
entre
mensajes
de
salida
mensajes
externos.
Estas
Ricardo G. Marelli
de
los
modelos
acoplados
permitiendo
ejecutar
un
modelo
independientemente de su tipo.
- 63 -
Ricardo G. Marelli
- 64 -
Ricardo G. Marelli
Simulator
+externalTransition()
+internalTransition()
+nextTN()
+model_name()
1..*
1
EventQueue
AtomicSimulator
CoupledSimulator
+addSimulator()
+addExternalEvent()
+setInternalEvent()
+pop()
1
1
+externalTransition()
+internalTransition()
+outputFunction()
+timeAdvanceFunction()
0..*
AtomicModel
Event
CoupledModel
+couplings
+addCoupling()
+translate()
Model
+inputPorts
+outputPorts
+name
+TN()()
+message()
+simulator()
+is_internal()
+is_external()
Time
Logger
2
+log()
PortCollection
+sec()
+nsec()
+compare()
+now()
+infinity()
+sleep()
Message
0..*
Port
+name()
+model_name()
+serialize()
+fromBuffer()
0..*
+putContent()
+content()
+serialize()
+fromBuffer()
ExternalMessage
OutputMessage
+dstPort()
+srcPort()
- 65 -
Ricardo G. Marelli
DEVS define que los modelos acoplados deben implementar una funcin
select para resolver colisiones entre eventos que deben ejecutarse en simultneo. No
obstante, en [Chow 1994] se describe el formalismo DEVS extendido (E-DEVS) que
elimina la funcin select para permitir paralelismo e incorpora una cola de eventos
para manejar eventos que llegan al mismo tiempo. Los eventos se secuencian
agregando al modelo acoplado una funcin de orden (Order); no obstante, si un
evento externo colisiona con la transicin interna, se ejecuta primero la transicin
interna. En la implementacin realizada, se opt por incorporar E-DEVS dado que la
implementacin de una cola de eventos, para llevar adelante la simulacin, surgi
naturalmente al disear el protocolo de simulacin y, por otro lado, implementar
E-DEVS deja preparado al framework para incorporar la ejecucin concurrente de
modelos y poder mejorar as la performance del mismo en un futuro. La funcin de
orden se resuelve directamente en la clase EventQueue (ver ms adelante) y entre
dos eventos simultneos se prioriza el evento que fue encolado en primer lugar
(FIFO).
- 66 -
Ricardo G. Marelli
Por otro lado, al igual que en Zhang [Zhang 2007] estas clases disponen de
mtodos para permitir su serializacin.
Port
Message
+name()
+model_name()
+serialize()
+fromBuffer()
+putContent()
+content()
+serialize()
+fromBuffer()
0..*
ExternalMessage
OutputMessage
+dstPort()
+srcPort()
Clase Time
Esta clase ofrece precisin de nanosegundos y se implement utilizando la
funcin clock_gettime y el reloj CLOCK_REALTIME. Adicionalmente, la clase brinda
mtodos para comparacin, adicin, obtener la hora actual y suspender (sleep). Es
una mejora respecto a las implementaciones analizadas que utilizan precisin de
milisegundos.
- 67 -
Ricardo G. Marelli
Simulator
+externalTransition()
+internalTransition()
+nextTN()
+model_name()
1..*
1
EventQueue
CoupledSimulator
AtomicSimulator
+addSimulator()
1
+addExternalEvent()
+setInternalEvent()
+pop()
1
1
0..*
1
AtomicModel
+externalTransition()
+internalTransition()
+outputFunction()
+timeAdvanceFunction()
Event
CoupledModel
+couplings
+addCoupling()
+translate()
+TN()()
+message()
+simulator()
+is_internal()
+is_external()
El
simulador
de
modelos
acoplados
(CoupledSimulator)
tiene
por
Ricardo G. Marelli
conocer cual debe ejecutar, lo que implica pasaje de mensajes adicionales o agregar
una dependencia entre el modelo acoplado y los modelos componentes. Desde el
punto de vista de la distribucin esto no es conveniente. En la implementacin
realizada se decidi asociar a los simuladores acoplados una cola de eventos (clase
EventQueue). En esta cola se almacenan en forma ordenada cuando deben ocurrir las
transiciones internas de los modelos componentes. La cola se actualiza cuando un
modelo componente realiza una transicin con lo que el modelo acoplado conoce en
todo momento cuando deben ejecutar los modelos componentes y se elimina as la
necesidad de recurrir a mensajes adicionales o iterar todos los modelos para conocer
cul es el prximo modelo que debe ejecutar. La transicin interna de un simulador
acoplado, implica, por lo tanto desencolar un evento de esta cola y ejecutarlo. Este
diseo es similar al propuesto en el trabajo de Xiaolin y Zeigler [Xiaolin 2004].
- 69 -
Ricardo G. Marelli
Para resolver este problema, y solo en el caso en que no se desea distribuir los
modelos componentes de un modelo acoplado, se decidi complementar al framework
con las clases CoupledCompositeModel y CoupledCompositeSimulator que se ven en
la figura 6-7.
- 70 -
Ricardo G. Marelli
Simulator
+externalTransition()
+internalTransition()
+nextTN()
CoupledSimulator
AtomicSimulator
+addSimulator()
1..*
1
CoupledCompositeSimulator
0..1
Model
-build_atomic_simulator()
-build_coupled_simulator()
0..*
CoupledModel
AtomicModel
+addModel()
+addCoupling()
+externalTransition()
+internalTransition()
+outputFunction()
+timeAdvanceFunction()
1
0..*
CoupledCompositeModel
1
+models()
0..1
0..*
Figura 6-7. Las clases CoupledCompositeModel y CoupledCompositeSimulator para automatizar
la creacin de simuladores.
- 71 -
Ricardo G. Marelli
- 72 -
Ricardo G. Marelli
- 73 -
Ricardo G. Marelli
que
se
describe
ms
adelante,
ser
utiliza
por
las
clases
RemoteSimulatorConnector, RemoteSimulatorAcceptor y RemoteSimulator (figura 610) para el intercambio de mensajes entre los diferentes procesos.
Simulator
1
+externalTransition()
+internalTransition()
+nextTN()
RemoteMessage
+raw_data()
+raw_size()
+getDevsMessage()
RemoteSimulator
#doProtocol()
RemoteSimulatorConnector
+connect()
+doProtocol()
1
RemoteMessageInterface
+connect()
+listen()
+accept()
+recv()
+send()
+disconnect()
Connection Handler
1
RemoteBinding
RemoteSimulatorAcceptor
+bind_all()
+remove_all()
+accept()
+listen()
- 74 -
Ricardo G. Marelli
ordena
ejecutar.
Estas
operaciones
son
reenviadas
por
la
clase
- 75 -
Ricardo G. Marelli
Process 1
CoupledModel
CoupledSimulator
RemoteSimulator
RemoteSimulator
RemoteSimulator
Ca pa d e m e ns aj es
Process 3
Process 2
Process 4
RemoteSimulator
Connector
RemoteSimulator
Connector
RemoteSimulator
Connector
Simulator
Simulator
Simulator
Model A
Model B
Model C
- 76 -
Ricardo G. Marelli
Protocolo de comunicacin
Para implementar la comunicacin entre procesos es necesario definir un
protocolo que realice la ejecucin de la simulacin. Como se mencion anteriormente,
se requiere un protocolo de tipo solicitud-respuesta que se describe en esta seccin.
Los mensajes que se definieron para el protocolo implementado en este trabajo, tienen
el siguiente formato en comn:
type
nextTN
payload size
payload
Conexin
con
un
carcter
- 77 -
nulo
(null-terminated
string).
Ricardo G. Marelli
nextTN
payload size
model name
parameters
type = 2
nextTN
payload size=0
Transicin externa
nextTN
payload size
DEVS message
nextTN
payload size=0
Transicin interna
type = 5
nextTN
payload size=0
- 78 -
Ricardo G. Marelli
nextTN
payload size
DEVS message
RemoteSimulatorConnector
RemoteSimulatorAcceptor
RemoteSimulator
Connection request
Connection response
Create remote simulator
Execute internal transition
Internal transition executed
- 79 -
Ricardo G. Marelli
los
mensajes.
Esta
capa
est
representada
por
la
interfaz abstracta
- 80 -
Ricardo G. Marelli
La
clase
RemoteMessage
representa
una
unidad
del
protocolo
de
RemoteMessageInterface
RemoteMessage
+listen()
+accept()
+close()
+connect()
+send()
+recv()
+disconnect()
+type()
+nextTN()
+payload()
+payload_size()
TCPMessageLayer
BasicTCPMessageLayer
1
- 81 -
Ricardo G. Marelli
DataCollector
+start()
+stop()
+collected_data()
+send()
BasicTCPMessageLayer
1
Stream
+read()
+write()
+size()
Figura 6-14. Clases para interaccin con sistemas externos
- 82 -
Ricardo G. Marelli
Puerto de entrada
Estado 1
Estado 2
Puerto de salida
- 83 -
Ricardo G. Marelli
X = { x1, ... , xn }
Conjunto de eventos externos de entrada.
S= { s1, ... , sn }
Conjunto de estados secuenciales (los estados que puede
tener el modelo).
Y = { y1, ... yn }
Conjunto de eventos externos generados para salida.
int : si -> sj
...
sn -> sm
Funcin de transicin interna que define los cambios de
estado debido al transcurso del tiempo (el modelo
realiza la transicin del estado si al estado sj).
ext : si * xj-> sh
...
sn * xm-> sp
Funcin de transicin externa que define los cambios de
estado debido a eventos externos. Es decir, si el modelo
est en el estado si y recibe el mensaje xj pasar al
estado sh.
: si -> yj
...
sn -> ym
Funcin de salida que determina qu mensaje se genera
(yj) de acuerdo al estado del modelo previo a una
transicin interna (si).
ta : Ti : si S = sj
...
Tn : si S = sm
Funcin de duracin de un estado; representa el tiempo
(Ti) que el modelo se queda en un determinado estado
(sj) si no ocurren eventos externos.
- 84 -
Ricardo G. Marelli
Modelos atmicos
AbstractProcessor y TinyOSProcessor
Serial y ConnectedSerial
Timer
Transceiver
Modelos acoplados
Mote
RadioMedium
- 85 -
Ricardo G. Marelli
Por otro lado, TinyOS utiliza un identificador de nodo que es informado por el
modelo TinyOSProcessor mediante la invocacin de la funcin set_sim_node de la
interfaz con TinyOS. Adicionalmente, est funcin asigna el tiempo actual en la
simulacin para que est disponible para los componentes del sistema operativo.
Por otro lado, las transiciones externas que puede realizar este modelo se
deben a mensajes desde los componentes del nodo hacia TinyOS; estos mensajes se
traducen en eventos de TinyOS como ser la llegada de informacin a travs del
transceiver. En este caso, la interfaz entre el modelo DEVS y TinyOS se realiza a
travs de devoluciones de llamadas (callbacks) asociadas a los puertos de entrada del
modelo. Estos callbacks son registrados por los componentes de TinyOS que
requieren interaccin con los modelos DEVS (funcin registerExternalEvent).
- 86 -
Ricardo G. Marelli
Las
funciones
putOutputMessage
registerRunTaskFunction,
registerExternalEvent
instancia de objeto del modelo TinyOSProcessor. Para poder realizar esta invocacin,
se debe localizar la instancia correspondiente del modelo a partir del identificador del
nodo de TinyOS. Esto se realiza mediante la clase MoteManager (figura 6-16) que
implementa los patrones de diseo instancia nica (singleton) [Gamma 2003] y registro
(registry) [Fowler 2002]. Esta clase permite, eventualmente, que el framework ejecute
varios nodos del mismo tipo utilizando un nico proceso.
- 87 -
Ricardo G. Marelli
AtomicModel
+externalTransition()
+internalTransition()
+outputFunction()
+timeAdvanceFunction()
AbstractProcessor
TinyOSProcessor
MoteManager
+mote_id()
+registerRunTaskFunction()
+registerExternalEvent()
+putOutputMessage()
0..*
1
+instance()
+add()
+get()
continuacin
se
presenta
el
modelo
DEVS
para
el
componente
SensorReadDone
SensorRead
TimerFire
TimerStop
TimerStart
Post Work
SleepIn
Sleep
Sleepin
SerialAMTurnOff
SerialAMTurnOn
SerialAMSend
SerialAMSendDone
SerialAMTurnOffDone
SerialAMTurnOnDone
SerialAMReceive
Working
Executing Event
Puerto de entrada
Puerto de salida
- 88 -
AMReceive
AMTurnOnDone
AMTurnOffDone
AMSendDone
AMSend
AMTurnOn
AMTurnOff
Ricardo G. Marelli
- 89 -
Ricardo G. Marelli
100000
T = T
16
El factor relaciona los MIPS (millones de instrucciones por segundo) de una
CPU Intel Core i7 con los MIPS de un procesador Atmel Atmega 128. Este factor es
arbitrario ya que es incorrecto comparar procesadores de arquitectura diferente
utilizando los MIPS como medida. Sin embargo, se hicieron mltiples simulaciones y
result ser un factor adecuado.
El estado Post Proc implica la generacin de mensajes de salida desde el
modelo de procesador hacia otros modelos conectados al mismo. Es la forma de
representar la interaccin de una tarea con un componente de hardware (realizada
mediante comandos de TinyOS). Este estado es necesario debido a que en DEVS
solo es posible generar un mensaje de salida antes de una transicin interna.
- 90 -
Ricardo G. Marelli
Start
Disabled
Enabled
Fire
Stop
Puerto de entrada
Puerto de salida
- 91 -
Ricardo G. Marelli
Read
Hold
Sensing
Puerto de entrada
ReadDone
Puerto de salida
- 92 -
Ricardo G. Marelli
TurnOn
TurningOff
Off
Sleep
Idle
TurningOn
TurnOff
AMSend
TurnOnDone
RadioRecieve
TurnOffDone
RadioSend
AMSendDone
AMReceive
Transmitting
Transmit
Receiving
Puerto de entrada
Puerto de salida
- 93 -
Ricardo G. Marelli
- 94 -
Ricardo G. Marelli
bits _ mensaje
rate
- 95 -
Ricardo G. Marelli
SerialTurnOn
TurningOff
Off
TurningOn
SerialTurnOff
SerialAMSend
On
SerialTurnOnDone
SerialTurnOffDone
SerialAMSendDone
Sending
Receiving
SerialAMReceive
Puerto de entrada
Puerto de salida
- 96 -
Ricardo G. Marelli
bits _ mensaje
rate
- 97 -
Ricardo G. Marelli
MOTE
PROCESSOR
SENSOR
ReadDone
Read
TinyOS
SERIAL
SerialAMTurnOff
SerialAMTurnOn
SerialAMSend
SerialAMSendDone
SerialAMTurnOffDone
SerialAMTurnOnDone
SerialAMReceive
TIMER
TimerStart
TimerStop
TimerFire
TRANSCEIVER
AMTurnOff
AMTurnOn
AMSend
AMSendDone
AMTurnOffDone
AMTurnOnDone
AMReceive
RadioSend
RadioRecieve
- 98 -
Ricardo G. Marelli
Pr = Pt Gt Gr
10
=
dBm / 10
Pwatts
1000
Gwatts = 10
GdBi / 10
- 99 -
Ricardo G. Marelli
c
f
R=
xt xr 2 yt yr 2 zt zr 2
- 100 -
Ricardo G. Marelli
Simulator
+externalTransition()
+internalTransition()
+nextTN()
+model_name()
1..*
1
CoupledSimulator
AtomicSimulator
+addSimulator()
1
1
AtomicModel
+externalTransition()
+internalTransition()
+outputFunction()
+timeAdvanceFunction()
Transceiver
Timer
CoupledModel
+couplings
+addCoupling()
+translate()
RadioMedium
Mote
AbstractProcessor
Serial
TinyOSProcessor
ConnectedSerial
Sensor
OscillationSensor
DataSensor
DataCollector
1
Figura 6-23. Clases DEVS para nodos.
- 101 -
Ricardo G. Marelli
- 102 -
Ricardo G. Marelli
Controller
+exec()
+step()
+commands()
AbstractUI
+run()
+loop()
#do_run()
Simulation
CoupledSimulator
CommandLine
1 1
RemoteBinding
+exec()
+step()
+commands()
#doRun()
RemoteSimulation
+bind_simulator()
+step()
+loop()
- 103 -
Ricardo G. Marelli
La clase Simulation define todos los comandos que pueden ejecutarse sobre la
simulacin y provee la implementacin correspondiente. Adems, ordena al simulador
acoplado la ejecucin de un paso de simulacin y se encarga de controlar el tiempo. Si
- 104 -
Ricardo G. Marelli
la simulacin no est corriendo "tan rpido como sea posible", se encarga de escalar
el tiempo y de esperar hasta que el prximo paso de simulacin deba ejecutarse.
- 105 -
Ricardo G. Marelli
7. Resultados
7.1. Validacin del simulador desarrollado
TinyOS incluye varias aplicaciones de ejemplo que pueden utilizarse para
comprobar que un nodo sensor funcione correctamente. No es posible comparar los
resultados de la simulacin directamente con TOSSIM debido a que este implementa
un modelo de radio substancialmente diferente. Especficamente, se valid DEVSTOSSIM utilizando las siguientes aplicaciones:
Blink
Blink es una aplicacin que enciende y apaga los LEDs del mote utilizando
para esto tres temporizadores. Se utiliza para validar la secuencia de inicio del mote y
los timers.
MultihopOscilloscope
MultihopOscilloscope es una aplicacin de TinyOS que recolecta la informacin
de los sensores y permite mostrarla en una herramienta realizada en Java (ver figura
7-1).
- 106 -
Ricardo G. Marelli
RadioSenseToLeds
Esta aplicacin toma peridicamente lecturas del sensor y realiza difusin
(broadcast) de esa informacin. Permite validar la comunicacin de radio (transceiver y
medio de radio), el sensor y los timers.
MViz
MViz es similar a MultihopOscilloscope y, al igual que esta aplicacin, utiliza el
protocolo de rbol de recoleccin y permite validar todos los componentes del mote.
- 107 -
Ricardo G. Marelli
- 108 -
Ricardo G. Marelli
simulacin mientras que Avrora ejecuta la simulacin en tiempo real y por un periodo
de tiempo que se especifica al iniciarla. Por otro lado, TOSSIM no es un simulador
completo sino que es necesario escribir el bucle principal de la simulacin y no
proporciona, al igual que Avrora, un modo de controlar la simulacin durante su
ejecucin. TOSSIM soporta ejecucin tan rpido como sea posible y en tiempo real si
se utiliza la extensin TOSSIM Live.
Otro punto que interesa evaluar, es la capacidad del simulador para ejecutar
nodos de distinto tipo o que ejecutan distinto software ya que el estndar IEEE
802.15.4 distingue entre dispositivos de funcionalidad completa y dispositivos de
funcionalidad reducida, los cuales pueden coexistir en una misma red inalmbrica de
sensores [802.15.4]. Al igual que Cooja y Avrora, el simulador desarrollado permite
nodos de diferente tipo o nodos que corren diferente software en la misma simulacin.
- 109 -
Ricardo G. Marelli
TOSSIM no provee un modelo de radio como tal sino que para cada
nodo se debe definir alcance, ganancia e informacin de ruido.
Por otra parte, una de las caractersticas clave de las redes de sensores
inalmbricas es que son limitadas en energa. Al igual que en TOSSIM, en la solucin
desarrollada no se simula consumo de energa. No obstante, a diferencia de lo que
ocurre en TOSSIM, se implementaron las interfaces de TinyOS utilizadas para
administrar el consumo de energa como ser las interfaces LowPowerListening y
McuSleep.
Ricardo G. Marelli
permite integrarse con otros simuladores o con otros sistemas si se implementan las
interfaces definidas para tal fin. En DEVS-TOSSIM, esta interaccin se logra
implementando nuevos modelos que podran utilizar la clase DataCollector para
intercambiar informacin con un sistema externo a travs de un socket.
Sistema operativo
Estndar de
modelado
Simulacin a
nivel de red
Simulacin a
nivel de
instruccin
Simulacin a
nivel del sistema
operativo
Modelo de
ejecucin
Control de tiempo
/ ejecucin
Simulacin con
distintos tipos de
nodo
Nocin de
posicin en
nodos
Modelo de radio
Consumo de
energa
Interfaz de
usuario
Extensibilidad
Integracin con
otros simuladores
y sistemas
Depuracin
Cooja
TOSSIM 2.x
Avrora 1.6
Contiki 2.x
TinyOS 2.x
TinyOS 2.x
DEVSTOSSIM
TinyOS 2.x
NO
NO
NO
SI
SI
NO
NO
SI
SI
NO
SI
NO
SI
SI
NO
SI
Dirigido por el
tiempo
Intervalo
entre pasos
de la
simulacin.
Dirigido por
eventos
Dirigido por
eventos
Dirigido por
eventos
NO
NO
Paso a paso,
tiempo real,
tiempo virtual.
SI
NO
SI
SI
SI
NO
Parcial
SI
SI
NO
SI
SI
SI
NO
SI
NO
Interfaz
grfica.
Scripting
Python o
C++.
SI
NO
Lnea de
comandos.
Interfaz
grfica
limitada.
Parcial
SI
NO
NO
SI
El proceso
entero (todos
los nodos).
El proceso
entero (todos
los nodos).
El proceso
entero (todos
los nodos).
Nodos en
forma
individual.
- 111 -
Lnea de
comandos.
SI
Ricardo G. Marelli
8. Conclusin
La mayor limitacin encontrada al utilizar el estndar DEVS es que no se puede
realizar comunicacin sincrnica entre componentes. Por lo tanto, muchos de los
modelos implementados en TinyOS (por ej. Timers) deben disponer de informacin de
estado local, al igual que ocurre en Cooja; esto no es un problema, ya que en TinyOS
el modo de invocar a otros componentes es mediante comandos y los mismos solo
deberan limitarse a almacenar la informacin necesaria en un buffer, con lo cual no se
requiere interaccin sincrnica entre componentes.
Otra limitacin encontrada tiene que ver con la forma en que DEVS genera los
mensajes de salida. Por ejemplo, en el caso del modelo TinyOSProcessor se requiere
poder generar un mensaje de salida inmediatamente tras una transicin interna. Esto
no es posible con DEVS lo que provoca que se deba agregar una transicin interna
adicional inmediata (duracin cero) con el objetivo de poder generar el mensaje de
salida requerido lo que conduce a modelos menos claros.
Una vez superada las limitaciones anteriores DEVS brinda un framework que
permite modelar en forma clara y sencilla todos los componentes de hardware de un
nodo y el medio de radio. En particular, la implementacin del transceiver y del modelo
de radio resulta extremadamente simple y breve en comparacin con las
implementaciones encontradas en el resto de los simuladores analizados en este
trabajo; esto se debe a que la mayor parte del trabajo la realiza DEVS y los modelos
se limitan a tomar una decisin de acuerdo al estado en que se encuentran.
- 112 -
Ricardo G. Marelli
no
se
realiza
en
forma probabilstica
sino
que
depende
Para terminar, vale la pena destacar que el modelado con DEVS proporciona
un bajo acoplamiento entre los componentes del nodo haciendo simple el reemplazo
de una implementacin por otra diferente y la incorporacin de nuevos componentes.
Adems, el modelado formal de los componentes permite conocer en forma indirecta
que est haciendo el programa que ejecuta en el nodo sensor al seguir las
transiciones de estado y los mensajes intercambiados por los componentes
modelados.
- 113 -
Ricardo G. Marelli
9. Futuros trabajos
En esta seccin se listan algunos temas que estn fuera del alcance de la
presente tesis de grado y que constituyen por lo tanto lneas de trabajo futuro:
- 114 -
Ricardo G. Marelli
- 115 -
Ricardo G. Marelli
- 116 -
Ricardo G. Marelli
- 117 -
Ricardo G. Marelli
- 118 -
Ricardo G. Marelli
- 119 -
Ricardo G. Marelli
Se debe hacer:
cd /opt/tinyos-2.1.2/apps/RadioCountToLeds/simbuild
./mote localhost:5001 root 0 0.5 0,0,0 9002 5000 &
./mote localhost:5001 node1 1 0.5 0,0,50 0 7000 &
- 120 -
Ricardo G. Marelli
30
60
90
120
150
20
40
10
60
11
12
13
14
15
80
16
17
18
19
20
100
21
22
23
24
25
- 121 -
Ricardo G. Marelli
- 122 -
Ricardo G. Marelli
Por otro lado, la funcin de duracin de estado tiene una implementacin por
defecto que devuelve el valor de la variable de estado sigma como se detalla a
continuacin:
virtual TIME timeAdvanceFunction()
La
variable
invocando
el
de
estado
mtodo
sigma
se
puede
setSigma()
en
el
asignar
mtodo
que
DEVS::TIME::infinity().
Tiene
precisin
de
nanosegundos.
Respecto al control de las fases o estados en los que puede estar el modelo se
proveen los siguientes mtodos:
void registerPhase(std::string phase)
Est mtodo registra una fase. Todas las fases o
estados que el modelo puede tomar deben registrarse
en el constructor.
- 123 -
Ricardo G. Marelli
std::string phase()
Devuelve la fase actual.
setPhase(std::string phase)
Se utiliza para cambiar la fase del modelo durante
una
transicin
interna,
en
externa,
durante
construccin
para
una
transicin
asignar
la
fase
al
TimerFire.
modelo
un
Notar
que
puerto
el
de
puerto
salida
se
llamado
construye
al
modelo
un
TimerStart.
- 124 -
puerto
de
entrada
llamado
Ricardo G. Marelli
el
- 125 -
Ricardo G. Marelli
que
de
no
los
requiere
modelos
disponer
componentes
de
las
sino
que
mtodo
dstPort
que
especificado
se
invoca
est
en
una
acoplado
el
vez
al
mensaje.
por
cada
puerto
Se
puerto
de
permite
salida
que
la
se
est
suprimiendo
la
salida.
Para
liberada
automticamente
DEVS.
- 126 -
por
el
framework
Ricardo G. Marelli
Instanciacin de simuladores
Para realizar una simulacin, es necesario instanciar los simuladores
correspondientes. Cada modelo DEVS debe asociarse con un simulador encargado de
ejecutar ese modelo. Por ejemplo:
SimpleAtomic atomic_model1( "modelo1" );
SimpleAtomic atomic_model2( "modeol2" );
DEVS::CoupledModel coupled( "UnModeloAcoplado" );
DEVS::AtomicSimulator simulator1( &atomic_model1);
DEVS::AtomicSimulator simulator2( &atomic_model2);
DEVS::CoupledSimulator coupled_simulator( &coupled );
Las lneas de cdigo precedentes instancian dos
modelos atmicos y un modelo acoplado e instancian
los simuladores correspondientes a cada modelo.
coupled_simulator.addSimulator( &simulator1 );
coupled_simulator.addSimulator( &simulator2 );
Una vez que se han instanciado los simuladores se
deben
registrar
los
simuladores
de
los
modelos
- 127 -
Ricardo G. Marelli
directamente
el
objeto
en
lugar
del
pueden
directamente
en
crearse
el
constructor
registrarse
del
modelo
acoplado.
DEVS::CoupledCompositeSimulator
coupled_simulator(&coupled);
Al
se
instanciar
la
instancian
clase
CoupledCompositeSimulator
automticamente
- 128 -
todos
los
Ricardo G. Marelli
devstossim/server/main.cpp
devstossim/client_mote/mote.cpp
devstossim/model/Data_Sensor.h
Este modelo utiliza la clase DataCollector para leer lnea a lnea valores
de sensor. Muestra como inspeccionar el stream de datos sin retirar la
informacin del buffer.
devstossim/model/Connected_Serial.h
- 129 -
Ricardo G. Marelli
devstossim/model/RadioMedium.h
para
generar
automticamente
los
devstossim/model/Mote.h
- 130 -
Ricardo G. Marelli
Referencias
[802.15.4] IEEE 802.15.4. 2011. Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs). http://standards.ieee.org/findstds/standard/802.15.4-2011.html.
Accedido: 31 de octubre del 2014.
[Antoine-Santoni 2007] ANTOINE-SANTONI, T., SANTUCCI, J.F., DE GENTILI, E.,
COSTA, B. 2007. Modelling & Simulation oriented components of Wireless Sensor
Network using DEVS formalism. In Proceedings of the 2007 spring simulation
multiconference, SpringSim '07, San Diego, CA, ACM, 2, 299-306.
[Akyildiz 2002] AKYILDIZ, I., WEILIAN, S., SANKARASUBRAMANIAM, Y., CAYIRCI,
E. 2002. A Survey on sensor networks. IEEE Communications Magazine, 40, 8, 102114. DOI: 10.1109/MCOM.2002.1024422
[Arora 2004] ARORA, A., DUTTA, P., BAPAT, S., KULATHUMANI, V., ZHANG, H.,
NAIK, V., MITTAL, V., CAO, H., DEMIRBAS, M., GOUDA, M., CHOI, Y., HERMAN, T.,
KULKARNI, S., ARUMUGAM, U., NESTERENKO, M., VORA, A., MIYASHITA, M.
2004. A Line in the Sand: A Wireless Sensor Network for Target Detection,
Classification, and Tracking. Elsevier Computer Networks, 46, 5, 605-634.
DOI: 10.1016/j.comnet.2004.06.007.
[Arora 2005] ARORA, A., DUTTA, P., BAPAT, S., KULATHUMANI, V., ZHANG, H.,
NAIK, V., MITTAL, V., CAO, H., DEMIRBAS, M., GOUDA, M., CHOI, Y., HERMAN, T.,
KULKARNI, S., ARUMUGAM, U., NESTERENKO, M., VORA, A., MIYASHITA, M.
2004. ExScal: Elements of an Extreme Scale Wireless Sensor Network. 2005. In
Proceedings of the 11th IEEE International Conference on Embedded and Real-Time
Computing Systems and Applications, Hong Kong, 102-108.
DOI: 10.1109/RTCSA.2005.47
[Atmel 2011] ATMEL. 2011. ATmega 128 datasheet.
http://www.atmel.com/images/doc2467.pdf. Accedido: 16 de noviembre del 2014.
- 131 -
Ricardo G. Marelli
Reno, NV,
1996]
BUSCHMANN,
F.,
MEUNIER,
R.,
ROHNERT,
H.,
[Chipcon 2013] CHIPCON. 2013. CC2420 datasheet. 2.4 GHz IEEE 802.15.4 /
ZigBee-ready RF Transceiver. http://www.ti.com/lit/ds/symlink/cc2420.pdf. Accedido:
16 de noviembre del 2014.
[Chow 1994] CHOW, A., ZEIGLER, B. 1994. Parallel DEVS: a parallel, hierarchical,
modular modeling formalism. In Proceedings of the SCS Winter Simulation
Conference, San Diego, CA, IEEE, 716-722. DOI: 10.1109/WSC.1994.717419
[Contiki 2015] CONTIKI. 2015. Contiki: The Open Source OS for the Internet of
Things. http://www.contiki-os.org/. Accedido: 20 de mayo del 2015.
[Cunha 2008] CUNHA, A., SEVERINO, R., PEREIRA, N., ANIS KOUBA, A., ALVES,
M. 2008. ZigBee over TinyOS: Implementation and experimental challenges.
http://www.open-zb.net/publications/CONTROLO08.pdf. Accedido: 31 de mayo del
2015.
- 132 -
Ricardo G. Marelli
[Deshpande 2005] DESHPANDE, A., GUESTRIN, C., MADDEN, S. 2005. ResourceAware Wireless Sensor-Actuator Networks. IEEE Data Engineering Bulletin, 28, 1, 4047.
[Dunkels 2004] DUNKELS, A., GRNVALL, B., VOIGT, T. 2004. Contiki - a
lightweight and flexible operating system for tiny networked sensors. In Proceedings of
the 29th Annual International Conference on Local Computer Networks, LCN 2004,
Tampa, FL, IEEE, 455-462. DOI: 10.1109/LCN.2004.38
[Dunkels 2006] DUNKELS, A., SCHMIDT, O., VOIGT, T., ALI, M. 2006. Protothreads:
Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems. In
Proceedings of the 4th international conference on Embedded networked sensor
systems, SenSys '06, Boulder, Colorado, ACM, New York, NY, 29-42.
DOI: 10.1145/1182807.1182811
[Dunkels 2007] DUNKELS, A., STERLIND, F., HE, Z. 2007. An adaptive
communication architecture for wireless sensor networks. In Proceedings of the 5th
international conference on Embedded networked sensor systems, SenSys '07,
Swissotel, Sydney, ACM, New York, NY, 335-349.
DOI: 10.1145/1322263.1322295
[Dunkels 2011] DUNKELS, A. 2011. The ContikiMAC Radio Duty Cycling Protocol.
http://dunkels.com/adam/dunkels11contikimac.pdf. Accedido: 30 de mayo del 2015.
[Farooq 2011] FAROOQ, M., KUNZ, T. 2011. Operating Systems for Wireless Sensor
Networks: A Survey. Sensors 2011, 11, 5900-5930. DOI: 10.3390/s110605900
[Ferscha 1994] FERSCHA, A., TRIPATHI, S. 1994. Parallel and Distributed
Simulation of Discrete Event Systems. Technical Report. University of Maryland,
College Park, MD.
[Fowler 2002] FOWLER, M., RICE, D., FOEMMEL, M., HIEATT, E., MEE, R.,
STAFFORD, R. 2002. Patterns of Enterprise Application Architecture. Addison Wesley,
Crawfordsville, IN.
- 133 -
Ricardo G. Marelli
[Furfaro 2008] FURFARO, A., NIGRO, L. 2008. Embedded Control Systems Design
based on RT-DEVS and Temporal Analysis using UPPAAL. International
Multiconference on Computer Science and Information Technology, IMCSIT 2008,
Wisa, Poland, IEEE, 601-608. DOI: 10.1109/IMCSIT.2008.4747305
[Gamma 2003] GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. 2003. Patrones
de diseo. Addison Wesley, Madrid.
[GreenOrbs 2009] GREENORBS. 2009. GreenOrbs: A Long-Term Kilo-Scale Wireless
Sensor Network System in the Forest. http://www.greenorbs.org/all/greenorbs.htm.
Accedido: 16 de noviembre del 2014.
[Goti 2010] GOTI, A (Ed.). 2010. Discrete Event Simulations. InTech, Croatia.
[Hartung 2006] HARTUNG, C., HAN, R., SEIELSTAD, C., HOLBROOK, S. 2006.
FireWxNet: A MultiTiered Portable Wireless System for Monitoring Weather Conditions
in Wildland Fire Environments. In Proceedings of the 4th international conference on
Mobile systems, applications and services, MobiSys '06, Uppsala, Sweden, ACM, New
York, NY, 28-41. DOI: 10.1145/1134680.1134685
- 134 -
Ricardo G. Marelli
[Intel 2006] INTEL. 2006. Intel Mote 2 Engineering Platform. Data Sheet. Rev2.0.
http://ubi.cs.washington.edu/files/imote2/docs/imote2-ds-rev2.0.pdf. Accedido: 17 de
noviembre del 2014.
[Jonsrud 2008] JONSRUD, G. 2008. Folded dipole antenna for CC2400, CC2420,
CC2430, CC2431, and CC2480. Application Note AN040, Texas Instruments, Dallas,
TX. http://www.ti.com/lit/an/swra093d/swra093d.pdf. Accedido: 16 de noviembre del
2014.
[Juang 2002] JUANG, P., OKI, H., WANG, Y., MARTONOSI, M., PEH, L.,
RUBENSTEIN, D. 2002. Energy-Efficient Computing for Wildlife Tracking: Design
Tradeoffs and Early Experiences with ZebraNet, In Proceedings of the 10th
international conference on Architectural support for programming languages and
operating systems, ASPLOS-X, San Jose, CA. DOI: 10.1145/605397.605408
[Karl 2005] KARL, H., WILLIG, A. 2005. Protocols and architectures for wireless
sensor networks. John Wiley & Sons, Southern Gate, Chichester.
[Lee 2007] LEE, H., CERPA, A., LEVIS, P. 2007. Improving Wireless Simulation
Through Noise Modeling. In Proceedings of the 6th International Symposium on
Information Processing in Sensor Networks, IPSN 2007, Cambridge, MA, IEEE, 21-30.
DOI: 10.1145/1236360.1236364
[Li 2003] LI, L, WAINER, G., PEARCE, T. 2003. Hardware in the loop simulation using
real-time CD++. In Proceedings of the Industrial Simulation Symposium, Valencia,
Spain.
[Levis 2003] LEVIS, P., LEE, N., WELSH, M., CULLER, D. 2003. TOSSIM: Accurate
and Scalable Simulation of Entire TinyOS Applications. In Proceedings of the 1st
international conference on Embedded networked sensor systems, SenSys '03, Los
Angeles, CA, ACM, New York, NY, 126-137. DOI: 10.1145/958491.958506
[Low 2005] LOW, K., NU, W., MENG, J. 2005. Wireless Sensor Networks for Industrial
Environments. In Proceedings of the International Conference on Computational
Intelligence for Modelling, Control and Automation and International Conference on
Intelligent Agents, Web Technologies and Internet Commerce, CIMCA-IAWTIC'06,
IEEE, Washington, DC, 271-276. DOI: 10.1109/CIMCA.2005.1631480
- 135 -
Ricardo G. Marelli
[MEMSIC 2010] MEMSIC. 2010 Mote Processor Radio & Mote Interface Boards User
Manual.
http://www.memsic.com/userfiles/files/User-Manuals/mpr-mib_series_users_manual7430-0021-09_a-t.pdf. Accedido: 17 de noviembre del 2014.
[Moon 2009] MOON, H. 2009. DEVS++: C++ Open Source Library of DEVS
Formalism. http://odevspp.sourceforge.net/. Accedido: 16 de noviembre del 2014.
[Myers 2000] Myers, B., WILLINGHAM, J., LANDY, P., WEBSTER, M., FROGGE, P.,
FISCHER, M. 2000. Design Considerations for Minimal-Power Wireless Spread
Spectrum Circuits and Systems. In Proceedings of the IEEE, 88, 10, 1598-1612.
DOI: 10.1109/5.888998
[Nutaro 2008] NUTARO, J. 2008. Adevs (A Discrete Event System simulator).
http://www.ornl.gov/~1qn/adevs/. Accedido: 16 de noviembre del 2014.
- 136 -
Ricardo G. Marelli
[sterlind 2006b] STERLIND, F., DUNKELS, A., ERIKSSON, J., FINNE, N., VOIGT,
T. 2006. Cross-Level Sensor Network Simulation with COOJA. In Proceedings of the
31th Annual International Conference on Local Computer Networks, Tampa, FL, IEEE,
641-648. DOI: 10.1109/LCN.2006.322172
[Parbat 2010] PARBAT, B., DWIVEDI, A., VYAS, O. 2010. Data Visualization Tools for
WSNs: A Glimpse. International Journal of Computer Applications, 2, 1, 14-20.
[Qela 2009] QELA, B., WAINER, G., MOUFTAH, H. 2009. Simulation of large wireless
sensor networks using cell-devs. In Proceedings of the 2009 Winter Simulation
Conference, WSC 2009, Austin, TX, IEEE, 3189-3200.
DOI: 10.1109/WSC.2009.5429272.
[RFC4944] IETF RFC 4944. 2007. Transmission of IPv6 Packets over IEEE 802.15.4
Networks. http://tools.ietf.org/html/rfc4944. Accedido: 31 de mayo del 2015.
[RFC7252] IETF RFC 7252. 2014. The Constrained Application Protocol (CoAP).
https://tools.ietf.org/html/rfc7252. Accedido: 31 de mayo del 2015.
[Schmidt 1997] SCHMIDT, D. 1997. Acceptor-Connector An Object Creational Pattern
for Connecting and Initializing Communication Services. Washington University, St.
Louis.
[Sohraby 2007] SOHRABY, K., MINOLI, D., ZNATI, T. 2007. Wireless sensor
networks. Technology, Protocols, and Applications. John Wiley & Sons, Hoboken, NJ
- 137 -
Ricardo G. Marelli
[TEP112] SZEWCZYK, R., LEVIS, P., TURON, M., NACHMAN, L., BUONADONNA,
P., HANDZISKI, V. Microcontroller Power Management.
http://www.tinyos.net/tinyos-2.1.0/doc/html/tep112.html. Accedido: 16 de noviembre del
2014.
[TEP115] KLUES, K., HANDZISKI, V., HAUER, J., LEVIS, P. Power Management of
Non-Virtualised Devices.
http://www.tinyos.net/tinyos-2.1.0/doc/html/tep115.html. Accedido: 16 de noviembre del
2014.
[TEP116] LEVIS, P. Packet Protocols.
http://www.tinyos.net/tinyos-2.x/doc/html/tep116.html. Accedido: 31 de mayo del 2015.
- 138 -
Ricardo G. Marelli
[TEP123] FONSECA, R., GNAWALI, O., JAMIESON, K., KIM, S., LEVIS, P., WOO, A.
2007. The Collection Tree Protocol (CTP).
http://www.tinyos.net/tinyos-2.1.0/doc/html/tep123.html. Accedido: 16 de noviembre del
2014.
[TEP139] LIANG, C., DECKER, E., CARLSON ,D., GNAWALI, O. 2010. The Source
Routing Protocol (SRP).
http://raw.github.com/tinyos/tinyos-release/tinyos-2_1_2/doc/txt/tep139.txt.
Accedido: 31 de mayo del 2015.
[Titzer 2004] TITZER, B. 2004. Avrora: The AVR Simulation and Analysis Framework.
Master's Thesis. Universidad of California, Los Angeles, CA.
[Titzer 2005] TITZER, B., LEE, D., PALSBERG, J. 2005. Avrora: Scalable Sensor
Network Simulation with Precise Timing. In Proceedings of the Fourth International
Symposium on Information Processing in Sensor Networks, IPSN 2005, Los Angeles,
CA, 477-482.
DOI: 10.1109/IPSN.2005.1440978.
[Titzer 2008] TITZER, B., PALSBERG, J., LEE, D., LANDSIEDEL, O. 2008. Avrora:
The AVR Simulation and Analysis Framework. http://compilers.cs.ucla.edu/Avrora/.
Accedido: 16 de noviembre del 2014.
- 139 -
Ricardo G. Marelli
[Werner-Allen 2005] WERNER-ALLEN, G., JEFF, J., MARIO, R., LEES, J., WELSH,
M. 2005. Monitoring Volcanic Eruptions with a Wireless Sensor Network. In
Proceedings of the Second European Workshop on Wireless Sensor Networks, EWSN
2005, Istanbul, IEEE, 108-120. DOI: 10.1109/EWSN.2005.1462003
- 140 -
Ricardo G. Marelli
Glosario
Acknowledgments (ACK): en protocolos de comunicacin, es un mensaje enviado
para confirmar la recepcin de otro mensaje.
ADC: conversin analgica-digital.
Flag: bandera.
Idle: inactivo.
MCU: microcontrolador.
- 141 -
Ricardo G. Marelli
Power-down: apagar.
Round-robin: recorrer todos los elementos de una lista en forma circular. Como
algoritmo de scheduling, implica asignar la misma cantidad de tiempo a cada proceso
y que todos los procesos tienen la misma prioridad.
Proxy: intermediario para un objeto.
Standby: en espera.
Timer: temporizador.
- 142 -
Ricardo G. Marelli
- 143 -