Applications - Network and Systems Lab

Data Quality-Centric 

Mode-Driven Development 

for WSN Applications 

Ryo Shimizu 

(kiyo07@fuka.info.waseda.ac.jp)

Research Overview 

• WSN (Wireless Sensor Network) Application 

+ MDD (Model-Driven Development) Process 

developer 

Initial Modeling 

Application 

Logic 

Communications 


Task 

Assignments 

Application 

Code 

Execute 

& 

Monitor 

& 

Analyze 

IPSN 2013 Ph.D. Forum 

Iterative Modeling 

developer 

Application 

Logic 

Task 

Assignments 

Application 

Code 

Rapid prototyping 

: automatic 

transformation 

: manual 

modeling 

Fine-grained tuning 

1


WSN “Monitoring” Applications 

• Most typical WSN application [Bai09] , e.g. building monitoring [Ceriotti09] 

• The data quality depends on the execution 

environment [Tilak02][Zhao03] 

• Data quality: quality of obtained data 

• data loss rate (reliability), data sensing span (lifetime), etc… 

lossy 

Data loss rate 

will increase 

developer 

Developers 

cannot grasp 

the qualities 

before 

execution 

The tuning for the data quality is important 

[Bai09] L. S. Bai et al. “Archetype-based design of sensor network programming for application experts, not just programming experts”, IPSN 2009. 

[Ceriotti09] M. Ceriotti et al. “Monitoring heritage buildings with wireless sensor networks: The Torre Aquila deployment” IPSN 2009. 

[Tilak02] S. Tilak et al. “Infrastructure tradeoffs for sensor networks”, WSNA 2002. 

[Zhao03] J. Zhao et al. “Understanding Packet Delivery Performance In Dense Wireless Sensor Networks”, SenSys 2003. 

2

Development Process 

• Prototyping & tuning & tuning & tuning… 

Execute the 

prototype 


developer 

Modify 

Develop a 

prototype 

High data 

loss rate 

Obtain the Tune the 

quality 

quality 

Change the following: 

‣ task assignments 

‣ e.g. assign tasks to more nodes 

‣ communications 

‣ e.g. change a routing protocol 

Rapid prototyping & fine-grained tuning is important 

3


WSN Application Development 

• Development with domain specific language (DSL) 

Node-level Group-level Dataflow-level 

trade-off between the feasibility of the rapid 

prototyping and the fine-grained tuning 

Aggregate 

data 

data 

• 

region = apmesh_region.create(); 

while(true){ 

SELECT temp, AVG(deformatin) … 

reading = get_sensor_reading(); FROM sensors 

send_to_basestation(avg); 

SAMPLE PERIOD 5 

sleep(periodic_delay); 

} 

e.g. NesC [Gay03] e.g. Abstract regions [Welsh04] e.g. TinyDB [Madden05] 

classified into three classes based on the level of abstraction [Mottola11] 4 

… 

event void Timer.fired(){ call Read.read(); } 

event void Read.readDone(error_t result, 

uint16_t data){ 

msg->deform = data; 

call Collection.send(&msg, 

sizeof(deform_msg_t)); 

} 

…. 

[Gay ’ 03] “The nesC Language: A Holistic Approach to Networked Embedded Systems”, D. Gay et al., PLDI 2003. 

[Welsh ’ 04] “Programming Sensor Networks Using Abstract Regions”, Matt Welsh and Geoff Mainland, NSDI 2004. 

[Madden ’ 05] “TinyDB: An Acqusitional Query Processing System for Sensor Networks”, S. Madden et al., TODS 2005. 

[Mottola11] L. Mottola et al. “Programming wireless sensor networks: Fundamental concepts and state of the art,” ACM Comput. Surv., 2011.


Idea: Combine the strength of three levels 

How to use them in one development process? 

Application Logic 

Deterioration 

Deformation 

AVG 

Fusion 

Acceleration 

How to realize on 

the target network? 


Compress? 

What 

topology? 

How to realize on 

each sensor node? 

Task Assignments 

How to 

assign? 

Base station role 

Leader role 

Member role 

5


Data Quality-Centric MDD Process 

• Explicit usage of three abstraction levels 

• Combine the strength of three levels 

Prototyping 

Tuning 

Req. 

Dataflow-level 

Modeling 

Dataflowlevel 

Model 

Dataflowlevel 

Model 


Modeling 


Model (mod) 

Grouplevel 

Model 

Grouplevel 

Model 

Group-level 

Modeling 

Group-level 

Model (mod) 

Automatic 

Generation 

Node-level 

Model 

Node-level 

Model 

Node-level 

Modeling 

Node-level 

Model (mod) 

Application 

Code 

Application 

Code (mod) 

Execute 

Measure the 

