A Framework for Modeling, Simulation and Automatic Code ...

A Framework for Modeling, Simulation and Automatic Code Generation of Sensor Network Applications Mohammad Mostafizur Rahman Mozumdar∗ [email protected] Laura Vanzago† [email protected] ∗ Politecnico

di Torino Torino, Italy

Francesco Gregoretti∗ [email protected]

Luciano Lavagno∗ [email protected]

Stefano Olivieri‡ [email protected]

† STMicroelectronics

‡ MathWorks

Milano, Italy

Torino, Italy

Abstract—Showing functional correctness by simulation before implementation, and preserving it by automated code generation, is extremely useful to reduce the development time for an embedded application. This is even more true for wireless sensor networks, since their nodes often provide very rudimentary debugging facilities, and sufficiently large networks for realistic analysis may be expensive to deploy. While this approach, also known as model-based design, is becoming quite standard for several domains that have similar constraints as wireless sensor networks, such as automotive electronics, there is a lack of tools for this purpose in the WSN world. In order to fill this gap, in this paper we present a framework (based on Simulink, Stateflow and Embedded Coder) in which an engineer can create sensor network components (both at the application and at the protocol level) that can be used as building blocks to model, simulate and automatically generate code for different underlying platforms and operating systems.

I. I NTRODUCTION Wireless Sensor Networks (WSN) have become a hot research topic and show much promise to become a driver of current and future microelectronic technologies. Currently, researchers are developing various types of software applications at different stack levels for WSNs. Implementation of these applications is usually done using as an underlying platform one of several operating systems, such as TinyOS [14], MANTIS [15], Contiki [16], FreeRTOS [17] etc. Functional verification of these applications is challenging, because most of the available sensor nodes (also called “motes”) on the market (such as MicaZ [18], TelosB [18], Tmote Sky [19]) only provide a few on-board blinking leds as debug aids. This makes code development on the actual platform virtually impossible. Even if better debugging aids were provided (similar to those provided by a state-of-theart in-circuit emulator), there would still be the need of a simulator to model networks with many nodes. The available functional analysis packages, such as TOSSIM [5] for debugging of TinyOS application, OmNet [20] and NS [21], fall into two main categories. One is very platform- and OS-specific (such as TOSSIM), and provides

essentially a binary API to model the OS and the motes, with limited facilities for re-using existing channel models, tracing, collecting statistics and so on. The other are generic network simulators (such as OmNet, NS, etc.), sometimes enhanced with models tailored to the radios and channels used by WSNs. Both have significant drawbacks when it comes to complex application development. The first group makes it virtually impossible to port an application to a different platform (e.g. from TinyOS to Mantis or to a ZigBee compliant platform). The second group still leaves a lot of detailed platform-dependent code to be developed and debugged. Integrated use of a network simulator followed by a platform simulator is the most commonly used path, but still requires one to port code between a number of environments. Moreover, in case a bug is found at the end, one has to resort to led-based debugging, which is extremely time-consuming. In order to solve these problems, we wanted to be able to model the application using high level abstractions, and simulate it using configurable and realistic topologies for the network itself. Then we wanted to be able to automatically generate code for several target operating systems. In this paper we present a framework for modeling, simulation and automatic code generation of sensor network applications based on MathWorks [9] tools. In our framework, applications can be modeled using Stateflow state charts [12] (and Simulink block diagrams [11], even though StateCharts were the best tool for the application we considered as case study). Then the application developer can configure the connectivity of the sensor network nodes and can perform behavioral simulation and functional verification of the application. After modeling and simulation, this framework can generate the complete application code for several target operating systems from the simulated model. The application developer can thus use the broad variety of debugging and analysis tools provided by MathWorks, such as animated state chart displays, scopes, plots, as well as exploit a large number of available pre-designed Simulink

978-1-4244-1777-3/08/$25.00 © IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE SECON 2008 proceedings.

515

