Efficient Data Collection with HeterogeneousCooperating Objects for Environmental Monitoring

Dissertationzur Erlangung des Doktorgrades

“Dr. rer. nat.”

der Fakultät für Wirtschaftswissenschaftender Universität Duisburg-Essen

vorgelegtvon

Richard Figura

aus

Bonn, Deutschland

Betreuer:

Prof. Dr. Pedro José MarrónNetworked Embedded Systems Group (NES)

Institut für Informatik und Wirtschaftsinformatik (ICB)

Essen, September 2019

Erstgutachter: Prof. Dr. rer. nat. Pedro José Marrón (Universität Duisburg-Essen)Zweitgutachter: Prof. Dr. rer. nat. Jörg Hähner (Universität Augsburg)

Tag der mündlichen Prüfung:

17. März 2020

Diese Dissertation wird über DuEPublico, dem Dokumenten- und Publikationsserver derUniversität Duisburg-Essen, zur Verfügung gestellt und liegt auch als Print-Version vor.

DOI:URN:

10.17185/duepublico/71757urn:nbn:de:hbz:464-20200610-081113-4

Dieses Werk kann unter einer Creative Commons Namensnennung4.0 Lizenz (CC BY 4.0) genutzt werden.

https://duepublico2.uni-due.de/https://duepublico2.uni-due.de/https://doi.org/10.17185/duepublico/71757https://nbn-resolving.org/urn:nbn:de:hbz:464-20200610-081113-4https://creativecommons.org/licenses/by/4.0/https://creativecommons.org/licenses/by/4.0/https://creativecommons.org/licenses/by/4.0/

Dedicated to my beloved son Jonathan.

A C K N O W L E D G M E N T S

I would like to express my sincere gratitude to my advisor Prof. Dr. Pedro José Marrónfor the opportunity to delve deeper into the variet aspects of this area of research and tocomplete this thesis in his group. My sincere thanks also goes to Prof. Dr. Jörg Hähnerfor agreeing to evaluate my research.

Furthermore, I am deeply appreciated of my colleagues from the Networked Em-bedded Systems Group of the University of Duisburg-Essen for their helpful commentsand suggestions. Here, I am particularly grateful to Matteo for always encouragingme to keep making progress and giving me invaluable advice whenever needed. Aspecial thank you also goes to Robert for questioning my solutions in a positive way, toStephan for challenging me in a constructive way, to Sascha for teaching me to alwaysremain optimistic, to Ngewi and his familiy for their hospitality and to Elke for keepingmuch of the administrative side of work away from me. I can always count on a fruitfuldiscussion with all of you! From my time in Bonn, I would also like to thank Alex forinspiring me to never stop learning.

Throughout this chapter of my life, nothing has been more important to me thanthe support of my family and friends. I am forever indebted to all of my parents andespecially my wife, whose endless patience and encouragement helped me accomplishthis task. Clarissa, thank you very much for all your support!

Essen, 22. September, 2019

A B S T R A C T

Environmental Monitoring is the process of retrieving and analysing information abouta specific target area, such as a city, a factory or a rural environment. Environmen-tal Monitoring is an essential piece of the puzzle, to get an understanding about howdifferent environmental attributes rely on each other or to understand how the area isinfluenced by external factors e.g. by human kind. After all, traditional approachesfor environmental monitoring – such as wired systems of sensors – require an existinginfrastructure, which makes them very costly and inflexible once they are installed. Asolution is provided by networks of Cooperating Objects (COs), which are an ideal can-didate for automated environmental monitoring. In such a network, each device bringsits own resources regarding energy supply, as well as computation and communicationcapabilities which makes them a scalable solution that can flexibly be adapted for theoperator’s needs. Here, a set of static sensors provide reliable monitoring data, whichis complemented by on demand readings from autonomous robots, such as UnmannedAerial Vehicles (UAVs) and Unmanned Ground Vehicles (UGVs). However, keepingin mind the environmental and system dynamics, the deployment and data collectionprocedures for these systems must also be carefully planned. Furthermore, the operatorneeds a simple and intuitive interface for the deployment, maintenance and data analysis.

This thesis focuses on how environmental characteristics can be made available tothe user, by using a network of COs. Specifically, this thesis makes the followingcontributions: 1. It enables faithful simulations for environmental-aware deploymentplanning, 2. it considers the system complexity by enabling the simulation of networksof heterogeneous COs, such as Wireless Sensor Networks (WSNs), UAVs and UGVs,3. it allows maximisation of the throughput to a mobile sink by providing an adaptivecommunication protocol and 4. it assists non-technical experts in using heterogeneousnetworks of COs by providing tools for efficient visualisation, data analysis and deploy-ment management. Each of these contributions is one unique and coherent step towardsenabling efficient data collection with heterogeneous COs for environmental monitoring.The evaluation was performed in different experimental setups in testbed scenarios, aswell as real-world experiments. It shows that the combination of all four contributionsallows users to efficiently plan a deployment of networked COs, to collect sensor datawith mobile sinks and to analyse the collected data. Based on this work, the outlookshows that it becomes also possible to include collected data into a publicly availableknowledge graph – known as the semantic web – that enables users around the world tointegrate monitored data into their own applications.

TA B L E O F C O N T E N T S

List of Figures ix

List of Listings xi

List of Tables xiii

List of Symbols xv

1 Introduction 11.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Definition of Terms and Goal of this Thesis . . . . . . . . . . . . . . . . . . 21.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 State of the Art 92.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Operating Systems and Software Support . . . . . . . . . . . . . . 112.1.2 Reference Applications . . . . . . . . . . . . . . . . . . . . . . . . 132.1.3 Strengths and Limitations . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Cooperating Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Operating Systems and Software Support . . . . . . . . . . . . . . 182.2.2 Reference Applications . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3 Strengths and Limitations . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1 Analytical Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Simulation Driven Solutions . . . . . . . . . . . . . . . . . . . . . 25

2.4 Data Collection with Mobile Sinks . . . . . . . . . . . . . . . . . . . . . 272.4.1 Challenges in Mobile Scenarios . . . . . . . . . . . . . . . . . . . . 272.4.2 Throughput Maximisation to a Mobile Sink . . . . . . . . . . . . . 28

2.5 Deployment Management and Operation . . . . . . . . . . . . . . . . . . 292.5.1 System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5.2 Application Data Analysis . . . . . . . . . . . . . . . . . . . . . . 30

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Deployment Planning 333.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Moρϕευς Framework . . . . . . . . . . . . . . . . . . . . . . . . 35

vi TABLE OF CONTENTS

3.1.2 Moρϕευς lifecycle in a deployment of Cooperating Objects . . . . 363.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Radio Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.2 Metrics discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.3 Fidelity Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Summary - Moρϕευς . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Distributed Simulation of Heterogeneous COs 454.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1 K A S S A N D R A Framework . . . . . . . . . . . . . . . . . . . . . . 474.1.2 K A S S A N D R A Lifecycle in a Deployment of COs . . . . . . . . . 48

4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.1 Communication Middleware . . . . . . . . . . . . . . . . . . . . . 494.2.2 Real COs, Application Modules and Visualiser . . . . . . . . . . . 504.2.3 Simulation-Specific Components . . . . . . . . . . . . . . . . . . . 514.2.4 K A S S A N D R A Modules Interaction . . . . . . . . . . . . . . . . . 53

4.3 Summary - K A S S A N D R A . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Mobile Data Collection 595.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.1 Modelling Transfer Strategies . . . . . . . . . . . . . . . . . . . . . 625.1.2 Composing Transfer Strategies . . . . . . . . . . . . . . . . . . . . 66

5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2.1 I C E L U S in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . 675.2.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3 Summary - I C E L U S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Data Analysis and Processing 736.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.1.1 I R I S Architecture Overview . . . . . . . . . . . . . . . . . . . . . 756.1.2 I R I S Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2 Implementation and Usage . . . . . . . . . . . . . . . . . . . . . . . . . 796.2.1 Pre-Experiment Phase . . . . . . . . . . . . . . . . . . . . . . . . . 806.2.2 Experiment Runtime . . . . . . . . . . . . . . . . . . . . . . . . . 826.2.3 Post-experiment: Analysis and Management . . . . . . . . . . . . . 836.2.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.3 Summary - I R I S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7 Evaluation 857.1 Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.1.1 Reconfiguration with Moρϕευς . . . . . . . . . . . . . . . . . . . 867.1.2 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 877.1.3 Bottleneck discussion . . . . . . . . . . . . . . . . . . . . . . . . . 897.1.4 Reconfiguration Strategies . . . . . . . . . . . . . . . . . . . . . . 917.1.5 Blacklisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.1.6 Impact of Alternative Configuration Strategies . . . . . . . . . . . . 94

7.2 Distributed Simulation of Heterogeneous COs . . . . . . . . . . . . . . . 1007.2.1 DDS-Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.2.2 PLANET Application Scenarios . . . . . . . . . . . . . . . . . . . 1007.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

