INTRODUCTION TO TINYOS 2.X AND NESC

Anatomy of TelosB Mote  Limited computational and communication resources  MSP bit microcontroller 10kB RAM  250 kbps, high data rate radio  Sensors (temperature, humidity, light)  Data collection and programming via USB interface  48kB of flash program memory  IEEE compliant  A pair of AA batteries (4 days)

Typical WSN Application  Periodic  Data Collection  Network Maintenance  Triggered Events  Detection/Notification  Infrequently occurs  Long Lifetime  Months to Years without changing batteries  Power management is the key to WSN success sleep wakeup processing data acquisition communication Power Time

TinyOS  TinyOS is designed for the small, low-power microcontrollers motes have.  MAIN AIM: saving power!  2 nd AIM: easy development of applications!  TinyOS applications and systems, as well as the OS itself is written in nesC a dialect of C.

TinyOS  Component-based architecture  Event-driven operating system  Developed for resource constrained wireless sensor networks  Ultimately not limited by WSN’s.  TinyOS, libraries, applications written in nesC  NesC language  A dialect of C Language with extensions for components  Features a task scheduler  Automatically puts the microcontroller to sleep when there is no code to execute  Allows for concurrency  Lets execution be split-phase

Software Challenges  Power efficient  Put microcontroller and radio to sleep  Small memory footprint  Non-preemptable FIFO task scheduling  Efficient modularity  Function call (event and command) interface between commands  Application specific  Concurrency-intensive operation  Event-driven architecture  No user/kernel boundary

TinyOS  Component based architecture allows frequent changes while still keeping the size of code minimum.  Event based execution model means no user/kernel boundary and hence supports high concurrency.  It is power efficient as it makes the sensors sleep as soon as possible.  Has small footprint as it uses a non-preemtable FIFO task scheduling.

What TinyOS provides Things to make writing applications easier:  A component model which allows you to write small, reusable pieces of code and compose them into larger abstractions;  application programming interfaces (APIs), services, component libraries and an overall component structure that simplify writing new applications and services.

COMPONENT BASED ARCHITECTURE

Component-Oriented Programming  A nesC application consists of components  Components can be reused  Components can be replaced  Components can be hardware or software

Component-Oriented Programming  Object-Oriented Programming:  Focuses on the relationships between classes that are combined into one large binary executable  Component-Oriented Programming:  Focuses on interchangeable code modules that work independently and don't require you to be familiar with their inner workings to use them.

nesC vs C and C++ Each non-abstract subclass of GraphicObject, such as Circle and Rectangle, must provide implementations for the methods of the abstract class GraphicObject. Components have only private variables. No inheritance.

Component-Oriented Programming  File name and types in TinyOS:  Module (suffixed with P.nc)  Configuration (suffixed with AppC.nc) – At TOP level  Configuration (suffixed with C.nc) – At Lower level  Interface (suffixed with.nc)  Collectively, a Configuration and a Module are combined to create a Component.

Modules 1/3  Define functionality that make your application run.  Provide interfaces to other modules.  Use interfaces from other modules.  Don’t care what’s behind the interface.  Implement interface definitions  Modules are like the IC’s on a circuit board that actually do something.

Modules 2/3  Each component is specified by an interface.  A Component has: – Frame (internal states) e.g. variables, functions, etc. – Tasks (data processing) – Interface(s) (commands/events)  Commands and Events are function calls

Modules 3/3 - Implementation  Implementation of a module defines how the component works  Application code  All commands and events declared as provided in the interface MUST be implemented

Configurations  Wire interfaces from several modules together.  Wrap modules.  Are implemented by connecting interfaces of existing components.  Configurations are like a Printed Circuit Board, laying out wiring that connects modules together.

Interface: Commands/Events  Define the interactions between modules  Commands Implemented by the module providing the interface Called by the module using the interface  Events Signaled by the module providing the interface Captured by the module using the interface  Components either provide or use an interface  Provide - All interface commands MUST be implemented for users to call  Use - All interface events MUST be implemented for providers to signal

Interface Example  The Provider (implementor) of this interface must implement the start and stop commands.  The User of this interface, i.e., a components that invokes commands, must implement the event fired. Timer.nc * filename for a bidirectional interface interface Timer { command result_t start (char type uint32_t interval); command result_t stop(); event result_t fired(); }

A HELLO-WORLD EXAMPLE

Component Diagram HelloC CONFIGURATION

HelloC Configuration configuration HelloC { } implementation { }

Component Diagram HelloC MODULE HelloP

HelloC Configuration configuration HelloC { } implementation { components HelloP; }

HelloP Module module HelloP { } implementation { }

Component Diagram HelloC FUNCTIONALITY HelloP void myFunctions() {…}

