1. System Architecture Directions for Networked Sensors Qiuhua Cao (qc9b@cs) Computer Science Department University of Virginia

2. Outline  Hardware Organization of Berkeley Motes  Critical Issues of Sensor Networks  Does an OS for the Motes exsit?  Design Goals of TinyOS  Concepts in TinyOS  Examples  Evaluation and Critiques

3. Hardware Platform-Motes  Assembled from off-the-shelf components  4Mhz, 8bit MCU (ATMEL 90LS8535) –512 bytes RAM, 8K ROM  900Mhz Radio (RF Monolithics) –10-100 ft. range  Temperature & Light Sensor  LED outputs  Serial Port

5. Critical Issues for Sensor Networks  Highly Limited Device  power, memory, bandwith  Inherently Distributed  large number of nodes coordinate, cooperate with each other to fulfill an job  Devices themselves are the infrastructure  ad hoc, self-organized  Highly Dynamic  failure in common  variation in connectivity over time

6. Does an OS for the Motes exist?  Traditional OS design  wait request, act, respond loop  monolithic event processing  full thread/socket POSIX regime  Alternative  concurrency and modularity  never poll, never block  data flows, events, power management interact

7. Design Goals of TinyOS  Concurrency-Intensive Operations  flow information from place to place on-the-fly  Example: simultaneously capture data from sensors, processing the data, then send out to the network

8. Design Goals of TinyOS (cont.)  Limited Physical Parallelism and Controller Hierarchy  Less independent controllers  Less processor-memory-switch level  Sensor and Actuator directly interact with the single-chip micro controller

9. Design Goals of TinyOS (cont.)  Diversity in Design and Usage  Sensor network application specific design  But wide range potential applications  deep modularity of software needed

10. Design Goals of TinyOS (cont.)  Robust Operations  Cross devices redundancy prohibitive  Individual reliable devices desired  Application tolerant individual device failures

11. Concepts in TinyOS  Application = graph of components + scheduler  Example: INT_TO_LEDS MIAN COUNTER CLOCK INT_TO_LEDS LED

12. Concepts in TinyOS (cont.)  Component  Implementation (.c file) Frame a set of commands a set of handlers a set of tasks  Interface (.comp)  Description file (.desc)

13. Concepts in TinyOS (cont.)  Frame  Contains all permanent state for component (lives across events, commands, and threads)  Threads, events, and commands execute inside the component’s frame  Only one per component Like static class variables, not internal class variables.  Fixed size  Statically allocated at compile time

14. Concepts in TinyOS  Frame example:  Frame declaration #define TOS_FRAME_TYPE AM_obj_frame TOS_FRAME_BEGIN(AM_obj_frame) { int addr; char type; char state; char* data; char msgbuf[30]; } TOS_FRAME_END(AM_obj_frame); VAR(state) = 0;  Use of frame Variables:

15.  Commands:  Commands deposit request parameters into its frame  Commands can call lower level commands  Commands can post tasks  Commands no-blocking  Commands needed to return status  Declaration TOS_COMMAND(cmd_name)(cmd_args_list);  USE: TOS_CALL_COMMAND(cmd_name)(cmd_args_list);

16.  Events  Deposit information into frame  Events can call lower level commands  Post tasks and fire higher level events.  Events can not be signaled by commands,  Declaration char TOS_EVENT(evnt_name)(evnt_arg_list);  Use TOS_SIGNAL_EVENT(evnt_name)(evnt_arg_list);

17.  Tasks  Tasks perform work that is computationally intensive.  FIFO scheduler  Run-to-completion  Non-preemptable among tasks (concurrent)  Preemptable by events  Task declaration: TOS_TASK(task_name){….}  Posting a task: –Asynchronous call to schedule the task for later execution –USE: TOS_POST_TASK(avg_task);

18. Commands, Events, Tasks  Relationship Graph Higher Level Component Lower Level Component Signal events Issue cmds Commands can not signal Events Both event and cmd can schedule tasks Tasks preemptive by Envents Tasks non preemptive by Tasks

19. An Component Example Messaging Component init Power(mode) TX_packet(buf) TX_packet_done (success) RX_packet_done (buffer) Internal State init power(mode) send_msg(addr, type, data) msg_rec(type, data) msg_send_done (success) send_msg_thread Cmd Issued Cmd accepted Events handled Events signaled

20. An Component Example (cont. ) .comp file interface definition TOS_MODULE name; ACCEPTS{ command_signatures }; HANDLES{ event_signatures }; USES{ command_signatures }; SIGNALS{ event_signatures };

21. An Component Example (cont. ) .comp file interface definition //ACCEPTS: char TOS_COMMAND(AM_send_msg)(int addr, int type, char* data); void TOS_COMMAND(AM_power)(char mode); char TOS_COMMAND(AM_init)(); //SIGNALS: char AM_msg_rec(int type, char* data); char AM_msg_send_done(char success);

