WSN Programming: From Abstractions To Running Code

Size: px

Start display at page:

Download "WSN Programming: From Abstractions To Running Code"

Kathryn Chambers
6 years ago
Views:

1 WSN Programming: From Abstractions To Running Code Luca Mottola Principles of Wireless Sensor Networks, KTH, September 14 th, 2009 A part of Swedish ICT

WSN Programming Ease of programming currently

enabler WSN programming mostly done in ad-hoc fashion

details difficult to port and re-use performance

58% [SenSys 04] Redwood Trees: average yield 40%

2 WSN Programming Ease of programming currently recognized as a major hampering factor and technology enabler WSN programming mostly done in ad-hoc fashion close to the OS largest coding effort in low-level details difficult to port and re-use performance issues due to bugs Great Duck Island: average yield 58% [SenSys 04] Redwood Trees: average yield 40% [SenSys 05] Volcano: average yield 69% [OSDI 06] Luca Mottola September 14th 2009

3 Programming Challenge Wide variety of application requirements Inherent tension between: the desire to shield programmers from complexity the need to enable cross-layer design decentralized Wireless Sensor and Actor Networks Wildlife monitoring Smart ambient Habitat monitoring Healthcare centralized January 28th, 2008 homogeneous heterogeneous Luca Mottola September 14th 2009

4 Cross-layering I: Energy I m interested in problem X. As long as I get that done, why should I care about something else? No radio duty-cycle Radio duty-cycle

5 Cross-layering II: Wireless Non-isotropic range, asymmetric links Collisions, hidden terminal problem Link quality affected by environmental parameters e.g., temperature, humidity, presence of people What-you-see-is-not-what-you-get topologies e.g., good connection to far nodes and bad to close ones

6 Agenda Examples of programming systems the TinyOS operating system the Contiki operating system Logical Neighborhoods TinyDB (and the like) Demo session with Contiki Contiki/ TinyOS Logical Neighborhoods Luca Mottola September 14th 2009 TinyDB

7 TinyOS Overview One of the first OSs to target NES currently the most widespread Emphasis is on memory consumption both program and data memory Open-source w/ rich component library Large community J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for networked sensors. In SIGOPS Oper. Syst. Rev., Vol. 34, No. 5, 2000.

8 TinyOS Programming Model (1/3) nesc provides the programming abstractions component based Split-phase execution return values arrive asynchronously through events Tasks provide the unit of concurrency typically spawned by events can be pre-empted by asynchronous events FIFO scheduling D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The nesc Language: A Holistic Approach to Networked Embedded Systems. In PLDI, 2003.

9 TinyOS Programming Model (2/3) Components encapsulate state and processing use or provide interfaces Interfaces list commands and events Configurations wire components together Calls sendmsg(msg) Uses Send Provides Send Signals senddone() Function calls Using Providing Commands Call Command Implement Command Body Events Implement Event Handler Signal Event

