CS542 @ 2009

A Dynamic Operating System for Sensor Nodes (SOS)

Source: The 3rd International Conference on Mobile Systems, Applications, and Service (MobiSys 2005)Authors: Simon Han, Ram Kumar, Roy Shea, Eddie Kohler and Mani Srivastava

Presented by Yoonjae Jeong and Sunjun Kim

October 12, 2009

1

CS542 @ 2009

2

Contents

Introduction

System Architecture

PROS vs. CONS

PROS (including Evaluation)

Conclusion

October 12, 2009

CS542 @ 2009

3

IntroductionThe Characteristics

Low-power, poor performance device Ex) AtMega128 – 128Kb Flash, 4K SRAM, 10Mhz

In-situ update Need to be re-programmed during use Tradeoff between flexibility & Concise update

Robustness Need to deal with various failures

* failures examples: - function call during module update(or after module removal) - Memory curruptions

October 12, 2009

CS542 @ 2009

4

IntroductionBase Work

TinyOS – Application specific OS App, OS, and drivers are NesC components, are integrated in single static binary Statically analyze and optimized Supports full binary upgrades

Maté Domain specific bytecode interpreter on TinyOS Programs are small scripts containing VM instructions Better suited for application specific tuning

October 12, 2009

CS542 @ 2009

5

IntroductionSOS Design Goals

A general-purpose, application independent sensor OS In TinyOS and Maté, app and OS are tightly linked Towards traditional kernel space/user space model

Re-programming via binary modules Risk : lose safety provided by static analysis or dynamic interpreter

Design Challenges Resources-constrained embedded sensor nodes

October 12, 2009

CS542 @ 2009

6

System ArchitectureArchitecture Overview

October 12, 2009

Dynamic

Memory

Dynamic

Memory

Message

Scheduler

Message

Scheduler

Dynamic

Linker

Dynamic

Linker

Kernel

Components Sensor

Manager

Sensor

Manager

Messaging

I/O

Messaging

I/O

System

Timer

System

Timer

SOS

Services Radio* Radio* I2C I2C ADC* ADC* Device

Drivers

Tree Routing

Module

Tree Routing

Module

Data Collector

Application

Data Collector

Application

Photo-sensor

Module

Photo-sensor

Module

Dynamically

Loaded modules Static SOS Kernel

* - Drivers adapted from TinyOS for Mica2

CS542 @ 2009

7

System ArchitectureSOS Kernel

Kernel Components Dynamic memory Dynamic Linker Message Scheduler

SOS Services Sensor Manager System Timer Messaging I/O

Device driversOctober 12, 2009

CS542 @ 2009

8

System ArchitectureSOS Module

Modules implement specific function or task

Modules can be dynamically loaded and unloaded

Position independent binary

Modules can communicate with other modules or kernel with messaging or dynamic linking

October 12, 2009

CS542 @ 2009

9

System ArchitectureInter-module Communication

Dynamic Linking Synchronous

Should return promptly

Message Passing Asynchronous

Long running operations

October 12, 2009

Module FunctionPointer Table

DynamicLinking

Module AModule A Module BModule BMessagePassing

MessageBuffer

Module AModule A Module BModule B

CS542 @ 2009

10

System ArchitectureInter-module Communication ( detail )

Dynamic Linking Each module publishes their

function address

FCB(Function Control Block) in kernel stores published function information

FCB subscribes functions to other modules

Message Passing Each message is stored in priority

message queue

No dynamic priority assign/change:- programmer should set the priority when they send a message

Messages can carry parameters, or more complex data between modules

October 12, 2009

CS542 @ 2009

11

System ArchitectureModule-Kernel Communication

October 12, 2009

Kernel services available as system calls Jump table redirects system calls to handlers Update kernel independent of modules System Call Overhead - 12 clock cycles

Data Collector ModuleData Collector Module

SystemJump table

PriorityScheduler

SOSKernel

Hardware

System Call

HW specific API Interrupt Service

System Messages

CS542 @ 2009

12

System ArchitectureSafety Concerns

Dynamic Linking Run-time type checking

Message passing Watchdog support High priority messaging (by priority queue)

Dynamic Memory Allocation Memory overflow detection Owner tagging Garbage Collection

October 12, 2009

CS542 @ 2009

13

PROS vs. CONSBrief Analysis (1/2)

PROS Well motivated and constructed paper in term of system architecture. SOS provides a framework for reusable binary modular architecture in sensor

network operation system. SOS shows not-bad performance in term of CPU overhead, code size and energy

consumption, while their framework provides more functionalities.

October 12, 2009

CS542 @ 2009

14

PROS vs. CONSBrief Analysis (2/2)

CONS Authors did not justify why dynamic modules are important in sensor network

operating system well. We needs actually useful application scenarios for sensor network

environments. There is no evaluation for the safety. It still contains the limitation of event-driven system.

Long-run tasks can reduce the overall system performance.

October 12, 2009

CS542 @ 2009

15

PROS (including Evaluation)Contribution of This Paper Framework for binary modular re-programming

Dynamic linking Message passing Dynamic memory

Inexpensive safety mechanisms for an embedded OS Type safe linking Monitored memory allocation Garbage collecting scheduler and error stub Watchdog mechanism

General purpose OS semantics on sensor nodesOctober 12, 2009

What about Performance?

CS542 @ 2009

16

PROS Evaluation Design Goal of SOS

Provide general purpose OS semantics Low resource utilization

Hypothesis Performance no worse TinyOS Update cost closer to Maté

Experiment Setup Surge data collection and tree routing on 3 hop network Low duty cycle application Mica2 motes: AVR 8-bit microcontroller

October 12, 2009

CS542 @ 2009

17

PROSEvaluation: Macro Benchmarks

Application performance is nearly identical for TinyOS, SOS and Maté

October 12, 2009

Different Boot Routine Different Protocolsfor Code Dissemination

Fluctuating Wireless Link Quality & Different Code Update Protocols

CS542 @ 2009

18

PROSEvaluation: CPU Overhead

CPU Active Time - Metric to measure OS overhead Measured by profiling Surge for 1 min on real nodes Examining the CPU active tie when running Surge on each of SOS, TinyOS, and

Maté.

SOS has 1% overhead relative to TinyOS Surge has minimal application level processing (“worst” case OS overhead)

October 12, 2009

TinyOS SOS Maté

Percent Active Time 4.58 ± 0.02 % 4.64 ± 0.08 % 5.13 ± 0.02 %

CS542 @ 2009

19

PROSEvaluation: Code Updates

October 12, 2009

CS542 @ 2009

20

PROSPossible Applications

October 12, 2009

Dynamically installing new behavior modules on ragobot

Ragobot - Mobile Sensor Node Building Automation

Remote operation and managementof the sensor network infrastructure

Mobile agent applications and a lot more …

CS542 @ 2009

21

Conclusion

SOS enables dynamic binary modular upgrades

Design choices minimize resource utilization

Run-time checks for safe code execution

Ported to AVR, ARM, TI MS

October 12, 2009