What to expect when programming a WSN Dr. Antonio Ruzzelli The CLARITY centre School of Computer Science and Informatics University College Dublin [email protected]

What to expect when programming a WSN

Dr. Antonio Ruzzelli

The CLARITY centre

School of Computer Science and Informatics

University College [email protected]

clarity-centre.comSenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

1st partOpen Issues and

programming environments

SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

Summary

• Typical WSN applications• Emerging WSN applications

New issues and system requirements

• Summer School student statistics• Overview of WSN simulators• WSN operating systems• Medium access control in WSNs• A closer look at TinyOS

Component-based programming How to make a new module


Typical WSN applications

• Started with military applications Smart dust

• Environmental monitoring• Fire detection• Precision agriculture

• Detection of Temperature Humidity Light


Such applications require protocols that differ from traditional ones

• Protocols for ad hoc networks to (e.g. WiFi) are aimed to obtain:

• High bandwidth Utilization• Good fairness• Low latency of packets• High throughput

These are generally the primary concerns in traditional wireless voice and data networks but in a typical sensor network they are secondary!


Typical challenges

• Energy-efficiency at all layers• Network scalability• Self-organising routing• Time synchronization• Node localisation• Data aggregation• Node placements• Data mining/visualisation

Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli

Emerging applications

• Audio/Video over WSNs

• Medical applications

• Building automation

• Sensor networks actuators

• Traffic/pollution monitoring

• WSN/mesh networks/RFID/Mobile integration

The emerging applications are causing a convergence between sensor and ad-hoc/mesh networks


Emerging requirements

• Data rate much higher than in initial apps Medical apps,

• Real-time or near real-time transmission voice over WSNs

• Combination of more sensorial data

• Mobility in sensor networks Wearable sensor networks Vehicular sensor networks

• Good tools for network behaviour visibility and control


Emerging Issues

• Deadlines on packet delivery is hard E.g. medical application, video/audio sensor networks

• Network congestion in duty-cycled networks• Higher local data processing • Network programmability

Middleware

• Network control User interface

• Integration between sensor, RFID and ad-hoc networks Industrial/commercial applicaitons

Are these issues studied also by the people attending to this school?


Student statistics (1)

