Based on slides from Andreas Larsson 2013

Table from CY Chong, SP Kumar, BA Hamilton - Proceedings of the IEEE, 2003

CPU7MHz Program Memory 128 kB RAM4 kB Storage Memory 512 kB Bandwidth250 kBps Indoor Range m Outdoor Range m Battery Life Full operation at all times 50 h

 Sleeping  The Main Task  Data gathering  Data aggregation  Data communication  Auxiliary Tasks  Synchronization  Security

 Utility  Structural health monitoring  Agriculture  Parking space guidance/monitoring  Research  Volcanos  Permafrost  Animal behavior COMMONSense Permasense

Part 2 TinyOS and nesC Programming Selected slides from: Wireless Sensor Networks Hardware/Software Tiny OS & NesC Programming borrowed from Turgay Korkmaz

What is TinyOS? Operating system developed by UC Berkeley Open Source development environment – System, library and applications written in nesC nesC (network embedded system C) a component-based C – Event-driven architecture – Single shared stack – NO kernel, process/memory management

Programming Model Basic concept behind nesC: Separation of construction and composition Programs are built out of components

Components A component is a black box specified by interface(s) Interfaces define a set of logically related I/O functions called commands and events Components use and provide interfaces Components are statically wired together based on their interfaces Timer Component StdControl Timer Clock provides uses StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Clock.nc interface Clock { command result_t setRate( char interval, char scale); event result_t fire(); }

Components (cont’d)‏ A component – Processes Commands – Throws Events – Has a Frame for local state – Uses Tasks for concurrency Components must implement – the events they use and – the commands they provide Can signalMust implement Provide Must implementCan call Use EventsCommandsComponent Timer Component StdControl Timer Clock provides uses

Commands and 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 {... status = call CmdName(args)‏... } command CmdName(args) {... return status; } {... status = signal EvtName(args)‏... } event EvtName(args) {... return status; }

Component Hierarchy Components are wired together by connecting users with providers Commands: – Flow downwards – Control returns to caller Events: – Flow upwards – Control returns to signaler

Types of Components There are two types of components: Modules: provide code that implements one or more interfaces and internal behavior Configurations: Wires/links components together to yield a new component A component does not care if another component is a module or configuration A component may be composed of other components

Component Syntax - Module module ForwarderM { provides { interface StdControl; } uses { interface StdControl as CommControl; interface ReceiveMsg; interface SendMsg; interface Leds; } implementation { code implementing all provided commands used events, and tasks } ForwarderM StdControl ReceiveMsg provides uses CommControl SendMsg Leds interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } interface SendMsg{ command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg); event result_t sendDone(TOS_MsgPtr msg, result_t success); }

module ForwarderM { //interface declaration } implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; } module ForwarderM { //interface declaration } implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; } Command imp. (interface provided)‏ Event imp. (interface used)‏ ForwarderM StdControl ReceiveMsg provides uses CommControl SendMsg Leds Component Implementation

Component Syntax - Configuration configuration Forwarder { } implementation { components Main, LedsC; components GenericComm as Comm; components ForwarderM; Main.StdControl -> ForwarderM.StdControl; ForwarderM.CommControl -> Comm; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.Leds -> LedsC; } Component Selection Wiring the Components together ForwarderM StdControl ReceiveMsg providesuses CommControl SendMsg Leds Main StdControl LedsC Leds GenericComm SendMsg ReceiveMsg StdControl Forwarder

21 DSII: Group Comm.

The lab is done on the computer: dark.cs.chalmers.se You will receive a username and password in pingpong. TinyOS with all sources for libraries and everything is installed at /opt/tinyos Unpack Rout.tar.gz into your home directory (at the server) and do the assignment from there. Compile the program by executing: make micaz sim Run the simulation by executing:./simulation.py Build topologies using buildtopo.py to get a grid and then remove some nodes to get some interesting formation

 Implement something better than the basic routing algorithm.  The battery level is something that is known to a node, so feel free to use that in your algorithm. Sink Messages: Announcement Content

 Aggregate information and send it to the sink.  Many nodes in an area send their information to a cluster head  The cluster head sends the aggregate message to the sink.  A simple algorithm to choose cluster head:  for every node with a certain probability announces itself to be a cluster head.  Choose the parameters you like: battery level of the node, battery level of neighbors, etc.  A cluster head should not store content for more than 1 round.

 Report:  Part 1:  Discuss the idea behind your algorithm.  Present results from comparing your algorithm to the original algorithm.  Discuss failed improvements.  Part 2:  Discuss the idea behind your algorithm.  Present results from comparing your algorithm to your algorithm in part one.  Discuss failed improvements.  Presentation:  Each group gives a 10 min presentation of their algorithm.  March 6, 13:15-17:00, Room: EL42. 25