TABLE OF CONTENTS vii

7.3 Mobile Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.3.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.3.2 Single Strategy Optimisation . . . . . . . . . . . . . . . . . . . . . 1097.3.3 Composition of Strategies . . . . . . . . . . . . . . . . . . . . . . . 1097.3.4 Outdoor Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.4 Data Analysis and Processing . . . . . . . . . . . . . . . . . . . . . . . . 1127.4.1 WSN Failure Detection and Diagnosis System . . . . . . . . . . . . 1127.4.2 Secure Communication . . . . . . . . . . . . . . . . . . . . . . . . 1147.4.3 Interfacing with WSN Applications: Horse Tracking in Doñana . . . 1167.4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8 Conclusion and Ongoing Work 1258.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.2 Ongoing Work - Interconnecting Different Domains . . . . . . . . . . . . 126

8.2.1 The Linked Open Data Warehouse . . . . . . . . . . . . . . . . . . 1278.2.2 Data Discoverability . . . . . . . . . . . . . . . . . . . . . . . . . 128

Acronyms I

Bibliography III

L I S T O F F I G U R E S

1.1 Environmental monitoring scenarios. . . . . . . . . . . . . . . . . . . . . 11.2 Environmental monitoring with a deployment of heterogeneous COs. . . . 31.3 Contributions for efficient environmental monitoring. . . . . . . . . . . . 5

2.1 Sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Concept of a Wireless Sensor Network (WSN). . . . . . . . . . . . . . 112.3 Component Graph of the standard TinyOS application Blink. . . . . . . 122.4 Concept of a network of heterogeneous COs. . . . . . . . . . . . . . . 162.5 Platforms for autonomous environmental monitoring . . . . . . . . . . 172.6 PLANET communication middleware. . . . . . . . . . . . . . . . . . . 212.7 Concept of a Wireless Sensor Network for environmental monitoring. . 27

3.1 CTP application metrics for real-life configurations and simulations. . . 343.2 Moρϕευς framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3 Moρϕευς Lifecycle in a Deployment of COs. . . . . . . . . . . . . . . 373.4 CTP application metrics behaviour for different bootup orders. . . . . . 403.5 Routing trees for different bootup orders. . . . . . . . . . . . . . . . . . 403.6 Node-wise application metrics (simulation/real). . . . . . . . . . . . . . 413.7 Routing metrics for simulations based on real-world measurements. . . 413.8 Linear regression and 95% confidence interval (simulation/real). . . . . 42

4.1 The Conceptual framework of K A S S A N D R A. . . . . . . . . . . . . . 474.2 K A S S A N D R A modules. . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Visualisation and Command Centre (VCC). . . . . . . . . . . . . . . . 50

5.1 Modelled throughput (best effort). . . . . . . . . . . . . . . . . . . . . 615.2 Modelled throughput (with 1 acknowledgement). . . . . . . . . . . . . 615.3 Theoretical throughput of alternative transfer strategies. . . . . . . . . . 625.4 Representation of the MC2 strategy. . . . . . . . . . . . . . . . . . . . 635.5 Link comparison (best effort, 1 acknowledgement). . . . . . . . . . . . 655.6 Link comparison (2 acknowledgements, 5 acknowledgements). . . . . . 665.7 Throughput comparison (direct, relayed, adaptive). . . . . . . . . . . . 675.8 Performance Measurement I C E L U S implementation. . . . . . . . . . . 70

6.1 I R I S modular architecture. . . . . . . . . . . . . . . . . . . . . . . . . 756.2 Different types of composition functions in I R I S. . . . . . . . . . . . . 786.3 The graphical user interface of I R I S with packet- and chart view. . . . . 796.4 The graphical user interface of I R I S with map view. . . . . . . . . . . 80

x LIST OF FIGURES

6.5 Creating a fire monitoring function instance using attribute mapping. . . 816.6 Adding the attribute, Applying a filter. . . . . . . . . . . . . . . . . . . 82

7.1 Comparison of node-level application metrics. . . . . . . . . . . . . . . 867.2 Indoor testbed with 32 TelosB devices, placed in different rooms. . . . . 877.3 Node replacement in a network with a weak link. . . . . . . . . . . . . 907.4 Node deployment in a network with a node under high workload. . . . . 927.5 Node deployment in a network with high latency. . . . . . . . . . . . . 937.6 Node replacement in a network with a weak link. . . . . . . . . . . . . 957.7 Links affected by the presence of the elevator at the same floor. . . . . . 967.8 Application metrics behaviour for case study 1. . . . . . . . . . . . . . 967.9 Application metrics behaviour for case study 2. . . . . . . . . . . . . . 987.10 Application metrics behaviour for case study 3. . . . . . . . . . . . . . 997.11 An operator is remotely requesting for Airfield Management System

(AMS) resources (UAVs, UGVs). . . . . . . . . . . . . . . . . . . . . . 1017.12 Left: Visualisation and Control Centre (VCC) showing a deployment.

Right: Automatic deployment. . . . . . . . . . . . . . . . . . . . . . . 1027.13 Simulation speed for different sending intervals. . . . . . . . . . . . . . 1047.14 Simulation speed for different number of nodes. . . . . . . . . . . . . . 1047.15 Throughput Evaluation 1. . . . . . . . . . . . . . . . . . . . . . . . . . 1067.16 Throughput Evaluation 2. . . . . . . . . . . . . . . . . . . . . . . . . . 1067.17 Evaluation of the absolute throughput achieved for different sending

frequencies depending on the payload size. Values at: 1, 64, 100, 6400,and 10000 bytes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.18 Throughput Evaluation 3. . . . . . . . . . . . . . . . . . . . . . . . . . 1077.19 Received Signal Strength Indicator (RSSI) maps for two testbed scenarios.1087.20 Evaluation I C E L U S strategy switching. . . . . . . . . . . . . . . . . . 1117.21 Case 1: The Failure Detection and Diagnosis System (FDDS) network

integrated with I R I S . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127.22 Case 2: Secure communication experiments using I R I S . . . . . . . . 1157.23 Data collection process for the horse tracking scenario in Doñana . . . . 1187.24 Graph view showing location information of two horses . . . . . . . . . 1207.25 I R I S horse tracking scenario . . . . . . . . . . . . . . . . . . . . . . . 1217.26 Positions of horse with id 5 in Doñana in October 2013 . . . . . . . . . 122

8.1 Architecture of a Linked Open Data Warehouse. . . . . . . . . . . . . . 127

L I S T O F L I S T I N G S

4.1 Excerpt of a configuration example specific to a WSN simulator written inGoogle Protocol Buffer. Node specific configuration like application andtype are given through additional embedded information (not reported inthis example). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Example of publication of a simulator configuration. . . . . . . . . . . . 554.3 Example of a subscription to telemetry information. . . . . . . . . . . . . 564.4 Example of a module registration. . . . . . . . . . . . . . . . . . . . . . 566.1 A user-defined CC2420 RSSI conversion function template . . . . . . . 817.1 A user-defined function template for computing the PRR . . . . . . . . . 1137.2 A user-defined function template for computing the ratio of successfully

secured packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.3 A user-defined function template for detecting inaccurate GPS readings . 122

L I S T O F TA B L E S

2.1 WSN-Application Overview. . . . . . . . . . . . . . . . . . . . . . . . . 142.2 CO Application Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Pearson correlation factor regarding all experiments for system-level andnode-level application metrics (as listed in Table 7.2). . . . . . . . . . . . 43

4.1 Example of interactions during the configuration and runtime stage. . . . 54

7.1 Set of nodes used for atomic tests for different reconfiguration strategies . 887.2 Set of nodes used for candidate network configurations (C1 - C16) . . . . 897.3 Throughput of the isolated strategies C0, C1 and C2 with single-ack and

adaptive-ack schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.4 Comparison of throughput between individual transmission strategies

and their composition in the A B R U P T scenario. . . . . . . . . . . . . . 1107.5 Comparison of throughput for the different strategy compositions in the

G R A D U A L, A B R U P T and outdoor scenarios. . . . . . . . . . . . . . . 110

L I S T O F S Y M B O L S

λWavelength of an RF signal (in meters).

σStandard deviation of a set of measurement-results.

∅Average value of a set of measurement-results.

cl

Congestion level which is defined as the number of packets with a CRC errordivided by the number of packets without a CRC error.

m

Number of messages in a burst.

pxyPacket Reception Rate (PRR) from node x to node y, with pxy ∈ [0,1] and x,y ∈{(o)rigin,(r)elay,(s)ink}.

tdTime for sending a message/ack (in seconds).

toTime for a channel switch (in seconds).

v

Application data per message (in bytes).

d

Distance between sender and receiver (in meters).

C0,1Instantiation of a protcol that switches between communication strategies forsending data either directly to the sink or for using a single-channel for relaying.

C0,2Instantiation of a protcol that switches between communication strategies forsending data either directly to the sink or for using multiple-channels for relaying.

xvi List of Symbols