• 22/43 replied to my email ~ 51% :(• Topics studied (some students are focusing on more than 1

topic): Industrial apps: 5 people (22%) Medical apps: 2 people (10%) Routing: 6 people (30%) Real time systems: 3 people (15%) Localisation: 2 people (10%) Looking for good topic: 2 people (10%) Middleware: 2 people (10%) Optimal deployment, image transmission, link quality sink

mobility, wearable sensors: 1 person (10%)


Student statistics (2)

• Using TinyOS: 11 people 50%Simulators:• Matlab 5 people (~22%)• OmNet++ 3 people (~15%)• Ns2 2 people (~10%)• Tossim 4 people (~20%)

• Students using only simulations: > 5 people (~25%) Advise: Simulations on WSNs are not enough for a good PhD due

to communication irregularities and system instability


General PhD guidelines

• Use a well known simulator for WSNs to help your work recognition;

• Perform field tests: A PhD thesis should be supported by real results. Simulations are important but studies demonstrated that real deployments often

do not follow expectations Some universities have open testbeds connected online that can be reserved for

a certain time and used to test your algorithm• http://motelab.eecs.harvard.edu/

• Focus on a fundamental research that is useful for many and that has an industry value

• Consult with your supervisor, mailing lists and experts in the related area as much as you can.

Let’s have a look at specific tools needed for your PhD


WSN Simulators

• What specific features are we looking for? Wireless transmissions and battery models Easy to use

• A simulator is a tool for your target not the target itself Scalable: networks consist of >100 nodes It should support long simulation time Good technical support and documentation It is better if well known communication protocols are already

implemented• You want to concentrate on implementing your work and possibly

without implementing some other works to compare against


WSN Simulators

• NS2/NS3 Pros: Well-known simulator, -active mailing list -good development help

-extensive documentation -large amount of contributing code. Cons: -Limited GUI support -often complex to debug -not a component-

based architecture WSN frameworks: Mannasim, 802.15.4.

• OmNet++ Pros: Well-known WSN simulator, active mailing list, good GUI support,

Component-based architecture. Cons: Some scalability problems noticed for large-scale networks. WSN frameworks: Castalia, Consensus, Mobility, NesCT.

• JSIM Pros: component-oriented architecture; extensibility; Platform indipendent

mailing list; supports several protocols for WSNs (GPRS or AODV). Cons: Less known to the research community than ns2 or OmNet++;


• Tossim Pros: 1-Scalable to hundreds or thousands of motes 2-Code can be uploaded onto

the Tinyos-based motes 3-Bit-level simulator Cons: 1-Only known inside the WSNs research sphere 2-Can simulate on TinyOS

only 3-No battery and CPU execution time models (unless recently added) 4-Cannot simulate different binaries running on different motes.

• Qualnet (ex Glomosim) Pros: 1-Good wireless models 2-easy to use, scalable 3-layered architecture 4- plug-

in capability. Cons: 1- not an open source 2-basic technical support by a community forum 3-

some people experienced delay in the forum-based technical support 4- advanced support to purchase.

WSN Simulators


WSN Operating systems

Do we need an OS running onto the nodes?

• No if a node run one application only.

• Yes if a node is required to • Schedule parallel application executions

• Meet deadlines (Real-time OS)

• Prioritize some tasks


RTOS for sensor networks

• Q: Do we need a real time OS for WSNs? In theory it would useful for real time applications (e.g.

voice over WSNs), however:

• RTOS not suitable for current WSN hardware e.g. task preemption is very memory costly

• The RT execution of a task (e.g. a deadline of packet transmission scheduling) may be nullified by MAC latency, collision and node duty-cycle

As Zach Shelby said:

“it is like putting a Ferrari engine on a Fiat 500”


Programming environment

• TinyOS• Contiki• Mantis• SOS• FreeRTOS• Nano-RK• BTnut• AmbientRT


TinyOS: a closer look

Most advanced MAC used in TinyOS • XMAC (with LPL) over CC2420/2430 radios

Routing in TinyOS:• Upstream: Collection Tree Protocol (CTP) based on Expected Transmissions

(ETX)• Downstream: Dissemination protocol

Latest version TinyOS 2.1• FTSP time synchronization• SafeTinyOS• 802.15.4-2006 MAC implementation• support for 802.15.4 T-frame and I-frame• TOSThreads• Support for Iris and Shimmer platforms


• Object-Oriented Concentrate on objects, methods and class relationships

combined into an executable

• Component-Oriented Interchangeable code modules (files) that work

independently and can be used through interfaces

Component-Oriented Programming



• 3 file types in TinyOS: Module (suffixed with P.nc) Configuration (suffixed with C.nc) Interface (suffixed with .nc)

• A component is a combination of Configuration and a Module


Tiny OS Concepts

• Component has: Internal state (storage) Tasks: computation Interface:

• Command • Event

• Internal state: static storage model - compile time memory allocation

• Command and events are function calls

Messaging Component

init

Pow

er(m

ode)

TX

_pac

ket(

buf)

TX

_pac

ket_

do

ne

(su

cces

s)

RX

_pac

ket

_do

ne

(bu

ffer

)

Internal

State

init

pow

er(m

ode)

send

_msg

(add

r, ty

pe,

data

)

msg

_re

c(ty

pe

, d

ata

)

msg

_se

nd

_d

on

e)

Internal tasks

Commands Events


TOS Component

Messaging Component

AM_SUB_INIT

AM_SUB_POWER

AM_SUB_TX_PACKET

AM_TX_PACKET

_DONE

AM_RX_PACKET

_DONE

Internal State

AM_INIT

AM_POWER

AM_SEND_MSG

AM_MSG_REC

AM_MSG_SEND_DONE

Internal Tasks

Commands Events

//AM.comp//TOS_MODULE AM;<ACCEPT COMMAND>{ char AM_SEND_MSG(char addr, char

type, char* data); void AM_POWER(char mode); char AM_INIT();};<SIGNAL EVENT>{ char AM_MSG_REC(char type,

char* data); char AM_MSG_SEND_DONE(char success);};<HANDLE EVENT>{ char AM_TX_PACKET_DONE(char success); char AM_RX_PACKET_DONE(char* packet);};<USE COMMAND >{ char AM_SUB_TX_PACKET(char* data); void AM_SUB_POWER(char mode); char AM_SUB_INIT();}; SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

TinyOS Two-level Scheduling

• Tasks do computations• Events handle concurrent dataflows

