Integration of Event-Driven Embedded Operating Systems ... · Integration of Event-Driven Embedded Operating Systems Into OMNet++ – A Case Study with Reflex Sören Höckner LS

Integration of Event-Driven Embedded Operating SystemsInto OMNet++ – A Case Study with Reflex

Sören HöcknerLS Verteilte

Systeme/BetriebssystemeBTU Cottbus

Cottbus [email protected]

cottbus.de

Andreas LagemannLS Verteilte

Systeme/BetriebssystemeBTU Cottbus

Cottbus [email protected]

cottbus.de

Jörg NolteLS Verteilte

Systeme/BetriebssystemeBTU Cottbus

Cottbus [email protected]

cottbus.de

ABSTRACTDeveloping wireless sensor network (WSN) applications isa challenging task. Simulations are a key component inthe development process, since they offer simple means oftesting and evaluating the applications without the need oftime consuming and tedious deployment. But simulationsalone are not sufficient to evaluate such applications. Onlyexperiments on real hardware can ultimately verify the cor-rectness of a given algorithm and its implementation. Totake the most benefit from a WSN simulator it must be ableto simulate a sensor network, where all nodes run the sameimplementation of the algorithm that will later be deployed.We show how to integrate event-driven operating systemsinto the OMNeT++ discrete event simulator. At the ex-ample of Reflex we show how an integration can be easilyachieved with minor effort. Additionally we discuss an alter-native approach which promises better scalability but comesat the cost of less flexibility at the application layer and re-quires more deeply intrusions into the operating system. Weargue that the integration is feasible and that it yields a sim-ulation tool, which can perform similar to other tools likeTOSSIM or COOJA but benefits notably from the flexibilityof OMNeT++ and its cornucopia of readily available modelsprovided by the community.

Categories and Subject DescriptorsC.3 [Special-purpose and Application-based Systems]:Realtime and embedded systems; D.2.5 [Software Engi-neering]: Testing and Debugging

General TermsExperimentation

KeywordsSimulation, OMNeT++, Sensor networks

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.OMNeT++ 2009, Rome, Italy.Copyright 2009 ICST/ACM, ISBN 978-963-9799-45-5 ...$5.00.

1. INTRODUCTIONWireless Sensor Networks (WSN) typically consist of do-

zens to hundreds of tiny micro controller based computers(usually called motes or nodes) equipped with a set of prob-lem specific sensors and actuators. Additionally every nodehas a transceiver allowing for wireless communication. Typ-ical sensor network applications are sense and send and mo-nitoring. In sense and send applications every single nodesimply samples its sensor readings and periodically sends thedata to a well known sink, where the data is processed. In amonitoring application individual nodes evaluate their sen-sor readings and react by issuing warning messages, whenthe values are not within predefined bounds. Both appli-cations demonstrate the event-driven nature of WSN. Thatmeans that the behavior of sensor network applications isdependent on the set of events that they are exposed to andon the possible set of interactions induced by each particularordering of events.

This implies that programs for WSN cannot be sufficientlytested let alone evaluated on a single node. The authorsof [13] postulate that the right simulation tool for WSNmust allow to study the whole application, including theoperating system (OS) and the network stack. Furthermorethese tools, according to [13], need to handle large numbersof nodes while providing sufficient detail to capture the sub-tle effects caused by unpredictable interference and noise.According to the authors, many researchers have concludedthat fulfilling all these requirements simultaneously is in-tractable. They have therefore instead applied very abstractsimulations for instance by adapting ns-2 ([16], [21] and [7]).While these are valuable simulation approaches they do notstudy the actual implementation of the WSN application,which actually hampers if not inhibits deployment, becauseyou have to implement the algorithm twice: once for the sim-ulator and once for the sensor node. This is not only verytedious, additionally it may lead to correct algorithms im-plemented wrongly. Guaranteeing consistency between twoimplementations is tremendously hard. Therefore it wouldbe most advisable to have some means of using the sameimplementation for the simulation as well as for the targetplatform with at most some minor adaptations in a centrallocation.