C0Instantiation of a protcol, in which the source delivers data directly to the sink.

C1Instantiation of a protocol, in which a node serves as an intermediary between thesource and the sink (single-channel relaying).

C2Instantiation of a protocol, in which multiple concurrent streams can be simulta-neously activated along different radio frequencies with multi-channel relaying.

MC0Class of communication strategies, in which the source delivers data directly tothe sink.

MC1Class of communication strategies, in which a node serves as an intermediarybetween the source and the sink (single-channel relaying).

MC2Class of communication strategies, in which multiple concurrent streams can besimultaneously activated along different radio frequencies with multi-channelrelaying.

T ∗MC0Modelled throughput for a direct communication strategy (reliable, 1 acknowl-edgement).

T ∗MC1Modelled throughput for a single-channel relaying communication strategy (reli-able, 1 acknowledgement).

T ∗MC2Modelled throughput for a multi-channel relaying communication strategy (reli-able, 1 acknowledgement).

T ∗∗MC0Modelled throughput for a direct communication strategy (reliable, adaptivenumber of acknowledgements).

T ∗∗MC1Modelled throughput for a single-channel relaying communication strategy (reli-able, adaptive number of acknowledgements).

T ∗∗MC2Modelled throughput for a multi-channel relaying communication strategy (reli-able, adaptive number of acknowledgements).

TMC0Modelled throughput for a direct communication strategy (best effort).

List of Symbols xvii

TMC1Modelled throughput for a single-channel relaying communication strategy (besteffort).

TMC2Modelled throughput for a multi-channel relaying communication strategy (besteffort).

Cha

pter

1

C H A P T E R 1

I N T R O D U C T I O N

1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . 11.2 Definition of Terms and Goal of this Thesis . . . . . . . . . . . . 21.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 Background and Motivation

“Data is the new oil,” this quote from 2006 ascribed to Clive Humby most clearlydescribes the increasing impact of information on our society and economy. Even today,our daily life is determined by various embedded sensing devices that ubiquitouslyuse information about our environment: Cars are equipped with parking assistants andprovide sensors to guarantee a safety distance to other drivers and road users [p79];smart houses help in saving energy by automatically controlling the lights and heaters[p108]; robots in our gardens regularly mow the lawn and use internal sensors todetect unfavourable weather conditions [p110]. Considering that devices with sensingand actuating capabilities can even be connected to each other wirelessly, even morecomplex systems for monitoring large scale environments become possible. Ultimately,distributed devices – which autonomously cooperate with each other – act like a single

(a) Smart City (b) Industry 4.0 (c) Rural Monitoring

Figure 1.1: Environmental monitoring scenarios (image sources: [m4, m8, m49]).

2 CHAPTER 1. INTRODUCTION

virtual device to provide a comprehensive view on the monitored target area and operatein it. In such a scenario, one of the major questions is how to design and operate a systemin the most effective way to gather all necessary information. By analogy with traditionalresources such as oil, where design, deployment and operation of oil rigs, pipelinesand refineries determine how effectively they can be exploited , the focus of this thesislies instead on the design and evaluation of technologies, algorithms and protocolsfor environmental monitoring. Having an efficient technical base for environmentalmonitoring is essential for many application scenarios that already cover many aspectsof our daily life, as shown in Figure 1.1.

Smart Cities: A smart city is the vision that explores the most effective ways of ex-ploiting information about city resources within urban environments. In such a city,information about private and public transportation, pedestrian movement and knowl-edge about the individual requirements of citizens helps reduce pollution and operationalcosts, and may improve residents’ health. Smart city applications such as automaticparking space allocation or traffic control reduce traffic density and fuel expenses, butalso help to optimise walking distances and travelling time. This sort of smart cityscenarios on the other hand requires having accurate and timely information about thecity’s resources such as buses, trains and parking spaces as well as information abouttraffic flow and volume. From a technological point of view, the Internet of Things (IoT)– in which different kind of sensors can directly communicate via the internet – is thetechnology that is envisioned to meet the requirements of such a scenario.

Industry 4.0: Using sensors and communication technologies in industrial scenariospromises to raise production to the next level, where products can be individuallymanufactured at the same cost as in mass production. In this vision, manufacturinggoods run through different stations, each with unique capabilities and processinginstructions specific to the final product. In such a scenario, individual processingstations (consisting of a single, or a set of stationary and mobile robots) must exchangeinformation about their state, processing capabilities and products. Additional sensorsmonitor the production line and relevant workers to guarantee on-schedule instructionsand safe operations. The main idea of such a scenario is the interaction between sensorsand actuators, which has been the focus of Cyber Physical System (CPS).

Smart Rural Environments: Nowadays even natural reserves can be covered withsensors and actuators to monitor wildlife and measure environmental variables. Sensorsattached to animals enable tracking their position and their context in real time. This in-formation provides inside knowledge about how the environment impacts the behaviourof single individuals or groups. Collecting information about the environment helpsunderstanding how environmental characteristics propagate over the time and space, forexample, to mitigate the impact of pollution in a river or lake. Environmental monitoringbelongs to the classical application scenarios of Wireless Sensor Networks (WSNs),where sensors build their own autonomous communication network, independent froman existing infrastructure.

1.2 Definition of Terms and Goal of this Thesis

The term Environmental Monitoring stands for the process of retrieving and analysinginformation about a specific target area, for example a city, a factory or a rural environ-ment. Originally, environmental monitoring meant collecting data for purely scientificpurposes, in order to receive insight about how different environmental attributes rely toeach other. This is essential to get an understanding about how the area is influenced

Chap

ter

11.3. CHALLENGES 3

Figure 1.2: Environmental Monitoring with a deployment of heterogeneous CooperatingObjects.

by external factors, e.g. by humankind. For such reasons measurements and sampleswere often taken manually in the target environment and analysed off site in a laboratory.Some analysis (like pH- or oxygen value) could also already be done on site, usingspecialised devices or simple chemical indicators. Nowadays, it is possible to automatethe process of environmental monitoring, using a network of wireless sensors, deployedon fixed positions. These systems have just minimal requirements on an existing infras-tructure in the target area. They do not necessarily require power supply or an existingcommunication infrastructure. Instead, they autonomously build a communicationnetwork to transmit messages to the operator. Since the target area (e.g. a facility, acity or a natural reserve) can easily extend to several thousand square metres, a purelystationary network of wireless sensors does not scale. However, in combination withmobile sensors that can be used on demand, they can most effectively cover large areasat reasonable costs. Systems of such networks are called heterogeneous CooperatingObjects (COs). The process of retrieving data from the network is called Data Collec-tion. A schematic presentation of a heterogeneous system of COs for environmentalmonitoring is shown in Figure 1.2.The goal of this thesis is to enable efficient data collection with heterogeneous COs forenvironmental monitoring. This includes providing algorithms to support the properinstallation of sensing systems, protocols for data collection during their operationand methods that enable system operators to aggregate and analyse incoming data.The following subsections entails a description of the challenges when dealing witha complex sensing system such as a network of COs (Section 1.3), as well as thecontributions of this thesis (Section 1.4).

1.3 Challenges

A system of COs offers a powerful solution of heterogeneous resources for environmen-tal monitoring. Sensor nodes, deployed in fixed location within the target area regularlytake environmental readings from key positions. These devices build a wireless com-munication infrastructure which offers measured data to the rest of the network andeventually to the user. Further nodes might be attached to animals to opportunisticallysurvey the environment. Other COs such as aerial or ground robots (Unmanned AerialVehicles (UAVs), Unmanned Ground Vehicles (UGVs)) can additionally act as mobiledata sinks which collect data from disconnected nodes and sub-networks.

4 CHAPTER 1. INTRODUCTION

However, such a scenario creates several challenges.

1. Environment aware deployment planning: Environmental characteristics hugelyaffect the final system performance. Topography, vegetation and the position ofobstacles can effectively reduce wireless devices’ communication capabilitiesand thus affect system performance such as lifetime, latency and throughput.Additionally, accurate system planning is hampered by unknown environmentalidiosyncrasies. As a result, efficient deployment planning for environmentalmonitoring requires methodical quantification of environmental effects on thefinal system performance.

2. System aware deployment planning: In addition to the specifics of the environ-ment, the system characteristics must be taken into account as well. Using acombination of COs, such as heterogeneous WSNs, UAVs and UGVs, creates asystem complexity that greatly affects the planning procedure. Each device mightbe unique in the kind of capabilities and limitations it brings into the network,such as processing power, storage capabilities and networking bandwidth. Fur-thermore, in cases where mobile elements are used for data collection, systemperformance depends on the exact contact time between sensors and mobile sinks.

3. Mobility aware data collection: In most networks, dedicated nodes collect datafrom the rest of the network in order to provide it to the user (e.g. by acting as agateway between the operator and the deployment). Mobile sinks increase theconnectivity of a network by collecting data at various locations in the target envi-ronment. However, using a mobile sink also leads to shortened communicationtimes and fluctuating link quality, which effectively reduces the final throughputfor data collection. As a result, adaptive communication protocols are necessaryto deal with the mobility of potentially fast-moving sinks.

