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

Operating Systems • 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 10

Classification Criteria network perception data acquisition hardware interaction 11

Classification Criteria network perception C/ � macroprogramming C/ � C/ � C/ � C/ � sensor based C/ � data acquisition hardware interaction 11

Classification Criteria network perception C/ � macroprogramming C/ � C/ � C/ � C/ � sensor based C/ � data acquisition C low-level virtual machine middleware GLUE � high-level hardware interaction 11

Classification Criteria network perception C/ � macroprogramming C/ � C/ � C/ � C/ � sensor based C/ � data acquisition C/ � C low-level messages streams databases mobile agents virtual machine middleware GLUE � high-level hardware interaction 11

Low-level HW Abs. C • 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 12

Low-level HW Abs. C • 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 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. GLUE • 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 16

Middleware Abs. GLUE • 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. 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. C/ � C/ � C/ � C/ � C/ � • 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 C/ � • 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 21

Macroprogramming C/ � • 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,... 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 operations • For instance, allow users to query sensor data via web services. • Examples: TinyDB, Cougar, IrisNet 25

Mobile Agent Abs. C/ � • 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) 26

Classification Grid Network Data Hardware Proposals/Abstractions perception acquisition interaction C Abstract Regions [45] C/ � � C/ � Agilla [21] C/ � C/ � C/ � C/ � C/ � � AmbientTalk [13] C/ � C/ � C/ � C/ � C/ � � Cosmos [5] C/ � � Cougar [23] C/ � • Refer to the book chapter for the classification of 30 programming languages + discussions on OSs and VMs 27

Collecting Temperature Node2 Node1 Sink � � �� � 28

Collecting Temperature Node2 Node1 Sink � � �� � 28

Collecting Temperature getTemp getTemp getTemp Node2 Node1 getTemp Sink � � �� � 28

Collecting Temperature replyTemp replyTemp Node2 Node1 replyTemp Sink � � �� � 28

Representing Sensors [ P 1 : P 2 : P 3 ... ▹ C ]p e 29

Representing Sensors [ P 1 : P 2 : P 3 ... ▹ C ]p e program queue code modules 29

Representing Sensors position [ P 1 : P 2 : P 3 ... ▹ C ]p e energy program queue code modules 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 ▹ did you spot System :: {...} /* /dev */ the error? 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