Events generated by interrupts preempt tasksTasks do not preempt tasksBoth essential process state transitions

Hardware

Interrupts

eve

nts

commands

FIFO

TasksPOST

Preempt

Time

commands



Modules (componentNameP.nc)• Implement the core functionalities of the module (commands)• Provide interfaces to other modules.• Use interfaces from other modules.

//E.g. Energy module to calculate the node energy consumption by software#include "Energy.h”

module EnergyP {provides {interface Energy;}uses{ interface Leds; interface Timer<Tmilli> as General; interface Timer<Tmilli> as TimerLed; interface Counter<TMicro, uint16_t> as AwakeTimer; …}}

Implementation {…



Configurations (componentNameC.nc)• Wire interfaces from several modules together.• May forward interfaces from external modules to internal modules.• May contain sub-configurations.

//E.g. Energy module to calculate the node energy consumption by softwareconfiguration EnergyC {

provides interface Energy;}implementation {

components EnergyP, LedsC, new TimerMilliC(), Msp430CounterMicroC;

Energy = EnergyP;EnergyP.Leds -> LedsC;EnergyP.General -> TimerMilliC;EnergyP.TimerLed -> TimerMilliC;EnergyP.Timer -> Msp430CounterMicroC;EnergyP.Msp430CounterMicro -> Msp430CounterMicroC;

}



Interfaces (componentName.nc)• 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

//E.g. Energy module to calculate the node energy consumption by softwareinterface Energy {

command uint32_t getPartialEnergy(uint16_t awakeDutyCycle);command uint32_t getTotalEnergy(uint16_t awakeDutyCycle);command uint32_t getRadioEnergy(uint16_t awakeDutyCycle);command uint32_t getMcuEnergy(uint16_t awakeDutyCycle);command uint32_t getLedEnergy();async command void startSend();async command void stopSend();command void startTimer();command void stopTimer();event void scaleVariation(uint16_t val, uint16_t valMcu, uint16_t valTotal);

. . .}


A Complete Application

RFM

Radio byte (MAC)

Radio Packet

i2c

Tempphoto

Messaging Layer

clocksbit

byte

packet

Routing Layer

sensing applicationapplication

HW

SW

ADC

messaging

routing


Component connections

Generated with graphviz within TinyOS: make telosb docsSenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

TinyOS in summary

Small memory footprint Non-preemptable FIFO task scheduling

Power efficient Put microcontroller and radio to sleep

Efficient modularity Function call (event, command) interface between components

Concurrency-intensive operations Event-driven architectureEfficient interrupts/events handling (function calls, no user/kernel boundary)

Real-time Non-preemptable FIFO task schedulingNO real-time guarantees or overload protection


How to use the energy module in TinyOS

• Download the bundle file of the software-based energy tracking from http://www.cs.ucd.ie/octopus

• The module can timestamp activity of the radio and further hardware components

• It requires that the energy command is called in few appropriate components -->Only a couple of lines modification

• Follow the steps in the readme.txt instructions in the bundle file

• Include the energy interface in your application file to obtain the live estimation of the energy consumed by the node.


Compiling a TinyOS app

TinyOS

nesC

GCC


A look at MAC issues in WSNs


To reduce the energy consumption, MAC protocols tailored for WSNs have introduced a novel concept:

The node duty Cycle and Wakeup concepts

nodes alternate periods of radio activity to periods inactivity

WSNs introduced a new concept of access control

Wakeup period Sleep periodListening

period

TimeSenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

Issues in Duty-cycled MAC

• Transmission Latency --> Low throughput A transmitter must wait for the receiver to

wake-up

• A packet should be transmitted when the receiver is awake Node synchronization/beacons (802.15.4) Carrier Sense/long preamble (BMAC/XMAC)


802.15.4 Network formation

• One PAN coordinator

• Zero or more coordinators

• Zero or more end devices

• First device starts the network as PAN coordinator

• A new device can detect all coordinators (both the PAN coordinator and coordinators)

• A device can join the network by associating with any coordinator in range

• After joining a device can volunteer as coordinator

PAN coordinator

Coordinator

End device


Step 1: Starting a new network

• Device starts network scan (MLME_SCAN)

• Detects no network

• Starts new network as PAN coordinator (MLME_START with PANCoordinator=TRUE)

• If PANCoord then other devices in range can discover device 1 by means of a network scan

1

PAN coordinator