22. An Component Example (cont.) //HANDLES: char AM_TX_packet_done(char success); char AM_RX_packet_done(char* packet); //USES: char TOS_COMMAND(AM_SUB_TX_packet)(char* data); void TOS_COMMAND(AM_SUB_power)(char mode); char TOS_COMMAND(AM_SUB_init)();

23. An Component Example (cont.) .c file frame, commands, events implementation #define TOS_FRAME_TYPE AM_obj_frame TOS_FRAME_BEGIN(AM_obj_frame) { char state; TOS_MsgPtr msg; }TOS_FRAME_END(AM_obj_frame); // This task schedules the transmission of the Active Message TOS_TASK(AM_send_task) { //construct the packet to be sent,fill in dest and type if(!TOS_CALL_COMMAND(AM_SUB_TX_PACKET)(VAR(msg))) { VAR(state) = 0; TOS_SIGNAL_EVENT(AM_MSG_SEND_DONE)(VAR(msg)); return; } }

24. .c file frame, commands, events implementation // Command to be used for power management char TOS_COMMAND(AM_POWER)(char mode){ TOS_CALL_COMMAND(AM_SUB_POWER)(mode); VAR(state) = 0; return 1; } // Handle the event of the completion of a message transmission char TOS_EVENT(AM_TX_PACKET_DONE)(TOS_MsgPtr msg){ //return to idle state. VAR(state) = 0; //fire send done event. TOS_SIGNAL_EVENT(AM_MSG_SEND_DONE)(msg); return 1; }

25. An Component Example (cont. ) .desc file  component modules specified  the wiring of commands and events across component interfaces  Example: include modules{ module list }; connection list

26. Storage Model  One frame per component, shared stack Previous frame Current frame Next frame %sp %fp(old %sp) variable data Stack Growth

27. Storage Model (cont.)  Message Buffer  Strict alternating ownership protocol  Only TOS_MSG type pointer across component AM send_msg AM is owner of message buffer, the requesting component can not access this message buffer send_done AM gives up the owner of message buffer,

28. Storage Model (cont.) char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){... if (!VAR(pending)) { VAR(pending) = 1; message->val = val; message->src = TOS_LOCAL_ADDRESS; if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_BC AST_ADDR, AM_MSG(INT_READING), &VAR(data))) { return 1; } else { VAR(pending) = 0; /* request failed, free buffer */ } } return 0; }

29. Scheduler  Two-level scheduling structure –Tasks, Events  FSM execution model –Each task is like a state in the state machine, which the events are like input signals  Events model –When there is no event, CPU is put in idle

30. An example of Execution Model Get_Light Send_MsgSleep Light done event / Msg send command Msg sent event / Power down command Clock Event / Light Request Command

31. Add a task Get_Light Send_MsgSleep Clock Event / Light Request Command Thread Schedule / Msg send command Msg sent event / Power down command Calc. Average Light done event / Post Task

32. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks bit byte packet Routing Layer sensing application HW SW ADC routing Temp

33. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp Send_message

34. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_Packet

35. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_byte

36. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_Bit_Event

37. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_Bit_Done

38. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_Byte_Done

39. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp TX_Packet_Done

40. An Composition Example RFM Radio Byte Radio Packet I2C photo Messaging Layer clocks Routing Layer sensing application HW SW ADC Temp Msg_Send_Done

41. Evaluation  meet power constraints? ActiveIdleSleep CPU5 mA2 mA5 μA Radio7 mA (TX)4.5 mA (RX)5 μA EE-Prom3 mA00 LED’s4 mA00 Photo Diode200 μA00 Temperature200 μA00

42. Evaluation  meet power save? Battery Lifetime for sensor reporting every minute Duty Cycle Estimated Battery Life Full Time Listening100%3 Days Full Time Low Power Listening 100% 6.54 Days Periodic Multi-Hop Listening 10%65 Days No Listening0.01%Years

43. Evaluation  meet memory constraints?

44. Evaluation  Meet concurrent-intensive operations?  Event-driven architecture  Efficient interrupts/events handling (function calls, no user/kernel boundary)  Modularity?  Function call (event, command) interface between components

45. Critique  Real-time not addressed  Non-preemptable FIFO task scheduling  NO real-time guarantees or overload protection  Tasks are dispatched to either software or hardware to best utilize the whole system resources but in TinyOS, all tasks go into software.  Adding event queues at the lowest layers can reduce the external event losses  The OS should collect runtime profiles and statistics, perform periodic system maintenance operations and maintain system level power state  No opposite argument

46. Thanks!! Any Question??