4. Operator aware data processing: In order to enable non-technical experts (suchas a biologist) to utilise a network of heterogeneous COs for environmentalmonitoring, appropriate tools must be provided. In a monitoring system consistingof heterogeneous COs, each sensor might provide its data in a unique way thatneeds to be pre-processed before it can be analysed. For example, raw datafrom the sensors must be normalised first or combined with data from othersources, before the operator can begin processing it. This step, however, requiresknowledge about the underlying system characteristics and specialist tools, whichare difficult to use for a non-technical expert.

1.4 Contributions

This thesis focuses on how environmental information can be made available to theuser, employing a system of heterogeneous COs. It provides solutions for systemplanning, evaluates different classes of data collection and protocols and supplies toolsfor data processing and visualisation. In line with the challenges described in theprevious section, this thesis makes four contributions to enabling efficient data collectionwith heterogeneous COs: 1. It enables faithful simulations for environment-awaredeployment planning (Figure 1.3a), 2. it considers the system complexity by enablingthe simulation of networks of heterogeneous COs, such as WSNs, UAVs and UGVs(Figure 1.3b), 3. it allows maximisation of the throughput to a mobile sink by introducing

Chap

ter

11.4. CONTRIBUTIONS 5

(a) Environment-aware deployment planning for stationary WSNs (Moρϕευς )

(b) System-aware deployment planning for heterogeneous COs (KAS SAN -DRA)

(c) Data collection with mobile sinks in heterogeneous WSNs (I C E LU S)

(d) Customised data processing and analysis for heterogeneous WSNs (I R I S)

Figure 1.3: Contributions for efficient data collection with heterogeneous CooperatingObjects for environmental monitoring.

6 CHAPTER 1. INTRODUCTION

an adaptive communication protocol (Figure 1.3c) and 4. it assists non-technical expertsin using heterogeneous networks of COs by supplying tools for efficient visualisation,data analysis and deployment management (Figure 1.3d). In other words, this thesistackles the methodological problems of planning a system for monitoring a dynamicenvironment, using a heterogeneous system, gathering required data and enabling usersto interact with such a system. These contributions are briefly explained in the followingparagraphs.

Faithful Simulation and Deployment Planning

To consider the environmental impact on the system efficiency, this thesis proposes aframework for simulation aided planning of WSNs. The framework was published underthe name Moρϕευς [b1, a1]. Moρϕευς enables faithful simulations by calibratingits models from real measurements and continuously validating such models withinformation coming from the actual system. It allows identification and assessmentof deployment plans, based on simulation output analysis. By using simulation, itgains full visibility of the system state and of the actual environmental impact on themonitored application performance. In this way, Moρϕευς enables a thorough analysisof which devices provide a significant benefit or detriment to application performancemetrics, such as throughput, latency and lifetime. Reconfiguration strategies can beidentified and evaluated to estimate the system efficiency. In case of environmentalchanges, Moρϕευς enables the adaptation of an existing deployment to guarantee thatthe application requirements can be fulfilled. Unfavourable configurations introducedby unpredictable environmental changes can be treated separately, e.g. by applying rulesto avoid specific configurations (blacklisting).

Simulation of Heterogeneous Cooperating Objects

The second contribution extends Moρϕευς to tackle the complexity for deploymentplanning and system performance estimation, introduced by using UAVs and UGVsin combination with a stationary WSN. This extension was made available under thename K A S S A N D R A [a4]. K A S S A N D R A introduces a framework architecture fordistributed COs simulations with real hardware-in-the-loop. The framework specifiesthe integration of existing simulators and the communication mechanisms required forthe interactions between real and simulated COs. For integrating the simulators, K A S -S A N D R A employs the very same communication middleware used for the interactionsamong real devices. In that way, further simulators can be seamlessly incorporatedlike their real counterparts, as long as the corresponding simulation models guarantee areal-time execution. As a result, it becomes possible to concurrently execute multiplesimulated and real sub-systems.

Throughput Maximisation to a Mobile Sink

As soon as the WSN is deployed, mobile devices such as UAVs and UGVs can startcollecting data from the ground sensors. However, using fast-moving sinks comes alongwith a limited contact time and may cause fluctuating link quality. Therefore, specialisedcommunication protocols are needed for efficient data collection. The third contributionof this thesis tackles the problem of maximising the throughput to a potentially fast-moving sink. The outcome is an algorithm for efficient data collection which waspublished under the name I C E L U S [a3]. During the data collection process to a sink,

Cha

pter

11.5. OUTLINE 7

the utilised path between source and sink might be blocked by obstacles, such as trees,animals, or other objects. To avoid a decreasing throughput to the sink, alternative datapaths can be used, e.g. by relaying transmitted data from the source to the sink viaa mutual neighbouring node. In I C E L U S , three different classes of communicationstrategies – with and without relaying – are analysed for efficient data collection. Asa further step, this analysis is used to suggest when to alternate between these classes,based on the observed system conditions.

Efficient Visualisation, Data Analysis and Experiment Management

The last contribution of this thesis deals with the challenges of making a complex system,such as a WSN, available to non-technical experts. To this end, a tool was created whichallows flexible management of a deployment, data processing and visualisation. Thistool was made available as open source software [m11] and was published under thename I M AC [b2] and later I R I S [a5, a2]. The operator may use it to automate theapplication installation procedure, to perform experiments with different configurationand parameter settings, to create customized logs for different purposes. For datacollection and result analysis, I R I S emphasises its extensibility by allowing the userto specify required data message formats and to flexibly define functions for dataprocessing. An operator can also support an application with I R I S , by implementingthe program logic using I R I S functions. During the operation, the user may interact withthe deployed WSN in order to fine tune the parameter settings for higher performanceor for debugging purposes. Finally, I R I S also includes a graphic interface to visualisethe data collection status as well as the analysed results.

1.5 OutlineThe remainder of the thesis entails the following. Chapter 2 frames the state of the art aswell as the background. Chapter 3 discusses Moρϕευς , a framework for planning theconfiguration of sensor nodes [b1, a1]. Chapter 4 covers K A S S A N D R A, a distributedsimulator that expands Moρϕευς for the simulation of heterogeneous CooperatingObjects [a4]. Chapter 5 describes I C E L U S, an evaluation on different classes of com-munication strategies when communicating to a mobile sink; this chapter also includesa reference implementation for an adaptive strategy switching protocol [a3]. Chapter 6presents I R I S, a framework for WSN-data collection, controlling and data analysis [a2,a5, b2]. Chapter 7 expounds the evaluation of the contributions. Chapter 8 concludesthe work and provides an outline about ongoing work. The outlook demonstrates that- based on this work - it will be possible to incorporate collected data into a publiclyavailable knowledge graph – known as the semantic web – that enables users around theworld to integrate monitored data into their own applications [b4, b3].

Cha

pter

2

C H A P T E R 2

S TAT E O F T H E A R T

2.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . 92.1.1 Operating Systems and Software Support . . . . . . . . . . 112.1.2 Reference Applications . . . . . . . . . . . . . . . . . . . 132.1.3 Strengths and Limitations . . . . . . . . . . . . . . . . . 14

2.2 Cooperating Objects . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Operating Systems and Software Support . . . . . . . . . 182.2.2 Reference Applications . . . . . . . . . . . . . . . . . . . 192.2.3 Strengths and Limitations . . . . . . . . . . . . . . . . . . 21

2.3 Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1 Analytical Solutions . . . . . . . . . . . . . . . . . . . . 232.3.2 Simulation Driven Solutions . . . . . . . . . . . . . . . . 25

2.4 Data Collection with Mobile Sinks . . . . . . . . . . . . . . . . . . 272.4.1 Challenges in Mobile Scenarios . . . . . . . . . . . . . . . 272.4.2 Throughput Maximisation to a Mobile Sink . . . . . . . . 28

2.5 Deployment Management and Operation . . . . . . . . . . . . . . 292.5.1 System Monitoring . . . . . . . . . . . . . . . . . . . . . 302.5.2 Application Data Analysis . . . . . . . . . . . . . . . . . 30

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

This chapter entails the background on environmental monitoring with heterogeneousCOs, as well as related work. It is divided into five different sub-chapters, each presentinga summary of established industrial and research solutions.

2.1 Wireless Sensor NetworksRecent development in Micro-Electro-Mechanical Systems (MEMS) allows to deployautonomous sensors, to process gathered data already on-site and to share gatheredinformation among neighouring devices. This made a complete new set of data-drivenapplications possible in which entire networks act as a single virtual device and establisha basis for smart rural monitoring applications or related scenarios, such as smart cities.

10 CHAPTER 2. STATE OF THE ART

Transceiver

Sensor 1

Sensor 2

ADCMicro-controller

External Memory

Pow

er S

ource

Figure 2.1: Sensor node (image by Wikimedia [m40]).