Coordinator FFD

End device RFD


Step 2: a device joins the network

• Device 2 starts network scan (MLME_SCAN)

• Detects PAN coordinator device 1

• Sends association request to device 1 (MLME_ASSOCIATE)

• Node2 is now and End device Other devices cannot discover device 2 by means of a network scan

PAN coordinator

Coordinator FFD

End device RFD

2

1

range


Step 3: Device 2 becomes a coordinator

• Device 2 starts serving as a coordinator of the existing network (MLME_START with PANCoordinator=FALSE, PANId & channel parameters are ignored)

• Node2 is now Other devices in range can now discover device 2 by means of a network scan

PAN coordinator

Coordinator FFD

End device RFD

2

1


Step 4: Device 3 joins the network


• Detects coordinator device 2(assuming device 1 is not in range of device 3)

• Sends association request to device 2 (MLME_ASSOCIATE)

• Note: Other devices cannot discover device 3 by means of a network scan

PAN coordinator

Coordinator FFD

End device RFD

2

1

3 range


Step 5: Device 4 joins the network


• Detects two coordinators: device 1 and device 2(assuming device 1 and device 2 are in range of device 4)

• Sends association request to device 1 (MLME_ASSOCIATE)(alternatively it could join the network also through device 2)

• Note: Other devices cannot discover device 4 by means of a network scan

PAN coordinator

Coordinator FFD

End device RFD

2

1

3

4range


Step 6: Device 4 becomes a coordinator

• Device 4 starts serving as a coordinator of the existing network (MLME_START with PANCoordinator=FALSE, PANId & channel parameters are ignored)

• Note: Other devices in range can now discover device 4 by means of a network scan

PAN coordinator

Coordinator FFD

End device RFD

2

1

3

4


Other devices can join in the same way

802.15.4 short unique addressing not handled

• IEEE 802.15.4 does not define network-wide unique short MAC addresses assigned by coordinators.

• Extended MAC addresses can be used instead of short addresses but with High packet overhead

PAN coordinator

Coordinator FFD

End device RFD

1

2

4

7

5

3

6

8

range


Issue 1: Beacons are weak and uncoordinated

• Beacons are prone to collide as transmitted without CSMA

• If a beacon collides then all RFD children are isolated.

• FFDs are 100% likely to be the time active as they have to relay information

2

3

8

10

9

11

14

7

BeaconBeacon

Beacon

Tx


Issue 2: The hidden association problem

• No coordination between FFDs is provided

• End devices (RFDs) can talk to its coordinator only packet collisions might occur

• 1) Eg. Node9 transmitting to node2 might generate collision at node8 that is receiving from node11.

• 2) Eg. node7 transmission might prevent correct neighbouring node 10 reception PAN coordinator

Coordinator FFD

End device RFD

1

2

4

7

5

3

6

8

range

10

9

11


Standard networking in TinyOS

• Devices are of two types: Base station (the gateway to the PC) Motes

• Motes form a peer-to peer Network

All motes are full functional Can route packets Can sense the channel Can send to any neighbour

• PAN coordinator

Coordinator FFD

End device RFD

1

2

4

7

5

3

6

8

range

10

9

11


The long-preamble approach in TinyOS

• The long preamble and low power listening adopted in duty-cycled MAC protocols such as BMAC and XMAC

(with a variation of the preamble for the CC2420 radio)

Pros: Avoids synchronizing the nodes Cons: It creates congestion for high data rate scenario

Long preamble Packet

Time

Transmitter

Receiver

Low power listening period

Carrier Sense


Thanks for your attention

Any questions?

End of the 1st part


…Towards the evolution of a GUI for Sensor Networks

2nd part:The Octopus Dashboard

As applications get more demanding,

There is a strong need for tools that empower developers and users to interact and control a sensor network


Why a visual control tool for WSN

• To help developers in: Network debugging Network assessment Understanding routing patterns Gaining an insight of network topology

• To empower users with a user-friendly tool to: Formulate multiple application queries Tune parameters according to user needs Localise nodes on a floor map


OCTOPUS

A Dashboard for Sensor Network

Visual Control

Existing Tools

• Surge

Pros Map of the network

Cons Not working with Tinyos 2.0 Dependency on the default routing protocol No energy estimation Very little network behaviour visibility No node localisation SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli

Existing Tools

• MViz

Pros Array of values displayed