experimental results and in Section 6 we conclude the paper.

Fig. 1.

A complete view of the framework

blocks. To the best of our knowledge, this is the first time that a framework of this sort has been developed and tested. A complete view of the whole framework is depicted in figure 1. In the following, we use as example target platforms TinyOS and MANTIS, since these provide very different programming models and abstractions (non-preemptive scheduler with splitphase coding versus multi-threaded kernel). Hence they are maximally different representatives of the programming platforms used by WSN developers. The closest example, described in [1], is a graphical development and simulation environment for TinyOS-based applications called Viptos. Viptos provides graphical development and interrupt-level simulation of actual TinyOS programs, with packet-level simulation of the network. It also allows the developer to use other models of computation available in Ptolemy II [22] for modeling various parts of the system. To model an algorithm using Viptos, the users are bound to code it for TinyOS, which implies that the user should have sufficient knowledge of TinyOS. In our framework, the users can model the application by using Stateflow and need not to have any knowledge of TinyOS or MANTIS. In short, our framework provides more freedom by decoupling the application from the platform and also supports several platforms for code generation. In [2], the authors describe a visual development framework for multi-platform wireless sensor networks, which is capable of generating application code for TinyOS and Yet Another Tiny Operating System [4] (Yatos). This tool supports only code generation of the developed model for the WISDOM [2] framework and it does not support functional verification of the designed model. Here also the model development is biased to TinyOS and Yatos, since these two target platforms share the same component based programming style. The rest of the paper is organized as follows: In Section 2, we present the methodology and the framework. In Section 3 we describe an example of modeling and simulation of a WSN application. We present multi-platform automatic code generation process in Section 4, whereas in Section 5 we describe an example of automatic code generation with

Fig. 2. Framework for modeling, simulation and code generation of WSN application

II. M ETHODOLOGY The complete framework for modeling, simulation and automatic code generation is depicted in figure 2. The WSN algorithm (application, middleware or device drivers) will be at first modeled by using Simulink and Stateflow blocks. We have designed blocks that specifically help WSN modeling such as the sensor node and communication medium described later. These are completely parameterized and can be used for model development like usual Simulink blocks. Sensor node blocks are connected to the communication medium block which provides a mechanism for the application developer to define the connectivity between the nodes in sensor network. The communication medium block is implemented in C, so it can be modified to reuse any existing channel and connectivity models. The sensor node contains mainly a timing generator, a random number generator, and a parameterized Stateflow block which actually implements the algorithm running inside each single node (shown in the figure 3). The Stateflow block is a library object and each sensor node contains an instance of it. Therefore, every node of the framework is running an independent copy of same algorithm. It is of course also possible to model sensor networks having different algorithms running in different nodes. In that case, one needs to create a small Stateflow library and instantiate objects from it as needed. To model a new sensor network application based on this framework, the application developer only needs to modify the template algorithm implementation (Stateflow-library object) and set the connectivity of the nodes in the communication medium block. Then simulation can be started and statistical data can be collected using animated

516

Fig. 3.

A simple simulation framework

state charts, scopes and displays to perform functional analysis of the algorithm. The algorithm implementation can be refined if the analysis of the results suggest to do so. Eventually the developer will get a refined model which represents the desired behavior. The next step will be to generate code automatically for TinyOS or MANTIS from the Stateflow representation of the algorithm, using a customization of Embedded Coder [13] which can generate ANSI C codes for Simulink and Stateflow blocks. In order to adapt the generated ANSI C code to the target operating system, Target Language Compiler [10] (TLC) scripts are used. TLC provides mechanisms by which one can generate platform specific code by taking sections (such as includes, defines, functions, etc) from ANSI C code and also by adding custom code for the target platform. In order to ease platform independent development we provide a set of generic library functions which can be used from Stateflow to access platform specific operating system functionalities (such as led toggle, led on, led off, sendPacket, receivePacket). From the Stateflow implementation perspective, the application developer does not have to think about the actual implementation of these generic functions in TinyOS or in MANTIS, since they have been implemented in the TLC library and can

