Tiny Microthreading Operating System: TinyOS

1. Tiny Microthreading Operating System:TinyOS

2. 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

3. Photograph and schematic for the Network Sensor

4. The Solution: TinyOS • A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces • Two level scheduling structure • Long running tasks that can be interrupted by hardware events • Small, tightly integrated design that allows crossover of software components into hardware

5. TinyOS - Design Components Scheduler Commands Events Events Hardware components

6. Structure of a Component Command Handlers Set of Tasks Event Handlers Frame (containing state information) TinyOS Component

7. TinyOS Component Model Messaging Component • Component has: • Frame (storage) • Tasks (computation) • Command and Event Interface Internal State Internal Tasks Commands Events • To facilitate modularity, each component declares the commands it uses and the events it signals. • Statically allocated, fixed sized frames allow us to know the memory requirements of a component at compile time, and avoid the overhead associated with dynamic allocation.

8. Tasks • Perform the primary computation work • Atomic with respect to other tasks, and run to completion, but can be preempted by events • Allow the OS to allocate a single stack assigned to the currently executing task • Call lower level commands • Signal higher level events • Schedule other tasks within a component • Simulate concurrency using events

9. Commands • Non-blocking requests to lower level components • Deposit request parameters into a component’s frame, and post a task for later execution • Can also invoke lower level commands, but cannot block • To avoid cycles, commands cannot signal events • Return status to the caller

10. Events • Event handlers deal with hardware events (interrupts) directly or indirectly • Deposit information into a frame • Post tasks • Signal higher level events • Call lower level commands

11. TOS Component //AM.comp// TOS_MODULE AM; ACCEPTS{ char AM_SEND_MSG(char addr, char type, char* data); void AM_POWER(char mode); char AM_INIT(); }; SIGNALS{ char AM_MSG_REC(char 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 AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT(); }; AM_SEND_MSG AM_POWER AM_INIT AM_MSG_SEND_DONE AM_MSG_REC Messaging Component Internal State Internal Tasks AM_SUB_POWER AM_TX_PACKET_DONE AM_SUB_TX_PACKET AM_RX_PACKET_DONE AM_SUB_INIT Commands Events

12. Putting It All Together • The task scheduler is a simple FIFO scheduler. • The scheduler puts the processor to sleep when the task queue is empty. • Peripherals keep operating and can wake up the processor. • Communication across components takes the form of a function call. This results in low overhead, and allows compile time type checking.

13. Sample Application • The sample application is consisting of a number of sensors distributed within a localized area • Monitor temperature and light conditions • Periodically transmit measurements to a base station

14. Sample Application (cont) • Sensors can forward data for other sensors that are out of range of the base station • Dynamically determine the correct routing topology for the network Image courtesy Jason Hill et al

15. Ad hoc Routing Application application Active Messages packet Serial Packet Temp Radio Packet SW byte HW UART Radio byte I2C Photo bit Clocks RFM Internal Component Graph Slide courtesy Jason Hill et al

16. 2 1 2 1 3 Ad hoc Routing • Base station periodically broadcasts route updates • Any sensors in range of this broadcast record the identity of the base station, and rebroadcast the update • Each sensor remembers the first update received in an era, and uses the source of the update as the destination for routing data back to the base station 0 Base Image courtesy Jason Hill et al

17. Resource requirements

18. Internal Tasks Messaging Component Internal State Events Commands Review • Component interface: • commands accepts (implemented) • commands uses • events accepts (implemented) • events uses • Component implementation • functions that implement interface • frame: internal state • tasks: concurrency control

19. comp3 comp1: C code comp4 Programming Model • Components • .comp: specification • .C: behaviour • .desc: select and wire • specification: • accepts commands • uses commands • signals events • handles events comp2: .desc application: .desc

20. Programming Model • 4 kinds of components: • .desc only (ex: cnt_to_leds) • .C and .comp (ex: CLOCK) • .desc and .comp (ex: GENERIC_COMM) • .C, .comp and .desc (ex: INT_TO_RFM)