In the 1990s, Kristofer S.J. Pister – one of the pioneers in the research and developmentof WSNs – envisioned the future sensing system of 2010 [m32] as follows:

“In 2010, MEMS sensors will be everywhere and sensing virtually every-thing. Scavenging power from sunlight, vibration, thermal gradients, andbackground RF, sensor motes will be immortal, completely self-contained,single- chip computers with sensing, communication, and power supplybuilt in.”

This vision already comes quite close to the description of a modern WSN, where anetwork of sensors nodes measures environmental attributes and prepares them forfurther processing. One of the key aspects is that each sensor comes with everything itneeds to collect, process and transmit data autonomously (Figure 2.1):

1. A power source, like a battery, which provides energy for the other componentsof the sensor node. Sometimes this is combined with components for energyharvesting to increase the lifetime of the sensor node.

2. A set of sensors, for example sensors for measuring light intensity, humidity,temperature or Global Positioning System (GPS)-readings. The exact numberand type of sensors depends on the platform which is used. These readings aredigitalised by an Analog to Digital Converter (ADC).

3. A memory unit for storing the application program, program data and sensorreadings.

4. A transceiver that allows communication through a low power wireless channel.

5. A microcontroller for controlling all other components and processing the col-lected data. Programs can either be installed prior to a deployment or on demandvia radio.

6. Further interfaces for debugging or interacting directly with the deployed program,e.g. a serial interface or Light-Emitting Diodes (LEDs) with different colours.

Cha

pter

2

2.1. WIRELESS SENSOR NETWORKS 11

Figure 2.2: Concept of a Wireless Sensor Network (WSN) for environmental monitoring.

There is currently a plethora of different WSN platforms, each specifically developedfor different kind of application scenarios. Still quite widespread today, the Telosb[t3] includes sensors for light, temperature and humidity, as well as a low power RFtransceiver. The Telosb’s continuing popularity also due to an Universal Serial Bus(USB) interface and support for established WSN operating systems, such as TinyOS orContiki [p60, p30]. However, other platforms might include more specialised sensors,e.g. for detecting seismic events [p36].

Where single sensor nodes provide only very limited resources for environmental moni-toring, in a network they are able to cover vast areas and offer sophisticated in-networkprocessing capabilities. Figure 2.2 shows the fundamental concept of a WSN. Sev-eral nodes are deployed in the target area and continuously deliver information to theoperator. The nodes are deployed either on fixed positions or as mobile nodes (e.g.mounted on animals for monitoring). A dedicated node called “sink” is attached to aData Collection Station (DCS), which acts as a gateway between the low power networkof the WSN and the outside world. The DCS is often connected to a stable power sourceand a stable network connection. Depending on the WSN application, some nodes in thedeployment may be responsible for first collecting data from a subnetwork or specificcluster and then making it available to the sink (or storing it, in case of the absence of asink). These nodes are called cluster heads.

2.1.1 Operating Systems and Software Support

Since WSNs consist of highly resource constrained devices, standard operating systemsfor PCs, such as Windows 10 or a vanilla Linux kernel, cannot be applied to sensor nodes.Even operating systems such as Android or Windows Mobile, which are optimizedfor a small footprint, require far too many resources. However, there are operatingsystems custom-made for WSNs, to support the development of WSNs applications.They provide hardware abstraction for simplifying the programming process of singlenodes or whole networks. They are optimised for low power consumption and efficienthardware usage for processing, communication and sensing while - at the same time -having a low memory footprint on the target device. During the last decades, a numberof operating systems for WSNs have emerged. The following focuses on TinyOS, oneof the most accepted operating system by the WSN community [p61].

12 CHAPTER 2. STATE OF THE ART

Figure 2.3: Component Graph of the standard TinyOS application Blink.

TinyOS, a Tiny Operating System

TinyOS [p60, m45] is an operating system that was originally developed at the Univer-sity of Berkeley in 1999 and distributed under Berkeley Software Distribution (BSD)licence. Version 1.0 was finished in 2002, version 2.0 was made available in 2006 andthe most current version 2.1.2 was published in August 2012. TinyOS relies on its ownprogramming language nesC, which is a dialect of the programming language C [t2].It is event driven, which means that a developer has to define how an application willreact to specific events (e.g. message received, timer fired, etc.) rather than just describethe program flow sequentially. TinyOS can achieve a very low memory footprint on thetarget device by assembling an application exclusively with the required logic. In orderto do so, the functionality provided by TinyOS is separated into different Tinyos compo-nents, which are small pieces of reusable code. These components are differentiated intothe respective specifications of their interfaces and their implementation (programminglogic). During the development process, the developer can wire pre-defined or customcomponents with each other to build an executable to run on the target device. Codethat is not wired in that way will not be part of that build and thus does not consume anyresources on the sensor node.Figure 2.3 visualises the component graph of the reference demo application Blink. Blinksimulates a binary counter on a sensor node by toggling the LEDs of the sensor nodeperiodically at different intervals. The component BlinkC defines the actual applicationlogic, furthermore it refers to the additional components: mainC, timerMilliC and LedsC.These components are responsible for the boot sequence, timer functionality and LEDcontrol respectively. Other components e.g. for controlling the flash memory or theradio are not part of the application Blink and thus will not consume any memory onthe target device.TinyOS supports many off-the-shelf standard platforms for WSNs and it entails a richset of libraries (e.g. for serial communication, RF communication or flash storage). Forexample, TinyOS supports the concept of Active Message (AM), where each messageincludes information about the subnetwork that is being addressed, a node ID and areference to the code which is being called on the receiving system. In doing so, a nodecan easily distinguish between different types of messages (e.g. a sensor reading oran alarm message) and provide different handlers depending on the type of message.This information is reflected by three different fields, the group ID, the node ID and theAM ID. A fixed message structure, defined as C-struct simplifies the reading process ofreceived messages.Furthermore, TinyOS provides a rich set of communication protocols at different layers,optimised for low power communication, e.g. a dissemination protocol and a datacollection protocol, mainly optimised for static networks.

Cha

pter

2

2.1. WIRELESS SENSOR NETWORKS 13

TinyOS Toolchain

In addition to programming libraries and messaging concepts, TinyOS provides moretools on the PC side in order to support the development of WSN applications. Forexample the command motelist shows a list of all nodes attached to the PC, includingtheir unique hardware address, their device address and description. This informationis crucial for the purpose of configuring single nodes with unique parameters for adeployment. The build system allows the developer to specify the node application, thenode ID that needs to be installed on a node, the target system and the specific PC deviceaddress to which the node is attached. Furthermore, the program SerialListener enablesdirect communication between the PC-side and a node by using serial communication.To support the development of new applications and protocols, TinyOS integratedTOSSIM as a simulation engine [p62].

2.1.2 Reference ApplicationsThe concept of using different sources of sensor data for detecting events was alreadyexplored in the middle of the last century in the SOund SUrveillance System (SOSUS)[p100]. This system consisted of a fixed array of sonobuoys. Measured signals weretransmitted to a shore base for detecting and locating submarines at a distance of 2.000miles (∼3200 km) in a 10-mile square (∼16 km). Compared to todays solutions, SOSUSdoes not include any processing on the node side and thus it cannot be seen as an actualWSN. However, as a predecessor of modern WSN applications, this case provides themotivation for distributed sensing and automated data processing.

At the beginning of this millennium, many new applications for environmental monitoringwere researched:

1. In 2002 a WSN was deployed for habitat monitoring at Great Duck Island in theGulf of Maine, U.S.A. [p67]. The network consisted of 32 nodes, collectingatmospheric data, such as temperature, humidity, barometric pressure and light ina seabird nesting environment. The goal of that application was to investigate thenesting behaviour of birds, as well as the environmental parameters of the nests.Collected data was made available on the internet to allow immediate processingof the results.

2. In the same year, a deployment called ZebraNet was planned to analyse thebehaviour of zebras in central Kenya, Sweetwaters Game Reserve near Nanyuki[p48]. The nodes were equipped with GPS and a small solar panel. A firstdeployment was tested in 2004 with 7 zebras [p126]. The second one withupdated hard- and software took place in 2005 with 4 zebras [m48]. The goal ofthese deployments was to track the position of the zebras over time and to monitortheir social behaviour.

3. Around the same time, in 2004, a WSN consisting of 3 sensor nodes was used atthe volcano Tungurahua in central Ecuador as a proof of concept to gather seismo-acoustic data in a hostile environment [p121]. One year later, the same authorsdeployed a larger network in northern Ecuador, consisting of 16 nodes, deployedin the area of volcan Reventador [p122]. This second deployment measured 230seismic events during a deployment time of 3 weeks.

4. At the end of that century, in 2008/2009, a large-scale experiment calledGreenOrbs with 330 nodes was started in a forest. The intention of the deploy-

14 CHAPTER 2. STATE OF THE ART

