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!Environment Healthcare Transportation

High-energy physics Manufacturing Agriculture

Environment Healthcare Transportation

High-energy physics Manufacturing Agriculture

and many more…

Sensor Networks: Application domains!

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

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




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 fixed ?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)










•  Promising protocol family using the Kalman filter 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

Wifi card

Node 1

WiFi Access Point

(AP)

Slave

Sound card

Wifi card

Node N

Sensor networks: Application deployment!

Sensor Network Distributed Platform


Master

Sound card

Wifi card

Node 1

WiFi Access Point

(AP)

Slave

Sound card

Wifi card

Node N

Sensor networks: Application deployment!Application Software


P1 P2 P2 P3 P4


Master

Sound card

Wifi card

Node 1

WiFi Access Point

(AP)

Slave

Sound card

Wifi card

Node N

Sensor networks: Application deployment!How to choose which application process goes to !which sensor node?


Application Software

P1 P2 P2 P3 P4


•  Design flow 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 flow •  Modeling the Applica?on So@ware in PPM •  Code genera?on in Distributed Sensor Network PlaEorms




Application Software (PPM)

Mapping/HW information (PPM)

Sensor Network HW

Specifications (XML)


Design flow for WSN Applications !

Inputs

Abstract System Model (BIP)


modeling (1)


Sensor Network HW


Sensor Network Library Components

(BIP) code generation (2)

Sensor Network

C/C++ Code

Sensor Network/HW Code Templates

+Configurations



Developed framework



System Model (BIP)

modeling (1)

SMC

calibration (3)


Sensor Network HW




analysis (4)

Sensor Network

C/C++ Code

Execution


+Configurations



Outputs




System Model (BIP)

modeling (1)

SMC

calibration (3)


Sensor Network HW




analysis (4)

Sensor Network

C/C++ Code

Execution


+Configurations


Pragmatic Programming Model (PPM)!


•  Descrip?on language facilita?ng the development of sensor network applica3ons

•  XML format providing the possibility to reference C files 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_fire(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 fire();

•  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

Wifi card

WiFi Access Point

(AP)

Slave

Sound card

Wifi 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) : %s\n", 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) : %s\n", errno, strerror(errno) );

return ( -‐1 ); }

PPM Example: Code Generation!

synchro PLL

FIFO

Process Process



System Model (BIP)

modeling (1)

SMC

calibration (3)


Sensor Network HW




analysis (4)

Sensor Network

C/C++ Code

Execution


+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 (conflict resolution)!

The BIP component framework!

Composi?on

glue

Atomic

components


BIP component example!


•  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





•  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 verifica3on •  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 verifica?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





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 configured 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 offset 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)






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

Mean






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)



Case study: Property verification!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

Property 2: Synchronization accuracy!

System Model Generated code


Case study: Property verification!

•  Focus: Difference between the Master and the Slave so6ware clock should be bounded by a non-‐nega?ve number ∆



System Model


Here A=100μs

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

•  For Δ=76μs φ3 is sa3sfied






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





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: [email protected]!


Science

Rapid development of WSN applications