While there are many ways to achieve this (refer to Sec-tion 2), we chose to integrate our lightweight, event basedoperating system Reflex [20] into OMNeT++ . This wasa relatively easy task. The reason for that lies in the design

of both Reflex and OMNeT++ .This paper presents the key properties of the design of

OMNeT++ and Reflex used for the integration and illus-trates how the integration was done. It is on the one handintended to serve as a guideline to fulfilling similar tasks withsimilar operating systems resp. simulators. On the otherhand it will identify enabling properties of the simulatorand the OS which serve the goal of seamless integration ofthe two worlds.

The paper is structured as follows: The next section dis-cusses related work in the field of simulating wireless net-works. The following two sections give a short overview ofReflex and OMNeT++. Then the integration is describedin detail and possible alternatives are discussed. At last weconclude with possible future work.

2. RELATED WORKThe choice of an adequate simulator is a crucial decision

for researchers in WSN, since the quality of the simulationdirectly correlates to the quality of the results to be pub-lished. A recent trend is that publications not relating toexperimental results are rarely accepted at conferences witha WSN related topic. It would seem that more and moreresearchers will agree that simulation alone is not sufficientto evaluate solutions for WSN. Nevertheless simulation is anessential step in the development process. Since the deploy-ment of WSN applications is very tedious and cumbersome,it is advisable to evaluate the application as accurately aspossible before carrying out the deployment of the actualsensor network.

There have been many approaches to simulating WSN ap-plications. Simulations can be roughly classified into threeclasses according to their level of abstraction. The first classoperates on the network layer and abstracts from the oper-ating system and the specific platform. One representativeof this class is ns-2 [5]. It is a general purpose networksimulator which led to an immensely accelerated progress inthe field of network protocol research by providing a com-mon toolbox for studying a wide range of network protocolsagainst various traffic models. ns-2 has also been utilized forWSN simulations ([16], [21], [7]). The problem with thesesimulation approaches is that they remain too abstract anddo not address issues with the actual implementation of thealgorithms.

The second class operates at the operating system level.A common example of this class is TOSSIM [13], a discreteevent simulator for sensor networks that use the TinyOSplatform. With TOSSIM it is possible to compile TinyOSapplications directly into its framework and then run thou-sands (according to [13]) of motes simultaneously executingthe same application.

The third class enables simulation at the machine codelevel. A representative for this is Avrora [18]. Avrora pro-vides cycle accurate simulation of the behavior of sensor net-work devices and communication. The authors claim thatavrora was as scalable as TOSSIM while it was merely 50%slower. As the name suggests, it is restricted to AVR basedmicrocontrollers. A similar tool exists for MSP430 micro-controller based nodes called MSPsim [10]. It is howevernot capable of simulating whole WSN as a standalone appli-cation but is merely intended to be used with a cross levelsimulator like COOJA [15].

COOJA has been designed to integrate all three categories

into one modular extensible simulation framework by simu-lating code on all three levels simultaneously. Behavior atnetwork level can be simply implemented in Java. The othertwo levels are based on the Contiki [9] operating system. Itcan be simulated on the OS level, where the Contiki appli-cation including all system components is compiled into ashared library. The simulator controls the application viathe Java native interface. It can also be simulated on themachine code level by utilizing MSPsim.

OMNeT++ is a discrete event simulator like ns-2 andTOSSIM. Unlike TOSSIM and ns-2 it is very generic andmodular, which allows it to model everything that fits theevent driven approach. Therefore it offers a proper plat-form to integrate all kinds of simulation approaches. OM-NeT++ is already widely used as simulation tool for WSN.Several frameworks exist, which offer models useful for WSNsimulation e.g. for wireless communication and node mobil-ity ([2], [3], [1], [6], [4] among others). Due to the modulardesign of OMNeT++ , components of the different modulescan be mixed relatively easy, to fit specific needs. The in-tegration of Reflex into OMNeT++ gives us access to agreat number of modules supported by a large user commu-nity and offers the opportunity to profit from future develop-ments made for OMNeT++, as they can be easily integratedwith our current models.

