Programming Wireless Sensor Networks Francisco Martins University - - PowerPoint PPT Presentation

Programming Wireless Sensor Networks

Francisco Martins University of Lisbon

MiNEMA Winter School, Göteborg, Sweden,March 23-26, 2009.

1

Summary

• Sensor networks overview
• Hardware and Operating System
• Program Languages and Systems
• Programming examples in a (formal) WSN

language

2

Are WSN any different?

• Design is strongly application driven
• Nodes (aka motes or smart dust) are highly

constrained in terms of

• energy, CPU speed, RAM, communication

range

• Targeted for a huge number of nodes,

possible deployed into unaccessible places

• Software updates without human

intervention

3

And from Prog. Lang.?

• WSN initial (and still major) focus on
• hardware, communication-oriented models,

routing, security, energy consumption

• Programming models and Languages are far

more recent and scarce

• typically WSN programmed at very low

abstraction level (nesC over TinyOS)

4

High-level Prog. Models

• Explore new views of the WSN
• streams - model the network with no

perception of its underlying hardware

• regions - developer can reason it terms of

groups of sensors satisfying some criteria

• databases - WSN as dynamic data repositories

queriable via declarative languages (e.g. SQL)

• computing - WSN as a computational platform

hosting autonomous mobile agents

5

Sensor Hardware

• Characterized by scarcity of resources

provided to the programmer

• Battery life. Discussed in the previous talk
• Microprocessor. Very limited due to energy,

miniaturization, and cost restrictions

• Memory. Very limited as above. Implications in the

complexity and size of programs.

• Communication range. Decreases with the square of

the distance. It’s the most energy consumption component

6

Sensor hardware

• UC Berkeley: MICA, MICAZ, and TELOS-B
• 512Kb of non-volatile memory
• sense ambient light, barometric pressure,

sound, magnetic field, temperature, etc.

• Free University of Berlin: ESB
• Very low energy consumption. An ordinary

AAA battery will last from 5 to 17 years.

7

Sensor hardware

• Sun Microsystems: SunSpot
• 512Kb of RAM
• 4 MB of flash memory
• 32-bit RISC ARM processor
• IEEE 802.15.4 wireless network
• Uses Squawk Java Virtual Machine
• Battery lasts less than 7 hours

8

Operating Systems

• TinyOS
• provides a very simple, event-based, single-

threaded execution-model with non- preemptive tasks

• composed of a set of modules available to

the application

• hand in hand with its sibling programming

language nesC

9

• Contiki
• suport for non-preemptive, multi-threaded

applications and dynamic loading of modules

• MANTIS, Nano-RK, and BTnut
• support preemptive threads, meaning that

the OS (not the application) manages the CPU

Operating Systems

10

Classification Criteria

network perception hardware interaction data acquisition

11

Classification Criteria

network perception

C/

macroprogramming sensor based

hardware interaction data acquisition

11

Classification Criteria

network perception

C/

macroprogramming sensor based

hardware interaction

• GLUE

C

low-level middleware virtual machine high-level

data acquisition

11

Classification Criteria

network perception

C/

macroprogramming sensor based

hardware interaction

• GLUE

C

low-level middleware virtual machine high-level

data acquisition

C/

messages streams databases mobile agents

11

Low-level HW Abs.

• Pros
• very fine control over the sensor hardware
• fine tune application in a more efective way
• Cons
• considerable debugging and deployment

problems for large-scale applications

C

12

Low-level HW Abs.

• nesC over TinyOS (event-based)
• a program is a collection on modules
• support for reprogramming via XNP (full

files, single-hop, bidirectional comm.)

• Protothreads over Contiki
• features non-preemptive, multi-threaded

environment

C

13

VM Abs.

• Pros
• provides a programming model that

abstract away specific hardware and OS

• enough low-level to retain some application

control

• Cons
• introduce computational overhead and

memory demands that may be incompatible with most restrictive sensor devices

14

VM Abs.

• Distributed Token Machine (for Regiment)
• Tokens with some data are sent and trigger

event-handlers upon reception

• Squawk (for Java - SunSpots)
• Very compact Java VM, for a simplified Java

byte code, running on the bare metal.

• Asymmetric model. Class loading at the base

station (suites serialized to the sensors)

15

Middleware Abs.

• Pros
• hides the details of the sensor from the

programmer

