TinyOS and NesC: programming low-resource sensor networks

1. TinyOS and NesC:programming low-resource sensor networks

2. OS Design: Different platforms need different solutions Highly constrained (memory, CPU, storage, power) Solutions: TinyOS,… StarGate Capabilities MK - II Ample resources Solutions: Linux, uCos, Emstar… MICA Mote Spec Size, Power Consumption, Cost

3. Hardware technology push towards miniaturization • CMOS miniaturization • 1 M trans/$  tiny (~mm2), inexpensive processing and storage • 1-10 mW active, 1 mW passive (at 1% use 100 mW average) • Micro-sensors (MEMS, Materials, Circuits) • acceleration, vibration, gyroscope, tilt, magnetic, heat, motion, pressure, temp, light, moisture, humidity, barometric • chemical (CO, CO2, radon), biological, micro-radar, ... • actuators too (mirrors, motors, smart surfaces, micro-robots) • Communication • short range, low bit-rate, CMOS radios (1-10 mW) • Power • batteries remain primary storage (1,000 mW/mm3), fuel cells 10x • solar (10 mW/cm2, 0.1 mW indoors) • 1 cm3 battery  1 year at 10 msgs/sec

4. sensors actuators storage network Sensor Impact on OS Design • Small physical size and low power consumption • Concurrency-intensive operation • multiple flows, not wait-command-respond => never poll, never block • Limited Physical Parallelism and Controller Hierarchy • primitive direct-to-device interface • Asynchronous and synchronous devices => interleaving flows, events, energy management • Diversity in Design and Usage • application specific, not general purpose • huge device variation => efficient modularity => migration across HW/SW boundary • Robust Operation • numerous, unattended, critical => narrow interfaces

5. History of the Mote Sensor Node • Jason Hill’s Master’s Thesis (UCB) • PhD Dissertation was a prototype for a smart-dust system on a chip • Small physical size: 1 mm3 • Low Power Consumption: < 50 mW

6. 3rd-generation mote (mica2) • Constraints • 4KB RAM • 128KB Program Flash Memory • >25mA (Tx), <15uA (sleep) at 3.3V • 8MHz Microcontroller • 19.2Kbps (at 433 or 916MHz) • Other exciting details • 512KB Measurement Flash • 4KB Configuration EEPROM • 10bit ADC • 3 LEDs • 51pin expansion connector • Transmission range ~500ft outdoor • Runs on 2 AA batteries (backside)

7. Sensor Node Hardware Architecture 3 subsystems: • Processing subsystem • Sensing subsystem • Radio communication subsystem

8. Processing Sub-System • Functions • Application Execution • Resource Management • Peripheral Interaction • Atmel AVR ATMEGA128L • RISC Architecture • 8 bit ALU/data-path • 128 Kb FLASH - Code • 4 Kb SRAM - Data • Multiple peripherals Details are available in the ATMEGA128L Datasheet

9. Sensing Sub-System • Functions • Sampling physical signals/phenomena • Different types of sensors • Photo-sensor • Acoustic Microphone • Magnetometer • Accelerometer • Sensor Processor Interface • 51 Pin Connector • ON-OFF switches for individual sensors • Multiple data channels Sensors consume power Turn them off after sampling ! • Useful Link/Resources • http://www.tinyos.net/ • Look under Hardware Designs tab • Crossbow website • http://www.xbow.com

10. Total Solar Radiation Photosynthetically Active Radiation Resolution: 0.3A/W Relative Humidity Accuracy: ±2% Barometric Pressure Accuracy: ±1.5mbar Temperature Accuracy: ±0.01oC Acceleration 2 axis Resolution: ±2mg Designed by UCB w/ Crossbow and UCLA Example: Mica Weather Board – Weather monitoring applications Revision 1.5 Revision 1.0