3. REFLEX – THE REALTIME EVENT FLOWEXECUTIVE

Reflex is an event driven operating system for deeplyembedded systems and is particularly useful for embeddedcontrol applications as well as wireless sensor nodes. It ismostly written in C++ (aside from few parts of the plat-form specific code written in assembler) and therefore ben-efits from a sound object oriented design. It has a mono-lithic structure which means that both the program and theoperating system are compiled into one single binary im-age. For space and performance reasons Reflex is a singlethreaded system which uses a specific task model to repre-sent independent activities. All tasks share the single sys-tem stack, therefore a task switch does not involve a stackswitch. As a consequence all tasks must exhibit a run tocompletion semantic. This task model is well known andsufficient to model typical applications for embedded sys-tems. Tiny OS [14] for instance is using this model as well.Reflex, like Contiki [9], has an event driven architecture.The basic structural entity is the component. A componentcan contain activities (tasks) and interrupt handlers. Theyrepresent logical blocks which may for instance be composedto implement a complex state based control algorithm. Thehandlers and tasks provide active behavior and are thereforethe entities managed by the scheduler. Handlers and tasksare connected by event channels. Events may contain dataand are exchanged via these channels. Events are alwaysbuffered by the channels, including the possibly containeddata. Whenever an event is assigned to a channel, the corre-sponding receiving task is added to the scheduler’s ready listand eventually selected for activation. This strategy effec-tively guarantees that only such tasks are activated, whichhave valid input, i.e. their corresponding input channels havedata available for processing.

Figure 1 illustrates the component based design of a Re-flex application, it is taken from [20]. Additionally to the

Control- function

Driver

Control- function

Control- function

DriverInterrupt-handler

Interrupt-handler

Sensor SensorActuator Actuator

Application layer

Driver layer

Hardware layer

Hardware event

Software event

Interrupt handler Activity Component

Figure 1: Reflex Event Flow Model

component structure each application can be divided intolayers. The lowest layer is established by the hardware com-ponents themselves, which can be coarsely classified intosensors and actuators. The hardware for our example ap-plication consists of two sensors and two actuators. Thedriver layer contains components for the control of the de-vices present at the hardware layer. Tasks that are responsi-ble for controlling devices are called drivers. Interrupt han-dlers are a special kind of task, which are not activated bythe scheduler but directly from an interrupt, triggered by asensor. They are the only entities that can be activated inde-pendently of the event flow. Therefore they should be keptas short as possible, merely take care of the pieces of workthat cannot be postponed and defer the actual handling toan activity by issuing an appropriate event. It can be easilyseen in figure 1 that the initial source of each event is al-ways an interrupt. While the communication between nodesis completely asynchronous, the activities and handlers in-side of components can share state information without ex-plicit synchronization. This approach is similar to Tiny-GALS (Globally Asynchronous Locally Synchronous) [8]. Ithas several advantages, e.g. implicit synchronisation as hasbeen shown in [11].

What distinguishes Reflex from other event-driven em-bedded operating systems, is its flexible scheduling frame-work [20], which gives the developer the choice betweenseveral scheduling strategies at compile time. It supportsFCFS- (First Come First Serve), FP- (Fixed Priority), EDF-(Earliest Deadline First) and TT- (Time Triggered) schedul-ing. Some of these strategies support resp. require preemp-tive scheduling of tasks. When using preemptive schedul-ing schemes, some caution is indicated to preserve the im-plicit synchronization properties. For instance when usingpreemptive FP-scheduling (a non-preemptive version existstoo), all tasks inside the same component which concurrentlyaccess their shared state must be assigned the same priority,otherwise synchronization has to be implemented explicitly.

