This document explores wireless sensor networks (WSNs), focusing on their architecture, applications, and the middleware and programming abstractions necessary for their operation. It discusses various programming models, specifically the Object State Model (OSM), Contiki, and TinyOS, highlighting their features and differences. The conclusion emphasizes the unique challenges and opportunities in the development of WSNs and points to potential future research directions.

1. Middle ware and Programming
Paradigms for WSN
Budwell Tamuka Masaiti
February 23, 2013
JNTUCEH(CSE Department)

3. Agenda
Wireless Sensor Networks :Introduction
Applications of WSNs
Main Issues in WSN
Middleware and Programming Abstractions for WSN
Goals for Middleware and Programming abstractions
OSM : Object State model (FSM)
Contiki: Event driven abstractions
TinyOs: Event driven abstractions
Conclusion

4. Wireless Sensor Networks :Introduction
A wireless sensor network (WSN) consists of
spatially distributed autonomous sensors to
monitor physical or environmental conditions,
such as temperature, sound, pressure, etc. and
to cooperatively pass their data through the
network to a main location.

5. Sensor Node
Transceiver
10Kbps-1Mbps 50-125 range
Memory
(3K-1Mb)
Embedded Processor
A 8bit 4-8Mhz
D
Sensor C
Transducer Battery

6. Popular Implementations
mica mica2 mica2dot micaz
telos telosb rene2 waspmote

7. WSN Architecture

8. Environment and Habitat Monitoring
http://fiji.eecs.harvard.edu/Volcano

9. Infrastructure Health Monitoring
 Monitoring bridge health

10. HealthCare Monitoring(BAN,PAN)

11. Smart Metering

12. WSN Middleware and
Programming Abstractions
 Middleware provides the software layer interfacing the
hardware and the application programs in an OS less
system
 Or the software layer between the OS and the
application programs.
 Programming abstractions refer to the interfaces and
data structures provided for a programming model and
language

13. Goals for WSN Middle and
Programming Abstractions
 Automatic node management
 Concurrency management
 Resource management
 Developer friendly abstractions

14. Object State Model
Oliver Kasten n Kay Romer
 A programming model and language for programming
sensor nodes, based on FSM
 Uses states and transitions such that the invocation of an
event is now a function of both the event and the
program state
 State attributes (infor sharing )

15. Object State Model(OSM)
 OSM goes beyond traditional event driven
programming and draws inspiration from FSM state
charts.
 OSM is a hybrid FSM implementation which tackles FSM
problems such as:
Memory Management(Global and local variables)
Event hierarchies
Manual flow control

16. OSM Main Features
 Uses Parallel State Machines
 Allows hierarchical composition of state(superstates)
 Explicit program state(not implied)
 State variables
 Event queues

17. Contiki
Background:
 Contiki – pioneering open source operating system for
sensor networks
 Development started in 2001
Got its name from Kon Tiki
Across the Atlantic with bare minimum
resources

18. Contiki Key Features
 Small memory footprint
 IP networking
 Hybrid threading model, protothreads
 Power profiling
-measure power consumption at network scale
 Network shell
- for easy command line interaction
 Designed for portability
 Dynamic loading

19. Contiki Communication Stack
 Two communication stacks
 uIP TCP/IP
 Rime low overhead
 Can run on top of each other

20. Contik :Event Driven Paradigm
 The Contiki kernel is event-based
 Invokes processes whenever something happens
Sensor events, processes starting,
 Process invocations must not block
 Protothreads provide sequential flow of control in
Contiki processes
 Protothreads extremely lightweight and stackless

21. Contik :Event Driven
 Event-driven vs multithreaded
 Event-driven requires less memory
 Multithreading requires per-thread stacks
 Threads require per-thread stack memory
 Events require one stack
 Protothreads like events require one stack for as many
as there are protothreads running

22. TinyOs:Event Driven
 An event driven OS specifically designed for WSN
 Completely non-blocking
 Programs are built out of softaware componets
 Tasks are non –preemptive and run in FIFO order
 Code is statically linked

23. TinyOS :Scheduling
 Two level scheduling: events and tasks
 Scheduler is simple FIFO
 A task cannot preempt another task
 Events preempt tasks (higher priority)

24.  Provides a specific Service
 Message Handling, Signal Processing
 Implemented in a Module(code)
 Wired up of other components in a Configuration

25. Comparison Contik n TinyOs

26. Conclusion
 Unique challenges and opportunities
 Expanding areas of applications
 Contik and TinyOs
 New research directions

27. references
 Geoff Werner-Allen, Konrad Lorincz, and Matt Welsh et al .Monitoring Volcanic
Activity at Reventador Volcano, Ecuador with a Wireless Sensor Network
 Oliver Kansten and Kay Romer. Beyond Event Handlers:Programming Wireless
Sensors with Attriunuted State machines
 A Dunkels,Bjorn Gronvall ,and Thiemo Voigt ,Contiki –a Lightweight and Flexible
Operating System for Tiny Networked Sensors”inEmNeTSI,Tampa USA 2005
 http://www.wsnmagazine.com/tinyos-tutorial/
 http://fiji.eecs.harvard.edu/Volcano
 https://www.sics.se/search/content/contiki
 http://www.tinyos.net