• Cons
• as for the previous case, but even

accentuating the computational overhead for the WSN

GLUE

16

Middleware Abs.

• EnviroTrack
• based on object-based distributed

middleware.

• exposes physical events that may be

addressed by the application

• Decouples the application from the physical

topology of the network, assigning computations to event perception.

GLUE

17

High-level Abs.

• Pros
• very high-level view of the network hiding

all networking and communication details

• application not targeted to a specific

architecture or configuration

• Cons
• big semantic gap between application and

its run-time representation

• 18

High-level Abs.

• Regiment
• macroprogramming language that uses

regions and data streams as its basic programming abstraction.

• runs on top of Distributed Token Machine
• SensorWare
• programs appear as mobile scripts that are

installed on-the-fly and run on sensors

• 19

Sensor Based Abs.

• Programmer distinguishes each node of the

network and must implement its behavior, compile it, and deploy it

• Requires that the programmer must be

aware of WSN details (e.g. architecture)

• Examples: nesC, Deluge, Pushpin and Agilla,

SensorWare, Smart Messages

20

Macroprogramming

• WSN applications should be deployed as

typical distributed applications without requiring the developer to specify the behavior of each sensor.

• This should be taken care by the compiler

and run-time libraries

• Developer focus on the application

C/

21

Macroprogramming

• Two approaches:
• global behavior
• regional behavior either based on sensors

position, distance (in number of hops), properties of the data gathered

• Examples: Hood, Cosmos, Directed

Diffusion, TAG, Regiment,...

C/

22

Message Abs.

• Lowest data abstraction level
• Programmers have only available the data

generated by nodes, packed in messages and transmitted over the network

• Associated with communication-centric

programming like message routing and data and code dissemination.

• Examples: XNP, Deluge, Pushpin

23

Stream Abs.

• WSN seen as streams of values, abstracting

hardware, communication protocol, topology (region streams).

• Operations on streams such as fold

(aggregate data) and map (apply some function to the stream).

• Examples: Regiment, Flask, SNACK, Kairos

24

Database Abs.

• WSN as data repositories upon which we

can apply database processing primitives

• Sophisticated compilers map the user

request into low-level sensor specific

• perations
• For instance, allow users to query sensor

data via web services.

• Examples: TinyDB, Cougar, IrisNet

25

Mobile Agent Abs.

• WSN as computational infrastructures in

which applications composed of multiple, interacting, mobile agents evolve.

• Agent traffic poses serious autonomy

problems

• Require middleware for agent mobility
• Examples: SensorWare (TCL based), Smart

Messages (Java based)

C/

26

Classification Grid

• Refer to the book chapter for the

classification of 30 programming languages + discussions on OSs and VMs

Proposals/Abstractions Hardware interaction Network perception Data acquisition Abstract Regions [45]

C

Agilla [21]

• C/

C/

AmbientTalk [13]

• C/

Cosmos [5]

• C/

Cougar [23]

• C/

27

Sink Node1 Node2

• Collecting Temperature

28

Sink Node1 Node2

• Collecting Temperature

28

Sink Node1 Node2

• Collecting Temperature

getTemp getTemp getTemp getTemp

28

Sink Node1 Node2

• Collecting Temperature

replyTemp replyTemp replyTemp

28

Representing Sensors

[ P1 : P2 : P3 ... ▹ C ]p e

29

Representing Sensors

[ P1 : P2 : P3 ... ▹ C ]p e

program queue code modules

29

Representing Sensors

[ P1 : P2 : P3 ... ▹ C ]p e

program queue code modules position energy

29

Get Temperature: Node

[ idle ▹ System :: {...} /* /dev */ Temperature :: { getTemp() = let t = System.senseTemp() in let m = System.getMAC() in send Temperature.replyTemp(t); send Temperature.getTemp() replyTemp(t, m) = send Temp.replyTemp(t, m) } ]

30

Get Temperature: Node

[ idle ▹ System :: {...} /* /dev */ Temperature :: { getTemp() = let t = System.senseTemp() in let m = System.getMAC() in send Temperature.replyTemp(t); send Temperature.getTemp() replyTemp(t, m) = send Temp.replyTemp(t, m) } ] did you spot the error?

30

Get Temperature: Sink

[ send Temperature.getTemp() ▹ System :: {...} /* /dev */ Sink :: {...} /* sink specific module */ Temperature :: { getTemp() = {} replyTemp(t, m) = Sink.log(t, m) } ]