21. Programming Model • (4th type) component := interface (.comp) + implementation (.c) + wiring (.desc) <CompName>.comp TOS_MODULE <CompName>; ACCEPTS { // command_signatures }; HANDLES { // event_signatures }; USES { // command_signatures }; SIGNALS { // event_signatures };

22. Programming Model <CompName>.c #include "tos.h" #include “<CompName>.h" #define TOS_FRAME_TYPE TOS_FRAME_BEGIN(< CompName >_frame) { // state declaration } TOS_FRAME_END(< CompName >_frame); char TOS_COMMAND(<command_name)(){ // command implementation } char TOS_EVENT(<event_name>)(){ // event implementation }

23. Programming Model <CompName>.desc // Component Selection INCLUDE { MAIN; <CompName>; <Comp_I>; <Comp_J>; … }; // Wiring <CompName>.<command> <Comp_I>.<command> … <CompName>.<event> <Comp_J>.<event> …

24. MAIN main_sub_init main_sub_start BLINK blink_init blink_start CLOCK LED blink_sub_init blink_clock_event blink_ledy_on blink_ledy_off clock_init clock_fire_event yellow_led_on yellow_led_off TOS 101: the Blink example • example app that handles the clock events to update LEDs like a counter

25. TOS 101: the Blink example blink.desc include modules { MAIN; BLINK; CLOCK; LEDS; }; BLINK:BLINK_INIT MAIN:MAIN_SUB_INIT BLINK:BLINK_START MAIN:MAIN_SUB_START BLINK:BLINK_LEDy_on LEDS:YELLOW_LED_ON BLINK:BLINK_LEDy_off LEDS:YELLOW_LED_OFF BLINK:BLINK_LEDr_on LEDS:RED_LED_ON BLINK:BLINK_LEDr_off LEDS:RED_LED_OFF BLINK:BLINK_LEDg_on LEDS:GREEN_LED_ON BLINK:BLINK_LEDg_off LEDS:GREEN_LED_OFF BLINK:BLINK_SUB_INIT CLOCK:CLOCK_INIT BLINK:BLINK_CLOCK_EVENT CLOCK:CLOCK_FIRE_EVENT

26. TOS 101: the Blink example blink.comp TOS_MODULE BLINK; ACCEPTS{ //commands char BLINK_INIT(void); char BLINK_START(void); }; HANDLES{ // events void BLINK_CLOCK_EVENT(void); }; USES{ // commands char BLINK_SUB_INIT(char interval, char scale); char BLINK_LEDy_on(); char BLINK_LEDy_off(); char BLINK_LEDr_on(); char BLINK_LEDr_off(); char BLINK_LEDg_on(); char BLINK_LEDg_off(); }; SIGNALS{ //events };

27. TOS 101: the Blink example blink.c #include "tos.h" #include "BLINK.h" //Frame Declaration #define TOS_FRAME_TYPE BLINK_frame TOS_FRAME_BEGIN(BLINK_frame) { char state; } TOS_FRAME_END(BLINK_frame); /* BLINK_INIT: Clear all the LEDs and initialize state */ char TOS_COMMAND(BLINK_INIT)(){ TOS_CALL_COMMAND(BLINK_LEDr_off)(); TOS_CALL_COMMAND(BLINK_LEDy_off)(); TOS_CALL_COMMAND(BLINK_LEDg_off)(); VAR(state)=0; TOS_CALL_COMMAND(BLINK_SUB_INIT)(tick1ps); return 1; }

28. TOS 101: the Blink example blink.c (cont.) /* BLINK_START: initialize clock component to generate periodic events. */ char TOS_COMMAND(BLINK_START)(){ return 1; } /* Clock Event Handler: Toggle the Red LED on each tick. */ void TOS_EVENT(BLINK_CLOCK_EVENT)(){ char state = VAR(state); if (state == 0) { VAR(state) = 1; TOS_CALL_COMMAND(BLINK_LEDr_on)(); } else { VAR(state) = 0; TOS_CALL_COMMAND(BLINK_LEDr_off)(); } }

29. nesC Programming Language • Goals: • pragmatic low-level language for programming motes • intermediate language for future high-level languages

30. nesC Programming Language comp3 comp1: module • Components: • implementation - module: C behaviour • configuration:select and wire • interfaces • provides interface • requires interface comp4 comp2: configuration application: configuration

31. nesC Programming Language • 2 kinds of components: • configuration: was .desc and .comp • module: was .C and .comp

32. nesC Blink example blink.td (configuration) configuration Blink { } implementation { uses Main, BlinkM, Clock, Leds; Main.SimpleInit -> BlinkM.SimpleInit; BlinkM.Clock -> Clock; BlinkM.Leds -> Leds; }

33. nesC Blink example blinkM.td (module) module BlinkM { provides { interface SimpleInit; } requires { interface Clock; interface Leds; } } implementation { bool state; command result_t SimpleInit.init() { state=FALSE; return SUCCESS; } ...

34. nesC Blink example blinkM.td (module) ... command result_t SimpleInit.start() { return call Clock.setRate(128, 6); } event result_t Clock.fire() { state = !state; if(state) call Leds.redOn(); else call Leds.redOff(); } }

35. nesC Programming Language • nesc1 takes a component and: • checks nesC errors • checks (most) C errors • generates one C-file for the application • avr-gcc compiles nesc1 output • generated code has #line directives, so clean error messages

36. nesC Programming Language

37. nesC Programming Language • nesC much nicer to use than TinyOS: • produces smaller code than TinyOS • get rid of the macros for frames, commands, events • eliminate wiring error through type checking • simplify wiring by using interfaces • increase modularity by separation of interfaces and modules

38. The Communication Subsystem Active Messages

39. Active Messages : Motivation • Legacy communication cannot be used : TCP/IP, sockets, routing protocols like OSPF • Bandwidth intensive • Centered on “stop and wait” semantics • Need real time constraints and low processing overhead

40. Active Messages • Integrating communication and computation • Matching communication primitives to hardware capabilities • Provides a distributed eventing model where networked nodes send events to each other • Closely fits the event-based model of TinyOS

41. Active Messages • Message contains : • User-level handler to be invoked on arrival • Data payload passed as argument • Message handlers executed quickly to prevent network congestion and provide adequate performance • Event-centric nature enables network communication to overlap with sensor-interaction

42. Active Message + TinyOS = Tiny Active Messages • Messaging is a component in TinyOS

43. Tiny Active Messages • Support for three basic primitives : • Best effort message transmission • Addressing • Dispatch • Three primitives necessary and sufficient • Applications build additional functionality on top

44. Tiny Active Messages - Details • Packet format

45. TinyDB-Design, Code and implementation

46. TinyDB-Overview • TinyDB is a query processing system for extracting information from a network of TinyOS sensors. • TinyDB provides a simple, SQL-like interface. • TinyDB provides a simple Java API for writing PC applications that query and extract data from the network

47. TinyDB-Overview Contd.. • Two Subsytems • Sensor Network Software • Sensor Catalog and Schema Manager • Query Processor • Memory Manager • Network Topology Manager • Java-based Client Interface

48. Architecture TinyDB GUI JDBC TinyDB Client API DBMS PC side 0 Mote side 0 TinyDB query processor 2 1 3 8 4 5 6 Sensor network 7

49. Data Model • Entire sensor network as one single, infinitely-longlogical table: sensors • Columns consist of all the attributesdefined in thenetwork • Typical attributes: • Sensor readings • Meta-data: node id, location, etc. • Internal states: routing tree parent, timestamp, queuelength, etc. • Nodes return NULL for unknown attributes • On server, all attributes are defined in catalog.xml

50. Query Language (TinySQL) SELECT <aggregates>, <attributes> [FROM {sensors | <buffer>}] [WHERE <predicates>] [GROUP BY <exprs> [HAVING having-list]] [EPOCH DURATION integer] [INTO <buffer>] [TRIGGER ACTION <command>]