HelloP Module module HelloP { uses { interface Boot; interface Leds; } implementation { }

Boot Interface interface Boot { event void booted(); } Boot sequence provides one interface:  Boot for signaling that the system has successfully booted TinyOS 2.x Boot Sequence

HelloP Module module HelloP { uses { interface Boot; interface Leds; } implementation { event void Boot.booted() { } USE an interface, CAPTURE all of its events! The HelloP module MUST implement the booted() event that is provided by the Boot Interface (see slide Interface: Commands/Events)

Leds Interface interface Leds { command void led0On(); command void led0Off(); command void led0Toggle(); … command void set(uint8_t val); }

HelloP Module module HelloP { uses { interface Boot; interface Leds as MyLeds; interface Leds as MySecondLeds; } implementation { event void Boot.booted() { call Leds.led0On(); } Keyword “as” is used when multiple usages of an interface is required (similar to the “new” keyword of Java/c++)

Component Diagram HelloC INTERFACES HelloP Leds void myFunctions() {…} Boot

Component Diagram HelloC HelloP Leds LedsC void myFunctions() {…} Boot MainC CONFIGURATIONS

HelloC Configuration configuration HelloC { } implementation { components HelloP, MainC, LedsC, SecondLedsC; // USES -> PROVIDES HelloP.Boot -> MainC.Boot; HelloP.MyLeds -> LedsC; HelloP.MySecondLeds -> SecondLedsC; }

Component Diagram HelloC HelloP Leds LedsC void myFunctions() {…} MainC Boot USES PROVIDES

RADIO COMMUNICATION

Split-Control 1/4  Because sensor nodes have a broad range of hardware capabilities, one of the goals of TinyOS is to have a flexible hardware/software boundary.  In a split-phase operation the request that initiates an operation completes immediately.  Actual completion of the operation is signaled by a separate callback.

Split-Control 2/4: Example 1  For example, to acquire a sensor reading with an analog-to-digital converter (ADC), software writes to a few configuration registers to start a sample.  When the ADC sample completes, the hardware issues an interrupt, and the software reads the value out of a data register.

Split-Control 3/4: Example 2  Packet send method in Active Messages component.  This is a long operation, involving converting the packets to bytes, then to bits and ultimately driving the RF circuits to send the bits, one by one.  A call to a split-phase operation returns immediately

Split-Control 4/4 ComponentAComponentB call Interface.doSomething(); return SUCCESS; signal Interface.done();

Radio Stacks Radio Hardware Transmit / Receive / Init CSMA / Acknowledgements ActiveMessage Message Queue Your Application Receive SplitControl AMSend

Main Radio Interfaces  SplitControl  Provided by ActiveMessageC  AMSend  Provided by AMSenderC  Receive  Provided by AMReceiverC

Setting up the Radio: Configuration configuration MyAppC { } implementation { components MyAppP, MainC, ActiveMessageC, new AMSenderC(0), // send an AM type 0 message new AMReceiverC(0); // receive an AM type 0 message MyAppP.Boot -> MainC; MyAppP.SplitControl -> ActiveMessageC; MyAppP.AMSend -> AMSenderC; MyAppP.Receiver -> AMReceiverC; }

Setting up the Radio: Module module MyAppP { uses { interface Boot; interface SplitControl; interface AMSend; interface Receive; } implementation { … }

Turn on the Radio event void Boot.booted() { call SplitControl.start(); } message_t sendbuf; event void SplitControl.startDone(error_t error) { call AMSend.send(AM_BROADCAST_ADDR,& sendbuf, sizeof(sendbuf)); } event void SplitControl.stopDone(error_t error) { } MyAppP.SplitControl -> ActiveMessageC; The SplitControl is connected to the ActiveMessageC (radio component of the mote) Destination addressPointer to send buffer Size of msg

Send Messages event void AMSend.sendDone(message_t *msg, error_t error) { // Successful transmission }

Receive a Message event message_t *Receive.receive(message_t *msg, void *payload, uint8_t length) { call Leds.led0Toggle(); return msg; }

Payloads  A message consists of:  Header  Payload  Optional Footer

TinyOS message_t typedef nx_struct message_t { nx_uint8_t header[sizeof(message_header_t)]; nx_uint8_t data[TOSH_DATA_LENGTH]; nx_uint8_t footer[sizeof(message_footer_t)]; nx_uint8_t metadata[sizeof(message_metadata_t)]; } message_t;

Payloads : Use Network Types (MyPayload.h) #ifndef MYPAYLOAD_H #define MYPAYLOAD_H typedef nx_struct MyPayload { nx_uint8_t count; } MyPayload; enum { AM_MYPAYLOAD = 0x50, }; #endif

Example: Filling out a Payload message_t sendbuf; void createMsg() { MyPayload *payload = (MyPayload *) call AMSend.getPayload(&sendbuf); payload->count = (myCount++); call AMSend.send(AM_BROADCAST_ADDR,& sendbuf, sizeof(sendbuf)); }

Example: Receiving a Payload event void Receive.receive(message_t *msg, void *payload, uint8_t len) { MyPayload *payload = (MyPayload *) payload; call Leds.set(payload->count); return msg; }

Tutorial Mote-mote radio communication  Consider two nodes running the same application.  Each node increments a counter and sends a message with the counter value over the radio.  The receiver of the message displays the counter's three least significant bits on the three LEDs.

TINYOS 2.X INSTALLATION

Installing TinyOS 2.x  2 easy choices 1. On Ubuntu: step_install_on_your_host_OS_with_Debian_packages 2. Running a XubunTOS Virtual Machine Image in VMware Player: a) On Ubuntu nux_VMware_Player_Installation b) On Windows ndows_VMware_Player_Installation

PROGRAM A TELOSB MOTE

Blink Application  It simply causes the LED0 to to turn on and off at 4Hz, LED1 to turn on and off at 2Hz, and LED2 to turn on and off at 1Hz.  The effect is as if the three LEDs were displaying a binary count of zero to seven every two seconds.

motelist

Program a specific mote  To compile a program for telosb platform: make telosb  To flash/upload the program to a telosb mote: make telosb install, bsl, e.g.

Successful programming!

SenseWALL  Protocol/algorithm implementation  Experimental comparison, validation and evaluation  Actuation  etc …

Example Application 1/2  Consider a basic data-collection application.  Nodes running this application periodically wake up, sample some sensors, and send the data through an ad hoc collection tree to a data sink.

Example Application 2/2  The four TinyOS APIs the application uses: low power settings for the radio, a timer, sensors, and a data collection routing layer.

References Για απορίες flip a coin (for load balancing, see LEACH):  (HEAD)  (TAIL) References  TinyOS Wiki  TinyOS installation  TinyOS reference  NesC reference  TinyOS Tutorials  Documentation and TEPs  TinyOS API