Rapid development of WSN applications

Alexios Lekidis, Paraskevas Bourgos, Simplice Djoko-Djoko, Marius!
Bozga, Saddek Bensalem!
Univ. Grenoble Alpes, VERIMAG, F-38000 Grenoble, France!
CNRS, VERIMAG, F-38000 Grenoble, France!
IEEE Sensors Applications Symposium!
Zadar, Croatia !
12-15 April, 2015!
Building Distributed Sensor Network
Applications using BIP!
Lekidis et al.! Building Distributed Sensor Network Applications using BIP! 1/33!

Sensor Networks: Application domains!
EnvironmentHealthcare Transportation
High-energy physics Manufacturing Agriculture

EnvironmentHealthcare Transportation
High-energy physics Manufacturing Agriculture
and many more…
Sensor Networks: Application domains!

Outline!
1)  Sensor
Networks:
Overview
and
development
challenges

2)  Proposed
design
ﬂow

•  Modeling
the
Applica?on
So@ware
in
PPM

•  Code
genera?on
in
Distributed
Sensor
Network
PlaEorms

•  Background
on
BIP

3)  Case
study:
Industrial
Mul?media
WSN
Applica?on

•  Code
genera?on
from
the
PPM
Applica?on
Model

•  Construc?on
of
the
System
Model
in
BIP

•  BIP
System
Model
Calibra?on

4)  Conclusion
and
ongoing
work

Sensor networks: Device constraints!
BaMery
life?me
is
limited..

What
happens
in
case
of
failure?

•  Scarce
resources

•  Communica?on
cost

•  Consumed
energy

•  Memory
usage

•  Network
bandwidth

BaMery
life?me
is
limited..

What
happens
in
case
of
failure?

•  Scarce
resources

•  Communica?on
cost

•  Consumed
energy

•  Memory
usage

•  Network
bandwidth

Sensor networks: Device constraints!

Sensor networks: Timing constraints!
•  Many
applica?on
require
accurately
3mestamped
data

•  Many
applica?on
require
accurately
3mestamped
data

•  Characteristic example: Multimedia Wireless Sensor
Network (MWSN) applications

•  Each
sensor
node
has
a
ﬁxed
?me
granularity

which
varies
according
to
the
opera?ng
frequency

of
its
clock

Clock
Time
C(t)

Real
Time
t

(Faster
clock)

(Reference
clock)

(Slower
clock)

t2

t1

t0

t0

How to obtain a common time reference in
a distributed system?
Solution: Clock synchronization
Clock
Time
C(t)

Real
Time
t

(Faster
clock)

(Reference
clock)

(Slower
clock)

t2

t1

t0

t0

Sensor networks: Clock synchronization!
•  Several
well
known-‐protocols
opera?ng
either
in
the

so6ware
or
hardware
level

•  Target
synchroniza3on
accuracy:
Microsecond
scale
(μs)

•  Improved
accuracy
with
enhancements
as:

•  Round-‐Trip
Delay
(RTD)
calcula?on

•  Requires
more
energy

•  Dedicated
drivers
for
hardware
access

•  May
not
be
available
in
lightweight
environments

RTD
calcula3on

in
Precision
Time

Protocol
(PTP)

•  Several
well
known-‐protocols
opera?ng
either
in
the

so6ware
or
hardware
level

•  Target
synchroniza3on
accuracy:
Microsecond
scale
(μs)

•  Improved
accuracy
with
enhancements
as:

Delay
(RTD)
calcula?on

•  Requires
more
energy

•  Dedicated
drivers
for
hardware
access

•  May
not
be
available
in
lightweight
environments

•  Several
well
known-‐protocols
opera?ng
either
in
the

so6ware
or
hardware
level

•  Target
synchroniza3on
accuracy:
Microsecond
scale
(μs)

•  Improved
accuracy
with
enhancements
as:

Delay
(RTD)
calcula?on

•  Requires
more
energy

•  Dedicated
drivers
for
hardware
access

•  May
not
be
available
in
lightweight
environments