Scenario Mobility Environment Scale1) Great Duck Island [p67] No Rural Small (32)2) ZebraNet [p48, p126, m48] Yes Rural Small (7)3) Volcano [p121] No Rural Small (16)4) GreenOrb [p63] No Rural Large (330)5) SmartMetering [p34] No Urban Large (300,000)

Table 2.1: WSN-Application Overview.

ment was twofold (a) to gather environmental characteristics, such as temperature,humidity, illuminance, and carbon dioxide and (b) to gain an insight into thelimitation of a large-scale network [p63]

5. In 2012 a metropolitan-scale deployment consisting of 300,000 nodes (smartmeters) was conducted. As opposed to the other scenarios, the nodes wereattached to a stable external power source; a battery was merely equipped as abackup to handle power outages. 7600 dedicated sinks were deployed, whichcollected the data from the smart meters via low power radio. The result was avery large-scale deployment, however with many different sub-networks [p34].

These applications nicely show that WSNs are suitable candidates for various types ofenvironmental monitoring. A WSN can be used in rural or urban environments, withmobile nodes, and be deployed on a large-scale (Table 2.1).

2.1.3 Strengths and LimitationsUtilising a WSN for environmental monitoring comes with some advantages and chal-lenges for the operator.

Strengths of Wireless Sensor Networks

Wireless Sensor Networks are the ideal candidates for different kinds of applications,since they are:

• Scalable (node quantity) Having each node providing its own resources forpowering, sensing, processing and communication makes a WSN highly scalablein terms of numbers of nodes. This is very important, since complex applicationscan easily require hundreds to thousands of nodes, as indicated by scenario 4 and5, described in Section 2.1.2. Additionally, this allows to increase the granularityof the sensing data, whenever needed, by adding more nodes to the target area.

• Customisable Several standard platforms of sensor nodes provide interfaces foradditional sensors, actuators or communication capabilities. For example, in[p129] the authors analysed energy efficient methods to establish a communica-tion between sensor nodes and android based smartphones, in order to exploit thepotential of smart environments. In [p72] the authors describe a testbed architec-ture to develop applications for heterogeneous COs, including wireless sensornodes and mobile robots.

Cha

pter

2

2.1. WIRELESS SENSOR NETWORKS 15

• Flexible Using RF communication and battery driven devices makes a WSNindependent from an existing infrastructure, which leads to high flexibility. Sincethe nodes do not need to be wired, they can be used as static nodes, as well as beattached to mobile entities.

• Adaptive Soft- and hardware of sensors nodes are designed to self-organisewithout any human interaction. If a node in a WSN fails, the system will try tocompensate the failing node by drawing on the remaining ones. Furthermore, newnodes can be included into an existing deployment automatically.

Limitations of Wireless Sensor Networks

Despite of the advantages of WSNs, they do have a number of limitations which have tobe taken into account, since they are:

• Resource Constrained Optimising a system such as a WSN for power consump-tion comes at the cost of limited processing, communication and data storagecapabilities. For example, the Telosb standard platform just offers an 8 MHz TIMSP430 microcontroller with 10kB RAM for processing, a CC2420 with 250kbpsat -24 dBm up to 0 dBm transmission power for communication and in regards tostorage 16K bytes for the application and 1 MB for data. This highly restricts theprogram size on the nodes, as well communication parameters like throughputand communication range. On top of this, relying on low power communicationmakes single links susceptible to environmental changes and thus can lead to dataloss.

• Complex to Plan When planning a system for environmental monitoring, theoperator needs to balance the resources of a WSN against the requirements ofthe intended application. However, a highly optimised system such as a WSNdoes not provide any reserve, in terms of hardware/software resources, for freelyadjusting the system during runtime. As a result, the operator has to carefully planthe intended system prior to deployment and take into account system dynamicsas well as environmental dynamics. The operator also needs to consider the factthat a manual redeployment is expensive in terms of time and money.

• Limited Scalability (Spatial Dimension) To save energy, the wireless sensornodes are designed to provide short range communication capabilities. In bigtarget areas, with a limited infrastructure, this may require a huge number ofnodes to be deployed, just to enable full connectivity (all nodes can directly orindirectly communicate to each other) in the target area. In some scenarios, likenumber 5, described in Section 2.1.2, this is not a big problem, since the sensorcosts can be amortised by the energy saving expected over time. However, inother scenarios, where full coverage (the network is able to monitor the wholearea) is not required, a static WSN might not scale well.

• Complex User Interaction All planning efforts notwithstanding, the interactionwith WSNs is rather complex as well. The main reason for this is that programsinstalled on the nodes are highly optimised for low processing, communication andstorage capabilities. As a result, customised cross layer protocols are frequentlyused, which are tied to a specific application. Operating such a deployment thusrequires expert knowledge of the system itself.

16 CHAPTER 2. STATE OF THE ART

Figure 2.4: Concept of a network of heterogeneous COs for environmental monitoring.

Summary - Wireless Sensor Networks

In summary, applications can profit from several advantages, which make WSNs idealcandidates for monitoring solutions, especially when the target area is hostile and doesnot provide an underlying communication infrastructure. Utilising a system as flexibleas a WSN also promises to be adaptable for scenarios in which requirements may changeduring the system’s lifetime.When using a WSN as base for an application, the operator has to keep the complexityand constraints of the underlying system in mind. Each sensor node provides very limitedresources with respect to processing power, communication capabilities and energystorage. Communication links can be easily affected by the surrounding environment,which must be considered when planning a deployment. Even though each node withina WSN carries its own resources, covering large areas with static nodes can be veryinefficient, since this requires much of the WSN resources to build up a backbonenetwork for communication. Finally, the user interaction is quite complex and mighthinder non-technical experts in operating an existing deployment.The planning complexity and challenges regarding user interactions directly motivatethe contributions of this thesis Moρϕευς and I R I S (presented in the Chapters 3and 6 respectively). The following subsection describes how autonomous robots cancompensate for the limitations already mentioned, in order to create more efficientsystems for environmental monitoring.

2.2 Cooperating Objects

As summarised in the last subsection, WSNs have many features which make them aperfect solution for many environmental monitoring scenarios. However, they still havea number of limitations which may lead to issues, especially in large target areas. Toaddress these challenges, sensor nodes can be combined with additional autonomousrobots in order to cope with their limitations. Considering that COs such as autonomousrobots/vehicles allow for control of the position of single sensors, their combinationcan greatly increase the capabilities of the sensing system. Figure 2.4 extends Figure1.3d with a more detailed view on the network architecture. It shows how vehiclesextend a WSN to a network of COs. Instead of relying on sinks at fixed positions, nodes

Cha

pter

2

2.2. COOPERATING OBJECTS 17

(a) Wireless Sensor Nodes (b) Unmanned Aerial Vehicle (c) Unmanned Ground Vehicle

Figure 2.5: Platforms for autonomous environmental monitoring (image sources [m39,m13, m19]).

attached to UAVs and UGVs can act as mobile sinks and collect data from the networkon demand. Furthermore, these autonomous vehicles can be used as deployment tools,either for adding nodes to an existing deployment or for retrieving them.

The definition of Cooperating Objects (COs) can be found in “The Emerging Domain ofCooperating Objects” [p70]:

“Cooperating Objects (COs) consist of embedded computing devicesequipped with communication as well as sensing or actuating capabilitiesthat are able to cooperate and organise themselves autonomously intonetworks to achieve a common task. ”.

This definition allows everything to become a CO, as long as it is able to communicateand cooperate with other devices. It can be a light bulb, a lawn mower, a car or even aplane. It can be a single node in a sensor network, or an actuator in an industrial robotscenario. However, with respect to environmental monitoring scenarios, the followingthree types of COs are considered as part of a system of networked COs for the remainingdocument (Figure 2.5):

1. Wireless Sensor Networks (WSNs), as described in section 2.1, where each nodeprovides its own resources for processing, storage and communication (Figure2.5a).

2. Unmanned Aerial Vehicles (UAVs), which according to the International CivilAviation Organization (ICAO), are parts of an Unmanned Aircraft System (UAS),defined as “an aircraft and its associated elements which are operated with nopilot on board.” [p45]. The UAV is remotely controlled by a piece of softwarecalled autopilot, running on a Ground Control Station (GCS). The GCS providesa stable connection to the aircraft for controlling and data exchange. The aircraftcan either have fixed wings (a plane), or rotary wings (helicopter or multirotorhelicopter). For the purpose of this thesis, the definition UAV includes the pilotingsoftware, the aircraft and any attached sensor nodes (Figure 2.5b).

3. Unmanned Ground Vehicles (UGVs), autonomous ground robots. Similar to theUAV, an UGV provides onboard sensors for telemetry data and is controlled by aGCS. The advantage of a UGV compared to a UAV is that it can easily hold itsposition without any energy consumption; however, its actuation range and speedare highly limited when compared to a UAV. Likewise to the UAV, the definitionof the UGV includes the vehicle and all attached sensors for the remaining thesis(Figure 2.5c).

18 CHAPTER 2. STATE OF THE ART

Types of Cooperation

