SensorWare: A Framework for Efficient and Programmable Sensor Networks

1

SensorWare:A Framework for Efficient and Programmable Sensor Networks

Athanassios Boulis, Chih-Chieh Han, Mani B. Srivastava

EE Dept. UCLA

Presented by Jia Xu

CS Dept. UVa

Nov 11, 2003

2

Outline

Contributions Introduction

Problem SensorWare’s approach to address this problem

SensorWare Details Language Run-time Environment Portability & Expandability Addressing & Routing

Code Examples Implementation & Evaluation Comparison & Related work Conclusion

3

Roadmap

ContributionsIntroductionSensorWare DetailsCode ExamplesImplementation & EvaluationComparison & Related workConclusion

4

Contributions

A script environment for dynamic programming WSNs in a proactive and efficient way

Code mobility through script replication & migration

Good support for portability and extensibility Admission Control & Policing of Resource

Usage to make scripts stay under their resource contract

5

Roadmap


6

Wireless Ad-hoc Sensor Network

7

Programming Paradigms for WSNs

How to write/debug/test/reuse programs on WSNs?

Challenges: Constraints (energy, computation, storage, bandwidth) Individuals are trivial, programming as an aggregate The aggregate is often a changing set Dynamically deploy algorithms Meet real-time, security, reliability requirements

How does one dynamically deploy different algorithms into the network?

8

Workarounds

Hard-coded algorithms tunable through the transmission of parameters Not applicable to the wide variety of possible apps.

Download executable images into the nodes Nodes could be physically unreachable or reachable at

a very high cost.

Transfer the executable images into nodes Energy inefficient (communication cost) Cannot allow the sharing of the WSN by multiple users.

9

Basic questions

How to express the algorithms?How to dynamically deploy them?

SensorWare employs lightweight and mobile control scripts that are autonomously populated in sensor nodes after a triggering user injection.

10

Scriptable Environment

Define:Basic Building Blocks

Basic commands

Examples :

Send packet to the radio

Get data from sensing device

11


How do you bind many basic commands into an algorithm?

You need a language core!(glue commands)

Examples:

Flow control

Variable support

Expression evaluation

12


Send packet

Abstracted high-level descriptionof an algorithm

Low-level tasksperformed by our system

• Access radio

• Find route

• Check energy

• Queue packet

13

Make Scripts MobileScript can

populate/migrate

Language + Run-time Environment = SensorWare

Scripts move NOT due to explicit user

instructions, but due to node’s state

and algorithmic instructions

14

Architecture

Sensor node 2

SensorWare

OS

Hardware

HW abstractionlayer

Scripts Apps,Services

CodemigrationSensorWare

OS

Hardware

HW abstractionlayer

ScriptsApps,Services

Message exchanging

Sensor node 1

User can inject script

15

SensorWare vs Mate

They share the same goal: make a WSN dynamically programmable in an efficient manner

Both are two-level abstractionBoth support code mobility

Question: what are the similarities so far?

16

SensorWare vs Mate

Mate is for motes, e.g., 128KB PM, 4KB RAM; while SensorWare targets richer platforms like 1MB PM, 128K RAM

Mate is on TinyOS; SensorWare is on Linux Mate is a stack-based architecture with ultra-compact

instruction set; SensorWare builds scripts based on basic blocks

No concurrent apps in one mote; SensorWare supports multi-tasking

SensorWare’s scripts are more powerful than Mate’s capsules

Question: what are the differences so far?

17

Roadmap


18

Language

The glue coreThe basic script

interpreter (stripped-down Tcl)

Radio API

Sensor 1 API

Mobility APIwait command

id command

Timer API

Extensions to the core

GPS APISensor 2 API...

...

Optional modules

19

Script Mobility API

spawn <node_list> <script> {variable_name}* replicate < node_list > {variable_name}* migrate < node_list > {variable_name}*

< node_list > : destination node addresses