•  Promising
protocol
family
using
the
Kalman
ﬁlter
algorithm

•  Dynamically
adap?ng
to
the
advance
of
the
reference
clock


•  Heterogeneity
of
devices

•  Communica?on
latencies

•  Conflicts
in
message
passing
through

the
protocol
stack

Sensor networks: Application development!
Considerable
cost
in
3me
and

development
effort

No
guarantee
that
design
errors
are
fixed
before
deployment

makeSense
project

(www.project-‐makesense.eu)

P1
P2
P2
P3
P4

Application Software

Master

Sound

card

Wiﬁ

card

Node
1

WiFi

Access
Point

(AP)

Slave

Sound

card

Wiﬁ

card

Node
N

Sensor networks: Application deployment!
Sensor Network Distributed Platform

Master

Sound

card

Wiﬁ

card

Node
1

WiFi

Access
Point

(AP)

Slave

Sound

card

Wiﬁ

card

Node
N



P1
P2
P2
P3
P4

Master

Sound

card

Wiﬁ

card

Node
1

WiFi

Access
Point

(AP)

Slave

Sound

card

Wiﬁ

card

Node
N

How to choose which
application process goes to !
which sensor node?


P1
P2
P2
P3
P4

•  Design
ﬂow
for
the
development
of
func3onal

WSN
applica?ons

•  Ensures
separa3on
of
concerns

•  Applica?on
So6ware
and
hardware
architecture

considered
independently

•  Deployment
based
on
the
op?mal
methodology
for

each
applica?on

•  Model-‐based:
Modularity,
reusability
of
ar3facts

•  Considers
all
the
constraints
of
sensor
networks
and

facilitates
applica?on
development
through:

•  Performance
Analysis
of
system
requirements

•  Automated
Code
Genera3on
Proposed method!

Outline!
1)  Sensor
Networks:
Overview
and
Development
Challenges

2)  Proposed
Design
ﬂow

•  Modeling
the
Applica?on
So@ware
in
PPM

•  Code
genera?on
in
Distributed
Sensor
Network
PlaEorms

•  Background
on
BIP

3)  Case
study:
Industrial
Mul?media
WSN
Applica?on

•  Code
genera?on
from
the
PPM
Applica?on
Model

•  Construc?on
of
the
System
Model
in
BIP

•  BIP
System
Model
Calibra?on

4)  Conclusion
and
ongoing
work

Application
Software (PPM)
Mapping/HW
information (PPM)
Sensor Network
HW
Specifications
(XML)
Design ﬂow for WSN Applications !
Inputs

Abstract System Model (BIP)
Application
Software (PPM)
modeling (1)
Mapping/HW
information (PPM)
Sensor Network
HW
Specifications
(XML)
Sensor Network
Library Components
(BIP)
code generation (2)
Sensor Network
C/C++ Code
Sensor Network/
HW Code
Templates
+Configurations
Developed

framework

Application
Software (PPM)
System Model (BIP)
modeling (1)
SMC
calibration (3)
Mapping/HW
information (PPM)
Sensor Network
HW
Specifications
(XML)
Sensor Network
Library Components
(BIP)
code generation (2)
analysis (4)
Sensor Network
C/C++ Code
Execution
Sensor Network/
HW Code
Templates
+Configurations
Outputs

Application
Software (PPM)
System Model (BIP)
modeling (1)
SMC
calibration (3)
Mapping/HW
information (PPM)
Sensor Network
HW
Specifications
(XML)
Sensor Network
Library Components
(BIP)
code generation (2)
analysis (4)
Sensor Network
C/C++ Code
Execution
Sensor Network/
HW Code
Templates
+Configurations

Pragmatic Programming Model (PPM)!
•  Descrip?on
language
facilita?ng
the
development
of

sensor
network
applica3ons

•  XML
format
providing
the
possibility
to
reference
C
ﬁles
as

external
libraries

•  Applica?on
So@ware
described
as
a
network
of

communica3ng
processes

•  Communica?on
through
shared
objects,
such
as:

•  FIFO

