1. Source : System Architecture Directions or Networked Sensors - Jason Hill, Robert Szewcyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister The Mica Sensing Platform – Alec Woo, Jan. 14 2002, NEST Retreat Mica Node Architecture – Jason Hill, Jan. 14 2002, WEBS Retreat All Sources could be located at: http://webs.berkeley.edu/tos/media.html Presented by Mark Miyashita 06-18-2002 TinyOS Overview

2. TinyOS Introduction Computing in a Cubic millimeter Advances in low power wireless communication technology and micro- electromechanical sensors (MEMS) transducers make this possible Continued progress in inexpensive MEMS based sensors and communication technology accelerate research in the embedded network sensor for information processing

3. TinyOS Introduction Computing in a Cubic millimeter Networked sensor is emerging area of interest as a result of advancement in RF communication technology and MEMS TinyOS (an event based operating environment) explores the software support for this emerging area of networked sensor It combines sensing, communication, and computation into single architecture Complete systems on a chip (micro controller + memory + sensors + interfaces etc)

4. Network Sensor Characteristics Use commercial components to build sensors Small Physical size (as small as square inch) Low Power consumption. Concurrency intensive operation. Limited Physical Parallelism and Controller Hierarchy Diversity in design and Usage Robust operation

5. Ad hoc sensing Autonomous nodes self assembling into a network of sensors Sensor information propagated to central collection point Intermediate nodes assist distant nodes to reach the base station Connectivity and error rates used to infer distance Routing Tree Link Connectivity Base Station

6. Previous Hardware Design MICA is the 4 th generation of the Berkeley Motes. COTS dust prototypes, by Seth Hollar weC Mote Rene Mote, manufactured by Crossbow 3.1 Dot mote, used for IDF

7. Hardware Organization (MICA) Atmel ATMEGA103Atmel ATMEGA103 4 Mhz 8-bit CPU4 Mhz 8-bit CPU 128KB Instruction Memory128KB Instruction Memory 4KB RAM4KB RAM Modes – idle, pwr down and pwr save 4 Mbit flash (AT45DB041B)4 Mbit flash (AT45DB041B) SPI interface (Serial Peripheral Interface)SPI interface (Serial Peripheral Interface) 1-4 uj/bit r/w1-4 uj/bit r/w RFM TR1000 radioRFM TR1000 radio 50 kb/s – ASK50 kb/s – ASK Internal antennaInternal antenna Focused hardware accelerationFocused hardware acceleration Network programming Network programming Serial port ---I/O pin connected to UART

8. Device Placement 2.25 in 1.25 in Microphone Accelerometer Light Sensor Temperature Sensor SounderMagnetometer

9. More on Hardware Two Board Sandwich –Main CPU board with Radio Communication –Secondary Sensor Board Allows for expansion and customization Current MICA sensors can include: Accelerometer, Magnetic Field,Temperature, Photo, Sounder, Microphone, Light, and RF Signal Strength Can control RF transmission strength & Sense Reception Strength

10. MICA

11. What is TinyOS? TinyOS is an event based operating environment design to work with embedded network sensors Designed to support concurrency intensive operations required by network sensors with minimal hardware requirements TinyOS was initially developed by the U.S. Berkeley EECS department

12. Software Challenge Concurrency intensive operations Unsynchronized, Multiple, high data flow (sensor readings, forwarding data packets etc) Low memory  data must be processed on the fly Low power consumption Bit by Bit interaction with radio ( no buffering – missed deadline  lost data) Small physical size – ( no multiple controllers, direct interface with micro controller) Modular – application specific

13. Tiny OS Overview Event driven model.--- uses CPU efficiently Two level scheduling ( Event and Tasks) System composed of state machines Each state machine is a TinyOS “component” Command and event handlers transition a module from one state to another Quick, low overhead, non-blocking state transitions Many independent modules allowed to efficiently share a single execution context No kernel/user space differentiation “Tasks” are used to perform computational work Run to completion, Atomic to respect to each other

14. Tiny OS Design Communication ActuatingSensing Communication Application (User Components) Main (includes Scheduler) Hardware Abstractions Application = scheduler + graph of components Compiled into one executable

15. Composition RFM Radio byte Radio Packet UART Serial Packet i2c Temp photo Active Messages clocks bit byte packet Route map routersensor appln application HW SW

16. Simple State Machine Logic bit_cnt++ bit_cnt==8 Send Byte Event bit_cnt = 0 Done No Yes Bit_Arrival_Event_Handler State: {bit_cnt} Start Don’t you have to do computational work eventually? “Tasks” used to perform computational work

17. Tiny OS – The Software Scheduler and graph of components constrained two-level scheduling model: tasks + events Provides a component based model abstracting hardware specifics from application programmer Capable of maintaining fine grained concurrency Can interchange system components to get application specific functionality