11. Other sensing boards • Ultrasonic transceiver – Localization • Used for ranging • Up to 2.5m range • 6cm accuracy • Dedicated microprocessor • 25kHz element • Basic Sensor board • Light (Photo), Temperature, Acceleration, Magnetometer, Microphone, Tone Detector, Sounder

12. Communication Sub-System • Functions • Transmit – Receive data packets wirelessly • Co-ordinate/Network with other nodes • Implementation • Radio • Modulation – Demodulation • Two types of radios: RFM, ChipCon CC1000 • RFM: Mica & predecessors • CC1000: Mica2 onwards • AVR • Protocol Processing

13. AVR Peripherals • UART • Serial communication with the PC • SPI – Serial Peripheral Interface • Synchronous serial communication • Interface to Radio in the Mote • ADC • Analog – Digital Converter • Digitizing sensor readings • I/O Ports • General Purpose Input Output pins (GPIO) • Used to light up LEDs in Mote

14. Radio Power Management • Radio has very high power consumption • Tx power is range dependant - 49.5 mW (0 dBm) • Rx power is also very high - 28.8 mW • Power-down sleep mode - 0.6 uW • Above data for CC1000, 868 MHz • Radio power management critical • Idle state channel monitoring power = Rx Power • Put radio to sleep when not in use • But then, how do we know when somebody is trying to contact us ?

15. AVR Power Management • Low Power operation – 15 mW @ 4 MHz • Multiple Sleep Modes • Sleep Modes: Shutdown unused components • Idle Mode – 6 mW • CPU OFF, all peripherals ON • CPU “woken up” by interrupts • Power Down Mode – 75 uW • CPU and most peripherals OFF • External Interrupts, 2 Wire Interface, Watchdog ON • Power Save Mode – 120 uW • Similar to Power Down • Timer0 continues to run “asynchronously”

16. Typical sensor network operation • Sensing Subsystem • Keep the very low power sensors on all the time on each node in the network • Processing subsystem • Low-power sensors interrupt (trigger) processor when “events” are identified OR • Processor wakes up periodically on clock interrupt, takes a sample from sensor, processes it, and goes back to sleep. • Radio subsystem • Processor wakes up radio when event requires collaborative processing or multi-hop routing. • Tiered architectures of above subsystems can be envisaged in other platforms

17. Why not use Traditional Internet Systems? • Well established layers of abstractions • Strict boundaries • Ample resources • Independent apps at endpoints communicate pt-pt through routers • Well attended Application Application User System Network Stack Transport Threads Network Address Space Data Link Files Physical Layer Drivers Routers

18. Sensor network by comparison ... • Highly Constrained resources • processing, storage, bandwidth, power • Applications spread over many small nodes • self-organizing Collectives • highly integrated with changing environment and network • communication is fundamental • Concurrency intensive in bursts • streams of sensor data and network traffic • Robust • inaccessible, critical operation

19. Goals for TinyOS and NesC • Flexibility • new sensor network nodes keep emerging • Telos, iMote, mica2, mica2Dot, etc. • Flexible hardware/software interface • Future designs may require different HW/software interfaces and may move service (MAC, e.g.) into hardware or software • Modularity • Component model • Sensor Network Challenges • Address the specific and unusual challenges of sensor networks: • limited resources, concurrency- intensive operation, a need for robustness, and application-specific requirements.

20. Do they meet these goals? • Static allocation allows for compile-time analysis, but can make programming harder • Does satisfying these goals warrant a new programming language? • Why not java? • The challenges (such as robustness) are often solved in the details of implementation. • While the language (nesC) offers some types of checking, whole-system robustness is not necessarily dependent on the language used

21. Missing from their goals… • Heterogeneity • Support for other platforms (e.g. stargate) • Support for high data rate apps (e.g. acoustic beam-forming) • Interoperability with other software frameworks and languages • Visibility • Debugging • Network management • Intra-node fault tolerance

22. application = scheduler + graph of components • event-driven architecture • single shared stack • NO kernel, process/memory management, virtual memory TinyOS: Operating System for Sensor Nodes

