TinyOS and NesC: programming low-resource sensor networks

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

Hardware technology push towards miniaturization CMOS miniaturization  1 M trans/$  tiny (~mm 2 ), inexpensive processing and storage  1-10 mW active, 1  W passive (at 1% use 100  W average) Micro-sensors (MEMS, Materials, Circuits)  acceleration, vibration, gyroscope, tilt, magnetic, heat, motion, pressure, temp, light, moisture, humidity, barometric  chemical (CO, CO 2, 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/mm 3 ), fuel cells 10x  solar (10 mW/cm 2, 0.1 mW indoors) 1 cm 3 battery  1 year at 10 msgs/sec

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 sensors actuators network storage

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 mm 3  Low Power Consumption: < 50 mW

3 rd -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)

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

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

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 Look under Hardware Designs tab Crossbow website

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

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

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

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

Radio Power Management Radio has very high power consumption  Tx power is range dependant mW (0 dBm)  Rx power is also very high mW  Power-down sleep mode 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 ?

AVR Power Management Low Power operation – 15 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”

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

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 User System Physical Layer Data Link Network Transport Network Stack Threads Address Space Drivers Files Application Routers

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

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.

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

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

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

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

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 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_sen d_done) internal thread Commands Events

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

Interface Bidirectional interfaces support split-phase execution

TOS Execution Model 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 RFM Radio byte Radio Packet bit byte packet event-driven bit-pump event-driven byte-pump event-driven packet-pump message-event driven active message application comp encode/decode crc data processing

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

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.

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

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

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

Challenges Event-driven: Driven by interaction with environments 1. Motes are event driven. React to changes in the environment (i.e. message arrival, sensor acquisition) rather then interactive or batch processing. 2. 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.

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? LED Counter Component D Application configuration Radio Component F

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

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

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 TimerM ClockC 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

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

Interface Examples 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); } StdControl.ncTimer.nc ReceiveMsg.ncSendMsg.nc

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

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

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

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

A Module 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; } Implements interfaces with decorated C code

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 }

Parameterized Interfaces in Modules parameterized interfaces:  i.e., it provides 256 instances of SendMsg and RecvMsg interfaces  they are not strictly necessary – the handler ID can be passed as an argument to the send method module GenericComm { provides interface SendMsg [uint8_t id]; provides interface ReceiveMsg [uint8_t id]; … } implementation {… } GenericComm.nc

A Configuration 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; } Define a wiring showing how components are to be connected. I.e., a linker:

Configurations 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:  endpoint 1 = endpoint 2  endpoint 1 -> endpoint 2  endpoint 1 <- endpoint 2 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; } 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; }

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)

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 Task void send(){ //get head of send queue //send message if (queue.size > 0) post send() } Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands while(1) { while(more_tasks) schedule_task; sleep; }

Posting Tasks 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; }… } BlinkM.nc

