Transcript What to expect when programming a WSN

What to expect when
programming a WSN
Dr. Antonio Ruzzelli
The CLARITY centre
School of Computer Science and Informatics
University College Dublin
[email protected]
clarity-centre.com
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
1st part
Open 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Typical WSN applications
• Started with military applications
 Smart dust
• Environmental monitoring
• Fire detection
• Precision agriculture
• Detection of
 Temperature
 Humidity
 Light
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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!
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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?
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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%)
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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.
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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 componentbased 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++;
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
WSN Simulators
• 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) 4Cannot simulate different binaries running on different motes.
•
Qualnet (ex Glomosim)
 Pros: 1-Good wireless models 2-easy to use, scalable 3-layered architecture 4plug-in capability.
 Cons: 1- not an open source 2-basic technical support by a community forum 3some people experienced delay in the forum-based technical support 4- advanced
support to purchase.
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
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”
Senzation’08 - WSN Summer School in Ljubljana - Author Ruzzelli
Programming environment
•
•
•
•
•
•
•
•
TinyOS
Contiki
Mantis
SOS
FreeRTOS
Nano-RK
BTnut
AmbientRT
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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 SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Component-Oriented
Programming
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
send_msg(a
ddr, type,
data)
Events
Messaging Component
Internal
State
RX_packet
_done
(buffer)
init
Power(mode)
TX_packet(buf)
Internal tasks
TX_packet_
done
(success)
• Command
• Event
power(mode)
 Internal state (storage)
 Tasks: computation
 Interface:
Commands
init
• Component has:
msg_rec(type, data)
msg_sen
d_done)
Tiny OS Concepts
• Internal state: static storage model - compile time memory allocation
• Command and events are function calls
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
TOS Component
AM_MSG_SEND_DONE
AM_MSG_REC
AM_SEND_MSG
AM_POWER
AM_INIT
//AM.comp//
Messaging Component
Commands
AM_RX_PACKET
_DONE
Internal State
AM_TX_PACKET
_DONE
AM_SUB_TX_PACKET
AM_SUB_INIT
AM_SUB_POWER
Internal Tasks
Events
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 tasks
Tasks do not preempt tasks
Both essential process state transitions
Tasks
Preempt
events
POST
FIFO
commands
commands
Interrupts
Hardware
Time
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Component-Oriented
Programming
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 {
…
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Component-Oriented
Programming
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 software
configuration 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;
}
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Component-Oriented
Programming
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 software
interface 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);
...
}
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A Complete Application
application
sensing application
Routing Layer
routing
messaging
Messaging Layer
Radio Packet
packet
byte
bit
Radio byte (MAC)
RFM
photo
clocks
ADC
Temp
i2c
SW
HW
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Component connections
Generated with graphviz within TinyOS: make telosb docs
SenZation’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 architecture
Efficient interrupts/events handling (function calls, no
user/kernel boundary)


Real-time 
Non-preemptable FIFO task scheduling
NO real-time guarantees or overload protection

SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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.
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Compiling a TinyOS app
TinyOS
nesC
GCC
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A look at MAC issues in
WSNs
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
WSNs introduced a new concept
of access control
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
Sleep period
Wakeup period
Listening
period
Time
SenZation’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)
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Step 1: Starting a new network
•
Device starts network scan
(MLME_SCAN)
1
•
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
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Step 2: a device joins the network
•
Device 2 starts network scan
(MLME_SCAN)
1
•
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
2
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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)
1
2
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Step 4: Device 3 joins the
network
• Device 3 starts network scan
(MLME_SCAN)
• 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
1
2
3
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Step 5: Device 4 joins the
network
•
Device 4 starts network scan
(MLME_SCAN)
•
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
1
4
2
3
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
1
4
2
3
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Other devices can join in the
same way
5
802.15.4 short unique addressing not
handled
•
•
6
1
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
4
2
7
8
3
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Issue 1: Beacons are weak and
uncoordinated
• Beacons are prone to collide as
transmitted without CSMA
1
4
• If a beacon collides then all
RFD children are isolated.
Beacon
9
2
Beacon
• FFDs are 100% likely to be the
time active as they have to relay
information
7
Tx
Beacon
8
3
10
11
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Issue 2: The hidden association
problem
•
•
5
No coordination between FFDs is
provided
End devices (RFDs) can talk to its
coordinator only
6
1
4
 packet collisions might occur
9
•
•
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
2
8
11
3
7
10
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Standard networking in TinyOS
•
Devices are of two types:


•
5
Base station (the gateway to the PC)
Motes
1
4
Motes form a peer-to peer Network
9

All motes are full functional



