SOS - A Dynamic operating system for Sensor Networks
Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, Mani Srivastava
{simonhan@cs, ram@ee, roy@cs, eddie@cs, mbs@ee}.ucla.edu
University of California, Los Angeles
1 INTRODUCTION
We present SOS, a new operating system for mote-class
sensor nodes that supports run-time reconfiguration of
the embedded software. The architecture of SOS consists
of dynamically-loaded modules and a statically compiled
kernel (ref. figure 1). An application in SOS is composed
of one or more modules interacting via asynchronous mes-
sages or function calls. Modules are position independent
binaries that implement a specific task or function. They
operate on their own state which is dynamically allocated
at run-time. Examples of modules are routing protocols,
sensor drivers and application programs etc.
SchedulerDynamic Mem. FunctionPointerControl Block
Timer Comm.Stack SerialFramer SensorManager
Clock SPI UART ADC I2C HardwareAbstractionLayer
DeviceDrivers
KernelServices
TreeRoutingModule LightSensorModuleSurgeApplicationModule DynamicallyLoadedModules
Static SOS Image
Figure 1—SOS Architecture - Function Layout
2 SOS ARCHITECTURE
This section describes the features of the SOS kernel
that enable dynamic module insertion.
2.1 Dynamic Module Linking
Modules interact with each other and with the SOS
kernel through message passing or direct function calls.
The SOS kernel provides a set of system services that are
accessible to the modules through a jump table in the pro-
gram memory. This mechanism is shown in detail in Fig-
ure 2. The SOS system services are accessible through a
ker * API. Modules can also invoke functions in another
modules. The SOS kernel provides a dynamic function
registration and subscription service. Modules can explic-
itly register functions that they provide with the SOS ker-
nel through the ker register fn system call. Through this
Program Memory Layout
Module #0
Module #N
Jump Table
SOS Kernel
ker_timer
ker_timer Re-directed CallDesired Call
1
2
1. Modules referto a fixed location into the jump table
2. Jump table refersto the function in the kernel.
Figure 2—Jump table layout and linking in SOS.
system call, the module provides the kernel with the rel-
ative address of the function implementation in the mod-
ule binary. The kernel stores information regarding the
dynamic functions in a function control block (FCB) data
structure. The process of subscribing to a function uses
the system call ker get handle. Upon receiving the han-
dle, a module can invoke direct function calls in the other
module. The dynamic linking of modules has many po-
tential failure modes which are explained in more detail
in [1].
2.2 Message Passing Scheduler
The SOS concurrency model comprises of a foreground
and a background context. The background context com-
prises of operations that can only be interrupted by events
occurring in the foreground context (for e.g. hardware
interrupts). Therefore, SOS uses cooperative scheduling
to share the processor between multiple executing mod-
ules. Modules are implemented as message handlers. The
message handlers execute in the background context. The
execution control is transferred to the operating system
upon the completion of the handler. The modules also
communicate with other modules by passing asynchronous
messages. SOS uses a simple FIFO scheduler with two
level priority. The messages are dispatched based upon
their priority. The various forms of interactions between
modules is shown in Figure 3.
1