$opCompleted(uint8_t result) { switch (whereiwas) { // case POINT_A: result // Do = call something Foo.$

10 TinyOS Programming Model (3/3) uint8_t whereiwas; // whereiwas = POINT_A; call Foo.op(); // uint8_t whereiwas result; = POINT_B; call Foo.op(); // result = call Foo.op(); // Do something event Foo.opCompleted(uint8_t result) { switch (whereiwas) { // case POINT_A: result // Do = call something Foo.op(); // Do break; something else case POINT_B: // Do something else break; } } State variable Split-phase model Sequential model

11 TinyOS Compilation Chain Complete inlining, detection of races Crosscompiled No linking Luca Mottola September 14th 2009

12 TinyOS Summary Memory efficient Rich tool-chain Large code-base and user community Split-phase yields entangled implementations Limited support to reconfiguration No energy abstraction or user interface

13 Contiki Overview Emphasis on the use of standard OS abstractions Prominent features: - IP networking / RIME network stack - hybrid threading model (protothreads) - dynamic loading - network shell - power profiling contiki Slides courtesy: Adam Dunkels

14 Contiki Programming Model (1/2) Four threads, each with its own stack Thread 1 Thread 2 Thread 3 Thread 4

15 Contiki Programming Model (2/2) One stack for different event handlers Eventhandler 12 34

16 Contiki Programming Model: Protothreads (1/2) The Contiki kernel is event-based invokes processes whenever something happens e.g., sensor events, processes starting, exiting Protothreads provide sequential flow of control on top of an event-based kernel

17 Contiki Programming Model: Example int a_protothread(struct pt *pt) { PT_BEGIN(pt); /* */ PT_WAIT_UNTIL(pt, condition1); /* */ if(something) { /* */ PT_WAIT_UNTIL(pt, condition2); /* */ } } PT_END(pt);

18 Contiki Programming Model: Protothreads (2/2) Single stack low memory usage, just like events Sequential flow of control no explicit state machines, just like threads Implemented using local continuations when set, capture the state of a function when resumed, resume the state and performs a jump stack information across blocking calls must be manually stored and retrieved (e.g., using static variables)

19 Contiki Networking: RIME Stack Modular stack Header processing separated from communication logic Chamaleon modules Channel identifiers bind sender and receiver modules Callbacks used when packets arrive, operations time out, collect runicast trickle mesh route-discovery multihop netflood unicast broadcast MAC A. Dunkels, F. Österlind, and Z. He. An Adaptive Communication Architecture for Wireless Sensor Networks. In SENSYS, 2007.

20 Contiki Summary Traditional OS abstractions Many system features dynamic linking, checkpointing, IP support, Requires good understanding of the internals to configure and debug Lack of modularization

21 Logical Neighborhoods Overview Replaces the physical neighborhood with a logical one developers decide what part of the system a node is to address Specified declaratively using the Spidey language extension of existing WSN programming languages (e.g., nesc) Broadcast-based communication API

22 Logical Neighborhoods Nodes (Logical) nodes are the application-level representation of a physical device a node template defines a node s exported attributes a logical node is instantiated from a node template by specifying the actual source of data node template Sensor static Function static Type static Location dynamic Reading dynamic BatteryPower Data Source create node vs from Sensor Function as sensor Type as vibration Location as office1 Reading as getaccel() BatteryPower as getbattery()

Logical Neighborhoods Neighborhoods A (logical)

predicate - encoded in a neighborhood template -

predicate I want to address all vibration sensor

VibrationSens[ f ] with Function = sensor and

neighborhood vb_my_location from VibrationSens[

23 Logical Neighborhoods Neighborhoods A (logical) neighborhood is the set of nodes satisfying a predicate - encoded in a neighborhood template - instantiation specifies where to evaluate the predicate I want to address all vibration sensor in a given location neighborhood template VibrationSens[ f ] with Function = sensor and Type = vibration and Floor = f Data Scope create neighborhood vb_my_location from VibrationSens[ f: Floor1 ] max hops 2 lying at a maximum distance of two hops.

$Logical Neighborhoods API The logical neighborhood id replaces the AM address interface LNSend { command error_t send(ln_id_t target_ln, void* data, uint8_t len, uint8_t credits); command error_t$

24 Logical Neighborhoods API The logical neighborhood id replaces the AM address interface LNSend { command error_t send(ln_id_t target_ln, void* data, uint8_t len, uint8_t credits); command error_t sendreply(uint16_t dest, void* msg, uint8_t len); // rest as in AMSend } Credits are an applicationdefined measure of communication cost create node vs from Sensor use cost 1/getBatteryPower() // Each node declares its own use cost in credits Credits needed to send a message are evaluated as the sum of the use costs of each node involved in routing Give developers a knob to explore the trade-off between accuracy and resource consumption

25 Logical Neighborhoods Summary Provides programmer-defined communication scopes Credits allow fine-grained resource management Only deals with communication Forces programmers to learn two languages

26 TinyDB Overview Declarative SQL-like interface Avoid writing low-level C code Limit programmers to handle only natively supported data types extensions are possible, but the TinyDB code is quite complex Can be embedded within Java applications Can output data to standard DBMS, e.g., PostgreSQL

27 TinyDB Example Queries Periodic query for temperature and light readings SELECT nodeid, light, temp FROM sensors EPOCH DURATION 1s FOR 10 s SELECT AVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold EPOCH DURATION 30s Continuous aggregation query SELECT nodeid, voltage FROM sensors WHERE voltage < threshold ONCE One-shot query for system information

28 TinyDB Query Language (1/2) SELECT select-list [FROM table_name] WHERE where-clause [GROUP BY gb-list [HAVING having-list]] [TRIGGER ACTION command[(param)]] [EPOCH DURATION integer] Data stored in a sensors table SELECT, FROM, GROUP BY, HAVING are like in SQL FROM can only list the sensors table TRIGGER specifies the name of a nesc function to execute when some result is produced the function implementation is left to the programmer linking to the TinyDB engine is non-trivial EPOCH specifies the data rate Not supported: nested queries, column renaming with AS, JOIN operator, OR and NOT operators, FROM with multiple tables, arithmetic expressions different from column-opconstant

29 TinyDB Query Language (2/2) Event-based queries when an event is raised by the OS e.g., a sensor reading above a threshold Definition and implementation of events is left to the programmer requires delving into the TinyDB internals Queries over flash store the results on the node s permanent memory the buffer can then be used as an additional table ON event_name SELECT CREATE BUFFER buffer_name SIZE integer (field1name type, field2name type, ) SELECT FROM INTO buffer_name SELECT FROM buffer_name

30 TinyDB Summary Very-high level and intuitive Efficient with simple queries Very hard to extend and to debug Only (static) data collection applications

31 Time to Play Around Sentilla jcreate: MSP430 MCU, CC2420 radio, acceleration sensor Luca Mottola September 14th 2009

Contiki Blink Example PROCESS(blink_process, "Blink");

$PROCESS_THREAD(blink_process, ev, data) {$ static struct etimer et; We want to blink the leds

PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));

leds_off(leds_all); } exit: leds_off(leds_all);

32 Contiki Blink Example PROCESS(blink_process, "Blink"); AUTOSTART_PROCESSES(&blink_process); PROCESS_THREAD(blink_process, ev, data) { PROCESS_EXITHANDLER(goto exit;) PROCESS_BEGIN(); while(1) { static struct etimer et; We want to blink the leds periodically etimer_set(&et, CLOCK_SECOND); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); leds_on(leds_all); etimer_set(&et, CLOCK_SECOND); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); leds_off(leds_all); } exit: leds_off(leds_all); PROCESS_END(); } Declare a protothread and makes it start at boot Pointer to exit procedure Set a timer and wait for it to fire

$PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); while(1) { } start_accel_sensing(); etimer_set(&et, CLOCK_SECOND/2);$ $accel_energy = compute_accel_energy(); printf ("Last accel signal energy is %lu\n",accel_energy); if (accel_energy > ACCEL_THRESHOLD) {$

33 Contiki Sensing Example We want to sense from the accelerometer Boot up the sensor accel_init(); etimer_set(&et, 2*CLOCK_SECOND); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); while(1) { } start_accel_sensing(); etimer_set(&et, CLOCK_SECOND/2); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); stop_accel_sensing(); Collect samples for half a second Local processing of sensed data uint32_t accel_energy = compute_accel_energy(); printf ("Last accel signal energy is %lu\n",accel_energy); if (accel_energy > ACCEL_THRESHOLD) { leds_on(leds_all); } else { leds_off(leds_all); }

