TinyOS Overview

1. TinyOS Overview • 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

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. Routing Tree Link Connectivity 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 Base Station

6. Previous Hardware Design • MICA is the 4th 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 ATMEGA103 • 4 Mhz 8-bit CPU • 128KB Instruction Memory • 4KB RAM • Modes – idle, pwr down and pwr save • 4 Mbit flash (AT45DB041B) • SPI interface (Serial Peripheral Interface) • 1-4 uj/bit r/w • RFM TR1000 radio • 50 kb/s – ASK • Internal antenna • Focused hardware acceleration • Network programming • Serial port ---I/O pin connected to UART

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

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. Main (includes Scheduler) Application (User Components) Actuating Sensing Communication Communication Hardware Abstractions Tiny OS Design Application = scheduler + graph of components • Compiled into one executable

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

16. Simple State Machine Logic Bit_Arrival_Event_Handler State: {bit_cnt} Start Send Byte Eventbit_cnt = 0 Yes bit_cnt==8 bit_cnt++ Done No • 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. Messaging Component Internal State Internal Tasks Commands Events 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)

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(); }; AM_POWER AM_INIT AM_SEND_MSG 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

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. TOS Component • 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

23. TOS Component • TASKS • Perform all the major work (computation) • Atomic w.r.t other tasks and run to completion. • Can be preemptedby 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

24. TOS Component • 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.

25. TOS Component • 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

26. TOS Component • 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.

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

28. Handling Network Message • 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

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. Compilation • 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.

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

32. Power Breakdown Panasonic CR2354 560 mAh • 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! http://tinyos.millennium.berkeley.edu

33. Work & Time breakdown Components Packet reception work breakdown CPU Utilization Energy (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% 100.00% 2028.66 • 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

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

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

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