Portability is a crucial property of operating systems fordeeply embedded systems. Reflex provides support foreasy porting by a strict modular organization of the sourcecode. A large section of the core system code is writtenindependently of specific hardware. All hardware depen-dent code is subdivided into a controller specific part and aplatform specific part. A controller refers to a specific mi-crocontroller architecture. A platform however refers to aspecific device consisting of a microcontroller equipped witha set of devices (e.g. sensors, actuators, radio etc.). Con-

trollers for which Reflex has been ported include MSP430,HCS12, MIPS32, Atmega128, Atmega8535, M16C, H8300and linux for executing Reflex on i386 based systems (fortesting or simulation). Platforms for which ports exist in-clude CardS12, MICA2, OMNetPP, guest, ESB, MICA2DOT,SK-XC164CS, GLYNR8C, Mega128, RCX and TMoteSky.

4. OMNET++OMNeT++ is a discrete event simulator written in C++.

To execute simulations with OMNeT++ a model needs tobe defined, which consist of modules. There are two kindsof modules, simple modules and compound modules. Thesimple modules are basic building blocks. They are the ac-tive components of the model, programmed in C++ andrepresented by the cSimpleModule class, which serves as abase for the implementing class. Simple modules can becombined into compound modules and so forth. Both sim-ple and compound modules are instances of module types.During model design, the developer declares module types,instances of which can be combined to more complex mod-ules. At last, the system module is defined as an instanceof any defined module type. Both kinds of module typescan be transparently used as building blocks. This allowsfor restructuring a module instance by breaking it up intoseveral module instances or synthesize several componentsinto one module without affecting the interface of the build-ing block. Modules communicate with messages which aretypically sent via gates but may possibly be sent to theirdestination module directly (via method calls). Gates de-fine the input and output interfaces of modules. A channelconnects an input gate with an output gate. Connectionsare always contained within a single hierarchy level. Thegates of a simple module may be either connected with cor-responding gates of other simple modules within the samecompound or with a gate of the enclosing compound moduleof the same type. Figure 2 (taken from [19]) demonstratesthe structure of OMNeT++ models. Boxes represent mod-ules, arrows represent connections and small square boxesrepresent gates.

Figure 2: The model structure of OMNeT++

Events are represented as messages in OMNeT++ . A sep-arate event class is not provided. A message is an instanceof the class message or any derived type. They are sentfrom one module to another; therefore the module wherethe event will occur is called the message destination. Pa-rameters add more flexibility to the usage of modules andfacilitate the reuseability of modules. They are mainly usedto pass configuration data to simple modules and to helpdefine model topology. A module can define an arbitrarynumber of parameters.

Since simple modules are the active elements of a model, adesigner may redefine four methods defined in cSimpleMod-

ule. The initialize() method is called before the simula-tion start, in order to initialization of the module. If needed,an arbitrary number of initialization stages can be defined inorder to solve dependency issues. The handleMessage() andthe activity() methods are called during event processing.Each method represents a different approach to event pro-cessing. While handleMessage() is called each time a mes-sage is delivered at the corresponding module, activity()implements the process interaction approach. Each simplemodule can use exactly one of both alternatives. Modulesimplementing handleMessage() and such using activity()

can be mixed freely. When using the coroutine based ap-proach, the receiveMessage() method has to be used inorder to receive messages. The call of receiveMessage isblocking, i.e. due to the cooperative nature of the corou-tine approach this is the only point where the control istransfered to the simulation kernel and then possibly to an-other module. Each module using the process interactionapproach, must call receiveMessage regularly. If it doesnot, the simulation will not proceed anymore. The purposeof most simulations is gathering statistical data about thealgorithms simulated. For this purpose cSimpleModule of-fers the finish() method. This method is called at the endof a simulation run, before the module’s corresponding ob-jects are destroyed. It provides the module developer withthe opportunity to gather all relevant data and for instancewrite it into a file.

5. REFLEX FOR OMNET++A lot of research results in Wireless Sensor Networks (WSN)