be targeted to any operating system. By using TLC scripts (which are also called Block Target Files and System Target Files), the developer now can generate automatically a TinyOS application (composed of .nc, .h and makefiles) or a MANTIS application (composed of .c, .h and makefiles), and then can compile and execute these applications for the target platform without any modification.

Fig. 4.

Connectivity matrix for the 16 nodes sensor network

III. A S IMPLE S IMULATION F RAMEWORK We will now demonstrate a simple sensor network model (shown in figure 3) that has been designed based on our frame-

517

work components (sensor node, communication medium). In this model, we consider sixteen sensor nodes, all connected to the communication medium block to form a sensor network. At the top level, the model has two major components:A. Communication Medium Model This block contains the medium logic and also models the connectivity between nodes. The logic of the communication medium block is implemented by a C based S-Function [11], which contains a (parameterized) 16x16 matrix to define the connectivity of the nodes in the sensor network (shown in the figure 4). For example in figure 4, node 1 (row 1) is connected to nodes 3, 10, 12 and 15. Packets are the input and output object of the communication medium block where incoming packets from the nodes will be at first processed by the medium logic and then fed to the appropriate nodes based on the connectivity setup of the sensor network. In this block, we have modeled a simple medium logic which at any point of time computes the input (packet) of a node as the summation of outputs (packets) of nodes connected to it. B. Node Block This block contains sixteen nodes as shown in figure 3. The individual node model is fully parameterized and contains mainly a timer generator, a random number generator and a Stateflow algorithm block. The timer is used for generating time events for the algorithm running inside the Stateflow block. Incoming and outgoing packets of nodes consist of data and signal. The data field contains the payload of the packet and signal (which triggers the Stateflow block) generates a packet arrival event which is processed by the Stateflow algorithm inside. The application developer now can perform functional analysis of the algorithm and modify it based on execution data provided by Simulink and Stateflow. In this example, we have shown a framework of sixteen nodes but the user can easily design a network with a larger number of nodes by slightly modifying the sensor node and communication medium blocks. IV. M ULTI -P LATFORM AUTOMATIC C ODE G ENERATION After functional analysis of the algorithm, the next step is to generate application code automatically for the target operating systems. In this section, at first we present a short description of the target operating systems (TinyOS and MANTIS) and then describe the code generation phases and mechanisms. A. TinyOS The programming model of TinyOS is based on components. In TinyOS, a conceptual entity is represented by two types of components, Module and Configuration. A component implements interfaces. The interface declares signature of commands and events which must be implemented by the provider and user of the interface respectively. Events are the software abstractions of hardware events such as reception of packet, completion of sensor sampling, etc. On the other hand commands are used to trigger an operation such as to start