23. Application = Graph of Components Route map router sensing application application Active Messages Serial Packet Radio Packet packet Temp photo SW Example: ad hoc, multi-hop routing of photo sensor readings HW UART Radio byte ADC byte 3450 B code 226 B data clocks RFM bit Graph of cooperating state machines on shared stack

24. msg_rec(type, data) msg_send_done) Basic Concepts in Tiny OS • Scheduler + Graph of Components • constrained two-level scheduling model: threads + events • Component: • Commands, • Event Handlers • Frame (storage) • Tasks (concurrency) • Constrained Storage Model • frame per component, shared stack, no heap • Very lean multithreading • Efficient Layering Events Commands send_msg(addr, type, data) power(mode) init Messaging Component internal thread Internal State TX_packet(buf) Power(mode) init RX_packet_done (buffer) TX_packet_done (success)

25. Component • A component provides and uses interfaces • The interfaces are the only point of access to the component • An interface models some service, e.g., sending a message • The provider of a command implements the commands, while the user implements the events

26. Interface • Bidirectional interfaces support split-phase execution

27. Radio Packet packet Radio byte byte RFM bit TOS Execution Model data processing • Commands request action • ack/nack at every boundary • call command or post task • Events notify occurrence • HW interrupt at lowest level • may signal events • call commands • post tasks • Tasks provide logical concurrency • preempted by events • Migration of HW/SW boundary application comp message-event driven active message event-driven packet-pump crc event-driven byte-pump encode/decode event-driven bit-pump

28. Task and Event Based Concurrency • Two sources of concurrency in TinyOS: tasks and events. • Tasks are deferred mechanisms of computation that run to completion. Can’t preempt other tasks. • Components post task, then the post operation returns. Task is later run by scheduler. • Components use task when time restriction is not strict. • Tasks should be short. Long operations should be broken up into small tasks. • Lifetime requirements of sensor networks prohibit heavy computation (reactive). • Events also run to completion. Events can preempt tasks or another event. • Events signify completion of split-phase operation or event from environment. • TinyOS execution is driven by events representing hardware interrupts

29. Split-Phase Operations • Because tasks execute non-preemptively, TinyOS has no blocking operations. • All long-latency ops are split-phase meaning operation requests and completions are separate functions. Non-split phase ops don’t have completion events (i.e. toggle LED). • Commands are requests to start and operation. Events signal completion of operation. • Send a packet example: one component invokes send, another communication component signals sendDone when packet is sent.

30. TinyOS Summary • Component-based architecture • An application wires reusable components together in a customized way • Tasks and event-driven concurrency • Tasks & events run to completion, but an event can preempt the execution of a task or an event • Tasks can’t preempt another task or event • Split-phase operations (for non-blocking operations) • A command will return immediately and an event signals the completion

31. What is nesC? • Extension of C • C has direct Hardward control • Many programmers already know C • nesC provides safety check missing in C • Whole program analysis at compile time • Detect race conditions -> Eliminate potential bugs • Aggressive function inlining -> Optimization • Static language • No dynamic memory allocation • No function pointers • Call graph and variable access are fully known at compile time • Supports and reflects TinyOS’s design • Based on the component concept • Directly supports event-driven concurrency model • Addresses the issue of concurrent access to shared via atomic section and norace keyword

32. Key Properties • All resources are known statically • No general-purpose OS, but applications are built from a set of reusable system components coupled with application-specific code • HW/SW boundaries may vary depending on the application & HW platform -> Flexible decomposition is required

33. Challenges • Event-driven: Driven by interaction with environments • Motes are event driven. React to changes in the environment (i.e. message arrival, sensor acquisition) rather then interactive or batch processing. • Event arrival and data processing are concurrent. Must now address potential bugs like race conditions. • Limited resources • Reliability • Need to enable long-lived applications. Hard to reach motes, therefore must reduce run-time errors since only option is reboot. • Soft real-time requirements • Although tasks like radio management/sensor polling are time critical, they do not focus on hard real-time guarantees. • Timing constraints are easily met by having complete control over OS and app. • Radio link is timing critical but since radio link is unreliable, not necessary to meet hard deadline.

