1. 1 System Architecture Directions for Networked Sensors (TinyOS & Mica2) Presented by Jang Young, Kim (Chris)

2. 2 Outline Introduction & Motivation Networked Sensor Characteristics H/W & Power Tiny Operating System (TinyOS) TinyOS Design Components Evaluation Mica2 mote programming and TOSSIM Conclusion Discussion

3. 3 Smart Dust

4. What is TinyOS ? Operating system developed at UC Berkeley for use with sensor motes Support sensor motes and ease development of sensor applications Event-driven architecture Utilizes new programming language called nesC Currently the standard in sensor OS

5. 5 Networked Sensor Smaller, cheaper, lower-power communication Complete systems on a chip Integrated low-power communication Integrated low-power transducers Networked sensor

6. 6 Motivation General purpose operating systems are not appropriate for sensor networks Sensor networks require a task specific OS Concurrency intensive Multiple flows move through sensor in parallel Modular design Components connect easily to facilitate application specific additions/modifications

7. 7 TinyOS Missing technolygy : the system software support to manage and operate the device. Address this problem TinyOS Concurrency intensive – several different flows of data must be kept moving simultaneously Efficient modularity – hardware specific and application specific components must snap together with little processing and storage overhead

8. 8 TinyOS 178 bytes of memory Propagates events in the time it takes to copy 1.25 bytes of memory Context switches in the time it takes to copy 6bytes of memory Supports two level scheduling

9. 9 Networked Sensor Characteristics Small Physical size and low power consumption Concurrency-intensive Operation Limited Physical Parallelism and Controller Hierarchy Diversity in Design and Usage Robust Operation

10. 10 Small Physical size and low power consumption  Reducing the size and power required for a given capability are driving factors in the hardware design.  The software must make efficient use of processor and memory while enabling low power communication. Concurrency-intensive Operation  Information may be simultaneously captured from sensors, manipulated, and streamed onto a network.

11. 11 Limited Physical Parallelism and Controller Hierarchy  The number of independent controllers, the capabilities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much lower than in conventional systems.  The sensor provides a primitive interface directly to a single-chip microcontroller.  In contrast, conventional systems distribute the concurrent processing over multiple levels of controllers.

12. 12 Diversity in Desing and Usage  Sensor devices will tend to be application specific, rather than general purpose, and carry only the available hardware support actually needed for the application. Robust Operation  This devices will be numerous, largely unattended, and expected to from an application which will be operational a large percentage of the time.  One of the ways of increasing reliability is to tolerate individual device failure.

13. 13 Hardware Organization Three sleep modes (idle, power down & power save) Three LEDs to represent outputs Photo-sensor Radio Temperature Sensor Serial Port

14. 14 Photograph and schematic for representative network sensor platform It consists of a microcontroller with internal flash program memory, data SRAM and data EEPROM, connected to a set of actuator and sensor devices, including LEDs, a low-power radio transceiver, an analog photo-sensor, a digital temperature sensor, a serial port, and a small coprocessor unit.

15. 15 Photograph and schematic for representative network sensor platform CPU: 4MHz Memory: 8KB flash (data), 512 B SRAM (program) Network: 19.2 Kbps Input: temperature and light sensors Output: 3 LEDs Serial Interface

16. 16 Three sleep modes (idle, power down & power save)  Idle, which just shuts off the processor.  Power down, which shuts off everything but the watchdog and asynchronous interrupt logic necessary to wake up.  Power save, which is similar to the one above, but leaves an asynchronous timer running.

17. 17 Three LEDs represent outputs  Connected through general I/O ports. Photo - Sensor  An analog input device which simple control lines.

18. 18 Radio  The most important component.  It represents an asynchronous input/output device with hard real time constraints.  Contains no buffering so each bit must be serviced by the controller on time. Serial Port  Represents an important asynchronous bit level device with byte-level controller support.

19. 19 Power Characteristics Biggest energy drain is radio About 3 orders of magnitude between idle and inactive! No transition costs documented Active == Peak Load

20. 20 TinyOS Overview Application = scheduler + graph of components  Compiled into one executable Event-driven architecture Single shared stack No kernel/user space differentiation Communication Application (User Components) Main (includes Scheduler)

21. 21 Tiny Microthreading OS (TinyOS) Requirements (small physical size, modest active power load & tiny inactive load)  An operating system framework is needed that will retain these characteristics by managing the hardware capabilities effectively, while supporting concurrency- intensive operation in a manner that achieves efficient modularity and robustness. Two-level scheduling structure High levels of concurrency