variable_name : a variable name to be passed along with its value to the new script.

An advantage over Mate: it supports both replicateand migrate

There is a question Mate doesn’t answer: how the nodes cooperate in code population and how does this process end?

20

Replicate

First, the parent is assumed to already have the code for the script

Second, send out “intention to replicate” Third, if the same script already exists, choose:

Not to transfer the code Initiate a second script of the same type “add-user” for this script if supporting multi-user

In addition, you need to explicitly specify the replication node list

If you leave node list empty, what happens? Flooding? When does it ends?

21

Event-based Programming

Event handler a

Event handler b

Initialization

code Zzz

Exit code

a?

b?c? wait for event a or b or c

Zzza?

b?

Zzza?

c?

Event handler a

Event handler c

Example

22

Event-based Programming

Achieved through the wait commandExamples of events:

Reception of a message of a given format Traversal of a threshold for a given sensing device reading Filling of a buffer with sensing data of a given sampling rate Expiration of several timers

More events supported than Mate• Is it implemented by the OS or by SensorWare?• When an event handler is running, can the system respond to another event? • Should the system idle or can go on with the event handler running aside as another thread?

23

Run-time Environment: Tasks

Fixed tasks

Platform specific

Script Manager(script state keeping, spawns new scripts)

Admission Control & Policing of Resource

Usage

Radio/Networking

Timer service

Sensor 1

Sensor 2

Paging radio

Resource Abstraction & Resource Metering Tasks

...

24

Special Tasks

Script Manager Accepts spawning requests Forwards the request to the Admission Control If pass, initiates a new thread/task running a script

interpreter for the new script Keeps script-related state info

Admission Control & Policing Make sure that the scripts stay under their resource

contract, and checks the overall energy consumption

How the Admission Control is implemented is in another paper [4].

25

Resource Abstraction & Metering Tasks

Every platform is assumed to have at least one radio and a timer service

Radio Accepts requests from the scripts about the format of

network messages Dispatches messages to appropriate scripts Measure the radio utilization for each script

Timer Provides many virtual timers relying on one timer

provided by the system

26

Run-Time Environment

Radiothread

Sensing

Timer Service

Script ManagerAdmission

control

Script 1

Script n

Radio

Sensor

Resource metering info

...Queue

OS thread

HW access code

event

interest in event

system msg.

Device related permanent Script related

27

Portability and Expandability

Capabilities variability, i.e., having different modules, such as sensing devices, GPS

HW/SW variability, i.e., having different OS and/or specifics of hardware devices

28

Dealing with Capabilities Variability

Define and support virtual devicesAlmost everything in SensorWare is a device

Radio, Sensing(magnetometer, accelerometer) Battery, Timer service Localization procedure, neighborhood discovery

Devices are registeredUnified interface presented to the scripts

4 commands: act,query, createEventID, disposeEventID

29

Dealing with HW/SW variability

Abstract Wrapper FunctionsFind OS dependencies and abstract them

Definition and creation of threads Support for non-polling message passing

Find hardware dependencies and abstract them send/receive packets/bits set a real timer set the sampling rate of a sensor

30

Code Structure

Platform independent code Device Definition code

OS specific code

• Register all devices• Define functions for

options parsing

HW access code• Definition of threads• Definition of msg passing

Tcl

APIs

Script manager

Admission control

Device 1 code

Device 2 code

Changed for porting

Never changedChanged with platform

capabilities

Code dependency

31

Addressing

Generic format: [nodes_specification.script_name.userID.appID]

For now, nodes_specification = node IDScript_name:

Level_0_name.Level_1_name….Level_n_nameUserIDAppID

Denote the application that the particular instance of a script belongs to

32

Routing

Need to support multiple and new routing protocols at SensorWare compile time

To achieve this Define routing protocols as devices Define a special device that gives scripts the

ability to handle system-kept routing table to support application-level routing

33

Roadmap


34

Code Example: multi-user aggregation