performance 

Redesign 

Modification 

for design 

6

DataflowML 


• Expresses data flow that application requires 

Example 

• Network-independent 

• Consists of data source, intermediate processing 

point (aggregation/fusion), data sink 

: DataSink 

: SpatialAggregationPoijnt 

function = AVERAGE 

inputDataType = TEMPERATURE 

Aggr 

Fusion 

: DataSource 

dataType = TEMPERATURE 

samplingCondition = 30sec 

transmissionCondition = 30sec 

location = ROOM1 

Data 

Data 

Data 

7


Prototyping Phase 

• Design an application logic as a dataflow 

Prototyping 

Req. 

Automatic 

Generation 


Modeling 

Grouplevel 

Model 

Node-level 

Model 

Dataflowlevel 

Model 

Application 

Code 

• DataflowML 

• to express the networkindependent 

dataflow 

• Transformation rules 

• generate an application 

code 

• generate corresponding 

models (group-level & 

node-level) 

Developers only need to design the application logic 

8

GroupML 


• Expresses the behavior / configuration of node 

group(s) on the network 

Example 

• Consists of leader/member group, 

group configuration, group’s task 

: Group 

topology = TREE 

locationCondition = WHOLE 

L : Leader 

: Member 

M 

: Sink 

: Communication 

compress = NONE 

encryption = NONE 

: Group 


locationCondition = ROOM1 

: SpatialAggregationOperator 



: LeaderNode 

selectionPattern = ANY 




: MemberNodes 

selectionPattern = ALL 




L 

M 

M 

L 

M 

9

NodeML 

• Expresses the assigned role & task for 

individual node 

: Node 

id = 0 


Example 


: BaseStationRole 

deploymentCondition = id == 0 

: ReceivingTask 

protocol = CTP 

receiveDataType = TEMPERATURE 



: Node 

id = 1 


: LeaderRole 

deploymentCondition = ANY 

memberIds = {2, 3, 4} 

: SendingTask 


sendDataType = TEMPERATURE 




: SpatialAggregationTask 



: Node 

id = 2 


: ReceivingTask 


receiveDataType = TEMPERATURE 



: MemberRole 

deploymentCondition = ALL 

: SamplingTask 



: SendingTask 






10

Tuning Phase 

• Re-design communication methods & task 

assignments 

Tuning 

Dataflowlevel 

Model 

Grouplevel 

Model 

Node-level 

Model 


Modeling 

Group-level 

Modeling 

Node-level 

Modeling 


Model (mod) 

Group-level 

Model (mod) 

Node-level 

Model (mod) 

Application 

Code (mod) 

• GroupML 


• to express the 

configuration of the 

leader-member type node 

group 

• NodeML 

• to express the behavior of 

each node 

Developers can redesign the communication 

methods & task assignments 

11

Tool Implementation 


As eclipse plugin 

with existing tools 

‣ Graphical Editing Framework 

(GEF) 

‣ GRoundTram System 

‣ Acceleo 

12

Case Studies 


• Conducted seven case studies (Simulated app. developments) 

Application 

Reference 

Heritage building monitoring 

Clinical monitoring 

M. Ceriotti et al. “Monitoring heritage buildings with wireless sensor networks: The Torre 

Aquila deployment” IPSN 2009. 

O. Chipara et al. “Reliable Clinical Monitoring using Wireless Sensor Networks: Experiences in 

a Step-down Hospital Unit” SenSys 2010. 

Wildfire monitoring D. M. Doolin, N. Sitar. “Wireless sensors for wildfire monitoring” SPIE 2005. 

Weather monitoring 

Bridge monitoring 

C. Hartung et al. “Firewxnet: a multi-tiered portable wireless system for monitoring weather 

conditions in wildland fire environments” MobiSys 2006. 

S. Kim et al. “Health monitoring of civil infrastructures using wireless sensor networks” IPSN 

2007. 

Volcano monitoring G. Werner-Allen et al. “Fidelity and yield in a volcano monitoring sensor network” OSDI 2006. 

Fence monitoring 

G. Wittenburg et al. “Fence monitoring: experimental evaluation of a use case for wireless 

sensor networks”, EWSN 2007. 

• Main focuses 

Q1. Can we model the application logic in the DataflowML? 

Q2. Can we model all design decisions related to the tuning of the 

data quality in our DSMLs? 

13


Heritage building monitoring 

Purpose 

• to detect structural deterioration 

Deployment 

• a medieval tower in Italy 

• with 16 nodes 

• monitored over four months 

† 

Application logic 

• senses four types of data 

• acceleration, deformation, temperature, 

humidity 

• Bayesian algorithm processes these data 

• to determine the deterioration 

Design for tuning 

• task assignments based on physical position 