22. 22 Two-level scheduling structure  A small amount of processing associated with hardware events can be performed immediately while long running tasks are interrupted. Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands

23. 23 Two-level scheduling structure Tasks do computations  Non-preemptive FIFO scheduling  Bounded number of pending tasks Events handle concurrent dataflows  Interrupts trigger lowest level events  Events preempt tasks, tasks do not  Events can signal events, call commands, or post tasks

24. 24 Two-level scheduling structure Event and Task  Tasks cannot preempt other tasks  Single shared stack Used by both interrupts and function calls  Simple FIFO scheduler  Events can preempt a task  Events can preempt each other  When idle, scheduler shuts down the node except for clock

25. 25 Tiny OS Design Tiny Scheduler Components  Frame  Tasks  Event Handlers  Command Handlers Messaging Component Internal State Internal Tasks CommandsEvents

26. 26 Tiny OS Design Frame  It has information related to the current state of the system.  Commands, events and tasks execute in the context of the frame. Tasks  Perform the primary work.  They are atomic with respect to other tasks and run to completion, though they can be preempted by events. Event Handlers  Invoked to deal with hardware events, either directly or indirectly. Command Handlers  Non-blocking requests made to lower level components.

27. 27 Components 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 Block of state Events signal commands Set of commands handlers

28. 28 /* Messaging Component Declaration */ //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); //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)();

29. 29 Component Types Send_message TX_Packet TX_byte TX_Bit_Event Msg_Send_Done TX_Packet_Done TX_Byte_Done TX_Bit_Done

30. 30 Component Types Hardware Abstractions - RFM Synthetic Hardware - Radio Byte High Level Software Components - messaging module

31. 31 Component Types Hardware Abstractions This component exports commands to manipulate the individual I/O pins connected to the RFM transceiver and posts events informing other components about the transmission and reception of bits. Its frame contains information about the current state of the component. Synthetic Hardware It shifts data into or out of the underlying RFM module and signals when an entire byte has completed. The internal tasks perform simple encoding and decoding of the data. Conceptually, this component is an enhanced state machine that could be directly cast into hardware. High Level Software Components It performs the function of filling in a packet buffer prior to transmission and dispatches received messages to their appropriate place. Additionally, components that perform calculations on data or data aggregation fall into this category.

32. 32 Component Types Two-level scheduler and directed graph of components Component parts Command handlers Respond to higher components Event handlers Respond to lower components Fixed-size frame Size of component is known at compile time Set of tasks Functions to do arbitrary computation

33. 33 Putting it All Together A sample configuration of a networked sensor, and the routing topology created by a collection of distributed sensors. Network sensor Light sensor Temperature sensor The internal component graph of a base station sensor is shown along with the routing topology created by a collection of sensors.

34. 34 Evaluation(1) Code and Data size Breakdown Small Physical Size Scheduler: 178 Bytes code Totals: 3450 Bytes code 226 Bytes data

35. 35 Evaluation(2) Time Breakdown Concurrency-Intensive Operations 50 cycle thread overhead (6 byte copies) 10 cycle event overhead (1.25 byte copes)

36. 36 Evaluation(3) Time Breakdown Efficient Modularity Events and commands can propagate through components quickly. Total propagation delay: 40 us Timing diagram of event propagation

37. 37 Evaluation(4) Power Breakdown Limited Physical Parallelism and Controller Hierarchy Diversity in Usage and Robust Operation What does this mean? Lithium Battery runs for 28 hours at peak load and years at minimum load! All its energy can only support 144KB data

38. Mica2 mote MICA2 MOTE

39. Download TinyOS http://www.tinyos.net/tinyos-1.x/doc/install.html  Windows: Uses Cygwin environment to simulate Linux environment More complex than Linux installation (this took some time) WARNING: TinyOS has problems with newer versions of Cygwin and prefers older versions for proper functioning  Linux: Preferred as it’s native and faster; Easier setup Simply involves installing several RPMs (for Red Hat) Note that nesc-1.1-1.i386.rpm should be used (the recommended nesc-1.1.2b-1.i386.rpm gives many compiler errors)nesc-1.1-1.i386.rpmnesc-1.1.2b-1.i386.rpm