The first command tries to replicatethe script to all the neighbors, declaring that this is a multi-userscript.The nodes that the script wasspawned or an “add user” messagewas sent are returned and addedto the need_reply_from variable.

For more details: http://www.ee.ucla.edu/~boulis/phd/Illustrations.html

35


The second command reads thecurrent value from the sensingdevice and sets the maxvaluevariable with it.


36


If there are no nodes to return areply the script sends the maxvalueto the parent and exits.Otherwise the parent node is addedto the list return_reply_to and the loop begins.


37


Each time a packet is received wecheck if it is a data reply or an “adduser” message and modify our listsand maxvalue accordingly.


38

Code Example: Porting to a platform

First, create a virtual device for the sensing device Create_device(char* name, int (*query)(), int

(*act)(), void* (*createEventID)(), int (*disposeEventID)(), void* (*task)())

Second, define the OS-specific code to create threads and use mailboxes/queues

39

Roadmap


40

Implementation: Platform

iPAQ 3670 Intel StrongARM 1110 rev

8 32bit at 206Mhz 16Mbytes flash mem 64Mbytes RAM mem OS: v0.5 Linux

StrongARM, kernel 2.4.18-rmk3

Compiler: gcc Radio: wavelan card Sensing: Honeywell HMR-

2300 Magnetometer

41

Implementation: Memory Size

Linux + TinyTcl = 80%

42

Implementation: Delay measurement

Lefttop: commands with less than 0.06 ms delay

Righttop:most time consuming commands

Leftbottom: delays of other special commands

spawn(one hop) < spawn(local) + send (one hop)

Overhead of real-time measurements: 0.25ms

43

Roadmap


44

Tradeoffs: native code vs. scripts

Slower execution 8% slowdown for a typical app.

Compactness of code: 209 bytes for a typical app 764 bytes the equivalent native code

Transmitting and Executing native code is not beneficial overall

Why not native code? What do we get with scripts?

Portability Code safety

Capabilities-related

Energy-related

-

+

+

How about the Linux and Tcl code?

45

Comparison (1)

EnviroTrack Mate SensorWare

Ease of programming

Not easy Not easy for large apps

Easier to build large app

Ease of debugging

? ? ?

Ease of testing ? ? ?

Ease of reuse Not easy Not easy Some kind of component-based

reuse model

46

Comparison (2)

EnviroTrack Mate SensorWare

Platform Independence

Motes Motes + TinyOS Independent of richer platforms

Application-specific

Yes No No

HW abstraction No Yes Yes

Memory Protection

No Yes Yes

Code Mobility No Yes Yes

Code safety No No Yes

47

Other Related Work

Active networking (e.g. PLAN at UPenn) Similarities: scripting abstraction, weak mobility packet-driven vs. event-driven resource management through language design vs. through run-

time mechanism Reactive Sensor Networks (at PSU)

no scripting abstraction code mobility is download oriented, no proactive

Sensor Querying and Tasking Language (Delaware) no provisions for efficient algorithms

no diverse mobility rules no code modularity support for multi-user scripts

no resource management

48

Roadmap


49

Conclusion

Is it truly a programming paradigm?Not really in terms of programming abstraction, just a scriptable environment.

Does it meet all the WSN constraints?It can’t support mote-like equipments

Does it implement programming an aggregate which is a changing set?Yes. It supports proactive programming and code population

Can it meet real-time, security, reliability requirements?Code safety is supported. Real-time can be supported in a roughly way. Reliability is an open issue.

50

Open Questions

How to define the scope of basic building blocks? (Efficiency vs Abstraction)

Is SensorWare appropriate for real-time applications? Security applications?

Is “general-purpose” programming paradigm really desirable?

Date post:	30-Dec-2015
Category:	Documents
Upload:	gray-pena
View:	33 times
Download:	0 times

SensorWare: A Framework for Efficient and Programmable Sensor Networks

Documents