34. LED Application Counter Radio configuration configuration nesC • the nesC model: • interfaces: • uses • provides • components: • modules • configurations • application:= graph of components • Why is this a good choice for a sensor net language? Application Component D Component F

35. Each mote runs a single application • Properties • All memory resources are known statically • Rather than employing a general-purpose OS, applications are built from a suite of reusable system components coupled with application-specific code • The hardware/software boundary varies depending on the application and hardware platform; it is important to design software for flexible decomposition • Challenges: • Driven by interaction with the environment (interrupts) • Limited resources (motes) • Reliability • Soft real-time requirements (radio management and sensor polling) • Lacking common service • Time synchronization

36. Applications are written by assembling components • Anatomy of a component • Interfaces • Implementation • Default handlers • Anatomy of an application • Main component for initialization, start, stop • Connected graph of components

37. TimerM ClockC Interfaces • Define “public” methods that a component can use • used for grouping functionality, like: • standard control interface (init, start, stop) • describe bidirectional interaction: • interface provider must implement commands • interface user must implement events interface IntOutput { /* Output the given integer. */ command result_t output(uint16_t value); /* Signal that the output operation has completed */ event result_t outputComplete(result_t success); } IntOutput.nc

38. Commands/Events • commands: • deposit request parameters into the frame • are non-blocking • need to return status  postpone time consuming work by posting a task • can call lower level commands • events: • can call commands, signal events, post tasks, can not be signaled by commands • preempt tasks, not vice-versa • interrupt trigger the lowest level events • deposit the information into the frame

39. interface StdControl { command result_t init (); command result_t start (); command result_t stop (); } interface Timer { command result_t start (char type, uint32_t interval); command result_t stop (); event result_t fired (); } interface SendMsg { command result_t send (uint16_t addr, uint8_t len, TOS_MsgPtr p); event result_t sendDone (); } interface ReceiveMsg { event TOS_MsgPtr receive (TOS_MsgPtr m); } Interface Examples StdControl.nc Timer.nc SendMsg.nc ReceiveMsg.nc

40. Split-phase Interfaces • Operation request and completion are separate functions: • No blocking operations because tasks execute non-preemptively • The usual way to do this is to register a callback by passing a function pointer interface SendMsg { command result_t send (uint16_t address, uint8_t length, TOS_MsgPtr p); event result_t sendDone (TOS_MsgPtr msg, result_t success); } SendMsg.nc

41. Parameterized Interfaces • Can associate a port with an interface, so that a provider can distinguish users • Used because the provider doesn’t know how many users will be connecting to it configuration CntToLeds { } implementation { components Main, Counter, IntToLeds, TimerC; Main.StdControl -> IntToLeds.StdControl; Main.StdControl -> Counter.StdControl; Main.StdControl -> TimerC.StdControl; Counter.Timer -> TimerC.Timer[unique("Timer")]; Counter.IntOutput -> IntToLeds.IntOutput; } CntToLeds.nc

42. Component Implementation • Two types of components: modules & configurations • Modules provide application code and implements one or more interfaces • Configurations wire components together • Connect interfaces used by components to interfaces provided by others

43. Component Frame Tasks Commands Events • Commands and Events are function calls • Application: linking/glueing interfaces (events, commands) Modules • A module has: • Frame (internal state) • Tasks (computation) • Interface (events, commands) • Frame : • one per component • statically allocated • fixed size