sensor reading or to start the radio for receiving or transmitting etc. TinyOS uses a split-phase mechanism, meaning that when a program calls a command, it returns immediately, and the command issues a callback event when it completes. This approach is called split-phase because it splits invocation and completion into two separate phases of execution [6]. The scheduler of TinyOS is based on an event-driven paradigm where events have the highest priority, run to completion (i.e. interrupts cannot be nested) and can preempt and schedule tasks. Tasks contain the main computation of an application. TinyOS applications are written in nesC [7] which is an extension of the C language. B. MANTIS MANTIS is a light-weight multi-threaded operating system that is capable of multi-tasking on energy constrained distributed sensor networks. The scheduler of MANTIS supports thread preemption which allows the operating system to switch between active threads without waiting. So the responsiveness of the operating system to critical events can be faster than in TinyOS. The scheduler of MANTIS is priority-based with round robin [8]. The kernel ensures that all low priority threads execute after the higher priority threads. When there is no thread scheduled for execution, the system moves to sleep mode by executing the idle-thread. Kernel and APIs of MANTIS are written in standard C. C. Automatic Code Generation The computational bodies of both MANTIS threads and tasks and commands of TinyOS are essentially written in C. In MANTIS, integration is straight forward, since the output (ANSI C) of Embedded Coder can be used directly as a user thread. In TinyOS, programs are composed of high level abstractions such as components, modules and interfaces which are absent in ANSI C. But the bodies of these abstractions are (almost) written in C. Therefore, we need a Code Converter which takes C code as an input and splits the code into sections (includes, defines, functions, etc.) and uses these sections to generate nesC code. TLC scripts can be used as a Code Converter to construct a complete application for MANTIS or TinyOS. The main purposes of the TLC scripts are :1) Generate custom main and initialization code for the target operating system: Since TinyOS and MANTIS use different programming languages (ANSI C and nesC), the main and initialization code of these platforms are also different. MANTIS is thread based so it requires to declare a start() function from where it can spawn the other threads. A skeleton of automatically generated code in MANTIS for WSN application is shown in Example 1, where at the top, it declares all operating system includes and afterwards in the start() function it creates a new thread which is indeed the application thread. In TinyOS, the main application module must use the Boot interface and implement the event Boot.booted() which is the entry point of the application. In the top level configuration component, the Boot interface of the application module is

518

wired to the Boot interface of the MainC component (which actually provides the Boot interface). A skeleton of automatically generated code in TinyOS for WSN application is shown in Example 2. Example 1: Skeleton of the automatically generated code for WSN application in MANTIS #include .... // All required system includes .... void state_machine() {.. Algorithm of the WSN application shown in figure 6 .. void clock_event(void) void incoming_pkt_event(void)

}

{ incoming_event = event_CLK; state_machine(); } { incoming_event = event_PKT; state_machine(); }

void receivePacket(uint16_t receivingTimeStamp) // Called from state machine { // to receive packet for specific time frame .... recv_pkt = com_recv_timed(IFACE_RADIO,receivingTimeStamp); if (recv_pkt!= NULL) { .... incoming_pkt_event(); ... } // Passing PKT event to state machine } void sendPacket( uint8_t *packet_payload ) // Called from state machine { // to send a packet // construct the packet com_send(IFACE_RADIO, &send_pkt); // Sending packet } void led_toggle (uint8_t ledN) // Called from state machine toggle Leds { mos_led_toggle(ledN); } void application_thread() { while(1) { mos_thread_sleep(10); clock_event(); } }

// Implementation of virtual CLK // Passing CLK event to state machine

The initialization and other basic structural code is generated by the TLC scripts depending on the target operating system. 2) Integrate the ANSI C code of the algorithm to the target operating System: Embedded Coder generates ANSI C code (in .c and .h files) for the Stateflow algorithm. Using TLC scripts, this code is split into sections (such as includes, defines, functions, etc) and then these pieces of code are used to construct the application in TinyOS (.nc, .h files) and in MANTIS (.c and .h files). In MANTIS, the algorithm code is put into a thread whereas in TinyOS it is triggered by a timer event (shown in Example 1 and 2). 3) Substitute generic function calls by their platform specific implementation: The model of sensor network algorithm in Stateflow may use operating system function calls such as sendPacket(args), receivePacket(args), led on(args), led off(args), led toggle(args). Depending on the target operating system, the TLC scripts add an appropriate implementation of these functions in the final generated application code. 4) Generate platform specific makefiles: TLC scripts finally generate the required makefiles for the target platform.