have been published which were solely based on data gath-ered in simulations and never have been verified with datafrom experiments on real hardware. Recent results suggestthat simulation alone is not sufficient for evaluation of WSNalgorithms. Due to the inherent complexity of distributedsystems combined with uncertainties and fluctuation intro-duced with the wireless medium, simulators alone are in-capable of providing sufficiently exact models. Neverthelesssimulation is a vital step in the development process of WSNalgorithms, since WSN deployment is tremendously expen-sive and debugging of embedded applications is cumbersomeat best.

The goal of integrating Reflex into OMNeT++ was there-fore to provide researchers with the opportunity of imple-menting their algorithms once for the Reflex operatingsystem and have that code run in a simulated WSN for testand basic evaluation as well as on real sensor nodes likeTMoteSky or ScatterWeb with only minor porting effort.

When adding functionality to OMNeT++ modules, thedeveloper has the choice between two alternative program-ming models: coroutine based and event-processing-function.When using coroutine-based programming , the module coderuns in its own thread. This thread is scheduled non-pre-emptively. It receives control from the simulation kerneleach time the module receives an event (i.e. a message).Typically the function containing the coroutine code willnever return. It will usually consist of an infinite loop con-taining send and receive calls. When using the event-pro-cessing function, the simulation kernel simply calls the givenfunction of the module object with the message as argument.This function has to provide a run to completion semantic,

i.e. it has to return immediately after processing the mes-sage. The drawback of the coroutine-based approach is thatit requires more memory since every module needs its ownCPU stack. When the model contains a large number ofmodules this can have significant influence on the simula-tion performance and its general applicability. On the otherhand this approach is more natural if a module represents asensor node.

Scheduler

ChannelControl

PowerManager

Serial Port

OmnetNode

OmNeT++ Reflex

Radio

sleep

waitf.msg

interrupt

message data

schedulereceived task

send orrecv.mes-sage

Figure 3: Components of the OMNeT++ -versionof Reflex

For our purpose the latter approach provides a less intru-sive way of integrating Reflex. Since it is a single threadedsystem, Reflex can be easily mapped onto the coroutinemodel without modification. Although Reflex enforcesrun to completion semantics for tasks, it is still possibleto use blocking code in the main thread (e.g. while wait-ing for a message to arrive). Such Reflex applicationscould not be run in the simulator when using the event-processing-function. For these reasons we decided to use thecoroutine-based approach first, although it might be interest-ing to investigate the alternative, because it could providebetter scalability regarding the number of sensor nodes asimulation model can contain, without suffering severe per-formance penalties. The limiting factor for the coroutinebased approach is the total of memory available. Since eachcoroutine holds its own stack, an upper bound for the num-ber of nodes in a simulation run is the amount of memoryavailable divided by the amount of memory reserved for acoroutine stack. The latter should be chosen carefully, be-cause if it was dimensioned too small, stack overflows willoccur, resulting in unpredictable behavior of the simulation.

With the coroutine based approach there is one additionalpitfall, which has to be kept in mind by the developer. Be-cause the Reflex-scheduler continuously queries the taskqueue and only calls the wait routine when the queue isempty, the application must be designed such that there isno task which will be scheduled continuously without de-pending on external input. An application in which sucha task exists, will effectively cause the simulation to stopsince it will never allow another OMNeT++-coroutine to be

scheduled which results in no events being generated and sono time progress in the simulation being made.

5.1 ArchitectureIn figure 3 you can see the components involved in the

integration of the Reflex operating system into the OM-NeT++ simulator. The most central component is the Om-net Node, it serves as a gateway between the OMNeT++runtime environment and that of Reflex. Viewed from anOMNeT++ perspective, Omnet Node is a SimpleModule.The Omnet Node processes messages received from othernodes and initiates an interrupt handling. Whenever Om-net Node receives a message from Channel Control it readsthe message’s kind attribute and calls the interrupt guardianof Reflex to indicate that there is an event pending at theSerial Port1. Therefore messages have to hold a valid inter-rupt vector in their kind attribute. Channel Control is themodule which represents the wireless channel in the INETframework.