44. A Module • Implements interfaces with decorated C code module Counter { provides { interface StdControl; } uses { interface Timer; interface IntOutput; } } Implementation { int state; command result_t StdControl.init(){ state = 0; return SUCCESS; } command result_t StdControl.start(){ return call Timer.start(TIMER_REPEAT,250); } command result_t StdControl.stop(){ return call Timer.stop(); } event result_t Timer.fired(){ state++; return call IntOutput.output(state); } event result_t IntOutput.outputComplete(result_t success){ if(success == 0) state --; return SUCCESS; } }

45. Modules • Module declaration • Provides • Which interfaces will be implemented by this module • Uses • Which interfaces the module will need to use • Module implementation • Interface methods implemented • All command for “provides” and events for “uses” • Keyword “includes” goes before module declaration • Semantic equivalent of #include, with caveats: • No cpp directives allowed • Practical hack: • Put #include in implementation block includes Foo; module ExampleM { provides { interface StdControl; } uses { interface Timer; } } implementation { #include “foo-constants.h” ... command result_t StdControl.start(){ return call Timer.start(TIMER_REPEAT,250); } ... event result_t Timer.fired(){ // do something } }

46. A Configuration • Define a wiring showing how components are to be connected. I.e., a linker: configuration CntToLeds { } implementation { components Main, Counter, IntToLeds, TimerC; Main.StdControl -> IntToLeds.StdControl; Main.StdControl -> Counter.StdControl; Main.StdControl -> TimerC.StdControl; Counter.Timer -> TimerC.Timer[unique("Timer")]; Counter.IntOutput -> IntToLeds.IntOutput; }

47. Configurations configuration CntToLeds { } implementation { components Main, Counter, IntToLeds, TimerC; Main.StdControl -> IntToLeds.StdControl; Main.StdControl -> Counter.StdControl; Main.StdControl -> TimerC.StdControl; Counter.Timer -> TimerC.Timer[unique("Timer")]; Counter.IntOutput -> IntToLeds.IntOutput; } • Configurations refer to configurations and modules • No distinction between an included configuration and an included module • Configuration can expose an underlying module’s interface • An application must connect a Main component to other components • connected elements must be compatible (interface-interface, command-command, event-event) • 3 wiring statements in nesC: • endpoint1 = endpoint2 • endpoint1 -> endpoint2 • endpoint1 <- endpoint2 configuration TimerC { provides interface Timer[uint8_t id]; provides interface StdControl; } implementation { components TimerM, ClockC, NoLeds, HPLPowerManagementM; TimerM.Leds -> NoLeds; TimerM.Clock -> ClockC; TimerM.PowerManagement -> HPLPowerManagementM; StdControl = TimerM; Timer = TimerM; }

48. Concurrency • Tasks and interrupts (foreground and background operations) • Tasks cannot preempt other tasks • Low priority for performing computationally intensive work • Interrupts can preempt tasks • Interrupts can preempt other interrupts, but not important for this course • TOSH_INTERRUPT() – interrupt allowed • TOSH_SIGNAL() – interrupt forbidden • Scheduler • Two level scheduling - interrupts (vector) and tasks (queue) • Queue of tasks • No associated priorities • FIFO execution • No local state associated with tasks • Programmer must manage own internal state when tasks need it • Danger: task queue overflows (because no dynamic memory)

49. Tasks Preempt POST events commands commands Interrupts Time Hardware FIFO What the scheduler does… • Operation • When no tasks pending, sleep • Wake on interrupt, lookup interrupt handler and execute • Before sleeping again, check task queue, call task in FIFO order • Practices • Statically defined maximum queue length means code should be carefully written to avoid posting too many tasks • E.g., if we have a list of thing to process (such as messages), rather than post a separate task for each message, post the next processing task at the end of the task handler while(1) { while(more_tasks) schedule_task; sleep; } Task void send(){ //get head of send queue //send message if (queue.size > 0) post send() }

50. module BlinkM {… } implementation {… task void processing () { if(state) call Leds.redOn(); else call Leds.redOff(); } event result_t Timer.fired () { state = !state; post processing(); return SUCCESS; }… } Posting Tasks BlinkM.nc