• Huffman data compression 

† http://d3s.disi.unitn.it/projects/torreaquila 14


Modeling of Application Logic 

• In the heritage building monitoring application… 

• Sensor data: acceleration, deformation, temperature, humidity 

• Processing: a Bayesian algorithm 

Dataflow-level Model 

: DataSink 

: FusionPoint 

function = DeseaseDetection 

inputDataTypes = {ACCELERATION, DEFORMATION, TEMPERATURE, HUMIDITY} 

outputDataType = StracturalCondition 

: DataSource 

dataType = ACCELERATION 

samplingCondition = 0.005 sec 

transmissionCondition = 30 sec 

location = WHOLE 

: TemporalAggregationPoinnt 


inputDataType = DEFORMATION 

timeWindow = 100 min 

duration = 10 min 

: DataSource 


samplingCondition = 10 min 

transmissionCondition = 10 min 


: DataSource 

dataType = HUMIDITY 




: DataSource 

dataType = DEFORMATION 




We could model five application 

logics with DataflowML 

15


Modeling of Designs for Tuning (1) 


• Req. : reduce the amount of communications 

• Design decision: adopt a data compression in 

communication 

: Group 



: Sink 




: Group 



: FusionOperator 

HUFFMAN 




function = DeseaseDetection 

inputDataTypes = {ACCELERATION, DEFORMATION, TEMPERATURE, HUMIDITY} 

outputDataType = StracturalCondition 

: Group 



: LeaderNode 





: MemberNodes 





: MemberNodes 





: MemberNodes 





: TemporalAgg 

inputDataType 

function = AVE 

timeWindow = 

duration = 10 m 

: LeaderNode 

: MemberNodes 







16


Modeling of Designs for Tuning (2) 


Before 







• Req. : detect early symptoms of deteriorations 

• Design decision: assign tasks based on the physical position 

of nodes 

: SendingTask 


sendDataType = HUMIDITY 




: MemberRole 


: Node 

id = 141 

location = 3F 

: MemberRole 


: SendingTask 






: Node 

id = 146 

location = 3F 

: SendingTask 


sendDataType = ACCELERATION 


compress = Huffman 


: MemberRole 


: Node 

id = 153 

location = 3F 

: MemberRole 


: SendingTask 


sendDataType = DEFORMATION 




After 


dataType = ACCELERATION protocol = CTP 

samplingCondition = 0.2 sec sendDataType = HUMIDITY 






samplingCondition : SamplingTask = 10 min 



: TemporalAggregationTask 



: 

timeWindow 

SamplingTask 

= 100 min 

dataType duration = TEMPERATURE 

= 10 min 


: SendingTask 

: MemberRole 


: Node 

id = 141 

location = 3F 

: MemberRole 


: SendingTask 

: Node 

id = 146 

location = 3F 

: SendingTask 


sendDataType = ACCELERATION 


compress = Huffman 


: MemberRole 


: Node 

id = 153 

location = 3F 

: MemberRole 


: SendingTask 







: TemporalAggregationTask 



sendDataType = TEMPERATURE sendDataType = DEFORMATION 

transmissionCondition = 10 min transmissionCondition = 10 min 

We could model task assignments compress = NONE & compress communication 

= NONE 



methods adopted in realistic applications 



timeWindow = 100 min 

duration = 10 min 

17

Summary of Case Studies 

• We conducted seven case studies with our MDD 

process 

Q1:Can we model the 

application logic in the 

DataflowML? 

Q2. Can we model all 

design decisions related 

to the tuning of the data 

quality in our DSMLs? 

O 

K 

N 

G 

O 

K 

N 

G 


Application logics of periodic WSN 

applications 

Application logics of event-based 

applications 

Designs of the applications 

(communications & task 

assignments) 

Designs for tuning related to OS-level 

functions 

We could model realistic monitoring WSN applications 

from the aspect of application designer 

with our MDD by using multiple abstraction level 

18

Summary 

Goal 


• Satisfy rapid prototyping & fine-grained tuning for 

the data quality 

Solution 

• propose MDD process defines explicit usage of 

three abstraction levels 

Prototyping Phase 

developer 

Dataflowlevel 

Dataflowlevel 

Group-level 

Node-level 

Application 

Code 

Execute 

& 

Monitor 

& 

Analyze 

developer 

Tuning Phase 

Group-level 

Node-level 

Application 

Code 

19


Future Direction 

Conduct experiment 

• through a complete application development 

• extend DSMLs to express the event-based application 

logic & more variability for the tuning of the data 

quality 

Consistency checking 

• to keep consistency between models at multiple 

abstraction levels 

• because we assume manual modifications for models 

in the development process 

20


THANK YOU. 

21

Applications - Network and Systems Lab

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?