40. TinyOS installation Installs  nesC compiler and AVR package (processor dependant)  Java JDK and Communications package  TinyOS software/modules TinyOS installation (Red Hat) can be found in /opt/tinyos-1.x/  /opt/tinyos-1.x/apps contains example components (such as Blink)  /opt/tinyos-1.x/tools/java contains many java applications that will be useful later  /opt/tinyos-1.x/tools/scripts contains toscheck which can be used to check installation for correctness Also ensure that you change your PATH variable to include

41. Blink.nc Blink.nc consists of: configuration Blink { } implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; }

42. Code(1) configuration Blink { }  Specifies this is a configuration file whose name is Blink implementation {  Indicates that this is where we specify the actual configuration of the component components Main, BlinkM, SingleTimer, LedsC;  A listing of the set of components that this configuration file references (makes use of)

43. Code(2) Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl;  Main is a component and StdControl is an interface it uses  -> symbol indicates that the component on the left “is wired to” (OR the component on the left “uses”) the component on the right and carries with it two conditions: The component on the right must implement all the functions provided by the component’s interface on the left The component on the left must implement event handlers for all the events that the component on the right exports Hence, Main’s StdControl interface uses (is wired to) the StdControl interfaces provided by (implemented by) both BlinkM and SingleTimer

44. StdControl Interface Anyone who provides the StdControl Interface must implement the following 3 functions:  StdControl.init(), StdControl.start() and StdControl.stop() When a mote is started, the first two functions called are Main.StdControl.init() and Main.StdControl.start()  Any modules who implement this interface and are wired to Main in such a way also have their init and start functions called  The last function called is Main.StdControl.stop() and it will call all the stop functions it is wired to

45. Code BlinkM.Timer -> SingleTimer.Timer;  Indicates the BlinkM module is wired to the SingleTimer.Timer interface and hence can utilize all the commands it provides and now as the obligation to respond to any events it exports BlinkM.Leds -> LedsC; – Similar to the Timer interface, through this line, BlinkM is now able to utilize the Leds interface (commands that can control the LED lights on the mote)

46. BlinkM.nc module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } // Code continued on next slide... Indicates this is a module file (an implementation) that:  Provides the StdControl interface (the init(), start() and stop() functions)  Uses the interfaces Timer and Leds (allows it to utilize the commands and respond to the events generated by those interfaces)

47. BlinkM.nc implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000) ; } command result_t StdControl.stop() { return call Timer.stop(); } //Code continued on next slide… This is the implementation of the module  Init() is called when the module is first initialized. It initializes the Led lights  Start() is called when the module is first started. It starts a timer function that will fire every 1000 milliseconds and repeats doing this till the stop command is called.  Stop() is called when the module is shut off and this stops the timer function

48. BlinkM.nc event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; } }//end implementation Since BlinkM uses the timer interface, it must also provide event handlers for the events that Timer exports  Every time the timer fires, we call a command provided by the Leds interface (a command which toggles the red LED) Hence, we have created a module that blinks the red LED light on the mote once every second!

49. TOSSIM cd /opt/tinyos-1.x/apps/Blink - where the Blink application example is stored make pc – compile the module for use in TOSSIM simulation on the host pc./build/pc/main.exe N -run simulation where N is the number of nodes in the simulation OR./build/pc/main.exe –rf=lossy.txt N – where lossy.txt specifies the topology of the nodes  By default, in TOSSIM, the nodes are all placed in virtual reach of each other

50. Debugging  Place debug lines in code such as: dbg(DBG_USR1, "processingRecieve from %d”, source)  export DBG=usr1  This will enable all dbg lines with DBG_USR1 to be outputted to the screen during simulation runs

51. 51 Conclusion TinyOS is a highly modular software environment tailored to the requirements of Network Sensors, increasing efficiency, modularity and concurrency.

52. 52 TinyOS Pros & Cons Small memory footprint  Non-preemptable FIFO task scheduling Power efficient  Put microcontroller and radio to sleep Efficient modularity  Function call (event, command) interface between components Concurrency-intensive operations  Event-driven architecture  Efficient interrupts/events handling (function calls, no user/kernel boundary) Real-time  Non-preemptable FIFO task scheduling  No real-time guarantees or overload protection

53. 53 TinyOS Pros & Cons Lack real-time scheduling  Urgent task may wait for non-urgent ones Lack kernel protection  Rely on compile-time analysis  Programmer deals with H/W directly  Dynamic memory allocation Lack flexibility  Static linking only  Cannot change code online  Cannot change part of the code Lack virtual memory  Physical memory used......

54. 54 Any Questions ?