18. Tiny OS Component Design Every component has Frame ( storage) Tasks ( computation) Command Handler Interface Event Handler Interface Frame: static storage model - compile time memory allocation (efficiency) Command and events are function calls (efficiency) Messaging Component Internal State Internal Tasks CommandsEvents

19. Component Interface Upper Interface (from upper comp) List of commands it ACCEPTS List of events it SIGNALS Lower Interface (from lower comp) List of commands it USES List of events it HANDLES

20. 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(); }; Messaging Component AM_SUB_INIT AM_SUB_POWER AM_SUB_TX_PACKET AM_TX_PACKET _DONE AM_RX_PACKET _DONE Internal State AM_INIT AM_POWER AM_MSG_REC Internal Tasks AM_SEND_MSG AM_MSG_SEND_DONE

21. TOS Component FRAMES / MEMORY ALLOCATION Keeps the state of the component between invocation of its functions. Statically allocated. ( mem req. is known at compile time) Defined as a global structure.

22. Commands & Events(Function calls) do a small, fixed amt of work in the component’s state COMMANDS Non blocking requests to lower components Post unconditional tasks for later execution. Can call lower level commands Travel downward through the graph Events Handles Hardware events directly or indirectly Can post tasks, signal higher level events or call lower level commands. Can preempt tasks Travel upwards through the graph. COMMANDS CANNOT SIGNAL EVENTS TOS Component

23. TASKS Perform all the major work (computation) Atomic w.r.t other tasks and run to completion. Can be preempted by events.( not vice-versa) Can call lower level commands, signal higher level events and schedule other tasks. Simulate concurrency within components. Provide means to incorporate arbitrary computation into the event driven model TOS Component

24. Two level scheduling structure (events and tasks) Scheduler is simple FIFO Bound on the number of pending tasks. Tasks cannot preempt other tasks. Scheduler is power aware Puts processor into Sleep mode when queue is empty. TOS Component

25. MAIN – top component, interface to lower components only APPLICATION – Define main purpose of OS and reside below MAIN. Documentation Apps/FOO.desc – describes the component graph of an app FOO.comp – describes the interface specification FOO.c – describes the implementation of the component TOS Component

26. Group certain components together to perform a certain function. These can be treated as a single entity. Example - GENERIC_COMM – used to handle radio communication There is no separate FOO.c for component groups. TOS Component

27. AM PACKETOBJ SEC_DED_RADIO_BYTE RFM Hardware.h CONNECT RFM Bit Level Byte Level Packet Level Messaging Application Bit level control Encoding Constructs packets from bytes Interprets packets as messages Example - Generic Comm

28. ACTIVE MESSAGES PARADIGM Integrate communication with computation Sender Includes event handler identifiers with each message Receiver The event handler is automatically invoked on the target node. Fits in well into the event based execution model Handling Network Message

29. Message format Destination address (0xff for broadcast) Message type (event handler to invoke -- 255) Communication group # (to enable smaller group comm. – 0x13) Payload (30 char) PC Simulation will add additional fields to the header and wrap around fields mentioned above

30. Matching of names/arguments of caller and calling function done through preprocessor directives. File tos.h -- mapping of initial names to intermediate names. File foo.desc – specific component interface Before compilation a Perl script .desc file  super.h Super.h – mapping of preprocessor directives and function names of all related components. Compilation

31. Code size for ad hoc networking application Scheduler: 144 Bytes code Totals: 3430 Bytes code 226 Bytes data http://tinyos.millennium.berkeley.edu Space Breakdown

32. A one byte transmission uses the same energy as approx 11000 cycles of computation. Lithium Battery runs for 35 hours at peak load and years at minimum load! 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 Panasonic CR2354 560 mAh http://tinyos.millennium.berkeley.edu Power Breakdown

33. 666.4% of work is done in RFM component IIt utilizes 30.48% of CPU time for receiving IIt consumes 451.17nJ per bit of energy Components Packet reception work breakdownCPU UtilizationEnergy (nj/Bit) AM 0.05%0.20%0.33 Packet 1.12%0.51%7.58 Ratio handler 26.87%12.16%182.38 Radio decode thread 5.48%2.48%37.2 RFM 66.48%30.08%451.17 Radio Reception --1350 Idle-54.75%- Total 100.00% 2028.66 Work & Time breakdown

34. Panasonic CR2354 560 mAh http://tinyos.millennium.berkeley.edu Sample tradeoffs

35. Ad hoc networking Each node needs to determine it’s parent and its depth in the tree Each node broadcasts out when parent is known At start, Base Station knows it is at depth 0 It send out Individuals listen for minimum depth parent 0 1 1 2 2 3

36. Conclusions Small memory footprint Non-preemptable FIFO task scheduling Power efficient  Put micro controller 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

37. Conclusion Driving force Smaller, low power and cheaper TinyOS is Highly modular software environment stressing efficiency Concurrency More Info http://webs.berkeley.edu/tos/index.html