This approach allows adding additional devices to the sim-ulation by simply defining a special message type represent-ing an interrupt from that device. If a temperature sensorshall be modeled for instance, a message type, which con-tains the time and the measured temperature at that timewould have to be created. At runtime the driver for the sim-ulated sensor could read the appropriate values from a filecontaining data from a real measurement to fill in the fieldsof the message. The interrupt would be initiated by simplysending this message. Until now only one device in additionto the radio is implemented: the system timer.

A WSN typically consists of a greater number of nodes.Since an OMNeT++ model is a monolithic application, allinstances of Omnet Node reside in the same address space.Since each Omnet Node represents a Reflex driven node,there are multiple instances of Reflex running in a singleaddress space. The Reflex system needs reference to itsmain system object. This is usually no problem, since in oneaddress space normally only one instance of Reflex exists.Therefore a mechanism is needed which yields a referenceto the system object of the currently active node. This isimplemented via a global pointer, which is always set appro-priately when control is transfered to another Omnet Nodemodule.

Figure 4 visualizes the control flow of a message being re-ceived and processed. The module Channel Control modelsthe wireless channel (it is part of the INET framework). Itis responsible for calculating the set of receiving nodes foreach message sent and delivering it accordingly. When themessage is received by an Omnet Node its kind attributeis retrieved, which has to represent a valid entry in the in-terrupt vector table (see above). With this entry the mod-ule managing the vector table called Interrupt Guardian isinvoked. The Interrupt Guardian invokes the appropriatehandler. The handler, after doing some preprocessing veryshortly, triggers an activity responsible for post processing.The trigger method of the activity then simply adds itself tothe ready list of the scheduler, which will eventually activateit.

To understand how the transfer from the simulation en-gine to the Reflex runtime and vice versa is realized, firstthe workflow of the Reflex scheduler has to be considered.

1we chose this name, because the transceiver is connectedvia the serial port on many sensor nodes