void start (void) { // Spawning of new thread mos_thread_new(application_thread, 128, PRIORITY_NORMAL); }

Example 2: Skeleton of the automatically generated code for WSN application in TinyOS module simpleAppM { uses interface Boot; // It boots the application uses interface Timer as CLKtimer; // Provides timing functions // uses all required interfaces } implementation{ event void Boot.booted () { call CLKtimer.startPeriodic(10);} task void state_Machine() {.. Algorithm of the WSN application shown in figure 6 .. void clock_event() void incoming_pkt_event()

}

{incoming_event = event_CLK; post state_Machine();} {incoming_event = event_PKT; post state_Machine();}

event void CLKtimer.fired() { clock_event(); } // Passing CLK event to State Machine void receivePacket(uint16_t receivingTimeStamp){ call LPL.setLocalDutyCycle(...); // Tune the radio in receive mode call Radio.start(); // Start the radio call Timer1.startOneShot(receivingTimeStamp); // 30ms for packet receiving } event void Timer1.fired() // Receiving time expires (30 ms) { call Radio.stop(); } // Stop the radio event message_t* Receive.receive(...) { incoming_pkt_event(); } // Passing PKT event to State Machine void sendPacket( uint8_t* packet_payload ){ // Copy the sending packet data call LPL.setLocalDutyCycle(...); // Tune the radio in transmit mode call Radio.start(); } event void Radio.startDone(...) { if (need_to_send_packet) { // Construct the packet call AMSend.send(..)} } event void AMSend.sendDone(...) { call Radio.stop(); }

// Radio is turned on

// Send the packet

// Packet sending complete // Stop the radio

void led_toggle(uint8_t ledN){ // Toggling the leds switch (ledN) { case 0: call Leds.led0Toggle(); break; ... } } }

Fig. 5.

Code generation in TinyOS and MANTIS

Figure 5 depicts a high level view of the overall multiplatform code generation process. A Code Converter (TLC scripts) converts the incoming ANSI C code to either TinyOS or in MANTIS, adds platform specific custom code and also generates makefiles to ease target platform code compilation. One of the crucial points of multi-platform code generation is to provide generic functions at the model level (in StateChart) for the basic operating system calls such as to turn on/off the leds or to send and receive packets. To demonstrate how these generic functions have been implemented by TLC scripts, let us consider a simple example, which is to turn on the first led (led 0) of a sensor node. In TinyOS, the code is Call Leds.led0On() and in MANTIS it is mos led on(0). The corresponding function call in Stateflow is simply led on(0) (as shown in figure 5). Therefore, the application developer does not have to think about the details of platform implementation but may concentrate on algorithm development.

519


##$
(




 
 
 
  
 
 
   
 +,##
 -#..#
 -# )
 // #
 //*

)*


1 )
 
 
  
$ 
*




## $$
(
 ) *

  )
 
 
  
$ 
 *


 # )#
$ 
 ###
 ###

(
" 
1#*


  )
$ 
 *

 
-0

  
     !
" 
  

   )  
'' 
$ 
%*  #  ###
"&     ###
!!&   # ###
' 

 ##
$ ##
$  ##
$%

Fig. 6.


##
!!&  

A simple WSN application for multi-platform code generation TABLE I C ODE COMPARISION IN T INYOS AND MANTIS

OS

Empty App.(Only OS) (Bytes)

MANTIS

15650

TinyOS

1558

Applications Simple App.

Manually Written (Bytes) 16364

Automatically Generated (Bytes) 16562

Increment of code size (Using Equation 1 ) 27.7%

EERINA Simple App.

16706 9826

17018 10168

29.5% 4.2%

EERINA

12892

13484

5.2%

V. A S IMPLE E XAMPLE OF M ULTI - PLATFORM C ODE G ENERATION We will now use a simple WSN application to illustrate the multi-platform code generation scenario. The application transmits and receives packets randomly until it receives six packets, then it stops communications and turns on all three leds of the node. The Stateflow modeling of the application is shown in figure 6. This simple application contains all the ingredients of sensor network applications such as transmitting, receiving, processing of packets and sleeping. PKT and CLK are external inputs of the algorithm. The PKT event is generated after receiving a packet and the CLK event is generated when the periodic timer expires. Here the periodic timer is set to generate a CLK event every 10 milliseconds. The application starts by initialization of next receiving (tNextRX) and transmitting (tNextTX) timestamps. To set these timestamps, it calls a library function getRandTimeStamp which is implemented by TLC scripts. Then it sets the number of received packets to zero. At the next CLK event, the application moves to the Sleep state from the Init state. In the Sleep state, the receiving and transmitting timestamps will be decremented by one at every occurrence of the CLK event. At the expiration of the transmit timestamp, the algorithm will make a transition to the Transmit Pkt state and toggle led 1.