•  Shared
memory

•  Mutexed
loca?on

PPM Example: Application Software!
synchro
PLL

FIFO
Process Process

PPM Example: XML description !
<header
lang="c"
file="global.h"/>

<process
name="pll"
process-‐class="WhileFire">

<port
name="out"
peer-‐class="FIFO"
peer-‐name="in"/>

<header
lang="c"
file="pll_state.h"
x-‐state="true"/>

<header
lang="c"
file="pll.h"/><source
lang="c"
file="pll.c”>

<source
lang="c"
file="SPM_clock.c"
libs="-‐lblas
-‐lm
-‐lrt"/>

</process>

...

<shared-‐object
name="SO1"
object-‐class="FIFO"
size="4"
item-‐size="64">

<port
name="in"/>

<port
name="out"/>

</shared-‐object>

...

<connec?on>

<port-‐ref
node="SO1"
port="out"/>

<port-‐ref
node="pll"
port="in"/>

</connec?on>

synchro
PLL

FIFO
Process Process

#include
"pll_process.h”

void
pll_init(pll_process
*p)
{

(p-‐>local-‐>pll).stream_size
=
1;

(p-‐>local-‐>pll).block_size
=
(unsigned
int)
sizeof(clockOut_t);

(p-‐>local-‐>pll).data_in
=
malloc((p-‐>local-‐>pll).block_size);

p-‐>local-‐>data_size
=
(p-‐>local-‐>pll).block_size;

}

int
pll_ﬁre(pll_process
*p)
{

FIFO_read(p-‐>in,
(p-‐>local-‐>pll).data_in,
(p-‐>local-‐>pll).block_size);

gelmeofday
(
&(p-‐>local-‐>slave_?me),
NULL
);

uint64_t
slave_clock
=
(
(
uint64_t
)
p-‐>local-‐>slave_?me.tv_sec
*

(
uint64_t
)
1000000
)
+
(
uint64_t
)
p-‐>local-‐>slave_?me.tv_usec;

clockOut_t*
master_frameClock
=
(
clockOut_t*
)
(p-‐>local-‐>pll).data_in;

master_clock
=
master_frameClock-‐>?me;

pll_clock_in
(
slave_clock,
master_clock,
p-‐>local-‐>argument);

return
0;

}

PPM Example: Process behavior!
•  Described
as
the
program:

•  P
init();while(true)P
ﬁre();

•  Communica?on
through:

•  Read
(e.g.
FIFO_read)

•  Write
(e.g.
FIFO_write)

synchro
PLL

FIFO
Process Process

PPM Example: Application deployment!
Master

Sound

card

Wiﬁ

card

WiFi

Access
Point

(AP)

Slave

Sound

card

Wiﬁ

card

UDOO
Node
N
UDOO
Node
1

synchro
PLL

FIFO
Process Process

<deployment>

<app-‐node
name="pll"/>

<hw-‐element
name="node"
hw-‐class="udoo"
index="0"/>

<hw-‐property
name="networkInterface"
hw-‐class="node-‐inter"
value="wlan0"/>

<hw-‐property
name="srcPort"
hw-‐class="node-‐srcPort"
value="375"/>

<hw-‐property
name="dstPort"
hw-‐class="node-‐dstPort"
value="250"/>

<hw-‐property
name="dstIP"
hw-‐class="node-‐dstIP"
value="10.0.0.14"/>

</deployment>

PPM Example: Application deployment!
synchro
PLL

FIFO
Process Process

•  Each
process
is
implemented
as
a
thread

•  Threads
allocated
to
sensor
nodes
according
to
applica?on

deployment
in
PPM

•  Shared
objects
implemented
according
to
the
underlying

hardware
plaUorm

•  FIFO_read
and
FIFO_write
primi?ves
replaced
by
API
func3on
calls

of
the
supported
communica?on
protocol
(i.e.
Linux
sockets

parameterized
with
the
UDP
protocol)

•  Applica?on
Deployment
also
used
to
define
configura?on

parameters
for
the
communica?on
protocols