A scheduler mainly consists of an infinite loop in which thetask queue is continuously checked for tasks. When it isnot empty, the scheduler removes one task from the queueaccording to its scheduling strategy and activates it. Whenthe task completes, the next task is selected and activated.When the list is empty, the scheduler signals the system thatit may enter a power save state. The available power savemodes are platform dependent. Therefore the correspondingmethod has to implemented for each platform. Recall thatthe portability of Reflex is provided by strictly separatingindependent code from such depending on a certain platformresp. controller (refer to Section 3. The Linux controller canbe used, since OMNeT++ will run on Linux and most Unixbased systems. The OMNeT++ simulator then constitutesan additional platform. The code for this platform containsthe Omnet Node module and some additional modules use-ful for a WSN model. It also contains a modified versionof the _wait() system call which is called by the schedulerwhen the ready list is empty. Here the switch to the simu-lation runtime is implemented. The OMNeT++ runtime isqueried for new events (by issuing a receive() call), whichmay lead to a context switch to another coroutine.

wai t ( ){

// b l o c k s u n t i l a message i s handed// to t h i s componentact ive message = r e c e i v e ( ) ;

// i n t e r r u p t hand lerdispatchMsg (msg ) ;

// re turn to s chedu l e rreturn ;

}

Figure 5: The code of the OMneT++ specific ver-sion of the _wait() method

In figure 5 the code for this method is shown. The publicstatic member active_node of the class OmnetNode is neces-sary to give the handlers access to the message representingthe interrupt. Since this information usually is availablefrom special hardware registers or similar, the interface ofthe handlers does not provide means to submit it. The dis-

patchMsg() call reads the message contents, extracts themessage kind carrying the index for the vector table andcalls the interrupt resolving component of Reflex with thisindex.

5.2 ExperiencesOur simulation framework for Reflex based WSN has

for instance been used for simulating a combined routinglayer for wireless sensor networks and mobile ad-hoc net-works [17]. This example is particularly interesting becauseit demonstrates the possibility to integrate arbitrary modelswith our Reflex based sensor node models. The object ofthe routing protocol was to support a scenario, where firstresponders equipped with some PDAs capable of WLANand ZigBee communication are sent to a disaster area wherea wireless sensor network that monitors the area for lethalamounts of contaminants or signs of life, has already been

ChannelControl

OmnetNode

InterruptGuardian

InterruptHandler

PostProcessing

Act. Scheduler

message

extr.msg kind

submitkind

lookupkind

in IVT

callhandler

pre proc.int.

triggeract.

scheduleself

Figure 4: Interaction of OMneT++ and Reflex components

deployed. The idea is that the PDAs build a mobile ad-hocnetwork for mutual coordination of the first responders. ViaZigBee they are also capable of communicating with sensornodes in range and therefore with the sensor network. Therouting protocol should provide means to allow all combina-tions of mutual communication between PDAs and sensornodes. The routing protocol should use weights assignableby the user to in route calculations. So it would for instancebe possible, to use the MANET as a backbone for the WSN,conserving the small energy reserves of the sensor nodes.

For the evaluation besides experiments on real hardware,some simulations where executed. The simulated networkconsisted of 40 sensor nodes and 8 PDAs. The sensor nodeswere modeled using the OMNeT++ platform for Reflex.The PDAs were modeled using CsharpSimpleModule [12],which allows definition of OMNeT++-modules in C#. Formobility and communication the INET framework has beenused. The simulations were caried out on a PC with IntelXEON CPUs at 2.4 GHz nominal CPU speed and 2GB ofRAM.

We recently used our framework for simulating up to 1000nodes on a 10000 m * 10000 m playground. Nodes were com-municating over a wireless channel using INETs Channel-control which we modified to simulate perfect links (i.e. nocollisions and no bit errors). The communication patternwas rather sparse. To simulate the system clocks, a timersignal occured each millisecond at each node. We let thesame simulations run on TOSSIM in parallel. Though wedid not perform the simulations on a strictly comparablebasis (different platforms, uncontrolled environmental influ-ences) the results suggest that we are at least not slowerthan TOSSIM. The simulation results are presented in a pa-per currently under review so we can give no reference here.Our simulations were run on a MacBook with a 2.1 GHzIntel Core 2 Duo and 4 GB of RAM. Apart from setting thestack limit to 64 KB we did not need to make any changesto the systems settings.

This shows that our approach is capable of simulating net-works of relevant size and it supports our claim that Reflexmodels can be integrated with existing models.

6. CONCLUSION AND FUTURE WORKWe have presented the integration of an embedded oper-

ating system called reflex into the discrete event simulatorOMNeT++ . The goal was to provide a simulator for WSN,which enables developers to run applications written for Re-flex once in the simulator as well as on any hardware plat-form supported by reflex with only minor modifications. TheOMNeT++ platform provides radio communication basedon the INET framework and a system timer to provide ac-cess to simulation time from the application. By utilizingsome similarities in the design of Reflex and OMNeT++seamless integration was easily possible.

We chose to use the coroutine based approach of OM-NeT++ , because that allowed for an integration with lessmodifications of Reflex and imposes less restrictions on thedeveloper regarding the program structure. Nevertheless itwould be interesting to investigate the possibilities of theevent processing approach. The benefit of that approach isthat it would allow for larger simulations (i.e. with a greaternumber of nodes) since it induces much less runtime over-head than coroutines. To achieve this, the scheduler of Re-flex has to be reimplemented without the endless loop. Theimplementation would have to guarantee that every time thesystem receives a message the scheduler will be called afterthat message is handled.

7. REFERENCES[1] Castalia. http://castalia.npc.nicta.com.au/.

[2] The inet framework. http://www.omnetpp.org/staticpages/index.php?page=20041019113420757.

[3] The mobility framework.http://mobility-fw.sourceforge.net/.

[4] Nesct: A language translator.http://nesct.sourceforge.net/.

[5] The network simulator.http://www.isi.edu/nsnam/ns/.

[6] The pawis simulation framework.http://pawis.sourceforge.net/.

[7] D. Braginsky and D. Estrin. Rumor routing algorthimfor sensor networks. In WSNA ’02: Proceedings of the

1st ACM international workshop on Wireless sensornetworks and applications, pages 22–31, New York,NY, USA, 2002. ACM.

[8] E. Cheong, J. Liebman, J. Liu, and F. Zhao. Tinygals:a programming model for event-driven embeddedsystems. In SAC ’03: Proceedings of the 2003 ACMsymposium on Applied computing, pages 698–704, NewYork, NY, USA, 2003. ACM.

[9] A. Dunkels, B. Gronvall, and T. Voigt. Contiki - alightweight and flexible operating system for tinynetworked sensors. In Proceedings of the First IEEEWorkshop on Embedded Networked Sensors(Emnets-I), Tampa, Florida, USA, Nov. 2004.

[10] J. Eriksson, A. Dunkels, N. Finne, F. Osterlind, andT. Voigt. Mspsim – an extensible simulator formsp430-equipped sensor boards. In Proceedings of theEuropean Conference on Wireless Sensor Networks(EWSN), Poster/Demo session, Delft, TheNetherlands, Jan. 2007.

[11] K.Walther and J.Nolte. Event-flow andsynchronization in single threaded systems. In FirstGI/ITG Workshop on Non-Functional Properties ofEmbedded Systems (NFPES), 2006.

[12] A. Lagemann and J. Nolte. Csharpsimplemodule:writing omnet++ modules with c# and mono. InSimutools ’08: Proceedings of the 1st internationalconference on Simulation tools and techniques forcommunications, networks and systems & workshops,pages 1–8, ICST, Brussels, Belgium, Belgium, 2008.ICST (Institute for Computer Sciences,Social-Informatics and TelecommunicationsEngineering).

[13] P. Levis, N. Lee, M. Welsh, and D. Culler. Tossim:accurate and scalable simulation of entire tinyosapplications. In SenSys ’03: Proceedings of the 1stinternational conference on Embedded networkedsensor systems, pages 126–137, New York, NY, USA,2003. ACM.

[14] P. Levis, S. Madden, J. Polastre, R. Szewczyk,K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh,E. Brewer, and D. Culler. Tinyos: An operatingsystem for sensor networks. Ambient Intelligence,pages 115–148, 2005.

[15] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, andT. Voigt. Cross-level simulation in cooja. InProceedings of the European Conference on WirelessSensor Networks (EWSN), Poster/Demo session,Delft, The Netherlands, Jan. 2007.

[16] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin,R. Govindan, and S. Shenker. Ght: a geographic hashtable for data-centric storage. In WSNA ’02:Proceedings of the 1st ACM international workshop onWireless sensor networks and applications, pages78–87, New York, NY, USA, 2002. ACM.

[17] T. Senner, R. Karnapke, A. Lagemann, and J. Nolte.A combined routing layer for wireless sensor networksand mobile ad-hoc networks. Sensor Technologies andApplications, International Conference on, 0:147–153,2008.

[18] B. L. Titzer, D. K. Lee, and J. Palsberg. Avrora:scalable sensor network simulation with precisetiming. In IPSN ’05: Proceedings of the 4th

international symposium on Information processing insensor networks, page 67, Piscataway, NJ, USA, 2005.IEEE Press.

[19] A. Varga. The omnet++ discrete event simulationsystem. In Proceedings of the European SimulationMulticonference (ESM’2001), Prague, Czech Republic,June 2001. IEEE.

[20] K. Walther and J. Nolte. A flexible schedulingframework for deeply embedded systems. In AINAW’07: Proceedings of the 21st International Conferenceon Advanced Information Networking and ApplicationsWorkshops, pages 784–791, Washington, DC, USA,2007. IEEE Computer Society.

[21] Y. Yao and J. Gehrke. The cougar approach toin-network query processing in sensor networks.SIGMOD Rec., 31(3):9–18, 2002.