In this state, it sets the first byte of the payload to 1 and sends the packet by calling library function sendPacket. After transmitting the packet, the application makes a transition to the Sleep state, sets the next transmission timestamp and toggles led 1. In the same way, when the receiving timestamp expires, the algorithm makes a transition from the Sleep state to Receive Pkt state and it calls the receivePacket function to configure the radio in receiving mode and also specifies the duration of receiving mode (here it is 30 milliseconds). In the Receive Pkt state, the algorithm waits for the PKT and CLK events. After receiving a PKT event, it calls library function getPktData which copies the packet’s data field into a local variable (payload). Now the algorithm calls a local function processData where it checks the first byte of the packet data and if it is equal to 1, then it increases the received packet counter and toggles led 2 to give us a visual indication of successful reception of a packet. After expiration of the receiving time slot, the algorithm makes a transition to the Sleep state from the Receive Pkt state. While making the transition it sets the next receiving timestamp and toggles led 0. In this manner, the algorithm makes transitions between Sleep, Transmit Pkt and Receive Pkt states until in the Sleep state it notices that the number of received packets is greater than five. Then it makes the final transition to the Done state

520

where it turns on all three leds and stop all communications to the external world. Increment

=

AG MW EA

= = =

((AG − EA) − (M W − EA)) ∗ 100 M W − EA Automatically Generated M anually W ritten Empty Application

(1)

      

 
 

more significant in MANTIS than in TinyOS. It is because MANTIS pre-loads most of the libraries by default and it has a more complex scheduler than TinyOS, while TinyOS loads all required libraries only on demand. The advantage of using our framework, as opposed to manual writing of WSN application code, is that after the framework succeeded generating correct target code for the simple application described above, it took us only 3-4 hours to get the EERINA algorithm running as well. In other words, with EERINA we could truly concentrate on spending the time modeling and simulating at the functional level, and then code generation, compilation and execution on two very different platforms was automated and extremely fast.

  





  



 


     



Fig. 7.

 

MANTIS code comparison

VI. S UMMARY AND O UTLOOK We described an extensible framework for modeling, simulation and multi-platform code generation of sensor network algorithms based on MathWorks tools. We developed parameterized blocks for the sensor node and communication medium to ease the modeling and simulation. We provided TLC scripts to generate the complete application code in TinyOS and MANTIS. The reason for choosing the MathWorks tools over, for example, TOSSIM, NS, OmNet, is that they are well known and already provide rich libraries for digital signal processing and control algorithm behavior simulation. A possible extension of this work will be to provide more building blocks for specific sensors and transceivers, and adding more models of the target operating system API for the code generation phase. R EFERENCES

Fig. 8.

TinyOS code comparison

Example 1 and 2, depict the skeleton of the automatically generated code in MANTIS and TinyOS respectively for the simple application described above. Table 1, figure 7 and figure 8 depict the code size comparison in MANTIS and TinyOS for the simple application and also for the Energy Efficient and Reliable In-Network Aggregation (EERINA) algorithm [3] for clustered sensor networks. EERINA is an aggregation algorithm to elect the cluster leader in a sensor network. It is a good example of a ‘typical’ algorithm used for drivers, middleware and application in WSN. In order to compare code sizes between manually written and automatically generated code, we also created an empty Stateflow block to take into account the size of the OS itself. In table 1, the increment of code size is evaluated by using equation 1. In the equation, (AG-EA) represents the size of automatically generated code and (MW-EA) represents the size of manually written code. The increment of code size due to automatic code generation versus manual code writing is