•  Generated
code
is
implemented
using
re-‐targetable
template
files

•  Portable
since
it
can
be
deployed
and
run
in
any
hardware
plaUorm

suppor?ng
Linux
sockets

PPM Example: Code Generation!

memcpy
(
self.buffer,
f
-‐>
data_in,
f
-‐>
block_size
);

iCom
=
sendto
(
self.sock,
self.buffer,

self.buffer_size,
0,
(struct
sockaddr*)
(&(self.dst_addr)),
sizeof(self.dst_addr)
);

if
(
iCom
==
-‐1
)

{

prinE
(
"COM_eth_udp_lin
process
(sendto)

error
(%d)
:
%sn",
errno,
strerror(errno)
);

return
(
-‐1
);

}

memset
(
&recvfrom_addr,
0,sizeof(
recvfrom_addr
)
);

iCom
=
recvfrom
(
self.sock,
self.buffer,

self.buffer_size,
0,
(struct
sockaddr*)
&recvfrom_addr,

&recvfrom_addr_len
);

if
(
iCom
==
-‐1
)

{

prinE
(
"COM_eth_udp_lin
process
(recvfrom)

error
(%d)
:
%sn",
errno,
strerror(errno)
);

return
(
-‐1
);

}

PPM Example: Code Generation!
synchro
PLL

FIFO
Process Process

Application
Software (PPM)
System Model (BIP)
modeling (1)
SMC
calibration (3)
Mapping/HW
information (PPM)
Sensor Network
HW
Specifications
(XML)
Sensor Network
Library Components
(BIP)
code generation (2)
analysis (4)
Sensor Network
C/C++ Code
Execution
Sensor Network/
HW Code
Templates
+Configurations

•  BIP
(Behavior-‐Interac?on-‐Priority)
is
a
formal

language
for
the
hierarchical
construc?on
of

heterogeneous
real-‐?me
systems

•  Provides
a
rich
set
of
tools
for
analysis
and

performance
evalua?on

B
E
H
A
V
I
O
R

Interactions (collaboration)!
Priorities (conﬂict resolution)!
The BIP component framework!
Composi?on

glue

Atomic

components


BIP component example!
•  Atomic
component
modeling
the
PLL
process

•  Atomic
component
modeling
the
PLL
process

•  BIP
components:
transi?on
systems
enriched
with
data
and
func?ons

in
C/C++

•  Atomic
component
modeling
the
PLL
process

•  BIP
components:
transi?on
systems
enriched
with
data
and
func?ons

in
C/C++

•  Interac?ons
used
to
transfer
data
between
components

•  Atomic
component
modeling
the
PLL
process

•  BIP
components:
transi?on
systems
enriched
with
data
and
func?ons

in
C/C++

•  Interac?ons
used
to
transfer
data
between
components

•  Priori?es
enforce
scheduling
policies
amongst
possible
interac?ons

CLK_REQ<CLK_RECV

The BIP component framework!
•  Func3onal
veriﬁca3on

•  BIP
state-‐space
explora3on
tool
used
to
verify
safety
requirements,

such
as
deadlock-‐freedom,
in
the
constructed
models

•  Model
calibra3on
based
on
code
execu?on
in
the
target
HW
plaEorm

•  HW/SW
dependent
constraints
injected
in
the
form
of
probabilis?c

distribu?ons

•  Aims
in
obtaining
faithful
models
for
a
considered
system

•  Performance
Analysis
of
applica?on
or
system-‐level
requirements

•  Sta3s3cal
Model
Checking
(SMC)
tool
for
quan?ta?ve
veriﬁca?on

•  Results
provide
feedback
in
the
applica?on
design/development
phase

Supports:

Outline!
1)  Sensor
Networks:
Overview
and
Development
Challenges

2)  Proposed
Design
Flow

•  Modeling
the
Applica?on
So@ware
in
PPM

•  Code
genera?on
in
Distributed
Sensor
Network
PlaEorms

•  Background
on
BIP

3)  Case
study:
Industrial
Mul?media
WSN
Applica?on