•
6
Can route packets
Can sense the channel
Can send to any neighbour
2
8
11
3
7
10
PAN coordinator
Coordinator FFD
End device RFD
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
Carrier
Sense
Long preamble
Packet
Transmitter
Receiver
Low power
listening period
Time
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
End of the 1st part
Thanks for your attention
Any questions?
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
…Towards the evolution of a GUI for Sensor Networks
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Feature of Octopus
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Global Design of Octopus
Gateway
GUI
Octopus
Sensor
Scout
MoteDB
Panels
Logger
User
File
Timer
Sensor
Serial
Timer
Radio
Octopus
Serial
Radio
Regular Mote
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Design of the communication
protocol
• From the GUI to the
mote
0
1 2 3
4
5
6
7
8 9
1 1
0 1
1
2
1
3
1 1
4 5

From the mote to the
GUI
0
1 2 3
4
5
targetId
parameters
request
6
7
8 9
1 1
0 1
G
parentId
moteId
1
2
1
3
1 1
4 5
count
quality
count energy
Reading
M ReadingM
Energy
quality
moteId
reply
parentId
reply
M
M
M
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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"
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
How to run Octopus (1)
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
How to run Octopus (2)
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
- Network Map
- Network chart
- Floor Plan
- Radio Request
- Application Request
- Alerts
- Localise
- Legend
Console
“The Octopus Dashboard”
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Radio request panel
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

SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Application Request panel
Within 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.
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
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.
-
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Query clause :
Condition
E.g. IF, WHEN
-Subject
The node parameter to
check
-Verb
The action to be taken
e.g compare the value
of data e.g. greater
than, less than, equal,
-Epoch
Time period that validates
the condition before
triggering an event
-
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Query clause :
Condition
E.g. IF, WHEN
-Subject
The node parameter to
check
-Verb
The action to be taken
e.g compare the value
of data e.g. greater
than, less than, equal,
-Epoch
Time period that validates
the condition before
triggering an event
-
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Query clause :
- Condition
- Subject
- Verb
- Value
-Epoch
Logic :
We can choose the logic
between “And”, “Or”, and
“Xor”
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Query clause :
- Condition
- Subject
- Verb
- Value
-Epoch
Logic :
Alert Type :
How the user will receive
the warning :
“e-mail”, “sms” or “popup”
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Rephrase :
“Clear last line” allows erasing the last
formulated clauses
“Clear all” allows starting the query sentence
from scratch
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Rephrase :
“Clear last line” allows erasing the last
formulated clauses
“Clear all” allows starting the query sentence
from scratch
Translator:
Queries are dysplayed automatically on the
translator box for convienience.
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Alerts panel
Rephrase :
“Clear last line” allows erasing the last
formulated clauses
“Clear all” allows starting the query sentence
from scratch
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 data
then transmitted
Reset:
We can erase the condition of motes with the button
“reset”.
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Temperature
0
1
2
3
4
5
6
7
1
2
3
4
5
6
7
8
9
10
11
12
13
8
9
10
11
12
13
If temperature > 7000
for 3 sec
or
it temperature < 6000
for 3 sec
then send sms.
------------------------------If light < 50 for 1 sec
then send e-mail
T (s)
Light
0
Condition for
Temperature
is OK
Condition for
light is OK
T (s)
Conditions
for temperature
and light
are OK
1 sec
3 sec
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
Send
sms alert
Send
e-mail alert
The Octopus Dashboard
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
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.
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
The Floor Plan Panel and Localise Panel
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Choose the xml file in your broswer
Floor Plan :
- Insert map (xml)
- Delete map
- Save configuration
- Load configuration
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Example of xml file :
<MAP>
<WALL id="0">
<X1>50</X1> <Y1>50</Y1> <X2>50</X2> <Y2>450</Y2><TYPE>wall</TYPE>
</WALL>
<WALL id="1">
<X1>50</X1> <Y1>50</Y1> <X2>550</X2> <Y2>50</Y2><TYPE>wall</TYPE>
</WALL>
<WALL id="2">
<X1>50</X1> <Y1>500</Y1> <X2>550</X2> <Y2>500</Y2><TYPE>wall</TYPE>
</WALL>
<WALL id="3">
<X1>550</X1> <Y1>50</Y1> <X2>550</X2> <Y2>500</Y2><TYPE>wall</TYPE>
</WALL>
<WALL id="4">
<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>
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
Exemple of
localisation
For mote 20 :
5 mote to localize
The node 20
The anchor
motes provide
5 intersecting
areas for the
mote 20
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Lujbljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Lujbljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Lujbljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
The Octopus Dashboard
The Octopus GUI (v.1) has been tested extensively
The 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
How to find a good research
topic
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A market-driven approach
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A market-driven approach
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A market-driven approach
• 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
A market-driven application:
An example (2)
 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
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli
End of the WSN
programming talk
Thank you for your attention
Any questions?
SenZation’08 - WSN Summer School in Ljubljana - Author: Ruzzelli