$*c) { printf("abc message received '%s'\n", (char *)packetbuf_dataptr()); } static$ $abc_open(&abc, 128, &abc_call); Open a channel for broadcast communication while(1) {$ $packetbuf_copyfrom("hello", 6); abc_send(&abc); printf("abc message sent\n"); Send a$

34 Contiki Broadcast Example We want to send a broadcast message Callback for received messages Memory area containing received data static void abc_recv(struct abc_conn *c) { printf("abc message received '%s'\n", (char *)packetbuf_dataptr()); } static const struct abc_callbacks abc_call = {abc_recv}; static struct abc_conn abc; abc_open(&abc, 128, &abc_call); Open a channel for broadcast communication while(1) { Wait a random time between 2 and 4 seconds etimer_set(&et, CLOCK_SECOND * 2 + random_rand() % (CLOCK_SECOND * 2)); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); } packetbuf_copyfrom("hello", 6); abc_send(&abc); printf("abc message sent\n"); Send a string in broadcast

$Contiki Broadcast Example We want to send a broadcast message with acceleration readings typedef struct msg_t { uint8_t rimeaddr0; uint8_t rimeaddr1; uint32_t accel; } msg_t; Message format static$

35 Contiki Broadcast Example We want to send a broadcast message with acceleration readings typedef struct msg_t { uint8_t rimeaddr0; uint8_t rimeaddr1; uint32_t accel; } msg_t; Message format static msg_t msg; // Sense from accelerometer msg.rimeaddr0 = rimeaddr_node_addr.u8[0]; msg.rimeaddr1 = rimeaddr_node_addr.u8[1]; msg.accel = compute_accel_energy(); packetbuf_copyfrom(&msg, sizeof(msg_t)); abc_send(&abc); printf("abc message sent\n"); Broadcast message Packing data in message

36 Learn by Doing! E.g., try to ping pong a message between two nodes that do not know each other! Download Contiki and documentation from

37 Conclusion Programming as a critical research topic Programming atop the OS will not work in the long term No well-established high-level programming solutions Plenty of related research topics: debugging verification deployments Luca Mottola September 14th 2009 Questions?

Architectures and Applications for Wireless Sensor Networks ( ) Node Programming

Architectures and Applications for Wireless Sensor Networks (01204525) Node Programming Chaiporn Jaikaeo chaiporn.j@ku.ac.th Department of Computer Engineering Kasetsart University Outline Microcontroller