Cons No Timeout feature Only one way communication No multihop


• Portability and extensibility: Octopus works with any hardware that run Tinyos 2.x Various option can be changed through h.files

• Adaptability: Choice of the protocol of communication during the compilation process

• Usability: Interactive tool to enable user and researcher to have an accurate insight of the

state of the network Message Requests to one, many, or all the motes of the network Data saved in a

file for future treatment Simple sliders allow to change node duty cycle or sampling rate

Feature of Octopus


Global Design of Octopus

Scout MoteDB

Panels Logger

User File

Ser

ial

Ser

ial

Timer

SensorOctopus

Rad

ioR

adio

Timer

SensorOctopus

GUIGatewayRegular Mote


• From the GUI to the mote

Design of the communication protocol

targetId

parameters

request

0 75 6421 8 109 1

311

12

143 1

5

From the mote to the GUI

moteId

count

0 75 6421 8 109 1

311

12

143 1

5

Reading energy

quality

parentId

reply

parentId

quality

countReadingEnergymoteIdreply

G

M M

M MM


Design of the embedded application

• One common application for both the gateway and the regular motes Choice between the gateway and a regular mote,

through the ID

• Configuration through the options of a file One file for the final user "OctopusConfig.h" One file for the developer "Octopus.h"


How to run Octopus (1)


How to run Octopus (2)


- Network Map- Network chart- Floor Plan

- Radio Request- Application Request- Alerts- Localise- Legend

Console

“The Octopus Dashboard”

The Octopus Dashboard


-Live changes of motes radio Features:- selection of mode Broadcast or Unicast,- mote selected and its live energy consumed,- Dynamic frequency channel selection- Setting of the radio duty-cycle.

Live monitoring of energy consumption by software energy assessment

Radio request panel



Application Request panelWithin this panel, we can select a mote and set its rsensorial data

We can change : - the sensor reading displayed- Sensing modes:

Awake duty-cycle,Sampling period,Sensing threshold,

-Choose the motes to be displayed in the chart.

- boot the network.



This Panel, we can formulate and send one or several conditions to one or

several motes.

We can combine conditions with other conditions, using logic operators.

We can choose the user alert type, for exemple :- e-mail- sms- popup

Alerts panel



Query clause :

-To formulate queries by choosing network parameters such as: the sensing device , the node data rate, the energy consumed, the link quality, or a moteID to be enquired.

Alerts panel



Query clause : -Condition

- E.g. IF, WHEN-Subject

- The node parameter to check

-VerbThe action to be taken e.g compare the value of data e.g. greater than, less than, equal,

-EpochTime period that validates the condition before triggering an event

Alerts panel



Query clause : -Condition

- E.g. IF, WHEN-Subject

- The node parameter to check

-VerbThe action to be taken e.g compare the value of data e.g. greater than, less than, equal,

-EpochTime period that validates the condition before triggering an event

Alerts panel



Query clause :

- Condition- Subject- Verb- Value-Epoch

Logic :

We can choose the logic between “And”, “Or”, and “Xor”

Alerts panel



Query clause :

- Condition- Subject- Verb- Value-Epoch

Logic :

Alert Type :

How the user will receive the warning : “e-mail”, “sms” or “popup”

Alerts panel



Rephrase : “Clear last line” allows erasing the last formulated clauses“Clear all” allows starting the query sentence from scratch

Alerts panel




Translator: Queries are dysplayed automatically on the translator box for convienience.

Alerts panel




Translator: Queries are dysplayed automatically on the translator box for convienience.

Send: If the sentence is ok, pressing the button “send”the query is translated in an efficient 48-bit datathen transmitted

Reset:We can erase the condition of motes with the button “reset”.

Alerts panel



If temperature > 7000 for 3 secorit temperature < 6000 for 3 secthen send sms.-------------------------------If light < 50 for 1 secthen send e-mail0 1 2 3 4 5 6 7 8 9 10 11 12 13

T (s)

Temperature

0 1 2 3 4 5 6 7 8 9 10 11 12 13T (s)

Light

Condition for light is OK

Condition for Temperature is OK

Conditions for temperature and light are OK

3 sec

Send sms alert

1 sec

Send e-mail alert





In the legend, we can choose whether to display several information on the network map and floor plan,

Timeout for diplaying of routes provides visual information about the routes between nodes and gateway