[1] Elaine Cheong, Edward A. Lee and Yang Zhao, Viptos: A graphical development and simulation environment for tinyOS-based wireless sensor networks. In Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, SenSys, page 302, 2005 [2] Luiz F. M. Vieira, Breno A. D. Vitorino, Marcos A. M. Vieira, Diogenes C. Silva, Antnio O. Fernandes Antonio Alfredo F. Loureiro, WISDOM: A Visual Development Framework for Multi-platform Wireless Sensor Networks.In Proceedings of the 10th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA , 2005, Catania, Italy. [3] L. Necchi, A. Bonivento, L. Lavagno, L. Vanzago, A. SangiovanniVincentelli, EERINA: an Energy Efficient and Reliable In-Network Aggregation for Clustered Wireless Sensor Networks.In Proceedings of the Wireless Communications and Networking Conference, WCNC, pages 3364-3369, 2007 [4] V. Almeida, L. Vieira, B. Vitorino, M. Vieira, A. Fernandes, D. Silva Jr. and C. Coelho Jr.,Microkernel for Nodes of Wireless Sensor Networks, 3rd Student Forum on Microelectronics, Chip in Sampa SFM 2003. [5] Philip Levis, Nelson Lee, Matt Welsh and David E. Culler, TOSSIM: accurate and scalable simulation of entire tinyOS applications. In Proceedings of the 1st International Conference on Embedded Networked Sensor Systems , SenSys, pages 126-137, 2003 [6] Philip Levis, Samuel Madden, David Gay, Joseph Polastre, Robert Szewczyk, Alec Woo, Eric A. Brewer and David E. Culler, The Emergence of Networking Abstractions and Techniques in TinyOS. In the Proceedings of 1st Symposium on Networked Systems Design and Implementation, NSDI, pages 1-14, 2004 [7] David Gay, Philip Levis, J. Robert von Behren, Matt Welsh, Eric A. Brewer and David E. Culler, The nesC language: A holistic approach to networked embedded systems. In the Proceedings of the ACM SIGPLAN 2003 Conference on Programming Language Design and Implementation,PLDI, pages 1-11, 2003

521

[8] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker, Charles Gruenwald, Adam Torgerson and Richard Han. MANTIS OS: An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms. In the journal of MONET , pages 563579,2005 [9] The MathWorks - MATLAB and Simulink for Technical Computing. www.mathworks.com/ [10] Real-Time Workshop - Generate C code from Simulink models and MATLAB code. http://www.mathworks.com/products/rtw/ [11] Simulink Simulation and Model-Based Design. http://www.mathworks.com/products/simulink/ [12] Stateflow - Design and simulate state machines and control logic. http://www.mathworks.com/products/stateflow/ [13] The MathWorks - Real-Time Workshop Embedded Coder Generate C and C++ code optimized for embedded systems. http://www.mathworks.com/products/rtwembedded/ [14] TinyOS Community Forum, An open-source OS for the networked sensor regime. http://www.tinyos.net/ [15] MANTIS, MultimodAl NeTwork of In-situ Sensors. http://mantis.cs.colorado.edu/index.php/tiki-index.php [16] Contiki, A Dynamic Operating System for Memory-Constrained Networked Embedded Systems. http://www.sics.se/contiki/ [17] FreeRTOS, A FREE open source RTOS for small embedded real time systems. http://www.freertos.org/PC/ [18] Crossbow Technology : Inertial Systems. http://www.xbow.com [19] Sentilla, Pervasive Computing Solutions. www.sentilla.com/ [20] OMNeT++ Community Site. http://www.omnetpp.org/ [21] The Network Simulator - ns-2. http://www.isi.edu/nsnam/ns/ [22] Ptolemy II: Heterogeneous modeling and design. http://ptolemy.berkeley.edu/ptolemyII/

522