Language features for concurrency post  Puts a function on a task queue  Must be void foo(void)  void task do-work() { //do something }  post do-work(); atomic  Interrupts can preempt execution  Turn off interrupts with atomic{ }  E.g. to implement a semaphore async  Use async to tell compiler that this code can be called from an interrupt context – used to detect potential race conditions norace  Use norace to tell compiler it was wrong about a race condition existing (the compiler usually suggests several false positives)

Example “Surge”: A Sensor Application Simple application that performs periodic sampling and using ad hoc routing over wireless network to deliver information to base station. Each node listens to messages and chooses node with least depth to be parent. Base station will periodically broadcast beacon messages with depth 0. Each node estimates parent’s link quality, if link quality falls below that, node selects new parent from their neighbor set based on link quality estimates and depth. If node receives message from another node, it forwards that message to its parent.

Examples of Components

Concurrency In nesC To handle events and concurrency, nesC provides 2 tools: atomic sections and tasks. Atomicity is implemented by simply disabling/enabling interrupts (this only takes a few cycles).  Disabling interrupts for a long time can delay interrupt handling and make systems less responsive. If potential race condition is present and programmer knows its not an actual race condition, can specify something as “norace”.

Evaluation Tested for three TinyOS applications  Surge, Mate, TinyDB Core TinyOS consists of 172 components  108 modules & 64 configurations Group necessary components, via nesC’s bidirectional interfaces, for a specific application

Remaining issues in NesC Static memory allocation  Advantages Offline analysis of memory requirements  No problem? No dynamic allocation Short code only in atomic sections & command/event handlers Little language support for real-time programming

nesC Summary nesC was originally designed to express concepts embodied in TinyOS. Focus on holistic system design by making it easy to assemble apps that include only the necessary OS parts. Component model allows alternate implementation and flexible hardware/software boundaries. Concurrency model allows highly concurrent programs with limited resources. Use of bidirectional interfaces and atomic statements permits tight integration of concurrency and component oriented design. Lack of dynamic allocation and explicit specification of apps call graph make it easier to run whole-program analysis and optimizations.  Aggressive in-lining reduces memory footprint and static data- race detection reduces bugs.

More on NesC for your programming Details and tips that are useful for you to program in NesC and TinyOS  Naming convention  Compiling  Directory  Makefile  …

Programming Environment OS: cygwin/Win2000 or gcc/Linux Software: atmel tools, java, perl mote programming board mote-PC comms Code download

nesC details naming conventions:  nesC files suffix:.nc  C stands for Configuration (Clock, ClockC)  M stands for Module (Timer, TimerC, TimerM) ● clarifications: – “C” distinguishes between an interface and the component that provides it – “M” when a single component has both: a configuration, a module

Compiling an application Avr cross-compilation  Specify platform, programming interface, mote ID  To make and install a binary with ID of 3: make mica2 install.3  To install a preexisting binary with ID of 12: make mica2 reinstall.12 Pc native compilation  Create a binary that runs on your pc for debugging and simulation  Make pc, make emstar

Directory structure tos-contrib – where all contributed projects go  Makecontrib –top-level build info for projects in tos-contrib  project-name – a particular project that has been contributed apps – the applications written for this project  Makefile  Directives for all application in this project  Makerules  Foo-App  Makefile – define TOSH_DATA_LENGTH, sensorboards, etc  Foo-App.nc – top-level configuration for the application  Foo-AppM.nc - non-reusable application-specific code lib - Configurations and modules defined for the project interfaces - interfaces defined to be used with the modules and configurations in lib tinyos-1.x has same structure (apps, lib, interfaces) as tos-contrib

Build system An application’s Makefile… COMPONENT=MultihopDse CONTRIB_INCLUDES += EmTos hostmote sensorIB dse #SENSORBOARD=basicsb SENSORBOARD=mda300ca CFLAGS += -DCC1K_DEFAULT_FREQ=2 CFLAGS += -DTOSH_DATA_LENGTH=50 CFLAGS += -DLPL_MODE=0 CFLAGS += -DSTATUS_DBG CFLAGS += -DHOSTMOTE_MAX_SEND_DATA_LENGTH=66 #CFLAGS += -DHOSTMOTE_DEBUG include../Makerules

Contrasting Emstar and TinyOS Many similar design choices  programming framework Component-based design “Wiring together” modules into an application  Event-driven reactive to “sudden” sensor events or triggers  Robustness Nodes/system components can fail Many differences  Platform-dependent constraints Emstar: Develop without optimization TinyOS: Develop under severe resource-constraints  Operating system and language choices Emstar: easy to use C language, tightly coupled to linux (devfs) TinyOS: an extended C-compiler (nesC), not wedded to any particular OS.

Build system integration with Emstar Tricky to get TinyOS and Emstar to play nice Read: Basically, a few symbolic links need to be established To build in emstar:  $EMSTAR_ROOT points to your emstar distribution  $TOSDIR points to your TinyOS distribution  in Make.conf set BUILD_EMTOS to 1  make [ARCH=mica2]

Debugging using print statements TinyOS’s printf:  dbg(DBG_USR1, “%s [%d] – link quality is %d\n”, __FILE__, __LINE__, link_quality); DBG_USR1, DBG_USR2, DBG_USR3, and DBG_ERROR are defined for your enjoyment