When combining an autonomous vehicle with a conventional WSN, the following fourmodes of cooperation are possible (as well as their combination):

• Mobile Coverage attaching a node to a vehicle allows adjustment of its positionaccording to the vehicle’s capabilities. By doing so, the position changes canbe modified depending on the sensor readings, since the GCS can direct thevehicle according to the sensor information, received through the data channel.Furthermore, the vehicles often provides additional onboard sensor readings thatcan provide information about the target area. For example a video stream ofan onboard sensor can provide visual feedback of the target area, which is animportant piece of information in order to determine the exact area of interest.Being able to control the location of the sensor on demand makes it a powerfultool for environmental monitoring. For instance, [p6] showed how a swarm ofmobile wireless sensors can optimise the network coverage.

• Power Provision A UAV or UGV provides powerful software and hardwareresources, compared to a sensor node. Having a node attached to the vehiclevia serial port allows it to share the vehicle’s hard- and software resources. Forexample, the node can be powered via the serial port, utilising the vehicles internalbattery or carbon engine.

• Mobile Connectivity A specific kind of resource sharing attaching a node to theserial interface of the vehicle’s onboard computer and thus sharing its communi-cation capabilities, which can be exploited in two different ways: 1. The vehiclecan act as a mobile sink to collect data from the deployment and make it availableto the operator [p71], 2. the mobile node can be used as data mule in order toconnect isolated parts of the WSN with each other [p98].

• Automatic Deployment Considering that the vehicle may also have an actuatorthat is able to grasp/release, UAVs and UGVs can also be used as deploymenttools for deploying/retrieving a node or for moving it to another position. Sincethe vehicle is able to utilise additional information available at the GCS, it is alsopossible to use information, that is not usually available within the network [p80].

2.2.1 Operating Systems and Software SupportSimilar to the case of WSNs there is a number of specialised operating systems anddevelopment tools available for other COs’ platforms. Robotic Operating System(ROS) is a popular and widely accepted framework for simplifying the developmentof robot applications, with support for cooperation among different robot platforms.The framework supports many off-the-shelf products and helps developers to buildapplications that include specific mobility patterns, require grasping and placing objects,and utilising and processing onboard sensors e.g. for face recognition or motion tracking.To facilitate the development procedure, it additionally provides interfaces to Matlab andSimulink that can be included in different simulation engines, such as Gazebo, whichprovides support for complex indoor and outdoor simulation [p54].

Task Distribution and Data Sharing through a Communication Middleware

Increasing the heterogeneity in a sensing system also means increasing its complexity.This puts a special emphasis on the middleware, which hides the complexity of the

Cha

pter

2

2.2. COOPERATING OBJECTS 19

underlying systems. All three systems – UAVs, UGVs and WSNs – have their owntechnology for communication, their own protocols and parameter settings. This isnecessary, considering that each kind of CO is highly specialised for a set of separatetasks. However, in a case of networked COs different systems need to interact with eachother, which makes a common communication platform necessary. Furthermore, thisplatform enables the operator to interact with all heterogeneous devices in the samemanner.

2.2.2 Reference ApplicationsThe first unmanned aerial vehicles were developed to analyse the concept of flying.According to writings of Aulus Gellius, one of first attempts was performed in 400 BCalready (the pigeon of Archytas) [p86]. Other prominent examples are the hot balloonexperiments of the Montgolfier brothers, which took place in 1782-84 [p86]. However,these aircraft did not actively control their flights. Either they followed a ballistictrajectory, or they were driven by environmental factors (like wind). The first successfulradio-controlled flight was in 1924 (by Montgomery Low) and one the first model-sizedRF controlled aerial vehicles with attached sensors was used in 1962 (Ryan Firefly)[p35]. A similar trend can also be seen for ground vehicles. An early approach was takenin 1932 in which a car, the “Phantom Auto,” was controlled via RF, without having adriver inside the car [m17]. Later, fully driverless cars were one of the goals of a researchprogramme that started in 1987, the Programme for a European traffic system withhighest efficiency and unprecedented safety (PROMETHEUS) project [p123, m34]. Oneof the results of that programme was a car that could drive autonomously on an emptyhighway by just using visual sensors [p9]. However, current technology allows for muchmore sophisticated approaches in smaller vehicles based on commercially availableproducts. This even makes it possible to build UGVs based on LEGO Mindstorms[p107]. This trend facilitates applications in which different kind of COs cooperate witheach other to achieve a common goal:

1. One important aspect in networks of COs is the physical coordination of the dif-ferent entities. In LANDING [p32], the authors demonstrated a fully autonomoussystem, that enabled a UAV to land on a moving platform, using only availableonboard sensors. The system did neither rely on any previously available infor-mation about the location of the platform, nor did it require any external systemto support the navigation (like a motion capturing system).

2. In SENEKA a network of UAVs and UGVs is used to create a mobile sensingsystem for supporting human rescue teams with data collected by mobile sensors[p57]. The goal was to render the search for victims and survivors more efficient.For this purpose, the robots were able to create a map of the operating area usingLIDAR (carried by the UGVs) or by mosaicking several 2D images, generatedby the UAVs. Additional sensors could be deployed, e.g. to detect harmful gasleakage.

3. A data mule approach was demonstrated in [p98]. Sensor nodes at static positionswait for the appearance of a mobile agent (MULE) for offloading their collecteddata. This agent then physically transported the data to a common sink.

4. In [p18] the authors showed how a rotary wing UAV can be used to deploy asensor node to repair a broken network. In a test deployment, 50 sensor nodes

20 CHAPTER 2. STATE OF THE ART

Scenario Deployment Mobile Coverage Mobile Sensing1) LANDING [p32] No No No2) SENEKA [p57] Yes Yes Yes3) MULE [p98] No Yes No4) REPAIR [p18] Yes No No5) PLANET [c3] Yes Yes Yes

Table 2.2: CO Application Overview.

were used alongside an autonomous flying robot that could deploy nodes for anintended communication topology.

5. The EU-Project Platform for the Deployment and Operation of HeterogeneousNetworked Cooperating Objects (PLANET). This project envisioned a systemfor planning, deploying and maintaining a network of COs. For this reason,two different types of use cases were identified: 1) Environmental monitoringin the spanish national reserve of Doñana Biological Reserve (DBR) and 2)an autonomous airfield deployment for UAVs. In DBR a network of over 40nodes was deployed to monitor the behaviour of wild horses and environmentalcharacteristics, such as the ph-value and temperature of the water. The UAVs andUGVs were used as deployment tools as well as for mobile coverage and mobilecommunication, in both different types of use cases mentioned above [c3].

These applications show that COs can cooperate with each other to achieve a shared goal.Especially SENEKA and PLANET show how environmental monitoring can benefitfrom a network of COs (Table 2.1).

Details on the PLANET Middleware

Due to the relevance of PLANET for this thesis, the following segment gives a moredetailed description of the PLANET middleware. In PLANET, a dedicated publish/-subscribe middleware was developed to enable the inter-communication between thedifferent sub-systems and Cooperating Objects. Typical examples of the type of dataexchanged includes gathered sensing data provided by the COs or delivered CO statusinformation. Additional commands are used to manage COs based on the applicationlogic or the PLANET CO control policies.

The implementation of the middleware follows a two layered approach (as shown inthe bottom part of Figure 2.6). The upper layer defines the CO registration routine, thePLANET messaging scheme and the default PLANET message channels, which maybe extended on demand. Default message channels were defined to separate betweendifferent kinds of messages, e.g. for registration, commands and status information.The platform includes a set of pre-defined message types, e.g. for sending telemetryinformation. Further customized messages can be defined in Google Protocol Bufferformat [m16]. The registration was implemented through a PLANET component toprovide unique IDs to each participating device. During the registration, a moduleprovides information about its type, status and capabilities. User may request a list ofactive modules to plan operations involving any combination of registered COs.

The lower communication layer supplies a set of communication Application Program-ming Interfaces (APIs) for underlying communication protocols. This layer specifically

Cha

pter

2

2.2. COOPERATING OBJECTS 21

Figure 2.6: PLANET communication middleware.

is responsible for discovery as well as message filtering and transportation. Currently, themiddleware is built on the Data Distributed Service (DDS) implemented by RTI [p83]but does not depend on it. DDS is an open standard, as defined by the Object Man-agement Group (OMG) [m9], and it provides efficient discovery, message filtering andtransportation. It is highly customisable though a variety of QoS parameters. The RTIimplementation is available for many platforms and languages, such as C, C++, C# orJava. Commercial alternatives to DDS are the Advanced Message Queuing Protocol(AMQP) [m1], Java Message Service (JMS) [m22] and Message Queue Telemetry Trans-port (MQTT) [m26]. Alternative related research projects with the goal of introducing adistributed middleware are, e.g. Amigo [p119], RUNES [p19] and iLand [p116].

2.2.3 Strengths and LimitationsUtilising a network of COs for environmental monitoring comes with some advantagesand challenges for the operator.