•  Code
genera?on
from
the
PPM
Applica?on
Model

•  Construc?on
of
the
System
Model
in
BIP

•  BIP
System
Model
Calibra?on

4)  Conclusion
and
ongoing
work

Case study: Industrial WMSN Application !
•  Clock
Synchroniza?on
in
a
Mul?media
Wireless
Sensor
Network
(WMSN)

•  Capturing
and
reproduc3on
of
synchronized
audio
data
in
the
sink

•  Use
of
the
API
provided
by
the
Advanced
Linux
Sound
Architecture
(ALSA)

•  Sender-‐to-‐receiver
synchroniza3on

Master Node
Slave Node
Slave Node
Access Point
(AP)

Case study: Industrial WMSN Application !
•  Clock
Synchroniza?on
in
a
Mul?media
Wireless
Sensor
Network
(WMSN)

•  Capturing
and
reproduc3on
of
synchronized
audio
data
in
the
sink

•  Use
of
the
API
provided
by
the
Advanced
Linux
Sound
Architecture
(ALSA)

•  Sender-‐to-‐receiver
synchroniza3on

•  Snowball
SDK
plaEorm
conﬁgured
as
AP
in
the
WSN
(sta?c
ad-‐hoc
DHCP

server
capable
of
assigning
automa?cally
IP
addresses)

•  3
UDOO
plaEorms
automa?cally
connected
to
the
WSN
through
the
AP

(1
Master,
2
Slave
nodes)

•  Master
UDOO
node
broadcasts
periodically
(T=5s)
a
?mestamp
frame

•  Phase
Locked
Loop
(PLL)
synchroniza3on
technique
applied
in
the
slave

UDOO
nodes
to
construct
a
so6ware
clock

•  The
so@ware
clock
follows
the
advance
of
the
Master
node’s
clock
and

maintains
a
rela?ve
oﬀset
from
it

Case study: PPM Model!

Case study: WMSN Application deployment!

Case study: Abstract BIP System Model!

Case study: System Model Calibration!

ρ1
ρ3
λok
ρ2
λfail
λdelay
Case study: System Model Calibration!

Case study: Distribution fitting!
•  Method
used
to
obtain
each
distribu?on:

•  Special
case
of
model
fiYng

•  Target
model
is
a
probability
distribu3on

•  Relying
on
sta?s?cal
methods
in
order
learn
the
best
probability

distribu?on
that
fits
the
obtained
execu3on
data

Probability
distribu3on
(λdelay) Box-‐Whisker
plot
(λdelay)

•  Method
used
to
obtain
each
distribu?on:

•  Special
case
of
model
ﬁYng

•  Target
model
is
a
probability
distribu3on

•  Relying
on
sta?s?cal
methods
in
order
learn
the
best
probability

distribu?on
that
ﬁts
the
obtained
execu3on
data

Probability
distribu3on
(λdelay) Box-‐Whisker
plot
(λdelay)

Outliers
Mean
•  Method
used
to
obtain
each
distribu?on:

•  Special
case
of
model
ﬁYng

•  Target
model
is
a
probability
distribu3on

•  Relying
on
sta?s?cal
methods
in
order
learn
the
best
probability

distribu?on
that
ﬁts
the
obtained
execu3on
data

Case study: Analysis results!
•  The
calibrated
BIP
system
model
was
used
for
tes?ng:

•  Cri?cal
func?onal
and
non-‐func?onal
requirements,
such

as
buffer
u3liza3on

•  The
synchroniza3on
accuracy

•  We
have
expressed
the
following
proper?es:

1)  What
is
the
probability
of
overflow/underflow
avoidance

in
the
transmission/recep?on
buffers
of
the
considered

WMSN
Applica?on?

2)  Is
the
achieved
synchroniza?on
accuracy
1μs?

•  Focus:
Es?ma?on
of
the
probability
for
overflow/underflow
in
the

transmission/recep?on
buffers
of
the
system

•  The
property
is
expressed
as:

1)  φ1
=
(size(Sbuffer)
<
MAX),
where
MAX=400

