Operating system for WSN

• OS for data centric & resource constraint WSN

• Category of sensor node
– Specialized sensing platform
– Generic specific platform
– High bandwidth sensing platform
– Gateway sensing platform
 Cont.,
• Issue in designing OS for wsn
– process management and scheduling
– memory management.
– kernel model.
– application program interface (API).
– code upgrade and reprogramming.
 cont.,
• Function of Sensor OS (SOS)
– compact and small in size
– provide real-time support,
– efficient resource management mechanisms
– support reliable and efficient code distribution
– support power management
– provide a generic programming interface
 Tiny OS
• free open source operating system.
– Designed for wireless sensor networks.
– written in nesC language.
– component based architecture.
– Provide concurrent data flows among hardware
devices
– uses an event-based model
 Cont.,
• TinyOS includes
– a tiny scheduler (FIFO mechanism)
– a set of components
• command handlers,
• event handlers,
• an encapsulated fixed-size frame, and
• group of tasks
 Cont.,
• Commands
– Cause actions to be initiated
• Events
– Small amount of processing to be done in a timely
Manner
– E.g. timer, ADC interrupts
– Notify that action has occurred.
– Can interrupt longer running tasks
 Cont.,
• Tasks
– Background Computation
– Not time critical
– Larger amount of processing.
– E.g. : computing the average of a set of readings in
an array
– Run to completion with respect to other tasks.
– Only need a single stack.
 Cont.,
• It defines three type of components:
– hardware abstractions
– synthetic hardware
– high-level software components
• Advantage
– very little code and a small amount of data.
– Events are propagated quickly
– efficient modularity.
 MATE

• byte-code interpreter
• program code is made up of capsules.
• Each capsule has 24 instructions,
• length of each instruction is 1 byte.
• Capsules contain type and version information,
• Four categories of Capsules
– message send,
– message receive,
– timer,
– and subroutine.
 Magnet OS
• single unified Java virtual machine
• distributed adaptive operating system
• provide application adaptation and energy
conservation
• Goals
– Adapt to the underlying resource
– Efficient energy conservation,
– provide general abstraction for the applications,
– scalable for large networks.
 Cont.,
• It includes static and dynamic components.
• static components
– rewrite the application in byte-code level
• Dynamic components
– application monitoring, object creation,
invocation, and migration.
• power-aware algorithms
– NetPull
– NetCenter
 MANTIS
• multithread embedded operating system
• uses standard C to implement the kernel and API.
• classical layered multithreaded structure
• layered structure
– multithreading,
– pre-emptive scheduling with time slicing,
– I/O synchronization
– network protocol stack,
– device drivers
 Cont.,
• RAM size is fixed
• thread scheduler - priority based & round
robin
• Four layers in network protocol stack
– application, network, MAC, and physical
• Advanced features,
– multimodal prototyping environment
– dynamic binary update-based reprogramming
– a remote shell and command server
 OSPM
• power management techniques.
• Factors to be considered
– Transitioning to a sleep state
– Waking up takes a finite amount of time.
– deeper the sleep state, the wake-up time will take
longer
 EYES OS
• event driven model and task mechanism
• FIFO-, priority-, or deadline-based
• approach (such as EDF)
• Sequence of operation

sleep
computation return a value
mode.
 Cont.,
• Function
– can be executed at boot time to upload software
module
– provide node localization information.
• Goal of code distribution mechanism
– update the code on the sensor node
– resilient in case of packet loss during update;
– use as few communications and local resources
– halt the application for a short period when updating.
 Cont.,
• procedure to distribute code
– initialization,
– code image building,
– verification
– loading.
 SenOS
• FSM based operating system
• Components
– Kernel
• state sequencer and an event queue
– state transition table
• information on state transition and the corresponding call
back functions
– Call back library of call functions.
• kernel and call back library are statically built
• state transition table can be reloaded or modified
at runtime
 EMERALDS
• written in C++ for embedded, real-time distributed systems
• runs on
– slow processors (15 to 25 MHz)
– limited memory (32 to 128 kB).
• supports
– multithreaded processes
– full memory protection,
• Scheduling
– combined earliest deadline first (EDF)
– rate-monotonic (RM) scheduler
• Device drivers are implemented at the user level,
• interrupt handling takes place at the kernel level.
• uses global variables to exchange information between
tasks
 Pic OS
• written in C for a microcontroller with limited
on-chip RAM (e.g., 4 kB).
• All tasks share the same global stack
• Follows FSM approach
• Supports multitasking