The panel allows setting wwhich data to log into a file.

It also includes “Anchor” information for a support for node localisation.





The Floor Plan Panel and Localise Panel



Floor Plan :

- Insert map (xml)- Delete map

- Save configuration - Load configuration

Choose the xml file in your broswer



<MAP> <WALL id="0">

<X1>50</X1> <Y1>50</Y1> <X2>50</X2> <Y2>450</Y2><TYPE>wall</TYPE></WALL><WALL id="1">




<X1>250</X1> <Y1>100</Y1> <X2>550</X2> <Y2>100</Y2><TYPE>other</TYPE></WALL>

... ... ...<WALL id="17">

<X1>50</X1> <Y1>455</Y1> <X2>50</X2> <Y2>495</Y2><TYPE>door</TYPE></WALL><WALL id="18">

<X1>550</X1> <Y1>60</Y1> <X2>550</X2> <Y2>265</Y2><TYPE>windows</TYPE></WALL><WALL id="19">

<X1>550</X1> <Y1>275</Y1> <X2>550</X2> <Y2>500</Y2><TYPE>windows</TYPE></MAP>

Example of xml file :



Exemple of localisation For mote 20 :

5 mote to localizeThe node 20

The anchor motes provide 5 intersecting areas for themote 20



SenZation’08 - WSN Summer School in Lujbljana - Author: Ruzzelli







The Octopus GUI (v.1) has been tested extensivelyThe Octopus dashboard (Octopus v.2) includes new functionalities which are in a version

The new functionalities of the Octopus Dashboard are: A larger number of network requests and a better categorization A live software-based energy estimation Localisation support for mote tested on link quality. An alert panel to formulate network queries

Initial tests show that link quality may not suffice for accurate range measurements - It is advised - To combine the measurements with other sensing devices e.g. a microphone- To implement some inteligence that discards faulty measurements .

Alerts :- logic Xor to be implemented- e-mail and sms message to be implemented



Documentation

• Two documents created "Final User Documentation"

• How to use Octopus

• Steps to follow

"Developer Documentation"• How to modify Octopus

• How to add a new protocol

• How to add a new sensor

• How to add a stack of the route of a message


How to find a good research topic


A market-driven approach

• Why a market-driven approach:

WSN falls in the field of applied research

WSN is a multi-disciplinary research field

A vast number of applications with very disparate requirements

No current hardware that is able to fulfill all the requirements



• Pros Higher chances of an interest from both academia and industry

Will likely face real issues in the domain

Higher possibility of generating patents

(and of course publications)

Higher possibility of licensing the technology to a company

A higher possibility of a research with strong impact on the community



• Cons It may curb brilliant ideas that are not yet understood

• i.e. the market is not ready for your crazy visions

The market may change more rapidly than your PhD

It may not be focused on fundamental issues required for a PhD

Some academics may be less interested because if the approach is too simplistic and does not involve heavy math

Some supervisor may be reluctant as it is their job to find a good research topic for the candidate



• The steps for a market-driven approach when devising an WSN application: Think of a new application for WSN or Think of an existing application that WSN can improve. What are the improvements of using WSNs in this domain? Are there alternative solutions already existing e.g. wired

solutions? Contact an expert in the specific domain and ask him system

requirements, feasibility and advices Identify research requirements and challenges


A market-driven application: An example (1)

Conception of a new application • E.g. WSNs for autonomous wind turbines

Improvement of an existing application• ~WSN can monitor the number of cycles and general condition• WSN can improve the power generation efficiency by actuating a

dynamic steering against the wind• WSN on one several turbines can communicate to find the best

orientation against the wind Existence of alternative solutions e.g. wired solutions

• Wired sensors possibly embedded in the next generation wind turbine


Benefits of using WSNs in this domain over wired solutions• WSNs can also be applied on the existing infrastructures more

effectively• Wires may impede the motion of blades• WSNs is a more cost-effective solution• Less maintenance: Faulty sensors can be easily replaced

Research challenges• Sensing devices required, • communication latency and reliability, • patterns of data aggregation, • Accuracy of decision process• Number of sensors to be deployed• Integration with existing technology

A market-driven application: An example (2)


End of the WSN programming talk

Thank you for your attention

Any questions?


Documents

What to expect when programming a WSN Dr. Antonio Ruzzelli The CLARITY centre School of Computer Science and Informatics University College Dublin [email protected]