2) 
φ2
=
(size(Mbuffer)
>
0)

Property 1: Buffer utilization!
P(φ1)
Case study: Property verification!
P(φ2)

Property 2: Synchronization accuracy!
•  Focus:
Difference
between
the
Master
and
the
Slave
so6ware
clock
should
be

bounded
by
a
non-‐nega?ve
number
∆

•  The
property
is
expressed
as:
φ3
=
(|(θM
−
θS
)
−
A|
<
∆)

•  A
is
a
fixed
offset
between
the
Master
and
each
Slave’s
so@ware
clock

System ModelGenerated code
•  Focus:
Difference
between
the
Master
and
the
Slave
so6ware
clock
should
be

bounded
by
a
non-‐nega?ve
number
∆

•  The
property
is
expressed
as:
φ3
=
(|(θM
−
θS
)
−
A|
<
∆)

•  A
is
a
fixed
offset
between
the
Master
and
each
Slave’s
so@ware
clock

System Model
Here
A=100μs

•  For
Δ=1μs
φ3
is
not
sa?sfied

•  For
Δ=76μs
φ3
is
sa3sfied

•  Focus:
Difference
between
the
Master
and
the
Slave
so6ware
clock
should
be

bounded
by
a
non-‐nega?ve
number
∆

•  The
property
is
expressed
as:
φ3
=
(|(θM
−
θS
)
−
A|
<
∆)

•  A
is
a
fixed
offset
between
the
Master
and
each
Slave’s
so@ware
clock

Here
A=100μs

•  For
Δ=1μs
φ3
is
not
sa?sfied

•  For
Δ=76μs
φ3
is
sa3sfied

•  Also
observed
from
the

results
of
the
generated

code

Generated code
•  Focus:
Difference
between
the
Master
and
the
Slave
so6ware
clock
should
be

bounded
by
a
non-‐nega?ve
number
∆

•  The
property
is
expressed
as:
φ3
=
(|(θM
−
θS
)
−
A|
<
∆)

•  A
is
a
fixed
offset
between
the
Master
and
each
Slave’s
so@ware
clock

Conclusions!
•  Fully-‐fledged
design
flow
for
the
development
of
func?onal
distributed

sensor
applica?ons

•  Automated

Code
Genera3on
and
Performance
Analysis
using
as
input:

•  Applica?on
So@ware
described
in
PPM
(XML
format
with
reference
to

C/C++
func3ons)

•  Hardware
specifica?on
(for
the
network
configura3on)

•  Mapping
specifica?on
(for
the
applica3on
deployment)

•  We
have
applied
it
in
a
Wireless
Mul?media
Sensor
Network
(WMSN)

Applica?on
and
our
experiments
focused
on:

•  Buffer
u3liza3on

•  Synchroniza3on
accuracy

•  Results
provide
feedback
for
the
proper
configura?on
of
similar
applica?ons

Perspectives!
•  Adapt
the
design
flow
for
lower
resource
consump3on
hardware
plaUorms,

which
use
dedicated
opera?ng
systems
(e.g.
TinyOS,
Con3ki
OS)

•  Low
amount
of
data
supported
in
each
packet

•  Packet
fragmenta?on
may
lead
to:

1)  Collisions
in
the
MAC
layer

2)  Frequent
packet
losses

•  Mechanisms
to
improve
clock
synchroniza3on

•  Reduc?on
of
the
rela?ve
offset
between
the
Slave
so@ware
clock
and

the
Master
clock
by
oscilla3ng
the
transmission
frequency
of
the

Master’s
3mestamp

•  High
frequency
rate
may
lead
to
higher
energy
consump3on

•  Possible
change
of
the
Kalman
filter
algorithm
will
be
considered

Questions?!
Thank you for your attention.!
Further details: alexios.lekidis@imag.fr!

Rapid development of WSN applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Rapid development of WSN applications

Similar to Rapid development of WSN applications (20)

Recently uploaded

Recently uploaded (20)

Rapid development of WSN applications