Strengths of Systems of Networked Cooperating Objects

In comparison to a classical WSN, a network of heterogeneous COs offers the followingadvantages:

• Scalablility (Spatial Dimension) Attaching a sensor node to a UAV or UGVallows for the use of its mobility-capabilities of the vehicle for controlling theposition of the sensor node. This is especially beneficial when the target deploy-ment is huge and cannot be fully covered by a network of static sensors. In thiscase, the vehicle can either steer the node for monitoring a specific area (mobilecoverage) or to let it communicate with further nodes of the deployment (mobileconnectivity). In either case, using the vehicle as a mobile node can greatlyincrease the scalability of a deployment, since communication and sensing can beadded on demand.

22 CHAPTER 2. STATE OF THE ART

• Strong Resources Compared to a sensor node, the control unit of an au-tonomous vehicle provides extensive resources, in terms of processing-power,communication-capabilities, storage, energy. For instance, using a UAV as mobilesink allows for sending data from within the network to the operator with lowlatency, utilising the data channel between the GCS and the onboard processor ofthe vehicle.

Limitations of Heterogeneous Systems of Cooperating Objects

Despite of the advantages, networks of COs still have the following limitations:

• Complex to Plan Attaching single sensor nodes to UAVs or UGVs renders itpossible to introduce controlled mobility to the deployment. This is especiallybeneficial in cases where the target scenario is huge and when a deployment of apurely static WSN would not scale properly. However, adding mobility to a WSNalso increases its complexity for planning, since the contact rendezvous timingsbetween different COs (each with different attributes regarding its operating rangeand speed) are an important factor and may impact the overall performance of anapplication. This increases the complexity for planning a network of COs whichis already challenging considering just the static WSN.

• Error Prone Communication To optimise the energy efficiency of a WSN,single sensors come with very limited hardware resources. With respect to com-munication capabilities, this results in radio links which are highly affected byenvironmental factors. These effects have to be compensated for by employingWSN communication protocols. When using a vehicle as a data mule or as amobile sink, this protocol additionally has to mitigate the effect of the systemdynamics. For example, a link may be disrupted from time to time due to shad-owing effects. Considering that a vehicle like a UAV can move very fast, theseprotocols also have to deal with short contact times for communication.

• Complex User Interaction The interaction with the sensors of network of COsis as complex as the interaction with a pure WSN (as described in Section 2.1).

Summary - Cooperating ObjectsIn summary, applications can profit from a deployment of wireless sensors in combi-nation with autonomous vehicles. Where sensor nodes can provide a self-organisingsensing network, UAVs and UGVs can complement some of the limitations of a WSN byproviding additional resources (processing power, communication capabilities, energy),by provide an opportunity to survey the target area on demand or by enabling mobileconnectivity.

However, combining a WSN with additional autonomous vehicles increases the com-plexity of the overall system, which requires adapted solutions for planning and datacollection. As a consequence, the planning process must factor in the volatile communi-cation network of the WSN as well as the dynamics introduced by the mobility of thevehicles. Furthermore, the impact of a moving sink’s mobility on the communicationquality has to be considered by the applied communication protocols. This directlymotivates two of the four contributions of this thesis: K A S S A N D R A, as an expansionto Moρϕευς and I C E L U S as a solution for throughput maximisation to a mobile sink.Both contributions are presented in Chapters 4 and 5 respectively.

Cha

pter

2

2.3. DEPLOYMENT PLANNING 23

2.3 Deployment Planning

While the heterogeneity of using systems of networked COs provides a new degree offreedom for data collection and environmental monitoring, the planning of such systemsbecomes more and more difficult. Furthermore, both the system and the environmentevolve over time, threatening the achieved reliability. Incorrect or suboptimal configura-tions and adaptations, e.g. positioning of static nodes or trajectories of mobile nodes, canendanger the ability of a system to meet application requirements, such as throughput,latency or lifetime.

2.3.1 Solutions for Systems of WSN

The challenge of designing and planning low power networked embedded systems hasbeen addressed by the research community from different aspects.

Position Planning

The design of a system prior to deployment, e.g. the choice of the actual position ofstationary sensors, is typically driven by application requirements and domain knowl-edge [p16, p15]. During deployment, several tools can be utilitsed to understand thespecific system properties in the target environment [a2, p46]. Such information canbe used to construct probabilistic models of communication and sensing quality forthe different possible node placements. Based on this, it is possible to identify theoptimal sensor locations that lead to high information quality at minimal communicationcost [p55].

This data-driven approach shows good results because it can describe the system inits operational environment through real observations. As such, it allows for definingmodels that are more realistic than what experience in similar environments and abstractmodels could provide. However, the generality of the employed system models areinadequate for capturing the complexity of the specific software services and protocolsemployed in practice. As such, approaches such as [p55] are unable to match applicationrequirements like throughput or latency resulting from a specific network software stackrunning in the system.

Despite through preparation by aquiring factual knowledge in the target scenario, design-ing a working system involves a lot of physical trial-and-error [p127] during deployment.In particular, antenna orientations and small changes in the actual positioning canhave huge effects on the final performance, justifying solutions in which the completeparameter space is explored exhaustively [p11].

Configuration Planning

In addition to the parameters describing the physical deployment, an appropriate config-uration for the services and protocols running in the system must be identified. A firstindication of the expected behaviour can be gathered through simulation. While a varietyof simulators can reproduce the behaviour of low-power networked systems, e.g. [p81,p62], they reproduce generic setups, whose characterisation might significantly deviatefrom the actual final performance. For this reason, some works [p111] have proposedthe integration of measurements from the target scenario to exhaustively explore thenetwork parameter space.

24 CHAPTER 2. STATE OF THE ART

Considering the large variety of network protocols and their unique functioning, theselection of appropriate system services also requires frameworks able to identify thebest network stack fitting the deployment scenario [p5].

Performance Estimation

The aforementioned approaches rely, in different flavours, on models of communicationquality and features. The widely used log-distance path loss model [p91] provides ananalytical description of how the wireless signal degrades over distance. Its use is oftenjustified by the low computational effort and the possibility to derive the environment-specific parameters from observations [p85, p2]. Nonetheless, studies have demonstratedthe deviations of the predicted performance from the one observed [p53]. More detailedapproaches, such as raytracing [p96], typically require an accurate characterisationof the environment to precisely calculate the paths followed by radio signals betweensenders and receivers. While accurate, these models have high computational costs andrequire precise maps of the scenario and the obstacles within.

Recognising the difficulty of estimating real system performance through simulation,the community has shifted to using publicly available testbeds [p39, p29] as referencevalidation tools. Despite their ability to describe real system behaviours, they representspecific configurations and setups. As a result, the information gathered is hardlyapplicable to other deployment scenarios and systems.

System Monitoring and Debugging

The possibility of inspecting and debugging the network performance is crucial toensure correct functioning and identifying opportunities for optimising the systembehaviour. This is particularly relevant in the case of networked embedded systemswith limited visibility in the system state and scarce resources. In the literature, it ispossible to identify several approaches to instrument the running code in order to traceparticular information, e.g. allowing the correct reply of the complete system behavioura posteriori [p58]. Different metrics can then be extracted to identify problems or simplycompare the performance of similar solutions in different setups [p88].

Monitoring and debugging systems online typically involves significant resources. How-ever, it has been demonstrated that adaptation of common tools is possible [p125].Alternatively, useful metrics can be extracted without significant impact on the sys-tem performance [p51] or through the deployment of secondary networks overhearinginformation and reconstructing views of the events in the network [p93].

System Adaptation

Once detailed information about the system is available, it becomes possible to adjust thebehaviour of the network. In particular, models of the different network protocols canthen be used to identify at run-time an optimal configuration and apply it to the systemto counteract changes in the environment or in the application behaviour [p128]. Otherapproaches utilise knowledge and measurements of the behaviour of different networkprotocols in different conditions to adapt the configuration of the running system basedon identified or learned rules [p73]. Orthogonal to these approaches is the possibility todesign or extend protocols to make them self-adapt to the current situation of the systemand the environment by tuning the parameters appropriately [p10]. Finally, if softwaresolutions are unable to make the system match the expected system performance, it

Cha

pter

2

2.3. DEPLOYMENT PLANNING 25

is possible to consider changes to the physical deployment by physically adding orrelocating devices [p114].

2.3.2 Solution for Systems of COs

Simulation has been widely performed to imitate the physical characteristics of COs orthe operations of COs systems, and to estimate the approximated performance of real-world CO systems. Numerous simulation tools have been developed to serve varioussimulation purposes for different levels of system components. The focus of this sectionis on the related work regarding the simulation tools for COs including wireless sensorsand UAVs.

Application Simulation

For simulating networks and protocols, ns2 [m28] and OMNeT++[p117] are widely ac-cepted simulation tools that can be adopted for testing WSN applications. Castalia [m5],which is based on OMNeT++, is used to test node behaviour, algorithms or networkingprotocols in realistic wireless channels with differ