31

The Sensor Network

[ send Temperature.getTemp() ▹ ... ] | /* the sink */ [ idle ▹ ... ] | /* node 1 */ [ idle ▹ ... ] | /* node 2 */ [ idle ▹ ... ] /* node 3 */

32

Collect Highest Temp.

• Idea:
• record the highest broadcasted

temperature

• only forward value above this (don’t

forget to update the highest broadcasted temperature value)

33

Highest Temp.: Node

Temperature :: { getTemp() = let t = ... in let m = ... in Temperature.transmit(t, m); send Temperature.getTemp() replyTemp(t, m) = let mT = Temperature.maxTemp() in if (t > mT) then Temperature.transmit(t, m) transmit(t, m) = install {Temperature::maxTemp() = m}; send Temperature.replyTemp(t,m) }

34

Bootstrapping Nodes

[ install { System :: { deploy(m) = install m;

send System.deploy(m)

...} /* the remaining system modules */ } ▹ {} ]

35

Bootstrapping Sink

[ install {

System :: ... /* as for the nodes */ Sink :: ... /* local sink code */ Temperature :: ... /* sink’s temperature */ };

send System.deploy(Temperature :: ...); /* node’s temp */ send Temperature.getTemp() /* query the WSN */ ▹

{}

]

36

Syntax for CSN

S ::= Sensor Networks 0 empty network | [ P : ... : P ▹ C ] sensor | S | S composition p e

37

Syntax for CSN

S ::= Sensor Networks 0 empty network | [ P : ... : P ▹ C ] sensor | S | S composition p e P ::= Processes v value | v.l(v1...vn) function call | send X.l(v1...vn) transmission | install(v) install module | let x = P in P new variable | post {P} defer execution

37

Syntax for CSN

S ::= Sensor Networks 0 empty network | [ P : ... : P ▹ C ] sensor | S | S composition p e P ::= Processes v value | v.l(v1...vn) function call | send X.l(v1...vn) transmission | install(v) install module | let x = P in P new variable | post {P} defer execution v ::= Values b built-in value | x variable | X module name | M module

37

Syntax for CSN

S ::= Sensor Networks 0 empty network | [ P : ... : P ▹ C ] sensor | S | S composition p e P ::= Processes v value | v.l(v1...vn) function call | send X.l(v1...vn) transmission | install(v) install module | let x = P in P new variable | post {P} defer execution C ::= {Mi} Module Collections M ::= Modules X :: {li(x1...xn) = Pi} named module v ::= Values b built-in value | x variable | X module name | M module

37

The meaning of programs

• One way of describing the meaning of a

program is to explain how its operations compute

Operational Semantics

State 1 State 2 State 3 State 4 a b c

38

Operational Semantics

if then

e > ein [post {P} : P1 : ... : Pn ▹ C ]p

e

[P1 : ... : Pn : P▹ C ]p

e - ein

39

Operational Semantics

if then

e > ein [post {P} : P1 : ... : Pn ▹ C ]p

e

[P1 : ... : Pn : P▹ C ]p

e - ein

e > ein [X.l(v) : ... ▹ C ]p

e

[P{v/x} : ... ▹ C ]p C(X) = M M(l) = (x) P

e - ein

39

What Properties?

• What kind of properties can we assure and

why are they interesting for WSN?

• when we call X.l(v), then it is always the case

that l is a function of module X and receives a parameter of the type of v

• installing a module preserves it signature
• Assure that sensors do not misbehave

40

Safety properties

• We want to guarantee that a running

program will not destroy the integrity of the virtual machine

• cf. C “core dump”
• Safety property: assure that a program will

not perform some undesired action

• Most of them are ensured statically (by a

compiler), for instance using type systems

41

Conclusions

• Summary
• overviewed hardware + OS
• classified current programming language

proposals

• played with a formal, low-level, WSN

programming language

42

Conclusions

• Challenging issues relating WSN languages
• find the right primitives that capture WSN
• perations
• develop compilers that preserve the

semantic properties all way down from a high-level language to a bytecode.

• generate simulation models from high-level

languages

43

Programming Wireless Sensor Networks

Francisco Martins University of Lisbon

MiNEMA Winter School, Göteborg, Sweden,March 23-26, 2009.

44