Design of Mobile Gas Sensor Systems for Industrial Processes · Design of Mobile Gas Sensor Systems for Industrial Processes David Simões da Silva Thesis to obtain the Master of

1

Design of Mobile Gas Sensor Systems for Industrial Processes

David Simões da Silva

Thesis to obtain the Master of Science Degree in

Chemical Engineering

Supervisors: Prof. Carla Isabel Costa Pinheiro

Prof. Rui Manuel Gouveia Filipe

Examination Committee

Chairperson: Prof. Sebastião Manuel Tavares Silva Alves

Supervisor: Prof. Carla Isabel Costa Pinheiro

Member of the Committee: Prof. Maria Isabel Azevedo Rodrigues Gomes

October 2015

2

ABSTRACT

Keywords: Design, Mobile gas sensors, Simulation, Heuristics.

This master’s thesis is dedicated to the study of spatial distribution of mobile gas sensors around different

industrial equipment configurations. The difference between mobile and static sensors is briefly addressed and

two alternatives for concentration are proposed and compared in order to define sensor sensitivity. The

possibility of temporary uncontrolled zones, dead-zones, is discussed.

Analytical solutions for the problem are presented and an agent based software with different heuristics is

created in MATLAB for the prediction of the minimal amount of required sensors. Multiple heuristics are

compared in three separate equipment geometries: an 11 m pipeline, a small pressurization station and a 10 m

high industrial distillation column.

The work’s results yielded a reduction in sensors needed for the mobile sensor system due to the possibility

of temporary dead-zones’ existence. Analytical solutions to the mobile problem were centered on allowing all

dead-zones to reach the maximum dead-zone time of five seconds. These solutions presented a minimum amount

of sensors required equal to a sixth of the control volume.

The developed programs’ best possible result is twice the amount of the analytical solutions and is only

achieved for certain equipment geometries, with possible over dimensioning of the solution. The softwares’

results possess higher redundancy than the analytical solutions. Therefore, industrial implementation should not

be automatic and pros and cons need to be weight with help of the tools developed in this work.

3

RESUMO

Palavras chave: Design, Sensores de gás móveis, Simulação, Heurísticas.

Esta dissertação é dedicada ao estudo duma distribuição espacial de sensores de gás móveis na vizinhança

de diferentes configurações de equipamento industrial. Analisa-se brevemente a diferença entre sensores moveis

e estáticos assim como duas alternativas à concentração para definir a sensitividade de sensores. Discute-se

também a possibilidade de zonas temporariamente não controladas, chamadas zonas mortas.

Apresentam-se soluções analíticas para o problema e é criado em MATLAB um software baseado em

agentes com diferentes heurísticas para prever o numero mínimo de sensores necessários. Ambas as vias são

comparadas em três geometrias de equipamento diferentes: uma pipeline de 11 m, uma pequena estação de

pressurização e uma coluna de destilação industrial de 10 m de altura.

Os resultados do trabalho mostraram uma redução do número de sensores móveis necessários devido à

possibilidade de existirem zonas mortas. Soluções analíticas para o problema móvel foram centradas em permitir

que todas a zonas mortas atingissem o máximo de tempo de zona morta de cinco secundos. Estas soluções

apresentaram um mínimo de sensores necessários igual a um sexto do volume a controlar.

O melhor valor possível do software desenvolvido é duas vezes a quantidade dada pelos resultados das

soluções analíticas e só é atingido para certas geometrias de equipamento, com a possibilidade de sobre-

dimensionamento da solução. Os resultados do software possuem maior redundância do que os resultados das

soluções analíticas. Por isso, a implementação industrial não deve ser de aplicação directa, e os prós e contras

devem ser considerados com ajuda das ferramentas desenvolvidas neste trabalho.

4

Acknowledgments

I would like to thank Professor Andrzej Kraslawski for his support in the early stages of this thesis as well

as his theme suggestion. Without him the inception of this work would not have been possible. His insight

helped shape the direction this work would take early on.

I would also like to thank Professor Carla Isabel Costa Pinheiro and Professor Rui Manuel Gouveia Filipe,

both supervisors that supported me through the different hurdles of this work as well as providing insights when

needed. The elaboration of this thesis would have been less straight forward without all of their input.

I would also like to thank my girlfriend, my family and friends, which experienced the effects of this work

through me and still supported me all the way.

5

Contents

List of Figures ......................................................................................................................................... 7

List of Tables ........................................................................................................................................... 8

List of Symbol ......................................................................................................................................... 9

1. Introduction ................................................................................................................................... 11

1.1. Motivation ............................................................................................................................. 11

1.2. Goal and objectives ............................................................................................................... 11

1.3. Context .................................................................................................................................. 11

1.4. Literature review ................................................................................................................... 14

1.4.1. Drones ........................................................................................................................... 14

1.4.2. Sensors........................................................................................................................... 16

1.4.3. Agent based modeling ................................................................................................... 17

1.4.4. Heuristics ....................................................................................................................... 19

2. Case Study ..................................................................................................................................... 21

2.1. Introduction ........................................................................................................................... 21

2.2. Sensor sensitivity ................................................................................................................... 21

2.3. Mean pressure in pipelines .................................................................................................... 21

2.4. Leak flow calculation ............................................................................................................ 22

2.5. Lower explosive limit ............................................................................................................ 23

2.6. Model development ............................................................................................................... 24

2.6.1. Definitions ..................................................................................................................... 24

2.6.2. Refining the problem ..................................................................................................... 25

2.6.3. Analytical Solution - Loop Configurations ................................................................... 37

2.6.4. The need for a heuristic ................................................................................................. 40

2.6.5. Best possible program solution ..................................................................................... 42

2.6.6. Software Development .................................................................................................. 43

3. Simulation Results ......................................................................................................................... 54

3.1. Empty cubical volume ........................................................................................................... 54

3.1.1. Six seconds of simulation time ...................................................................................... 54

3.1.2. Sixty seconds of simulation time ................................................................................... 56

3.1.3. Six hundred seconds of simulation time ........................................................................ 59

3.2. Pipeline .................................................................................................................................. 60

3.2.1. Equipment volume definition ........................................................................................ 60

3.2.2. Random sensor allocation.............................................................................................. 61

6

3.2.3. Non-random sensor allocation ....................................................................................... 62

3.2.4. Heuristic 1 ..................................................................................................................... 63

3.2.5. Comparison of random with non-random allocation for heuristic 1 ............................. 64

3.2.6. Other Heuristics ............................................................................................................. 65

3.2.7. Introducing specific leaks ............................................................................................. 67

3.2.8. Overall performance test ............................................................................................... 68

3.3. Pressure Station ..................................................................................................................... 69



3.4. Distillation column ................................................................................................................ 72



3.5. Redundancy ........................................................................................................................... 74

3.5.1. Introduction and definitions .......................................................................................... 74

3.5.2. 11 m pipeline ................................................................................................................. 75

3.5.3. Pressure station .............................................................................................................. 76

3.5.4. Distillation column ........................................................................................................ 77

3.5.5. Comparison ................................................................................................................... 77

4. Conclusions ................................................................................................................................... 78

4.1. Analytical Loop configuration .............................................................................................. 78

4.2. Empty cubical volume ........................................................................................................... 78

4.3. Eleven meter pipeline ............................................................................................................ 79

4.4. Pressure station ...................................................................................................................... 80

4.5. Distillation Column ............................................................................................................... 80

4.6. Redundancy ........................................................................................................................... 80

4.7. Final conclusions ................................................................................................................... 82

4.8. Recommendations and further areas of study ....................................................................... 82

References ............................................................................................................................................. 84

List of Appendices ................................................................................................................................ 87

Appendix I ............................................................................................................................................. 88

Appendix II ........................................................................................................................................... 92

7

List of Figures

Figure 1 Visual representation of the volume to be controlled around the pipeline………………….…26

Figure 2 Cross section of the pipeline surrounded by 4 sensors and their detection volumes………......29

Figure 3 Cross-section of two detection volumes around a pipeline…………………………………….30

Figure 4 Top-down view of a diagonally moving drone with two adjacent occupied volumes………...34

Figure 5 Dimensions of a Parrot AR Drone..............................................................................................35

Figure 6 Side view of a drone moving in planar upwards or downwards diagonal ………………….…36

Figure 7 Examples of volume layouts allowing for an analytical loop configuration......………………38

Figure 8 Plot of occupation percentage vs. volume size for 6 s of simulation………………………......54

Figure 9 Plot of volume size vs. average amount of sensors needed for 6 s of simulation……………...55

Figure 10 Plot of volume size vs. min., maximum and average of sensors needed for 6 s of simulation...56

Figure 11 Plot of occupation percentage vs. volume size for 60 s of simulation…………………………57

Figure 12 Plot of volume size vs. average amount of sensors needed for 60 s of simulation…………….57

Figure 13 Plot of occupation percentage vs. volume size for 600 s of simulation……………………......59

Figure 14 Plot of volume size vs. average amount of sensors needed for 600 s of simulation ……...…...59

Figure 15 Plot of occupation percentage vs. volume size for 60 s and 600 s of simulation ………...…...60

Figure 16 Visual representation of the volume elements used for simulations with pipe in the centre…..61

Figure 17 Occupation percentages vs. simulation time for random allocation 11 m pipeline control……62

Figure 18 Average sensor numbers vs. simulation time for random allocation 11 m pipeline control…...62

Figure 19 Sensor number vs. simulation time for non-random allocation 11 m pipeline control (H1)…..64

Figure 20 Non-random vs. random sensor allocation for 11 m pipe simulation (60 to 600 s)……………64

Figure 21 Non-random vs. random sensor allocation for 11 m pipe simulation (60 to 6000 s)…………..65





Figure 26 Amount of dead-zone time limit exceeded vs. number of sensors for 24 h control (11 m pipe)67

Figure 27 % of volume elements without failure vs. number of sensors for 24 h control of 11 m pipe….68

Figure 28 Schematic of a pressure station. (WIKA 2015)………………………………………………..79

Figure 29 Cubical volume occupation representation of the pressure station with units in meters………70

Figure 30 Horizontal cross sections of the volume elements to be controlled (pressure station)………...70

Figure 31 Sensor number vs. simulation time for non-random allocation pressure station control (H1)...71



Figure 34 Sensor number vs. simulation time, non-random allocation distillation column control (H1)...73



Figure 37 Failures vs. defective sensor id for the 11 m pipeline test…………………………………......76

Figure 38 Failures vs. defective sensor id for the pressure station test…………………………………...76

Figure 39 Failures vs. defective sensor id for the Distillation column test……………………………….77

8

List of Tables

Table 1 Case and model results comparison…………………………………………………………....33

Table 2 Vol object properties…………………………………………………………………………...46

Table 3 Coordinates of volumes verified with x minus one meter……………………………………..49

Table 4 Coordinates of volumes verified with x fixed…………………………………………...…….49

Table 5 Coordinates of volumes verified with x plus one meter……………………………………….49

Table 6 Study of sensor number for 6 s simulations………………………………………………....…56

Table 7 Study of sensor number for 60 s simulations (part 1)………………………………………….58

Table 8 Study of sensor number for 60 s simulations (part 2)……………………………………….....58

Table 9 Min. sensors required for 11 m pipeline control for varied heuristics for 6000 s…………..….67

Table 10 Min. sensors required for designed pressure station control with 3 heuristics for 6000 s…......72

Table 11 Min. sensors required for designed distillation column control with 3 heuristics for 6000 s….74

Table 12 Analytical loop configuration failures vs. maximum heuristic 1 failures for all equipment…..77

9

List of Symbol

ROMAN CHARACTERS

a Unknown x coordinate to be solved

all Logic variable recording if the sensor has been allocated to a specific volume after its creation

b Unknown y coordinate to be solved

c Unknown z coordinate to be solved

d Diameter of the leak

d’ Distance between centres of two spheres

D Diameter of the pipe

hx Heading x coordinate of the agent’s final destination

hy Heading y coordinate of the agent’s final destination

hz Heading z coordinate of the agent’s final destination

id Identity of an agent, sensor, drone, i.e. identification number

l Length of the leak

L Length of the pipe

M Relative mass of molecule

N Number of sensors

occ Logic variable that identifies the volume as being passable space or occupied by equipment

p1 Highest pressure

p2 Lowest pressure

P Pressure

r Radius of a sphere

R Universal gas constant

sid Identity of the last sensor present in a volume recorded by the volume

sp Volume’s property noting the presence or absence of a sensor in the volume

sa Extension in meters in the x direction from the origin of the simulated space size in the software

sb Extension in meters in the y direction from the origin of the simulated space size in the software

sc Extension in meters in the z direction from the origin of the simulated space size in the software

t Time

tar Logic variable that records if a volume is targeted as a sensor’s heading

tsc Time since the last sensor was present in a volume for controlling of said volume for leaks

T Absolute temperature

V Volume

x x coordinate of the agent at the moment of the calculation

y y coordinate of the agent at the moment of the calculation

z z coordinate of the agent at the moment of the calculation

GREEK CHARACTERS

π Mathematical constant Pi

10

ABREVIATIONS

abs Absolute value function

cos Trigonometric function cosine

DZ Percentage of dead-zones existing at any given time

GPS Global Positioning System

GRASP Greedy Randomized Adaptive Search Procedure

LEL Low explosive limit

ODV Overlap of detection volumes

PSO Particle Swarm Optimisation

sens The sensor object

vol The volume object

Wi-Fi Local area wireless technology that allows an electronic device to exchange data

11

1. Introduction

Despite the use of the 'authorial we', common in academia, this thesis is the work of its author only.

The aim of this introductory chapter is to define the reasons for the subject of this thesis as well as the

objectives of our research. Furthermore, we briefly present today’s gas sensing technology available to the

industry as well as the current state of drone technologies. Finally, we’ll discuss agent base modelling in addition

to heuristics in programming.

1.1. Motivation

The motivation for the subject of this master’s thesis was the important industrial issue of flammable gases’

early detection and the fact that a reliable method for positioning static gas sensors doesn’t exist. At the moment,

positioning of sensors is based on experience or analysis of possible scenarios and these methods do not

guarantee an early detection of all gas leaks. To address this serious issue we require the development of a new,

effective detection method and this master’s thesis will attempt a different approach to this challenging task,

which could contribute to the improvement of safety in gas processing plants.

1.2. Goal and objectives

The aim of this master’s thesis is to create a model of mobile sensors dedicated to the identification of

flammable gases’ leaks with and without a programming method.

The specific objectives are:

1. To compare static and mobile sensor approaches to gas leak detection, with both cubical and spherical

detection range approaches.

2. To determine the possibility of leaving volumes uncontrolled for a specific amount of time, determined

as dead-zones, and define said time, which we will call dead-zone time.

3. To determine an analytical solution and propose multiple alternatives based on heuristics.

4. To create a computer software able to simulate the movement of a semi-intelligent swarm of drones

according to the proposed heuristics.

5. And finally to compare the analytical solution with the results obtained with the heuristic based

software for efficiency and redundancy.

1.3. Context

With any equipment processing gases under pressure, perfect permeability is impossible. Therefore,

constant surveillance of these systems is required, but unfortunately controlling the entire surface of an

installation including kilometer long pipelines is not an easy task.

12

For this purpose, the industry has developed many ways of effectively detecting gas leaks, each with its

advantages and disadvantages. While leaks can occur for multiple reasons, they mainly do because of “external

interference, corrosion, construction defects, material failure and ground movement” (Murvay & Silea, 2012).

One can address these preventively, although one can never completely exclude leaks later on. This is why two

control approaches are used: active control, as to detect the leaks as soon as they occur; or ad hoc control, for

example during scheduled maintenance runs. We estimate that the safest approach is the active one, while still

applying the usual preventive measures.

There are three different categories, as proposed by Murvay and Silea, to define gas sensing methods: “non-

technical, hardware based and software based” methods (Murvay & Silea, 2012).

The non-technical methods are solely based on human capabilities, like smell, vision and hearing. The

limitations of this approach are obvious, since the human senses are fallible and their detection is impending to

an observable event, leaving smaller, noiseless leaks undetected. Furthermore, if the gas to be detected has no

smell, taste nor colour, the task becomes impossible for the single operator. The cheap soap and bubble test is

therefore a tool for the operator to detect the eventual leak, but when the size of the equipment is a kilometre

long pipeline or when the equipment is so intricately laid that the operator cannot access it, that is the point

where non-technical methods become insufficient. In addition, if the gas is toxic to humans, it is impossible to

sacrifice a human operator’s health for its detection. In order to overcome the limitations regarding sensitivity,

dogs have also been used to detect leaks, but with animals, time limitations, regarding attention span, arise and

the toxicity problem is still an issue. (Murvay & Silea, 2012)

In order to overcome all the shortcomings of the non-technical methods, hardware and software based

methods have been developed. The hardware methods use hardware that control changes in physical properties

directly on the exterior of the equipment that we want to control, while the software based methods use the data

read on the equipment itself and infer the probability of a leak when specific parameters change. (Murvay &

Silea, 2012)

For hardware methods we can mention acoustic methods, in which the vibrations of the air produced by gas

escaping through a leak are measured; optical methods, in which optical patterns of “absorption, scattering or

emitted radiation caused by the gas are monitored” (Murvay & Silea, 2012); the use of optical fibre cables, in

which the optic properties of the cable are altered by gas leaks; soil monitoring, in which the soil is sampled for a

tracer compound added previously to the gas; vapour sampling, which is the technique we will focus on and

which consists in sampling the surroundings of the equipment with a gas sensor; and finally by using ultrasonic

flow meters, which consist of flow meters and thermometers distributed along the pipeline that verify through a

master computer that total mass flow is constant along the pipe (this technique has already software implemented

into it and hence overlaps with the software methods). (Murvay & Silea, 2012)

Some of these techniques have shortcomings and are applicable only under certain conditions. For example,

the soil monitoring technique only works for buried pipes or equipment and can’t be easily added to the system

13

ad hoc. It also requires the addition of a tracer compound to the gas which is not always possible due to end

composition specifications. (Murvay & Silea, 2012)

Optic fibre cables must be placed close to the pipe and might lose their desirable properties for monitoring

over time leading to false positives as well as failed readings. Fibre cables are also very sensitive and may not be

possible to install everywhere due to harsh conditions, for example high temperature fluctuations that change the

cables’ properties. (Murvay & Silea, 2012)

Most of the hardware methods require the implementation of multiple components along the equipment if

we desire continuous control, which increases the costs as the size of the equipment rises. Therefore, the

hardware methods are mostly used as a maintenance tool or for finding of the actual position of the leak and not

as frequently for continuous monitoring of the equipment. (Murvay & Silea, 2012)

This is why software methods are used as a complement to the hardware methods. Since the system needs

to be continuously monitored for basic parameters, such as pressure, flow and temperature, it is easy to have

software treat all of the gathered data. We’re not going to present in detail the different software methods used in

the industry, all which can be read upon in A survey on gas leak detection and localization techniques by

Murvay & Silea, but we will just point out the fact that usually the software methods detect the leak and leave it

to the operator to find where exactly the leak is located. The software might provide an approximation, but

further analysis is usually required through hardware methods. (Murvay & Silea, 2012)

As explained by Murvay and Silea, hardware techniques present a high cost proportional to the number of

“sensing” points needed and some methods, like the optic technique, use sometimes costly flying transportation

in order to monitor high distances of pipelines (Murvay & Silea, 2012). With this premise in mind, we proposed

the hypothesis of reducing the number of equipment by allowing it to move along and around the equipment in

order to fully monitor it and reduce the operation costs by reducing the hardware quantity required through

automation of movement. We needed to choose for this purpose a type of hardware as well as a medium for our

hardware to move autonomously.

It is necessary that such a medium is able to move in three axes and is independent of any other structure

that clutters the exterior of the equipment. Also, fixing the sensors requires a supporting medium that usually

requires high amounts of material, and hence raises the cost of the system. The only appropriate solution for this

task is a flying medium that can transport a sensing device, can stay charged and can communicate with its

surroundings. We considered for this purpose flying drones as medium.

Regarding the sensor we had to dismiss all hardware methods that require direct contact or that need to be

static. Power limitations were also at mind as well as the necessity of free movement for the drone. The acoustic

methods could not be used since the drones’ rotors are going to create their own airflow and noise that cover up

the eventual leak noise. Optical methods were not chosen because it requires either multiple sensors for 360

degree coverage or the drone to aim at the equipment. We wanted a method that would allow us to detect in any

14

direction and with the use of a single sensor. The use of optical fibre cables and soil monitoring were dismissed

for obvious reasons, the need for cabling and underground sampling respectively, while ultrasonic flow meters

were not possible due to this method only working with components internal to the equipment. The only option

remaining is therefore vapour sampling. It uses a single compact sensor with low power usage and is able to

detect gas originating from any direction. The only negative aspect is its need for direct contact with a minimum

amount of gas particles.

1.4. Literature review

Many aspects involved in the creation of this work need to be studied in detail. The literature review

section of this work focuses on each important aspect and attempts to explain the relevant knowledge existent on

the subject in order to correctly apprehend the rest of the work. The main subjects involved are drones, sensors,

agent based modelling and GRASP type heuristics.

1.4.1. Drones

First of all, we must admit that our premise of using drones for gas sensing in their current state is not

viable; this is mainly because of autonomy limitations and high cost of equipment. But, although in their current

state drones might not be very competitive with other transient detection methods, many companies are

developing more and more sophisticated drones that might one day have enough technical advancement to be

efficient and be affordable enough to become the number one solution to the pipeline controlling problem.

Constructers like Parrot are bringing prices down to a level at which the regular citizen can afford a drone,

while DJI has extensive expertise in key areas of drone development for them to grow into a sophisticated

platform for durable payload transportation. At the same time, Facebook announced in March 2014 it wants to

develop solar powered drones capable of month long flights (Zuckerberg, 2014; Bocquet et al., 2014). Also,

researchers from Eötvös Loránd University in Budapest showed that flock organization between ten drones is

possible and the experiment acknowledged the drones’ ability to cross simple obstacles as a group, while

following only a basic set of rules (Bocquet et al., 2014).

At the moment, Parrot produces the AR.Drone 2.0 that has the capability of transporting a high definition

camera and can be operated through Wi-Fi. Its latest model, the GPS edition, even possesses GPS localization.

Parrot’s AR.Drone 2.0 can fly at maximum speeds of 11 m/s and costs between 320 and 360 €, depending on

model and country of purchase (Parrot Shop a, 2014; Parrot Shop b, 2014), but unfortunately the GPS accuracy

is still superior than 2 meters which would make handling around equipment without shocks impossible.

Nevertheless, the drone is capable of flying at a maximum height of 199 meters making it suitable for monitoring

high distillation towers. (Parrot SA, 2013) It is also capable of flying in windy conditions, withstanding winds of

15 m/h while its Wi-Fi connection allows it to move only to a range of 50 meters from the controlling source

(Parrot Shop e, 2014), although there is a newer model, the Parrot Bebop Drone who possesses a 300 meter

range (Parrot SA, 2014).

15

Another limitation of the AR.Drone 2.0, besides the range, is its autonomy. For the most expensive model,

the Power Edition, the flying time can go as high as 36 minutes, using two high capacity batteries (Parrot Shop c,

2014). An advantage of Parrot’s drone is the ability of changing the batteries and flying out again immediately,

although there is no automatic system to change the battery currently available on the market and the charging

time of each battery is 2 hours and a half (Parrot Shop d, 2014). This is simply too much for a battery that only

allows 18 minutes of operability.

Regardless of its limitations, which are even more pronounced for the base Parrot model, which uses only

one 1000 mA/h battery with 12 min of autonomy, the equipment transported by the drone is multiple and could

be diverted for analyses purposes as well. It carries for example a pressure sensor, a magnetometer and an

ultrasound sensor for ground altitude measurement. (Parrot Shop e, 2014) This shows that drones are capable of

carrying and running small scale sensors of various purposes and still fly in a controlled fashion.

Meanwhile, the autonomy shortcomings can eventually be overcome in the future by using high density

capacitors and batteries, as well as reducing the power consumption of the engines and equipment, but the most

promising solution comes from Facebook’s vision of solar powered drones. It still doesn’t solve the power issue

at night, but if the system proves to be viable then continuous flight can already be ensured during daytime,

enabling continuous drone control for batch type operations that are performed only during daytime. Issues of

light exposure varying depending on seasons would still persist but could eventually be overcome. Finally,

experimental wireless power transmitting technologies which use electromagnetic radiation or inductive fields

exist, but these are not yet sufficiently developed to be used on the required distances and applications.

Regarding the range limitations, simple solutions are available, like substituting the Wi-Fi connection with

a 3G or 4G connection, making it possible to go as far as there are communication towers. In remote locations

one could also imagine the usage of a GPS satellite connection. But all these connection types have a major flaw:

they are currently unsecure due to the lack of any signal encryption and hence, allow for an easy diverting of the

drones by exterior assets (Bocquet et al., 2014).

Therefore, in the case of industrial applications, secure drone connections have to be developed before

these systems can be used. Another solution for the range and pirating issue is to give the drone complete

freedom by embedding the controlling program into its systems and hence removing the need for an uplink with

a master computer, but this requires a complete loss of control over the drone while it is operational and waiting

for the autonomous return of the drone, procedure that can be unsafe if the drone starts malfunctioning or suffers

a software bug. This seems unlikely to be adopted by the industry, but we included it for the sake of

exhaustiveness. Nevertheless, one can easily envision the creation of an in-house encrypted wireless network

controlling the sensors, eventually using each drone as a relay between the others, to increase range.

A different issue could be the drone’s size. If it has to maneuver between two pieces of equipment, the size

of the drone can be limiting. Parrot offers three sizes. The Bebop drone has dimensions of 33x38x3.6 cm with

the hull on (Parrot SA, 2014), but only 12 min of autonomy. The bigger AR.Drone 2.0 has dimensions of

16

51.7x51.7cm with the hull on (AR.Drone, 2012), which complicates maneuvering around and in-between

structures. Fortunately, Parrot revealed in January of 2014 a new smaller model named MiniDrone: Rolling

Spider with only 14 cm of diameter making it very agile but at the cost of a reduced flying time (8 min) (Parrot

Blog, 2014; Rolling Spider, 2014). Although very compact, one can only assume that its maximum payload will

be just as little, since this is currently related to the size and weight of the battery the drone carries. Nevertheless,

one can imagine a combination of smaller and bigger drones flying together to control all the surrounding space

of any equipment and each having their areas and frequencies of control.

An additional drone constructer, DJI, has been providing drones for professionals, mainly in the area of

aerial filming, pictures or any other form of observation from the sky. Similarly to Parrot, the flight autonomy is

the biggest limitation with its best performing model, the Phantom 2 VISION+, having 25min of flight time until

the battery is depleted (DJI Store, 2014), while its biggest model, the Spreading Wings S1000, has only 15 min

of charge (DJI a, 2014) but is capable of flying while under power through a cord, allowing it to fly for over 72

hours at the cost of reduced movement (DJI Youtube, 2014). A major strength of the Spreading Wings model is

its maximum payload. It can carry up to 7 kg of equipment and still fly for 15 min. (DJI a, 2014)

Although the corded Spreading wings model from DJI has impressive payloads and autonomy

characteristics it comes at the cost of its dimensions. It has a diagonal wheelbase of over a meter which impedes

it to fly in restrained spaces and makes collisions with other drones more likely. (DJI b, 2014)

One must admit that in its current status, the drone technology and expertise is not yet at the level required

for all around the clock equipment surveillance, but payload, mobility, GPS guidance and autonomy are

advantages that show a great potential for drones in the coming years, if their shortcomings can be overcome.

Regarding the variety of drones present on the market at the moment and the numerous changes that will

happen in the future it is impossible to find the optimal dimensions to use in our simulations, but as it is a

variable that can be changed, we decided for now to use the dimensions of 50x50x10 cm. It is a good middle

ground between bigger and smaller drones and seems representative of what could be a standard drone used in

the future.

1.4.2. Sensors

After knowing our transport medium, we decided to use the vapor sampling of hydrogen as our detection

method. In fact, the drones will only fly in the vicinity of the equipment, never touching it, and their rotors create

enough turbulence for an easy mixture of the atmosphere around the equipment.

Hydrogen was chosen because it is the lightest and most permissive gas existing and it will most probably

be the first gas to be expelled through very small leaks. Any other gas will not permeate as fast as hydrogen

under the same conditions. Hydrogen seemed therefore the most restrictive option. We needed thus to learn more

about the capabilities of hydrogen gas sensors.

17

The basic process of detection by hydrogen sensors consists usually in the cracking of the hydrogen

molecule by an active metal, embedded on an oxide covered electrode, which as the reaction occurs, suffers a

conductivity variation that can be detected (Ren & Pearton, 2011). Based on this principle many different

materials are used for the sensors, each being more or less accurate, having better or worse affinity,

responsiveness etc. Listing them all here would reach beyond the scope of this thesis and we will therefore

abstain from doing so. But, the most active metallic catalyzers for the hydrogen dissociation are platinum and

palladium and hence are the most widely used. Both function at room temperature and allow the detection of

reduced amounts of hydrogen, as some ppm can be detected with the expensive rare metals deposited on a cheap

surface, such as zinc oxide. (Ren & Pearton, 2011)

Advances on sensors are still being researched although platinum and palladium have uncontestably been

accepted as the most effective catalysers. Improvements are obtained by modifying the supporting material’s

structure as well as manufacturing processes. A recent thesis work has shown that for a nanostructured tungsten

oxide basis, the lowest detection limit of hydrogen can be as little as 10 ppm (Kukkola, 2013). This recent result

was chosen as a starting point for our simulations, since recent technologies have been shifting towards nano-

materials and based on the assumption that these types of sensors will be widely used when the drone’s

technology acquires sufficient maturity for drone swarm plant control.

1.4.3. Agent based modeling

When attempting to simulate the behaviour of a swarm of flying sensor carrying drones, we recognize that

each drone is equal to the others and hence we agree that agent based modeling is a well suited programming

method. The reasons being that agent based modeling follows a few simple concepts that can be applied to our

case.

Agent based modeling can only be applied to systems, by which is meant an ”idealization of a delimited

and persistent system containing multiple interdependent and organized components or agents that show

emergent behavior through feedback to the other elements and or their surrounding and vice versa, originating in

a non-trivial behavior” (Lukszo et al., 2013).

Meanwhile, an agent is considered any entity that is physically represented with its own boundaries and

that through exchange of information with its environment can take action through its own processing. They are

also acting purposefully and are able to cope with unpredictability. (Lukszo et al., 2013)

This ideal case only happens in real world programming of agents evolving in a physical system, as

opposed to our software, which will simulate the entire scope of the problem, as for example the system itself,

including disturbances and information exchange, that otherwise would be read by the agent’s sensors

themselves. Because of this difference our programming approach will not only possess one single agent, the

sensor, but also a second agent: individual cubic meter volumes. This is necessary, because in our simulated

environment we lack the spatial perception of the real world. For instance, in the real world, when trying to

avoid each other the sensors would only verify the data of nearby sensors and not all sensors in existence as we

18

would have to do if we didn’t implement the volume agents. The exact repercussions of this aspect will become

clearer in the simulation chapter.

Nevertheless, the agents involved in our simulation still possess a state, being it the sum of all the

parameters associated to each agent. These can be changed, or remain fixed, and are the main information

differentiating each agent from each other. An agent’s state can contain more than just information regarding

itself. It can include information about the environment’s state and even other agent’s state. (Lukszo et al., 2013)

Agents also have embedded rules in order to access their state, exterior states and additional information.

The rules usually record information and then apply changes to the agent’s own state according to it.

Interestingly, the rules may also lead the agent to not change its state at all, as the rules can imply inaction in

certain conditions or the rules can be dependent on a probabilistic factor. All these variations are the basic

decision making process of an agent. (Lukszo et al., 2013)

An agent’s decision process will inevitably lead to an action or inaction. Actions are always internal state

changes, but these can also influence the exterior environment which in turn is then an action that can be

perceived by an external observer. This is called the agent’s behavior. (Lukszo et al., 2013)

In a practical context, an agent’s state will typically include parameters that are related to a mechanical

function that enable actions such as movement. A common parameter being a voltage applied to an electric

engine that when increased, moves the agent in the real world, changing the sensor’s data perceived and then,

another rule can nullify the voltage, bringing the agent to a standstill. This is only one example of multiple

possible actions that have a repercussion on the real world.

In simulations, state changes imply actions in a simulated environment. For instance, movement reflects as

a coordinate parameter change in the agent’s state. Nevertheless, if ignoring parallel computing techniques,

which we won’t use in our thesis, there is always one difference between modeling the behavior in a simulated

environment and the actual real-world behavior. Programming forces us to be sequential in the decision making

process of the agents, one agent deciding upon its action before all the others and so on until every single agent

has done so in a sequential matter. In a real-world perspective, the agents could each have a processor with all

the same software including the exact same rules and allowing them all to take a decision at the same time,

overcoming in this way the sequentiality of programming. (Lukszo et al., 2013)

Nevertheless, in modeling we require a scheduler which ensures that each agent performs one action per

tick, so that over a long period of time the simulation seems to be happening in parallel. One should, through the

scheduler, ensure that the order in which the agents are performing their tasks varies each tick to ensure that the

first agent is not advantaged in any way and biases the modeling if the simulation’s goal is to analyze the

individual’s success rate at a defined parameter. (Lukszo et al., 2013)

19

We will not be taking this precaution in our simulation, since the agents are working towards a common

goal, and it is irrelevant if a sensor has a higher success rate than others. We will actually promote preferentiality

of certain agents. This is a perfect example of divergence from the agent base modeling’s definitions. In fact, the

application scope of agent based modeling is so broad that not every definition must be respected. In our case, a

simulation, we are distancing us from a real world application software and therefore need to make

approximations and modifications in order to achieve significant results.

1.4.4. Heuristics

The concept of a heuristic is a mathematical approach to a problem which has high chances of providing a

close to optimal solution without the guarantee to do so. Usually heuristics are used in combinatory

computational problems. The reason being that, although the process to obtain the absolute correct solution

might be known, the computational time required might be too high. The use of pertinent heuristics usually

decreases the simulation time with a minimal impact on the obtained solution’s accuracy. (Burke & Kendall

2014; Katta, 2003)

There are many different types of heuristics and each one is better suited for different types of problems.

One example of a heuristic type is a constructive heuristic, a simple type of heuristic that provides a single

solution after a process of building up. There is no reevaluation of the solution as opposed to other more

complex heuristics. A constructive heuristic can involve selecting more difficult sub problems to be solved

before other easier problems, in the hope that this will avoid conflict in solutions. (Burke & Kendall, 2014)

Metaheuristics take place one level above heuristics. A metaheuristic uses multiple underlying heuristics,

which, each, provide a single solution for a local problem, which in turn the metaheuristic uses to obtain a higher

level solution for a problem composed of the underlying sub problems. (Glover & Laguna, 1997)

Just like heuristics, many different types of metaheuristics exist; most are designed to tackle a specific type

of problem but many overlap to some degree in each other’s respective applicability fields. We will discuss the

ones we deem most pertinent to this work.

1.4.4.1 Particle Swarm Optimization - PSO

Particle Swarm Optimization is a heuristic method used commonly in bird flock simulations as well as any

other swarm like group in which each single element has the same goal; for example, searching for the most

amount of food. In practice this represents an element with a maximum search function that defines the

element’s next movement. Once the element traveled to its local maximum it might encounter a higher

maximum and will move on towards it. (Burke & Kendall, 2014)

PSO is only one example of a field called Swarm Intelligence in which the goals and decision making

processes of the swarm elements vary. Furthermore, many adjustments can be made to PSO, for instance one can

20

take into consideration the quality of the food, effectively differentiating the possible maxima to discover and

create additional rules to choose between them. (Burke & Kendall, 2014)

PSO is relevant for our work as in many aspects the drones behave like a flock of birds. They try to avoid

each other, hence not moving to where another bird/drone is or has just been and they both look for the highest

output; food in the birds’ case and the time since a volume was last controlled for the drones. The difference

being that the food distribution diminishes with time, as birds consume it, whereas the time continuously

increases with the absence of drone.

1.4.4.2 Greedy Randomized Adaptive Search Procedures - GRASP

A GRASP algorithm incorporates multiple sub heuristics working for the benefit of the higher order

GRASP heuristic, called metaheuristic. Meanwhile, a greedy algorithm is called greedy, as it constantly

reexamines variables that increase or decrease as time passes. At each tick, it chooses the best solution,

minimum or maximum depending on its objective, subjectively deciding between equivalent solutions, in order

to build up an overall solution to the problem. (Burke & Kendall, 2014)

Greedy type metaheuristics are commonly used in problems that require finding the maximum or minimum

of a big neighborhood of elements. It reduces simulation times by parallelizing the process, i.e. instead of one

program verifying all elements for the absolute maximum; many sub heuristics verify restricted amounts of

elements and then the metaheuristic selects the maximum of the maxima obtained through the sub heuristics.

A randomized greedy metaheuristic is any greedy metaheuristic that includes elements of randomness in its

process. It can range from simple randomness applied during the decision process of tied results, to a randomized

restart of the process in order to obtain many different solutions and choose the best between them. Another way

randomized greedy algorithms are used is to generate different results for different trials in order to remove

biases. (Burke & Kendall, 2014)

Our drone simulation is partly inspired in simple GRASP techniques, as for instance each drone choses the

best solution from a selected amount of destinations, yet even results are broken arbitrarily. But as the drones’

insertion in the system can be randomized, some of our tests fall into the GRASP category.

21

2. Case Study

In this chapter we will present basic physical data essential to the problem, as well as perform basic

calculations. It includes data regarding gas pressure, detection sensitivity and lower explosive limit range.

Additionally, the case study will be detailed.

We will also devise the first solutions to the problem and implement the software with the help of agent

based modeling techniques and metaheuristic inspired coding.

2.1. Introduction

Before we can start modeling the mobile sensor system we have to gather initial information in order to

determine the virtual range of detection we can assume for our sensors. Of course, parameters vary according to

the composition of the gas to be detected, the sensor’s sensibility and the mass flow of the leak. Each case must

therefore be studied separately. Consequently, our simulation work is unique but transposable to other cases

when modified. It is also a realistic first approach, due to its simplifications and extreme restrictions.

With the ensuing data we propose two sensor range interpretations, cubical and spherical, and determine

which is better by comparison of both static and mobile sensor hypotheses. Moreover, we develop a model

capable of replicating mobile sensor movement with varying underlying heuristics and simultaneously determine

the analytical minimum amount of sensors guaranteeing total coverage with maximum efficiency.

2.2. Sensor sensitivity

As previously mentioned, we choose H2 as the gas to be detected since it is present in natural gas and it is

the most volatile compound in existence. If a leak occurs with a mixture of hydrogen and other gases, it is

reasonable to assume that hydrogen is the first gas escaping through a small crack, rather than any other

compound present in the gas mixture. At best, hydrogen’s escape rate should be the highest in the case of minute

cracks. We will not consider big cracks, as we want to be very restrictive, in order to catch leaks as early as

possible.

One estimate of sensor sensibility found in literature is 10 ppm minimum response for H2 when using a

nanostructured tungsten oxide basis for the sensor’s electrode at room temperature (Kukkola, 2013). This is the

limit we arbitrarily decide to use in our simulations.

2.3. Mean pressure in pipelines

In a dissertation written by Sletfjerding (1999), two onshore pipelines exhibit a mean pressure of 64.43 bar

and 69.74 bar, which is approximately 63.6 atm and 68.8 atm respectively. Meanwhile, offshore pipelines can

reach a mean pressure of 155.93 bar, i.e. 153.89 atm (Sletfjerding, 1999).

22

According to another source, the average pressure in a gas line can vary between 200 and 1500 pounds per

square inch, which equals 13.6 atm to 102 atm. It is also mentioned that pipelines resist to higher pressures than

their normal operation pressure, which makes it possible to imagine leaks happening at much higher pressures if

a surge should occur (American Gas Association, 2014).

Nevertheless, if we limit ourselves to the pressure ranges of operation, then we can easily assume that the

higher ranges of pressure will be found in or near compressor stations or any other similar gas handling facility,

as pressure drop along pipes reduces pressure in relation to distance from the starting point. At the same time, the

correlation between the internal pressure of the pipe and the mass flow of the gas escaping the leak, guarantees

us that the lower the pressure, the lower the flow and hence the more time is needed for enough gas to escape, in

order to reach the lower explosive limit. Therefore we are only going to consider the higher pressure leaks since

the mass flow of the leaking gas will be higher and the risk of explosion will be faster to develop.

One could argue that, the higher pressure at which the gas exits through the leak disperses the gas more

efficiently, reducing the concentration, as the gas is divided across a greater volume, but we are considering the

worst case scenario in which the leaking gas would entirely gather in a close volume near the leak, which allows

us to ignore the distance effect of the pressured stream exiting the leak, since it only increases the time for a

dangerous concentration to develop. This way, we attain the lowest possible time for the low explosive limit to

be achieved.

Furthermore, we considered the highest pressure for our study, because the higher the pressure, the more

mechanical effort a pipeline endures and hence the higher the risk of failure. We decided consequently to use

100 atm of pressure in our test equipment as it is an easy to handle round number close to the maximum of

102 atm.

2.4. Leak flow calculation

An important data to be gathered is the molar or mass flow of hydrogen leaking through a crack in order to

calculate an approximate hydrogen concentration in the vicinity of the leak and also to have a measure of ejected

quantity versus time. This allows us to determine a limit in which it is safe to leave the equipment unattended

without risking an explosion in the event of a leak.

In order to calculate the flow, we need to understand that there are three fundamental types of gas flows:

laminar, turbulent and molecular. While the laminar flow is a flow in which all the molecules of gas progress in

an ordered fashion along parallel paths, the turbulent flow is unorganized and provides a constant mixing of the

molecules. But the molecular flow only consists of a single molecule advancing through a confined space

followed by another single molecule. Multiple molecules do not flow all at once; there is a sequential

progression instead.

23

Ignoring the fact that leaks and cracks in installations are all but ideal, we will assume that our leak point is

a cylindrical perforation of the equipment with a diameter d of 1 mm and a length l equal to the maximum

thickness of an average gas pipeline. According to the Indian Petroleum and Natural Gas Regulatory Board’s

notification the maximum thickness to be used for a pipeline should be 7.2 mm (PNGRB, 2009).

Furthermore, at high pressure differentials, the leaks are usually turbulent with a flowrate higher than

0.02 ml/s and the exact value is usually not calculated as the leaks are easily detectable (Technetics, 2015). We

will nonetheless be more restrictive and assume our leak will be of molecular flow type, as leaks through cracks

represent a very thin passage for molecules. We can then use the Knudsen formula for molecular flow leaks

provided by KVS:

𝑞 =√2𝜋

6√

𝑅𝑇

𝑀

𝑑3

𝑙(𝑝1 − 𝑝2) (1)

In order to obtain a realistic although approximate value of q, we assume the temperature to be ambient

25 °C, which equals to 298.15 K. The inner higher pressure p1 chosen is 100 atm as discussed in sub chapter

2.3., while the exterior lower pressure is assumed to be the atmospheric pressure of 1 atm. Finally, the relative

atomic mass M of the Hydrogen molecule is 2 g/mol. The value and units chosen for R, the universal gas

constant, is 8.314 m3

Pa K−1

mol−1

. Since the Pascal unit can also be expressed as kg m-1

s-2

the units of the mass

flow q will be m3

atm s-1

. Using 0.001 m for the leak’s diameter d and 0.0072 m for the leak’s length l we obtain

the following volumetric flow value of q=6.395 x 10-3

m3 atm s

-1 or 6395 ml atm s

-1 or 6.395 L atm s

-1.

As we discussed previously in chapter 1.4.2., about sensors, detection happens at 10 ppm, which means

10 mL of H2 in 1 cubic meter of air. As a leak injects 6395 ml atm s-1

into its adjacent cubic meter volume we are

instantly over the threshold for detection. Therefore, if there is no convection and the escaping hydrogen is

filling up a single cubic meter of air around the leak, there will be 639.5 mL of H2 present after one second,

value which is way above the 10 mL detection threshold.

If there is convection opposed to the direction of the sensor, molecular diffusion upstream might not be

enough for detection and a sensor in the direction of the convectional stream will be required. Hence sensors

need to be placed in a grid opposite to each other with detection boundaries touching each other or overlapping.

2.5. Lower explosive limit

To understand at which level a leak becomes dangerous, we need to know what the lower explosive limit

(LEL) is. For hydrogen the LEL is 4 %, as a percentage of hydrogen volume in air (Matheson Gas, 2014; Ren &

Pearton, 2011). This means that in one cubic meter of air, the lowest acceptable amount of Hydrogen gas is 0.04

m3 or 40000 ml. Considering the sensors used, there is no risk of detection occurring past this threshold, as the

detector’s sensitivity is of 10 ppm or 10 ml per cubic meter and hence lower.

24

2.6. Model development

As the sensitivity of vapor sensors is commonly defined in concentrations and not in detection range we

will develop a model that is close to reality and allows us to define an approximate frontier beyond which a

sensor will not detect a leak anymore. We will introduce definitions to ease the further understanding of the

theme. Furthermore, an analytical solution to the problem at hand is proposed as well as multiple different

heuristics.

2.6.1. Definitions

Detection volume is the volumetric representation of a sensor’s geometrical reach. Because a sensor detects

a gas only if a molecule of said gas enters in contact with it, a definition of sensitivity based on concentration is

not perfect. For instance, a small and a huge volume with same concentrations will only be equivalent if there is

perfect mixture. In the event of a leak, this is all but true. Therefore, to avoid representing the probability of

molecules touching the sensor, we assume the minimal detection concentration in a given volume ensures

instantaneous meeting of sensor with gas as long as the volume is sufficiently small. This volume is considered

in this case as the detection volume and we define it as a one cubic meter surrounding the sensor.

Leak volume is the assumed volume in which a leak will pour its content before moving to another. Since

reality reflects a much more complex process in which the leak’s content disperses through convection and

diffusion and is not dependent on geometry (meaning that the total leaked flow is spread over a vast volume), we

assume a closed volume in the leak’s vicinity, that represents a higher probability to contain the leak’s content

for a short period of time, in order to restrict our case to the worst case scenario. This virtual leak volume with

one cubic meter dimensions will most likely not retain all of the leak’s material. In reality we have a distribution

of concentrations along the three axes, but assuming the containment of all the gas close to the leak’s origin

allows us to match detection volume with leak volume.

Overlapping is the concept ensuing from both definitions, when there is overlap of both leak and detection

volumes. Since the leak volume has a minimal concentration which is above the minimal detection concentration

of the sensors, we can assume that, when there is 100 % overlap, there is detection. But overlap might be inferior

to 100 %, so a minimal overlap will be necessary for detection according to the time of leakage. This minimum

overlap will be determined further ahead.

ODV is the overlap of two or more adjacent detection volumes. We will want to minimize this overlap in

order to diminish the amount of sensors needed while still covering all the space. Because, the bigger the

overlap, the less efficient the control, if defined as control volumes used per total volume to be controlled.

A dead-zone is considered any volume that is not occupying the same space as a detection volume. Dead-

zones have a limited life-time, defined as dead-zone time. This one is proportional to the leak rate and depends

on the LEL of the studied gas. Ultimately a dead-zone is any volume that we deem fit to not be controlled for the

25

duration of the dead-zone time, which is the temporal interval in which a volume is allowed to remain

uncontrolled.

A volume element is a section of space delimited by a cube of one cubic meter in volume. Any space can

be divided up in a series of adjacent volume elements.

2.6.2. Refining the problem

In this sub chapter we will discuss the possibility of dead-zones being permitted in the system, as well as

compare number of sensors, percentage of ODV and percentage of dead-zones in two different models, cubical

and spherical, under two different scenarios, static and mobile case.

2.6.2.1. Are dead-zones possible?

First, we have to determine if a dead-zone is possible, because it could be that the leak flow is so important

that the Hydrogen’s LEL is reached instantaneously when a leak occurs. Fortunately this is not the case.

Since 4 % of H2 (V/V) is equal to 40 L/m3, it is only past this quantity that we have a risk of explosion. But,

as we have a leak flow of 6.395 L atm s-1

at 1 atm exterior pressure, we have 6.395 L/s, meaning that

40/6.395 = 6.25 s until the explosion limit is reached.

Assuming that there is only one leak at all times, a leak can exist for 6.25 seconds before an explosion risk

will appear. So we can only have a dead-zone existing for 6 seconds, as long as we assume that dead-zones are

separated systems and that no Hydrogen will transit to adjacent zones and that all the H2 will accumulate in a

leak volume near the leak. If not, then our dead-zone existence time limit will increase, but as we need to be safe

in any situation, we will take the most restrictive time of 6 seconds. Hence, the maximum allowed dead-zone

time will be therefore of five seconds, i.e. every volume will have to be controlled periodically with a maximum

of 5 seconds between each control, as the 6th

second is the second in which the system is controlled.

2.6.2.2. Defining the detection volumes

As explained previously in the definitions, we are setting the detection volume arbitrarily to one cubic

meter because the detection limits of vapor sampling sensors are expressed in concentrations and in reality a

volume might lack perfect mixture to achieve a detection at the right concentration. Once more, we assume the

most restrictive setting for our case and consider a situation of very badly mixed volumes. It implies we are

assuming that any H2 concentration beyond the detection volume will not be detected by our sensors. This is

another restrictive measure to ensure that every leak is absolutely detected, although it is possible that in the real

world practice a sensor detects gas from a leak outside of its detection volume.

26

Now that we have decided on representing the detection volume as a cubic meter, we need to define the

cubic meter’s shape. The most logical and compact representation would be a sphere, while a cube with 1 meter

sides is appealing through its simplicity in calculating volume overlapping.

Nevertheless, the radius for a cubic meter sphere is then a constant that can be known by using equation

(2):

𝑟 = √3

4𝜋𝑉

3 (2)

The result when using 1 m3 for the volume is r=0.62 m. This means that the sensor is at the center of the

sphere and it will be able to detect any leak included in the sphere.

Using the Pythagorean Theorem, the corresponding dimensions for the cubical model are a cube with edges

of 1 m and the sensor nested on its very center at 0.5 m from each side’s centers, with a distance of √1

3

2 m from

the corners of the cube.

This leaves us with two distinct detection models which we will compare, cubical and spherical.

2.6.2.3. Static Case

To support our theory of moving sensors being more advantageous than static ones we devise a simple case

where we are able to test both cubical and spherical models and compare the amount of sensors used as well as

the amount of overlapping. We want both values to be minimal, since the first reduces our costs and the second

ensures that we are not wasting any extra sensor to control the same volume as another.

The geometry to be controlled

For our test case, we assume a 10 m long pipe with a diameter of 1 m as test equipment and we consider a

standard leak volume adjacent to the pipe which fills up when a leak occurs. A visual representation of the

pipeline with its surrounding total control volume can be seen in figure 1:

Figure 1: Visual representation of the volume to be controlled around the pipeline.

27

To be restrictive and ensure optimal detection, we can assume the leak volume to be spherical with 1 cubic

meter and with its center at the leak point. This will be in reality less than 1 cubic meter, because part of the

volume consists of the pipe and its interior, but we assume it to be the best representation, since it is from the

leak point that the gas will diffuse in order to fill the volume. So we could argue that part of the volume might

have higher than safe H2 concentrations, but as any concentration will be detected by the sensor when its

detection volume and the leak volume overlap, there is no problem.

Calculating the minimal overlap for every second of dead-zone

At this point, the required overlap between detection volume and leak volume is unknown; because if we

only have a fraction of the volumes overlapping, then the concentration in the leak volume will be higher than

the concentration perceived by the detection volume and hence the sensor might not detect any gas. We must

ensure that we have enough overlap for detection. Therefore, since detection occurs for 10 ml in the detection

volume, the overlap with the leak volume has to contain 10 ml (minimum V needed).

As the leak flow is 6.567 L/s or 6567 ml/s after one second we have 6567 ml in the leak volume (V in the

leak volume). Using the equation (3) we can calculate the overlap for each second after the leak started.

𝑂𝑣𝑒𝑟𝑙𝑎𝑝 (%) =𝑚𝑖𝑛𝑖𝑚𝑢𝑚 𝑉 𝑛𝑒𝑒𝑑𝑒𝑑

𝑉 𝑖𝑛 𝑡ℎ𝑒 𝑙𝑒𝑎𝑘 𝑣𝑜𝑙𝑢𝑚𝑒× 100 (3)

After one second only 0.15 % overlap is enough for detection. After 2 seconds we have double the leak

flow, so half the overlap is needed: only 0.076 %. After 3 seconds only 0.051 %. After 4 seconds only 0.038 %.

And finally, after 5 seconds only 0.031 % overlap is needed.

Considering all our previous assumptions, then very little overlapping is necessary. But does it represent

properly the reality? Or at least close enough?

Obviously, not any fraction of the detection volume overlapping with any fraction of the leak volume will

ensure detection, but since the required overlapping percentage is so minimal and we are in our representation

forcefully keeping the gas bound to the leak volume, we can assume that in reality the gas will have spread out

further than the leak volume and that a theoretical overlap will be inferior than the reality. In other words, in

reality we will have more gas in our sensor’s vicinity, even if we only assume that the overlap is minimal. This

will allow us to ignore the concept of leak volume and just assume that as long as the detection volume is in

close vicinity of the equipment to be controlled, then any possible leak will be detected.

For the cubical case, it is easy to imagine a configuration in which there is total volume control around the

equipment, with 0 % of the volume being controlled by two or more sensors (no ODV). This is needed, because

as we are representing a static case, where sensors cannot move, we have to ensure no dead-zones exist, as no

volume can remain uncontrolled in a static sensor situation.

28

On the other hand, in the spherical case there is no solution that would recreate a total volume control

setting while having no ODV. Hence we have to find a solution that both does not allow dead-zones’ existence

and minimizes ODV.

We can address the problem with two different options. We can assume that the pipe or equipment can be

ignored when filling the space with detectors, but we’re not going to do so. Or we can also take the equipment

into consideration and assume there is no sense in controlling beyond the surface of the pipeline. The best case

lies in-between: while it is true that we don’t need to control the interior of the pipe, trying to keep the entirety of

the detection volumes from overlapping with the equipment would not bring the optimal case. We have to

consider the impossibility of placing sensors inside the equipment, but small overlapping of the detection

volumes and the equipment should not be a restriction.

At the same time, if there is continuity in the detection volumes, we assume that any volume beyond the

sensors has no point in being controlled, since the source of leaks is the equipment. In the static case we are

obliged to have a continuous detection volume, or there might be a situation where the leak could escape our grid

of sensors. Also, keeping our sensors close to the equipment is a priority as to limit free volumes between

detection volumes and the equipment; i.e. potential uncontrolled volumes that could “hide” a leak with explosive

concentrations.

Cubical model

To ensure contact between the pipe and the detection volume we should place sensors at a distance of

minimum 0.5 m. If the surfaces of the detection volumes touch each other on the axis of the pipe then we can

remove overlapping in that axis. A good approach would be to completely turn all the immediate volume in the

vicinity of the equipment into detection volumes.

Therefore, the solution required would be a minimal overlap of individual detection volumes with the

guarantee of 100 % overlap with a leak volume if a leak occurs, i.e. an outer shell made of detection volumes.

The factors to be minimized in this situation are the individual detection volumes overlapping as well as the

number of detectors. Overlapping inside the equipment is to be ignored.

In this situation the best configuration is a sequence of 4 sensors repetition, spaced from each other by 1

meter on the axis of the pipeline, while its cross-section is separated by 90° from each other like showed in

figure 2.

29

Figure 2: Cross section of the pipeline surrounded by 4 sensors and their detection volumes.

For the entirety of the pipeline 40 sensors are needed and the overlap of the different detection volumes is

calculated with equation (4), valid only when the pipe’s diameter is smaller than the side of the detection cube.

𝑂𝐷𝑉 =𝑥2𝐿−

𝜋𝐷2

4𝐿

𝑁×𝑥3 × 100 (4)

Where x is the side of the detection volume (1 m), L is the length of the pipeline (10 m) and N is the

number of sensors (40). The obtained ODV is equal to 5.365 %, as overlapping inside the equipment is not taken

into consideration, while the percentage of dead-zones is 0 %.

The sensors could be placed further away from the equipment in a diagonal pattern, which would originate

an ODV of 0 %. Yet, the number of sensors used would still be 40, but the increased distance between sensors

and equipment could allow for leaks to slip by unnoticed. To place sensors closer to the equipment increases the

sensors’ proximity to the potential leaks and in turn reducing the path that molecules have to travel to activate

the sensors. This is why we adopted the configuration shown in figure 2.

Spherical model

Since the radius of a spherical detection volume is lower than the diameter of the pipeline, we can imagine

placing the sensors in a similar fashion as the cubical case, having therefore some overlapping along the pipeline

axis as well as the same type of overlapping we had in the cubical case. In this scenario we also have multiple

overlapping inside the pipe which renders the exact exterior overlapping calculation impossible. We will

therefore approximate the value at best.

We require the same 40 sensors and the ODV is calculated with the intersection coordinates for the specific

case of two spheres intersecting a cylindrical pipe. For it, we use the sphere function (5) and the cylinder

function (6) (special case of axis of cylinder being the x axis). All following units are in meters.

(𝑥 − 𝑥0)2 + (𝑦 − 𝑦0)2 + (𝑧 − 𝑧0)2 = 𝑟2 (5)

𝑦2 + 𝑧2 = 𝑟2 (6)

30

In our specific case, the sphere’s center coordinates being x0=0; y0=0.5 e z0=0, with a radius of 0.62 m, we

have to solve the following system of equations:

(𝑥)2 + (𝑦 − 0.5)2 + (𝑧)2 = 0.622 (7)

(𝑥)2 + (y)2 + (z − 0.5)2 = 0.622 (8)

(y)2 + (z)2 = 0.52 (9)

The solution found is (A) (-0.488,0.354,0.354) and (B) (0.488,0.354,0.354). When solving only the system

of equations (7) and (8), i.e. the spheres’ equations, we have the following two points: (C) (0.509,0.25,0.25) and

(D) (-0.509,0.25,0.25). We can observe the points calculated in figure 3.

Figure 3: Cross-section of two detection volumes around a pipeline. (A,B,C, D & E are not in the plane!)

The overlapping of the two spheres creates a lens which has a circular surface of symmetry that is separated

in two by the overlapping cylinder. The points A and B represent the edges of the circle where the pipeline

intersects the lens. While points C and D, represent the largest section along the x axis of the lens. We can easily

observe that the pipeline cuts the lens above its middle section, i.e. the C D intersection.

According to the spherical symmetry we can also assume that the point of intersection between spheres

furthest away from the pipelines central axis would be (E) (0,0.509,0.509), as the lens is perfectly spherical on its

plane. Hence, if we consider the cylinder’s intersection of the lens to be equivalent to a tangent to the axis

created by points A and B, we can say that the cut is done at a distance of 0.354 from the pipe’s axis, and we

have 0,354

0,509× 100 = 69.4 % of the lens included in the pipe. Since the lens and the cut aren’t straight it must be

pointed out that it is only an approximation if we remove 69.4 % to the lenses volume.

Calculating the lens

Since the objective of considering both cubical and spherical model is to detect any difference and choose

the better representation out of both, we are going to place the same amount of sensors in the same configuration

as for the cubical model. In this scenario we will have two kinds of overlapping: a lens type of overlapping for

31

sensors in the same x axis, 0,707 m distant from each other (obtained by calculating the distance between the

coordinates (0,0.5,0) and ((0,0,0.5)), and a second overlap for adjacent sensors at 1 meter from each other.

To calculate the volume of intersection we then use the following equation (10) which is valid for spheres

with identical radius (Wolfram, 2014).

𝑉 =1

12𝜋(4𝑟 + 𝑑′) × (2𝑟 − 𝑑′2) (10)

Which gives for r =0.62 m and d’=1 m a volume of 0.219 m3 that we will denominate as volume V1. And

for r=0.62 m and d=0.707 m a volume of 0.618 m3 that we will denominate volume V2.

But as we saw before, the lenses are cut by the pipe and therefore we need to remove 69.4 % of the lens’s

volume and calculate the ODV as presented in equation (11).

𝑂𝐷𝑉 =40×𝑉2×0.306+9×4×𝑉1×0.306

𝑁×4

3×𝜋×𝑟3

× 100 = 39.93 % (11)

Conclusion

We can see that the ODV for the spherical model is more than 7 times higher than for the cubical model,

39.93 % as opposed to 5.365%. This means that for the same distance between two sensors, when considering

the spherical model, the spatial distribution of sensors is less efficient. Consequently, if we desire a lower ODV

we need to separate sensors further from each other, but this adds uncontrolled areas on the edges of the contact

plane between both detection spheres. This implies that for a similar distribution of 40 sensors the static case

performs better when using the cubical model than the spherical model.

2.6.2.4. Mobile case

Considering the drone’s maximum flight speed of 11 m/s (Parrot Shop a, 2014) and assuming that flying at

1 m/s would preserve the battery, we could have drones flying at a distance from each other of 5 meters in order

to fly over each dead-zone every 5 seconds; time at which a leak would almost reach the lower explosive limit.

The section to be controlled in the mobile case will be the same as defined in the static case in order to

allow for a comparison.

Cubical model:

In the cubical model we would only require 8 sensors. Having them fly along a predetermined path along

the pipe’s axis (x axis). Four pairs of two sensors at opposing sides of the pipe, while two pairs move similarly to

each other. Whereas one pair is at mid-section of the pipe, the other pair is at its end. Then they proceed to move

to the opposite direction of the pipe. Also, while the pairs, aligned according to the z axis, are moving in one

32

direction, the pairs, aligned in the y axis, are moving in the other direction. In this scenario there is only

overlapping when two pairs cross each other at x=2.5 m and x=7.5 m. At that moment the ODV is calculated

with the equation (12).

𝑂𝐷𝑉 =𝑥2𝐿−

𝜋𝐷2

4𝐿

𝑁×𝑥3 × 100 (12)

When using 8 for N and 1 m for L we obtain a maximum ODV of 5.365 %, identical to the static case, but

not constant in time, since the minimal ODV is zero percent when the sensors are furthest from each other.

If we assume 40 sensors to be the maximum of sensors required for ensuring 0 % of dead-zones, as

determined for the static case, and 0 sensors implies 100 % dead-zones, then we can calculate the percentage of

dead-zones while having 8 sensors using equation (13).

𝐷𝑍 = (1 −8

40) × 100 (13)

The resulting percentage of dead-zones at all times is 80 percent. In this situation the drones fly according

to a delimited path in a periodic manner, as it is one of the few possibilities that our mind can imagine without

any computational aid.

Spherical model

We will assume the same profile as for the cubical model, since there is no reason that would suggest an

improvement in changing it and because our goal is still to compare both models with one another under the

same conditions. There are no particular changes in results in regards to the cubical case, meaning that the

number of drones used is the same, as well as the percentage of dead-zones. Nevertheless, the maximum overlap

for the spherical model will be superior according to the equation (14).

𝑂𝐷𝑉 =8×𝑉2×0.509

8×4

3×𝜋×𝑟3

× 100 = 31.2 % (14)

Conclusion

Once more, the ODV is higher for the spherical representation than for the cubical, 31.2 % as opposed to

5.365 %. Also, as there is no noticeable loss by setting sensors up in a similar configuration, we come to the

conclusion that using the cubical or spherical representation is almost equivalent. Nevertheless, using the cubical

model is much more advantageous, for ease of use and for representation purposes. We decide therefore to

continue our work with the cubical representation.

Analyzing both mobile and static case, one can see a five time reduction of sensors needed for the mobile

case, this seems advantageous at first, but economically it will depend on the cost of the mobile sensor system

used as well as its maintenance cost. A detailed comparison of sensor number, maximum ODV percentage and

dead-zone percentage can be seen in table 1.

33

Table 1: Case and model results comparison.

Case Model Number of

Sensors

Maximum ODV

percentage

Dead-zone

percentage

Static Cubical 40 5.37 0

Spherical 40 39.93 0

Mobile Cubical 8 5.37 80

Spherical 8 31.2 80

In any case, we’ll proceed with the assumption that fewer sensors needed, be it mobile or static, is

advantageous and we agree that the mobile case needs further studying.

2.6.2.5. Path refinement

The drones’ movement will realistically not correspond to a simplified view of delimited paths for each

drone. Therefore, the way we assume the possible paths to be and vary will influence the programming

requirements. Limiting the drones’ paths to only straight lines is obviously reductive and we should choose a

mobility pattern with more freedom. The freest mobility pattern of all is total 6 degrees of freedom, while letting

the speed of the drone fluctuate between its maximum and minimum. Unfortunately this would require solving

multiple equation systems with multiple variables at each pass for each sensor. It would not just only increase the

software’s running time, but also make the collision problem unsolvable for our limited programming

knowledge. Although we desired the use of more ambitious concepts, we have to change them to a more

simplified yet accurate methodology.

Once more, the best solution lies in between both limited and free approaches. We choose to consider the

sensors’ speed variable according to the direction. If moving in one of the axis’s direction, it will move at one

meter per second ensuring that it will transit from one cubic meter volume’s center to the next cubic meter

volume’s center in one second. Furthermore, we will ensure that when moving in both diagonal directions,

planar and cubic, it will travel at respectively the square root of two meters per second and the square root of

three meters per second. This allows the sensor to move from center to center of adjacent cubic meter volumes in

one second, while providing at the same time twenty six options to choose from.

One can argue that for longer distances the drone is not taking the shortest path, but it doesn’t make sense

to have the sensors pick headings that are far from their close vicinity, as the likelihood of another sensor being

closer increases with distance.

34

This approach contains the threat of collisions and this is why we will discuss it in the upcoming chapters.

Nevertheless we can already outline the movement restrictions the sensors are constrained to:

If drone cannot move, then it is allowed to stay at its place;

Movement is only allowed from volume element center to volume element center;

Movement is only allowed between adjacent volume elements touching each other face to face,

side to side or corner to corner;

Drone speed will vary in order to perform any movement in 1 s;

Finally, drones cannot move to a volume element already occupied by another drone.

Maximum allowed sensor dimensions

Assuming the maximum Parrot drone’s dimensions as the most viable size of drones used in the future, we

take the values of depth and width as 51.7 cm, the height being negligible. If we assume the drone’s center to be

nested in the center of a cubical volume, then we will have a reach of 25.85 cm in the horizontal directions.

Parallel and perpendicular movements will therefore not induce collision problems.

Nonetheless, we must remember that the drones must keep a stable horizontal position when static, but in

reality they have a slight inclination when moving, which we will ignore for simplification purposes.

Subsequently, in the case where the sensor needs to move to a diagonal volume, but has other drones occupying

the adjacent volumes in the front and on the side, will there be a collision?

Planar diagonal lateral movement

The moving sensor will move in a straight line and the moment of maximum intrusion in adjacent volumes

is at the intersection of both corners of the starting and ending volumes as shown in figure 4 from a top down

view.

Figure 4: Top-down view of a diagonally moving drone with two adjacent occupied volumes.

35

As we can see in figure 4, there is a strong possibility of collision at the mid-way point. We will calculate if

there is a collision and if not, what our margin is. With the use of the Pythagoras formula we know that a

rectangle triangle with 1 m sides has a hypotenuse of square root of two which is approximately 1.414 meters,

which, from the center of a cube till its corner, leaves half: 0.707 m.

One side of a drone is 0.517 m which gives a diagonal of approximately 0.731 m. As two halves of sensors

need to fit in one diagonal the drones will collide in this configuration. The maximum allowed dimensions for

sensors not to collide is 50x50 cm.

But observing the design of the parrot AR drone 2 in figure 5, we can see that the maximum width is not on

the corners, enabling the possibility of a collision not happening. For calculating this possibility we would have

to know the exact measurements of the drone, which we don’t.

Figure 5: Dimensions of a Parrot AR Drone.

Ultimately, there is no guarantee that the drones used for sensing are going to be similar in size to the AR

Drone. Therefore we leave here the note that the sensors used in our software will be of dimensions lower than

50x50cm. The process of avoiding collisions for drones with higher dimensions will be left to further study and

we will not discuss this in our thesis.

Planar diagonal upwards/downwards movement

Before we analyze the cubical diagonal movement, let’s look at the planar diagonal movement upwards or

downwards, represented in figure 6. In these situations there is no risk of collision, as during the corner crossing

point the drones in question are not on the same plane. They’re in fact at half a meter from each other and since

the drones’ height is much inferior, there is no risk of collision.

36

Figure 6: Side view of a drone moving in planar upwards or downwards diagonal.

Cubical diagonal movement

In this case, the movement is a combination of both planar diagonal movements previously discussed, but

just as in the upwards/downwards diagonal movement, the crossover point is half a meter away of the nearest

possible hittable drone. Once more the restricted height of the drones removes the possibility of a collision. If the

height of the drones ever surpasses half a meter, then the verification of collision and possible avoidance

software will have to be developed as we will not further investigate these possibilities in this thesis.

Drone movement speed

As long as the drones are under the maximum allowed dimensions and assuming that the drones’

acceleration and deceleration are very high, we can define instead of a constant speed a varying speed. This way

we can guarantee that the drones move precisely between centers or adjacent cubic meter volumes. Therefore the

drones’ speed for movement along the axes will be one meter per second, square root of two for planar diagonal

movement and square root of three for diagonal cubical movement.

Simultaneous movement

If two or more drones move to adjacent volumes with crossing paths, there will be a collision. The process

of avoidance is something that can be easily programmed in the practical situation with data from radars and

other inputs, unlike in our simulations. We will therefore not address collision issues in our work and assume

that proper collision avoidance algorithms will be used when implementing our study into practice. As the

drones’ speed can vary in a wide range, there are many possible solutions to the collision problem, like multiple

longer paths to keep a minimum distance between moving drones, or drones performing their movement in

shorter times but sequentially. In any case, we consider our simulations to remain true, even if they don’t

simulate the details of collision avoidance.

37

2.6.3. Analytical Solution - Loop Configurations

With the data gathered about dead-zone time in chapter 2.6.2.1. and with the defined movement pattern of

the drones, we can formulate an optimal path for a single sensor for maximum efficiency. That is, for a sensor to

control a maximum amount of volumes possible with each volume being allowed to remain uncontrolled for the

duration of the allowed dead-zone time. The last condition is that the system must be stable for an infinite

amount of cycles, i.e. never can a dead-zone remain uncontrolled for longer than the imposed limit of 5 seconds.

There are a few patterns possible that a drone can adopt that respect all constraints. First of all, a drone can

only move from one volume to another each second, moving half a second inside of each volume when moving

from one center to another. We are here avoiding specificities induced by collision avoidance solutions. The total

time spent in one volume is one second as it enters the volume, travels half a second to the center and then leaves

the volume another half a second later.

Moreover, the need for the systems perpetuity requires the drone to return to its origin periodically. The

period of the system is therefore six seconds, because a volume can only stay uncontrolled for a total of five

second and the travel time in the controlled volume is one second. This means that the path navigated by the

drone during one cycle needs to be six volumes long and the sensor is not allowed to pass twice over the same

volume before it has completed a full loop. This way, each volume will have an uncontrolled time of five

seconds.

As a sensor can travel between volumes which are in contact with each other, either by surfaces, edges or

corners, there are a multitude of possible configurations in which the volumes can be assembled in space to form

a suitable six volumes long looping path. For further reference we will denominate any such successful path as

an analytical loop configuration or simply a small loop configuration.

We are presenting, as a top view, two simple small loop configurations of the many possible, as they

represent a path with mostly surface interfaces between volumes in the figure 7.

38

Figure 7: Examples of volume layouts allowing for an analytical loop configuration.

In figure 7 the upper six volume representation can accommodate three different loops: the obvious 1, 2, 3,

4, 5, 6 sequence, the 1, 5, 3, 4, 2, 6 or 1, 2, 4, 3, 5, 6 sequences. All other configurations are available through

symmetries.

In the lower six volume representation of figure 7 we can also accommodate multiple loops. We are

proposing only three: the 1, 2, 3, 4, 5, 6 sequence, the 1, 5, 3, 4, 2, 6 or 1, 4, 2, 3, 6, 5.

As demonstrated briefly, there are a multitude of variations possible in volume placement as well as the

possible routes for the drones in those configurations. Only a dedicated software would be able to find them all,

but the end result is always the same: a single sensor can control a sequence of six volumes with maximum dead-

zone times for all volumes. We will call this a small loop configuration.

Of course a different gas LEL or leak diameter would change the dead-zone time and in turn increase or

decrease the maximum amount of volumes that a single drone can control with maximum efficiency. This makes

it possible to determine an analytical solution for each situation.

At the same time, with the multitude of possible combinations, most control volume configurations can be

controlled at maximum efficiency by joining multiple small loops of the adequate shapes. We will name this

process as the multiple loops configuration. Geometric anomalies and total control volumes, which are not a

39

multiple of the small loop configuration’s six volumes, would have to suffer a loss in efficiency by using

additional dedicated drones.

For example, if the total volume to be controlled is composed of 80 volume elements and the dead-zone

time is five seconds, leading to six volume elements loops, then 78 of the volume elements are going to be

formed of a combination of thirteen small loop configurations, with one sensor dedicated to only control the two

last volume elements with reduced efficiency.

In case of an anomaly a similar approach can be used. For example even if the total volume elements are a

multiple of the loop volume elements, but there is a pair of volume elements isolated from the rest of the volume

or they are organized in such a geometric configuration that no possible loop permutation can include them, then

all but one loop are distributed with one extra sensor controlling the odd pair and another controlling the four

remaining volumes that didn’t fit in the even loop configuration.

This shows that in any case, this multiple small loop approach always determines the absolute minimum

amount of required sensors for a given volume. The restrictions being that the sensors have to follow a

deterministic loop that is never crosschecked by another sensor. Therefore, similarly to any static sensor system,

redundancy is non-existent.

One way to palliate the redundancy issue is by expanding the loop concept to the entire system. In fact, a

path can be devised that passes through each volume element of the total system while never passing twice

through the same volume element in one loop and which simultaneously has its ending adjacent to the start.

Then, by moving multiple drones along the loop with five non-controlled element volumes intervals, we can still

guarantee a maximum efficiency with minimum drones, but with the added advantage of each volume element

being controlled by a different sensor at each passage. We will call this the big loop configuration.

This adds redundancy to the system as each volume element is periodically controlled by all sensors.

Nonetheless, if one sensor is malfunctioning without the operator’s knowledge, then all volume elements will

periodically have a dead-zone time of two times the allowed time plus one second.

In the multiple loops configuration if one sensor fails without the operator’s knowledge, then the failure

remains localized, but the dead-zone times of the concerned loop can reach very high times if the sensors are not

regularly checked.

Both configurations have therefore their advantages and drawbacks to take into consideration.

Nevertheless, both required the use of a dedicated brute force software that verifies which loops respect the

defined conditions and then matches the multiple loops to the total geometry. Any brute force software has an

exponential computational time increase in pair with the intensification of the geometry’s complexity. We

require hence a faster approach to the problem.

40

2.6.4. The need for a heuristic

As seen in chapter 1.4.4., a heuristic is a method used to solve a problem in such a way that assumptions

are taken as premise to most likely lead to a near optimal solution without the guarantee of the solution being the

absolute optimum.

Why do we then require an approximate solution when we already found the analytical solution? One of the

reasons is the need for added redundancy. Acquiring an approximate solution through a heuristic may give us a

reasonably close solution, but with the added redundancy of additional sensors. Other advantages can be

flexibility. For example, if a certain area of the controlled volume must be shut off for maintenance, then a

heuristic based autonomous system will automatically adapt to the shrunken total volume, while the analytical

loop based solution requires a new loop configuration to be redefined.

Another reason is the fact that if we consider the problem in its entirety, then we are already approximating

the solution as we are considering cubical volumes for detection and other approximations. This makes our

solving process close to reality at best, but not the absolute real solution as many aspects are ignored or

estimated. Our model is itself a type of heuristic to the sensor swarm simulation which is actually beneficial as it

reduces the amount of time necessary to solve the problem.

According to Goldengorin and Jäger “a heuristic is a solution strategy that produces an answer without any

formal guarantee as to the quality”. Nonetheless heuristics are useful when the simulation time of a given

problem exceeds a realistic time frame, i.e. when it would take too long to calculate the exact result.

(Goldengorin & Jäger, 2005) Calculating all the possible configurations of the analytical loop based solution is

likely to take a lot of computational time. We will not confirm this as it lies beyond the scope of our work.

Much like the problem of the traveling salesman described in Goldengorin’s paper, we will use a heuristic

to approximate our solution. Although we need to stress, that in our problem, the sensors or equivalents of the

salesman are multiple and can do multiple passes through the destination cities, in our case, volume elements.

Nonetheless, parallels can be drawn. For instance, our heuristic will be a construction type heuristic, as it will

modify its result in order to succeed at a defined optimization criterion. (Katta, 2003)

So why do we choose to use a construction type of heuristic and not just to improve on the final result?

Because to obtain a minimum, it is easier to add elements and stop the heuristic process when the solution is

achieved rather than starting from a random amount and then exploring higher and lower solutions.

But our construction type heuristic will also contain a greedy sub heuristic, because most optimizations

performed in heuristics involve tolerances that consist of attributing scores to different localized results and

dismiss worst score outcomes (called high cost arcs) to only use those with better scores (Goldegodin & Jäger,

2005). In fact, in our case we can use a greedy heuristic to guide the sensors in their movement. By defining the

time since last checked of individual volume elements tsc to be the moving criteria of the drones, we are defining

a heuristic in which the sensor objects search for the highest local result. They will only settle for the local

41

maxima, in a manner proper to greedy heuristics. This divides our problem into subsets of problems that may

lead to a reasonable approximation of the global solution, which is the minimum amount of sensors needed.

Improvements of the heuristics are manifold, but we will not change the construction type aspect of the

heuristic. For optimization issues, we desire to maintain a consistence over our testing. Nevertheless, we will test

multiple different greedy sub heuristics in order to see if a change in the drones’ movement process influences

the global outcome and by how much.

To simplify further referencing we will call all greedy sub heuristics only heuristic and number the different

cases from one to five.

2.6.4.1 Heuristic 1

The first heuristic used is the simplest. We will define the movement of a drone by choosing the maximum

time since last checked (tsc) displayed by any of the 26 non-occupied and non-targeted adjacent volume

elements. In case of two or more identical maxima, the choice performed between those is the first maximum

encountered by the software’s screening process. This process analyses the 26 non-occupied adjacent volume

elements in a sequential order, from smallest x value to highest, then y and finally z. All sensor elements will

follow the same heuristic, but in a sequential order that is arbitrary, the sequence of addition, and the same at

each cycle. If no free adjacent volume element is available, then the drone will wait the cycle out and remain in

its position.

In summary:

Drones move in a sequential order, starting with the first drone added to the software;

Amongst 26 possible surrounding volume elements, both volume element already occupied or

targeted by another drone are ignored;

From the remaining volume elements the ones with maximum tsc value are determined;

In the event of multiple maxima being found, the first volume element with maximum tsc value

found in the screening process is chosen;

Screening process starts with negative x coordinate value, increases it until its positive value, then

iterates the same for y coordinate and finally z coordinate.

In the event of no free adjacent volume, the drone doesn’t move.

Process repeats for all remaining drones in order of addition to the software.

2.6.4.2 Heuristic 2

The second heuristic has all the same bases as the first heuristic but in the eventuality of no free

surrounding volume elements, instead of remaining in its position, the drone will wait out all other sensors’

movements, in effect ceding his place to the other sensors and, after the movement of all the other drones, it will

42

then perform the first heuristic again. More than an independent heuristic, it is more an attempt to remove the

effect of sequentiality originating from the use of a software simulation.

2.6.4.3 Heuristic 3

The third heuristic is based on the second heuristic and shares all its rules, but when confronted to multiple

equivalent maxima during the drone’s choosing process, the concerned drone will cede his place just like a non-

movable drone does in heuristic 2 and then choose a heading once more. The aim being to eventually have the

multiple maxima reduced to only one when the concerned drone is allowed to choose from its surroundings

again.

2.6.4.4 Heuristic 4

The forth heuristic is based on the first heuristic, but with the added restriction that the drone’s movement

is only allowed when the time since last checked is above 3 seconds. The aim of the heuristic is to artificially

increase the efficiency of the software’s solution in situations where the average time since last checked is a low

value.

2.6.4.5 Heuristic 5

The fifth heuristic is based on the first heuristic, but diagonal movement of the drones is not allowed.

Movement is restricted to the six main axes. The aim of this heuristic is to add more order in the drones’

movement and try to reduce bizarre trajectories with many kinks; the expectation being to have smoother

straighter paths and less backtracking, eventually leading to a solution closer to the analytical loop based

configurations.

2.6.5. Best possible program solution

Since all proposed software algorithm options are based on heuristic one and build upon it, we can

determine the best possible result for the software using heuristic one applied to a limited volume space. By

choosing a limited volume of six volume elements, we can apply the different steps of the software sequentially

and analyze all possible outcomes in a brute force manner, in order to determine the worst case scenarios. With

these results we can define the minimum amount of sensors needed to control the limited volume indefinitely

and we can then extrapolate for bigger volumes.

In a six volume elements space, the software starts with a single sensor and adds more whenever one

volume object reaches a tsc value higher than 5 s. One should note that the upper six volume elements

configuration shown in figure 7 possesses two types of volumes. Volumes 1, 3, 4 and 6 are equivalent and

volumes 2 and 5 are equivalent as well. The first four only offer three movement options while the two last offer

five movement opportunities. Direction discrepancies can be removed by simple symmetries and translations.

43

By starting with one sensor, there are a few movement configurations that will lead some volume objects to

violate their maximum tsc allowance. As an example we can describe the following sequence for a sensor

starting in volume 1. From volume element one the sensor can choose between the elements 2, 5 and 6. If it

moves to the element 2 it can then choose between elements 3, 4 , 5 and 6, element 1 possessing a lower tsc than

all the others it will ignore that option. If it moves to element 5 it will have three options: 3, 4 and 6, all others

having lower tsc values. If it moves to element 6 next, then it’s only option will be to move to element 1, then

element 2 and then it can chose between either element 3 or element 4. No matter which element it moves to, the

other one will reach a tsc of 6 exceeding the allowed limit. This forces the software to add one more sensor.

In summary:

Sensor starts in 1

moves to 2

moves to 5

moves to 6

forced to move to 1

forced to move to 2

either moves to 3 or 4

6 seconds have passed and element not moved to fails

When starting the system with two sensors, there is no imaginable configuration that fails. If testing all

possible permutations, the volumes’ tsc will never rise above 5 and this means the system is infallible. In fact

two sensors for six volume elements can be interpreted as one sensor for 3 volume elements and in this

configuration the sensor starts in volume element one and then has two options, whichever it takes the third

sensor will always be the one that hasn’t been controlled by then. From that point on the sensor takes on a loop

that is three volumes long.

When joining both loops, the sensors might switch places with each other and the loops can change to

become pendulum routes when one sensor follows the following path: 1, 2, 3, 2, 1 etc. But this setup does not

allow for tsc’s to rise above a value of 5 s.

The maximum amount of sensors needed to control a six volume element system indefinitely is therefore

two, which will be the minimum needed provided by the software. Hence, the best possible program result that

the software can find for any given volume is 2 sensors for each 6 volume elements. This implies that when

performing at its best, the software’s results are always twice as much as the analytical loop configuration result

discussed in chapter 2.6.3.

2.6.6. Software Development

In this sub chapter we discuss the development of the software as well as its subsequent iterations. It

includes the programming of a decision making process for the drones as well as movement. An example of our

44

first successful software code for multiple simulations of an empty cubic volume with 60 s of stabilization time

can be seen in appendix I.

2.6.6.1. Introduction

Before we proceed to explain the process of creating the simulation software we must stress that, although

we tried to predict as much as possible the outcomes of our sequence of programming we had to go back on

some choices and proceed to changes. We will try to explain when we modified our strategy, simplified our

assumptions or changed the process in any other way. In order to minimize such changes we proceeded step by

step and incremented the software’s code bit by bit in order to overcome increasing criteria that would lead to the

final software.

2.6.6.2. The drone as sensor object

First we implemented the drone as an object in MATLAB and gave it properties as well as a simplified set

of rules to make it move along the shortest path from its origin to a randomly generated destination. This path

choice was corrected further along the elaboration of the software.

We proceeded with the creation of an “m” file defining the class of the object sens; sens being the short

version of sensor. We gave it the following properties:

the coordinates x, y and z,

an identity: id,

a heading, specified by its coordinates hx, hy and hz,

and an allocated status, all, recording if the sensor has been allocated to a specific volume after its

creation (this property was only added later, when we required to allocate the sensors, since in early

stages they were all generated at the origin)

2.6.6.3. Drone movement simulation

At this early stage of the programming, we still envisioned the sensors to move at a constant speed of 1 m/s

in any direction and with any desired heading target. This type of movement quickly creates sensor coordinates

that are all but integers. Nonetheless, we devised a mathematical process to simulate movement through a system

of equations regulating how the sensor coordinates change.

This system of equations was the set of rules given to the sensor objects along with some basic functions.

First we implemented a function to simplify the extraction of properties from the object, then, another function

that would randomize the heading coordinates for testing purposes and finally the moving rule consisting of the

system of equations. As the sensor’s speed is 1 m/s, to avoid overshooting scenarios we will only solve the

“moving” equations’ system, when the distance between heading and starting position is greater than 1 m.

45

The system of 3 equations (15), (16) & (17), with three degrees of freedom used, allowed us to determine

the final coordinates after moving in a straight line towards the heading coordinates at the sensor’ speed of 1 m/s

for a duration of one computational cycle, in this case one second. This system would allow us to choose any

point in space as a heading, be it close or far. The three equations used were first, the equality between the

difference of the final distance with the initial distance and the sensor’s speed, while the second and third

equations represent the conservation of two components of the direction vector.

√(𝑥 − ℎ𝑥)2 + (𝑦 − ℎ𝑦)2 + (𝑧 − ℎ𝑧)2 − √(𝑎 − ℎ𝑥)2 + (𝑏 − ℎ𝑦)2 + (𝑐 − ℎ𝑧)2 = 𝑠𝑝𝑒𝑒𝑑 × 𝑡𝑖𝑚𝑒 (15)

√(𝑥 − ℎ𝑥)2 + (𝑦 − ℎ𝑦)2 ∗ 𝑎𝑏𝑠(𝑎 − ℎ𝑥) = √(𝑎 − ℎ𝑥)2 + (𝑏 − ℎ𝑦)2 ∗ 𝑎𝑏𝑠(𝑥 − ℎ𝑥) (16)

√(𝑧 − ℎ𝑧)2 + (𝑦 − ℎ𝑦)2 ∗ 𝑎𝑏𝑠(𝑏 − ℎ𝑦) = √(𝑐 − ℎ𝑧)2 + (𝑏 − ℎ𝑦)2 ∗ 𝑎𝑏𝑠(𝑦 − ℎ𝑦) (17)

Equation (15) is self-explanatory, while equations (16) and (17) are the combination of the initial and final

equalities of the projection’s cosines’ angle definition:

cos(𝛼) =𝑎𝑏𝑠(𝑥−ℎ𝑥)

𝑖𝑛𝑖𝑡𝑖𝑎𝑙 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (18)

cos(𝛼) =𝑎𝑏𝑠(𝑎−ℎ𝑥)

𝑓𝑖𝑛𝑎𝑙 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (19)

Equations (18) and (19) represent the two cosines projections on the z plane used to generate equation (16),

while for equation (17) the same process was applied, but with a cosine’s projection of the movement vector on

the x plane. One could also have substituted equation (18) or (19) with the equation resulting from the projection

on the y plane.

a, b and c are the solution coordinates to solve for and which respectively substituted the sensor’s x, y and z

coordinates after its movement. Solving this system in addition to changing the sensor’s coordinates with the

new calculated ones became the sensor’s “move” function, i.e. the process that defined how the sensor moved in

space.

2.6.6.4. Volume object definition

For the next part of the software, we gave the sensor object an exterior defined heading and this would only

be provided by the volumes requiring checking at specific time intervals. We hence created a second new class

of objects vol; short for volume. The process of defining it was similar to the definition of the sensor object, with

the difference of the properties being only the coordinates x, y and z, the identity id and the time since last

checked tsc.

The additional properties that were added further along the programming process were: sp for recognizing

the presence of a sensor in the volume, sid, for registering the id of the last sensor present in the volume, tar, for

registering if the volume was being targeted as a sensor’s heading and finally occ, for differentiating the volume

46

as an occupied or free volume, for instance if the volume is occupied by a piece of equipment or if it is a wall

(boundary of system). A summary of the properties can be seen in table 2.

Table 2: Vol object properties.

x,y & z Coordinates of the object.

id Identity of the object.

sp Sensor presence (logic variable).

sid Identity of the last present sensor.

tar Variable recording if the vol object is being targeted by a sensor.

occ Variable to determine if a vol object is occupied by equipment or otherwise inaccessible.

Meanwhile, the basic set of rules only contains the function for the object’s property extraction and nothing

else. As a volume cannot be punctual, we have to keep in mind that the object’s properties only contain the

centre coordinates of a cubic volume with 1 meter of side.

2.6.6.5. Volume array - space

After the object class vol definition, we created a process that generates and stores the vol elements. The

size of the generated space should be variable, since the equipment to be controlled can be it as well. Therefore

the first step is to ask the user what size the desired volume is. The input variables demanded by the system are

defined as space sizes (sa, sb and sc), i.e. the distance by which the space expands in all 6 directions starting

from the origin. This means the total volumes size will be defined by the equation (20).

𝑉 = (2𝑠𝑎 + 1) × (2𝑠𝑏 + 1) × (2𝑠𝑐 + 1) (20)

In the “mapping” process, explained below, the generated vol object is given an id, which starts at 1 and

increases by one for each new volume object. These vol objects are not generated in an isolated manner, but are

coded into a vol object array that only stores that specific type of object and each object’s position number in the

array is made to coincide with its id, i.e. volume object one is in position one of the array and so on. Additionally

the vol objects receive the five additional properties explained previously, of which each is set to a specific

value: tsc is set to start at zero, sp is set as false, sid is left untouched, while tar and occ are both set to false. We

point out that any variable set to false is automatically considered as a logic variable by MATLAB.

The “mapping” process uses the space size given by the user and then proceeds to cycle through each axis

starting from the negative value of the corresponding input and stopping at its positive value. The “mapping”

starts at one corner of the space with the negative value of sa and increases it by 1 meter until it reaches the input

value, then changes to the second input sb in its negative value, adds 1 meter to it and proceeds again by raising

sa from its negative value till it reaches the desired size and repeats this process until sb reaches its positive

value. The same process occurs a level further with sc until each and every volume has been “mapped”.

47

To limit the volume in which the sensors are going to evolve, we add an extra layer of volumes around the

“mapped volume”. This is accomplished by adding 1 to the space size variable. At the same time, as this layer

needs to be impermeable to sensor movement, each volume generated that has either the maximum or minimum

value of the space size in one or more of its coordinates gets its occ value set to true.

2.6.6.6. Sensors array

Generating the array of sensors is not as straight forward as they can’t all start at the same coordinates, nor

can we place them in order along the created volumes either, as it could generate unwanted preferentiality

effects, while having many of the sensors locked for some time before they can begin movement. Furthermore,

the volumes might be occupied, by equipment for instance, or be the edge volumes. The software was therefore

designed to assign the desired amount of sensors into an array, each with its own identity, ranging from one to

the desired amount. Each sensor receives a specific set of coordinates different from every other sensor. These

coordinates were in a first iteration defined randomly and then verified against occupation of the corresponding

volume. If this volume is determined to be already occupied, then new coordinates are randomized until a free

volume is discovered. The coordinates corresponding to this random free volume are then specified to the

sensor’s properties.

We opted for an iterating amount of sensors for optimization purposes, following the construction type

heuristic style. The software launches therefore with one sensor and increases it by one each time the success

condition fails.

2.6.6.7. Safety distances

In our initial free movement assumption for the drones, as we started implementing multiple sensors into

our software, we needed to calculate multiple paths and ensure that they would not collide with each other. There

are a few options we could use to do so. We could either have each sensor check if the volume towards which it

was heading was occupied or crosscheck the position of every drone and observe if the distance between them

and itself was sufficient. While the first option is the least calculation time consuming, it does not ensure the lack

of collision between sensors, as two sensors’ centres can be inside their respective volumes but still touch each

other by the edges. Therefore, the second option is necessary to ensure that a sufficient safety distance was kept

between sensors at all times. But as the number of sensors present soars, so does the calculation time to verify

the other sensors’ positions.

We considered a possibility to mix both approaches. If the moving drone only test sensor presence for

adjacent volumes to his heading, then it only requires verifying the minimum distance between it and the sensors

discovered in the vicinity, ignoring the sensors that are further away. It was for this purpose that we required to

modify our initial definition of the volume object and give it a logic property of sensor presence, sp, which could

have either its value set to false or true. Additionally, in order to identify the present sensor, we needed to

implement an additional property, sid, the identity of last present sensor.

48

Most of these detection procedures made it into the final software although the problem was then simplified

in order to ignore collisions altogether as seen in chapter 2.6.2.5.

2.6.6.8. Selective detection

At this point, the sensor object still had its moving function embedded in its object functions; we soon

realized that it was more advantageous to have the software move the sensors rather than having the object retain

that function.

In fact, in order to have an aimed verification of specific volumes surrounding the point of destination of

the drone, our selective code needed to use the already existing “move” function to calculate the straight path’s

final coordinates and verify the empty state of the cells nearby as well as the destination cell itself. In case of

occupied neighbour volumes, the code would then recalculate a new path that ensured maximum distance

covered towards the heading and ensured at the same time a minimum distance between neighbouring sensors,

so as to avoid collision.

During this process, the code requires to access properties from the volumes. Unfortunately this can’t be

done in MATLAB as a method included in the sensor’s definition. I.e. the function to access the volumes data

has to be in the main body of the software and not in the corpus of the sensor object. The same applies for the

volume trying to access sensor specific properties. This was the reason behind the creation of an exterior

function that detects the volumes around a specific sensor and moves it by changing the sensor’s properties.

(Mathworks Inc., 2014) The object embedded “move” function was therefore abandoned.

2.6.6.9. Detection of the surroundings

As mentioned above, the detect function required to extract the heading of a sensor and calculate a first

virtual straight movement. Then, we could use the theoretical final coordinates to determine the surroundings to

be controlled for drone presence. This is possible, because the generation of vol objects is deterministic and we

can hence, with any coordinates, determine the identity belonging to any specific volume. The same can be done

to any adjacent volumes. The usefulness of this characteristic is that the identity of a volume coincides with its

position in the vol array and we can access it faster than if we have to find the position of an object in an array

through property matching of all coordinate properties, while going through all elements of the array.

The equation allowing us to calculate the identity of a volume with the knowledge of its coordinates is the

following:

𝑖𝑑 = (𝑠𝑎 + 1 + 𝑥) + (𝑠𝑏 + 1 + 𝑦 − 1) × (2 × 𝑠𝑎 + 1) + (𝑠𝑐 + 1 + 𝑧 − 1) × (2 × 𝑠𝑎 + 1) × (2 × 𝑠𝑏 + 1)(21)

Where id is the identity of the volume and sa is the space size chosen by the operator for the x axis, sb

space size chosen by the operator for the y axis, sc the space size chosen by the operator for the z axis and x,y

49

and z are the coordinates of the volume identity to be found. The origin of this equation is the simple addition of

all elements generated prior to the one with the coordinates x, y and z.

Since the generation process starts with the negative value of the sa and raises the value of x until it reaches

its positive value and then uses sb in its negative value while raising the y value by one and then repeating the

process until y reaches the positive value of sb, moment at which it is reset to use the negative value of sc and the

z value is raised by one and the process repeated until all the volumes have been generated; it is only necessary

to add the number of completed planes minus one, times the amount of volumes per plane, plus the number of

completed lines, times the amount of volumes in a line, plus the amount of volumes generated in the current line.

This can be seen in the equation (21) above which can also be simplified as shown in equation (22).

𝑖𝑑 = (𝑠𝑎 + 1 + 𝑥) + (𝑠𝑏 + 𝑦) × (2 × 𝑠𝑎 + 1) + (𝑠𝑐 + 𝑧) × (2 × 𝑠𝑎 + 1) × (2 × 𝑠𝑏 + 1) (22)

With this tool, we can now verify every relevant volume for sensor presence. Nevertheless, while sensors

have free movement, their coordinates don’t follow integer numbers. Hence, we have to round up or down the

moving sensor’s final coordinates’ value to zero decimals, in order to apply this formula. With the integer

values, we can then add and subtract one meter to the coordinates in order to achieve a full cubical coverage

around the destination volume. The software verified therefore the volumes for the following 27 coordinates

shown in tables 3 to 5.

Table 3: Coordinates of volumes verified with x minus one meter.

For x-1 z-1 z z+1

y-1 x-1,y-1,z-1 x-1,y-1,z x-1,y-1,z+1

y x-1,y,z-1 x-1,y,z x-1,y,z+1

y+1 x-1,y+1,z-1 x-1,y+1,z x-1,y+1,z+1

Table 4: Coordinates of volumes verified with x fixed.

For x z-1 z z+1

y-1 x,y-1,z-1 x,y-1,z x,y-1,z+1

y x,y,z-1 x,y,z x,y,z+1

y+1 x,y+1,z-1 x,y+1,z x,y+1,z+1

Table 5: Coordinates of volumes verified with x plus one meter.

For x+1 z-1 z z+1

y-1 x+1,y-1,z-1 x+1,y-1,z x+1,y-1,z+1

y x+1,y,z-1 x+1,y,z x+1,y,z+1

y+1 x+1,y+1,z-1 x+1,y+1,z x+1,y+1,z+1

50

Here is when we required more additional volume properties. tar, sp and sid were added to enable

knowledge about a volume being occupied by a sensor and which one, as well as to know if a sensor has already

targeted the volume as its future heading.

2.6.6.10. Avoiding collisions

The objective at this stage of the software was to determine which sensors were in the vicinity of the

moving sensor’s path and then calculate a path that would avoid collisions, while minimizing the distance to the

targeted heading. The function to determine the new final coordinates would use the same system as previously

(equations: (15), (16), & (17)), but instead of solving it for one value, it would minimize the system’s results

while at the same type applying a restriction to the distance between the result coordinates and the previously

detected close sensors. This meant that we would have to minimize a system of three equations with three

variables and multiple parameters, subjected to a variable number of restriction equations.

MATLAB has tools to minimize as well as restrict minimizations, but for a problem of this scope the

programing complexity surpasses our capacities. We came to the realization that our first assumption of free

moving sensors was overambitious for the programming language used and we revised our methodology.

We decided to restrict our sensors to movement that ranges from one volume centre to exactly another

volume’s centre. This means also that our sensor objects have varying speeds but integer coordinates at all times

and that, according to chapter 2.6.2.5.’s findings, we can ignore collision issues with these assumptions.

2.6.6.11. New moving procedure

The new assumptions from 2.6.6.10., allow us to greatly simplify and optimize our software. We

abandoned the previous “move” function, based on a system of equations. Now, the code simply changes the

coordinates of every sensor at the end of each cycle with its stored heading coordinates through a simple equality

function. It then imposes a true status to the sensor presence property of the volume it moved to, as well as

imprints its identity in the sid variable.

2.6.6.12. Selection process - “heading” function

The main reason for a sensor moving in a specific direction is the need for controlling a volume that hasn’t

been checked before the expiration of its limited dead-zone time as defined by our greedy heuristic component.

It is at this point in programming that we require the addition of the time since last checked tsc in the volume’s

properties. The counter starting at 0 when the volume is created, we need to increase the counter by one second

each tick. This is easily done by creating a cycle at the end of our software that goes through the list of volumes

and adds one second to the counter if the sp property is set to false. At the same time we use this routine to reset

the counter to zero if the sp value is set to true, as it means that the volume is being controlled at that specific

instant.

51

Meanwhile, we want to avoid two sensors heading for the same volume. This is where the tar variable

addition to the volume’s properties becomes useful. With it, we can easily verify if a volume has already another

sensor heading for it. We adjusted the code accordingly, to make sure that every time a sensor sets his heading

for a specific volume, it sets the tar variable of that vol element to true.

After creating the functioning timer and ensuring single targeting, discrepancies between volumes will

appear with the passing of software cycles. Some volumes will have higher times on their counter, and some,

lower. At the same time, sensor movement will be dictated by tsc maxima. However there can be more than one

volume with highest tsc, as well as the situation in which a distant volume has highest tsc but a closer volume is

only one second short.

Should a sensor then verify all volumes and decide upon the highest timer? We decided to not search the

entire volumes list, as it would make the software less efficient, as every sensor would have to verify the list in

its entirety. Likewise, we believe that only verifying the adjacent volumes would be better advised, because if a

sensor does detect a higher counter time further away than in its vicinity, it won’t be able to reach it during the

next cycle and most probably there will be another sensors closer to that volume. One could argue that there

might be areas with lower sensor density that at some point will suffer a low coverage, but this is what our model

is going to try and find out. From which density of sensors onwards can we guarantee the system’s total safety?

For the chosen procedure we wrote therefore a “heading” function that only scans the 26 adjacent volumes

of a sensor, using equation (22), in order to identify the already occupied volumes as well as the free volumes

and their respective tsc count. The “heading” function chooses the highest tsc from those 26 non occupied free

volumes and if there are two or more identical values, then it choose the first encountered volume during the

arbitrary screening, as it simplifies the programming process. Though we cannot guarantee that because of this

procedure no geometrical preferences will occur.

In the eventuality that all 26 adjacent volumes are occupied, the sensor will simply stay at its place

according to heuristic 1. Further outcomes of this situation are then explored by applying the other proposed

heuristics.

Once a sensor object defines his heading it substitutes its current coordinates with the heading at the end of

each computing cycle as explained in 2.6.6.11.

52

2.6.6.13. Applied heuristic schematic

The first final iteration of global heuristics used in the software can be visualized in the following steps:

Choose a random starting point for all sensors that is individual to each sensor

In order of list, have the sensor choose the adjacent volume or volumes with highest tsc and both

occ and tar value set to false

Define first encountered maximum as heading, the order of discovery being from smallest x value

to highest, then y and finally z, from lowest value to highest

If all adjacent volumes are occupied or targeted by another sensor, then

o Heuristic 1: there shall be no movement

o Heuristic 2: move only after all other sensors have moved

o Heuristic 3: move only after all other sensors have moved and eventually resolved

multiple maxima

o Heuristic 4: move only to maxima higher than 3 second

o Heuristic 5: move without using any diagonal movements

Sensors move to their target and reset the volume’s tsc value to zero

Cycle keeps going until optimization condition is satisfied.

2.6.6.14. Success condition

After coding the creation of both sensor and volume objects, the successful random allocation of sensors, as

well as the sensor’s means to generate a heading. We require a means to control the software and convey it a

success condition. Using the already designed piece of code that increases the tsc counter of volumes by one

second at the end of each software cycle, we force the software to verify, after five initial simulated seconds have

past, each non-occupied volume’s tsc counter and restart the software with one additional sensor in the event of

at least one tsc value being found with a higher time than allowed. The initial five seconds are there to optimize

the software as every volume’s tsc counter starts at zero and five is our limit of dead-zone time. I.e. as long as

five seconds haven’t pasted there is no volume with tsc higher than five.

Also, in the non-random allocation of sensors, it allows all volumes’ tsc to keep counting while giving a 5

second buffer before the software starts checking for failures. This way the sensors will move to the absolute

maxima since the very start of sensor allocation and not artificial maxima created by restarting the tsc count at

each sensor addition.

The software will restart with one additional sensor each time it fails to reach the success condition, which

is to go through all volume objects and have no volume with tsc higher than five. If such a condition is

maintained during the amount of required simulation time, then the software is successful. The software is

stopped and the number of sensors is recorded.

53

2.6.6.15. Software modifications

After we created our initial iteration of the software and obtained our first viable result we went through

multiple modifications in order to obtain different types of results.

First, we incorporated our software in a cycle repeating it in order to run it multiple times in a row,

recording multiple results, as they may vary depending on the starting conditions, which themselves change

depending on the random allocation of sensors.

Second, we modified the software in order to allow it to control for success during longer simulation times.

That simulation time, was made variable and defined the time during which the simulation is left running and

adding sensors, even if at some point the success condition was met. This is useful, as the success condition

might be reached for a small number of sensors, but then will fail repeatedly with that number of sensors,

requiring the software to add more sensors after the fact. In effect, the longer a simulation will run, the longer the

system has time to stabilize and the higher the probability of retaining a sensor number that will keep the system

stable for an extended period.

Third, we set a defined equipment and volume to be controlled, in the initial phase an eleven meter pipeline

surrounded by a control volume layer of one meter in thickness with a total of eighty-eight volume elements.

Then further equipment geometries followed as explained in their respective chapters.

Fourth, we devised a non-random allocation counterpart to the original software which, instead of

reallocating the sensors randomly at each new sensor addition, retains the sensors’ positions while adding the

last sensor in the location of the last failure found after the at least the initial five seconds of run simulation have

passed. This process tries to resemble a plant start-up process.

Fifth, we implemented a way to count the amount of times the different volume elements will not perform

as desired, i.e. have a time since last checked greater than the allowed five seconds. This failure measurement

process is detailed in the redundancy chapter 3.5.

Sixth, a method to implement leaks in the system was formulated for punctual testing of leaks and their

detection or not.

Here is a step by step breakdown of the modifications:

From single run to multiple run program.

Added variability in system’s minimum stable running time.

Defining simple equipment: 11 m pipeline.

Non-random allocation of sens objects implemented.

Volume element failure counter implemented.

Punctual leaks method devised.

54

3. Simulation Results

In this chapter we will present the simulations performed and the ensuing results for the different systems

studied.

3.1. Empty cubical volume

The following chapter only handles simulations performed for an empty cubical volume and presents the

ensuing results. The purpose of this open environment testing is to verify that the basic software functions are

working as intended and to retrieve a simple vision of the process at hand when applying it to a simple geometry.

Therefore, all simulations were done solely with heuristic one.

3.1.1. Six seconds of simulation time

Our first simulations are designed to determine the minimum amount of sensors required to fully control a

defined volume for a simulation time of six seconds and ensure that past this time there is no sensor with a tsc

higher than the allowed 5 s. For every simulation and at every new sensor addition, all sensors are allocated

randomly across the volume. We performed the simulation a total of 150 times for the volumes of 27 m3, 125 m

3,

343 m3, 729 m

3 and 1331 m

3. These total volume values originate from the software’s method for creating

volume through the use of direction size variables. By choosing the same value for all three variables, the

formula generating the total volume is the cube of two times the given size plus one. Thus, 125 m3 are equivalent

to a defined direction variable of two meters in each axis’ direction (positive and negative) of space, i.e. the cube

of two times two plus one.

We calculated the average amount of sensors needed over all the trials for each given volume as well as the

average occupation percentage, i.e. which percentage of the total amount of volume elements is occupied by a

sensor. Both series of results have been plotted versus total space size as can be seen in figures 8 to 10.

Figure 8: Plot of occupation percentage vs. volume size for 6 s of simulation.

18%

19%

20%

21%

22%

23%

24%

25%

26%

27%

28%

0 200 400 600 800 1000 1200 1400

Tota

l ave

rage

occ

up

atio

n

Volume size(m3)

55

In figure 8 one can see that the occupation percentage doesn’t stay constant, nor does it increase

proportionally with volume size. Not represented in figure eight are the obvious points (0,0) and (1,1) for very

low volumes. Indeed we can predict these values, as for no volume we don’t require any sensors, and for a

volume of 1 cubic meter we require 100 % occupation as no drone movement is possible. These two points are

non-trivial and are out of the boundaries of what we are trying to test.

We can also observe there are two regimes: one for small volumes, where the occupational percentage

growth increases rapidly as we increase the volume size and another one past the inflection point, close to 400

m3, where the percentage increase rate starts decreasing as we increase the volume size. We speculate that the

reason behind this effect must be related to the ratio of volume added to the previous existing volume when

increasing the cube’s total volume.

We also have the intuition that there should be a superior limit value for the percentage, but we currently

lack the amount of trials in order to perform the adequate verification and potentially observe a second inflection

point at higher volumes. As these simulations are for six seconds only, we will look for more evidence in further

longer lasting simulations.

In figure 9 we can observe the steady increase in sensors needed following the raise in volume size. A

linear regression analysis of the data can be performed, obtaining a determination coefficient of R2=0.9947,

which is a good value, but a second degree polynomial regression generates a determination coefficient of 1,

suggesting an even better correlation, but ultimately, we have not enough points to determine which correlation

is the best. And as higher volumes require higher real time of simulation, we will abstain to do so for this

preliminary stage.

Figure 9: Plot of volume size vs. average amount of sensors needed for 6 s of simulation.

0

200

400

600

800

1000

1200

1400

0.00 100.00 200.00 300.00 400.00

Vo

lum

e s

ize

(m

3 )

Average amount of sensors needed

56

In figure 10 we can observe another phenomenon to be expected due to the random nature of the sensor

allocations: the increase in variance between results. In fact, for small volumes the starting possibilities are

reduced and therefore the outcomes as well, but the bigger the volume the more varied the possibilities.

Figure 10: Plot of volume size vs. minimum, maximum and average of sensors needed for 6 s of simulation.

Nonetheless, the maximum and minimum values are always close to ten per cent of the average value of

sensors needed as we can see in table 6.

Table 6: Study of sensor number for 6 s simulations.

Total volume (m3) 27 125 343 729 1331

Max sensors 7 29 82 186 385

Min sensors 6 24 67 155 318

Average sensors 6.33 26.49 73.21 169.39 352.45

Max variation (%) 13.64 7.58 11.09 9.09 8.38

Min variation (%) 11.76 10.39 9.26 9.52 10.95

3.1.2. Sixty seconds of simulation time

We performed further simulations similarly to chapter 3.1.1, but for an increased simulation time of sixty

seconds. Additionally, we broadened our volume range to include the bigger volumes of 2197 m3, 3375 m

3,

4913 m3, 6859 m

3, 9261 m

3, 12167 m

3, 15625 m

3 and 19683 m

3. For these we perform less simulation

repetitions, as the increased amount of calculations lead to the real time of simulations to reach 24 hours for

certain high volume cases. A table of real time and number of simulations for each volume can be found in

appendix II.

Figure 11 indicates a quick growth regime for an increase in the small volume range, while for bigger

volumes the percentage growth tends to stabilize and even slightly diminish.

0

200

400

600

800

1000

1200

1400

0 100 200 300 400 500

Vo

lum

e s

ize

(m

3)

Average amount of sensors needed

max sensors

min sensors

57


Figure 11 presents the second inflection point as predicted, but one can only assume that for very high

volumes the percentage will remain constant although concrete results are out of our reach, as we do not possess

nor the time nor resources for performing extreme volume simulations due to their tremendous real time duration

increase. We can however obtain an estimate of the limit percentage by using the results in figure 12.


If we perform a linear regression to the results in figure 12 we obtain equation 23.

𝑣𝑜𝑙𝑢𝑚𝑒 = 1.9044 × 𝑠𝑒𝑛𝑠𝑜𝑟𝑠 + 411.82 (23)

Although the linear dependence resulting from equation 23 doesn’t cross the origin, we can approximate

that the inverse of the first coefficient is equal to sensors over volume, i.e. to the limit percentage of occupation,

in this case 0.525 or 52.5 %.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 5000 10000 15000 20000

Tota

l ave

rage

occ

up

atio

n

Volume size (m3)

0

5000

10000

15000

20000

25000

0 2500 5000 7500 10000 12500

Vo

lum

e s

ize

(m

3)

Number of sensors

58

From tables 7 and 8 we can determine that the higher a volume, the lower the variance in results. This is

explained as for small volumes, certain starting configurations can be beneficial for controlling while others not.

The same is valid for bigger volumes, but at a similar scale than for small volumes. Therefore, although

beneficial configurations are present locally, they are counterbalanced by other non-beneficial configurations in

other regions, requiring the software to add more sensors. Eventually the total number of sensors will increase in

such a fashion that those preferential sub regions of volume stop influencing the final result, explaining the

convergence of results for higher volumes.

This implies that although some configurations yield lower sensor results, we cannot accept those as the

minimum result. Because to ensure control at all times for long durations, the system cannot fail under any

possible configuration, the absolute possible minimum that we can therefore accept is the maximum obtained by

the software. Anything under that value will present failures as time passes.

Table 7: Study of sensor number for 60 s simulations (part 1).

Volume in m3

27 125 343 729 1331 2197

maximum of

sensors 7 36 108 263 525 928

minimum of

sensors 6 31 90 224 459 858

average value of

sensors needed 6 34 99 247 503 896

maximum

variation in % 13.6 7.3 8.2 6.0 4.2 3.4

minimum

variation in % 11.8 8.7 10.2 10.6 9.5 4.5

Table 8: Study of sensor number for 60 s simulations (part 2).

Volume in m3

3375 4913 6859 9261 12167 15625

maximum of

sensors 1504 2255 3291 4602 6139 8048

minimum of

sensors 1408 2228 3173 4482 6077 7949

average value of

sensors needed 1462 2236 3227 4524 6114 8002

maximum variation

in % 2.8 0.9 1.9 1.7 0.4 0.6

minimum variation

in % 3.9 0.4 1.7 0.9 0.6 0.7

59

3.1.3. Six hundred seconds of simulation time

A further series of simulation was performed for six hundred seconds of simulated time, for the same

volumes as in chapter 3.1.2, except 19683 m3 due to the very high real time taken by the respective simulations.

The results are presented in figure 13 and 14.



The results found for six hundred seconds of simulation show the same progression as in chapter 3.1.2.

There is a rapid increase for small volumes but as the volumes get bigger, the progression is lowered to almost

halted. Nonetheless, in figure 14 we can apply a linear regression and determine equation 24 below.

𝑣𝑜𝑙𝑢𝑚𝑒 = 1.8814 × 𝑠𝑒𝑛𝑠𝑜𝑟𝑠 + 176.11 (24)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 5000 10000 15000

Tota

l ave

rage

occ

up

atio

n

Volume size in (m3)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

0 2000 4000 6000 8000 10000

Vo

lum

e s

ize

in (

m3)

Number of sensors

60

The obtained equation shows a better approximation to the origin than equation 23. The resulting

approximation for the maximum percentage is 53.2 %. It is noteworthy that for an increase in simulation time of

a factor ten, then limit percentage of occupation only rose by 0.7 % (absolute value). Therefore, to increase the

simulation time further will have little impact on the absolute maximum total percentage that can be obtained in

comparison with the resources spent to obtain the results.

When comparing both results for 60 s and 600 s of simulation, as shown in figure 15, we can observe that

for a higher time, the percentage of occupation is higher. This is due to the favourable configurations of the

system being gummed out with time and hence, more sensors are added. We can also discern that the difference

in percentage is reduced, the bigger the volumes are. This is most likely another repercussion of the loss of

favourable states that arises with the increase in volume size.

Figure 15: Plot of occupation percentage vs. volume size for 60 s and 600 s of simulation.

3.2. Pipeline

The following sub chapter will only handle simulations performed for a volume surrounding an eleven meter

pipeline and present the ensuing simulations. Aspects of random allocation versus deterministic allocation are

compared, while also further elements such as control failures are discussed.

3.2.1. Equipment volume definition

The equipment tested was an eleven meter pipeline in order to be as close as possible to our previous static

versus mobile test cases, which used a ten meter pipeline. We cannot use a ten meter pipeline as the sides of the

simulated volumes in our software can only be an uneven number; therefore we use the volume with eleven

meter sides, i.e. 12167 m3. The volume is then crossed by an infinite pipeline in the x axis passing through the

origin. This results in an eleven meter pipeline.

20%

25%

30%

35%

40%

45%

50%

55%

0 5000 10000 15000 20000

Tota

l ave

rage

occ

up

atio

n

Volume size in (m3)

600s

60s

61

The volume elements crossed by the pipeline are considered occupied even though there is a small

percentage that is not occupied by the pipe. This is not a concern, as any leakage in this volume will diffuse and

disperse to the adjacent controlled volumes. Furthermore, as seen before, only a small overlap between detection

volume and leak volume is enough to trigger the sensors. All adjacent volumes to this central occupied rectangle

are therefore the volume elements to be controlled. Any volume element further from the equipment is dismissed

and set as occupied due to a leakage only be possible at the equipment, in this case, the pipe. The amount of

volume elements to control is therefore 88, as for each cubic meter of equipment there is a ring of eight cubic

meters around it to be controlled. The edges of the pipe are considered outside of the system and hence are

ignored. A schematic representation can be observed in figure 16.

Figure 16: Visual representation of the volume elements used for simulations with pipe in the centre.

The analytical loop configuration result obtained for a volume composed of 88 one cubic meter volume

elements is a sixth of 88, or approximately 14.7. Hence the analytical loop value is 15 sensors in which one of

the sensors would control only 4 elements. This implies a best possible program result of 30 sensors.

3.2.2. Random sensor allocation

As the control volume remains constant but the starting position of the drones varies, we performed fifty

simulations for each given simulation time using only heuristic 1. The durations used were every 60 second

interval starting from 60s to 600 seconds, as well as every 600 second interval between 600 s and 6000 s.

Additionally fifty simulations of 60000 seconds were performed. The ensuing results can be observed in figure

17 and 18.

62

Figure 17: Occupation percentage vs. simulation time for random allocation 11 m pipeline control.

In figure 17 all points are represented except the result for 60000 s for legibility reasons.

Figure 18: Average sensor number needed vs. simulation time for random allocation 11 m pipeline control.

The maximum result shown in figure 18 is 36.28 of average sensors needed, which is more than the

predicted best possible program result of 30 sensors.

3.2.3. Non-random sensor allocation

As the random sensor allocation adds tremendous uncertainty in the results’ outcome and likewise the

process doesn’t represent a real life approach to the drone introduction in the system, we devised a process by

which sensors are allocated in a controlled fashion. The initial sensor can be placed in any empty volume, but we

decided to place it in the volume element with the coordinates (0,1,0) as it is one of the closest elements to the

centre of the equipment, the aim being, to reduce any preferentiality effect rising through start up asymmetry.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0 1000 2000 3000 4000 5000 6000 7000

Tota

l ave

rage

occ

up

atio

n

Simulation time (s)

0

5

10

15

20

25

30

35

40

0 1000 2000 3000 4000 5000 6000 7000

Ave

rage

se

nso

rs n

ee

de

d

Simulation time (s)

63

With that initial sensor, the software begins the search for volume elements out of the allowed control time range

and adds a sensor in the location of the first encountered discrepancy after each restart.

Then the software can be enhanced through two different ways. It can either reinitialize the counters of all

volume elements and resumes the verification process or it can leave all counters to increase, but while waiting

five seconds, i.e. the dead-zone time limit, before resuming the search. In both scenarios the sensors remain in

the location they were when another sensor is added. We chose to follow the last method as it ensures that the

sensors tend to travel to the regions with lowest overall sensor presence since the start of the software. This way

the distribution of sensors is reached faster and more evenly.

The process keeps adding sensors at the location of failure discovery until it is able to perform error free for

the required simulation time. Unlike the optimization software, where sensors were reset at their first

introduction coordinates, no such thing is done here; this is to remove the possibility of a sensor being added to

another sensor’s starting point as well as to reproduce a closer to reality start up simulation.

The fact that the error screening process is always the same and that our initial sensor is placed at the same

place every time, allows us to consistently achieve the same unique result. Variance appears only with the

increase of simulation time, as for higher times more sensors are required due to more errors encountered.

3.2.4. Heuristic 1

To obtain a representative minimum of sensors required we performed a unique optimization for one year

of simulated time. The sensors needed for that amount of simulated time was 41 sensors, the same amount as for

one day of simulated time. The real time needed for this simulation to run was over a week.

With this result we confirm the existence of a maximum to the number of required sensors for a defined

geometry. In this case 46.59 % is the minimum occupancy of mobile sensors required around an 11 meter

pipeline for total continuous volume control according to heuristic 1 used.

When observing the results of non-random sensor allocation, the most noticeable effect of switching from a

random allocation process to the non-random allocation is the loss of uniform increase in sensor number. While

in figure 18 the progress is uniform due to multiple extremes being smoothed by averaging fifty results for each

time. In figure 19 we can see how a single sensor number optimization process works.

64

Figure 19: Sensor number needed vs. simulation time for non-random allocation 11 m pipeline control (H1).

When a certain simulation time threshold is passed, the system isn’t able to control every single volume

element and a sensor is added. A single sensor might not prove enough, another one being added immediately at

the next screening. When finally a stable number is reached, then the system tends to remain stable for longer

than previously, until that next simulation time threshold that requires more sensor additions.

3.2.5. Comparison of random with non-random allocation for heuristic 1

Both figure 20 and 21 contain fifty results for each time simulated with random allocation of sensors as

well as the corresponding unique results for the non-random sensor allocation. From these results we can

conclude that the deterministic simulation is always more restrictive than the random allocation, as it features

higher sensor amount needed for every simulated time. Nonetheless, as time increases, the results converge to

the same maximum of 40 sensors as can be seen in figure 21.

Figure 20: Non-random vs. random sensor allocation for 11 m pipe simulation (60 to 600 s).

0

5

10

15

20

25

30

35

40

45

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time (s)

20

22

24

26

28

30

32

34

36

38

40

0 200 400 600

Nu

mb

er

of

sen

sors

Simulation time (s)

60s

120s

180s

240s

300s

360s

420s

480s

540s

600s

non-random

65

Figure 21: Non-random vs. random sensor allocation for 11 m pipe simulation (60 to 6000 s).

3.2.6. Other Heuristics

After verification with heuristic 1 that, one year of simulation yields no different result than for a day, we

decided to perform all further simulations with a smaller simulation time to allow us to perform more different

types of simulations in the given time span of this work. Therefore, the maximum simulation time used during

the following simulations was 6000 seconds, except for heuristic 5 where bad results were already seen at 600 s,

reason for which we didn’t perform higher time tests. The results of sensor numbers versus simulation time for

all 5 heuristics can be seen in figures 22 through 25.


20

25

30

35

40

45

0 1000 2000 3000 4000 5000 6000

Nu

mb

er

of

sen

sors

Simulation time (s)

60s

120s

180s

240s

300s

360s

420s

480s

540s

600s

1200s

1800s

2400s

3000s

3600s

4200s

4800s

5400s

6000s

non-random

0

5

10

15

20

25

30

35

40

45

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time (s)

66




0

5

10

15

20

25

30

35

40

45

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time (s)

0

5

10

15

20

25

30

35

40

45

50

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time (s)

30

32

34

36

38

40

42

44

46

48

50

0 100 200 300 400 500 600 700

Nu

mb

er

of

sen

sors

Simulation time (s)

67

As we can observe in table 9, none of the proposed heuristics come close to the best possible program result

and heuristic 4 and 5 behave worse than all the others. As complexity increases throughout heuristics, so does

computational time. Hence for a practical use, the heuristic with closest result to the best possible program result

and with lowest complexity would be the best. We would like to remind the reader that the best possible program

result is the result originating from the application of heuristic one to six volume elements subdivisions for an

infinite amount of simulation time.

Table 9: Min. sensors required for 11 m pipeline control for varied heuristics for 6000 s (non-random allocation).

Method

Analytical

loop

configuration

Best

possible

program

result

Heuristic

1

Heuristic

2

Heuristic

3

Heuristic

4

Heuristic

5 (600 s)

Min.

sensors 15 30 40 40 39 43 43

There is no improvement for the maxima between heuristics 1 and 2 meaning that for high times, the

effects of a sensor being blocked are minimal. While heuristic 3 shows a very small improvement.

3.2.7. Introducing specific leaks

In a first iteration, leaks were introduced in the software using heuristic 1 with non-random sensor

allocation, to allow us to specifically test scenarios for specific leak times and location. We decided to run the

simulation for 24 hours of simulated time, with leaks occurring hourly at the coordinates (0,1,0). Figure 26

presents the ensuing results.

Figure 26: Amount of failures vs. number of sensors used during 24 h control of 11 m pipe.

In figure 26 we can determine that when using 50 % of the maximum sensors needed the designed leaks are

still detected within allowed margins, but under 20 sensors the number of late detected leaks rises exponentially

0

2

4

6

8

10

12

14

16

0 10 20 30 40 50

Nu

mb

er

of

no

n d

ete

cte

d le

aks

Number of sensors

68

with the decrease of sensors. Important to mention is that even for the lowest number of tested sensors of 14

units, the maximum uncontrolled time the leak remained for was eight seconds.

Unfortunately this method of testing only verifies the performance of the system during 24 selected points

out of 86400 instants of simulation with the possibility of failure happening in 88 different locations. It is

therefore a reductive approach that has an academic interest, but will not be expanded as such. We will explore

the analysis of all failures in the following chapter.

3.2.8. Overall performance test

In order to overcome the shortcomings of point leak testing we decided to ignore leaks but test all volume

elements’ failures, in which failures are considered any volume element with tsc exceeding the allowed five

seconds at each second of simulation. This means that a volume element unattended for 20 seconds will present

15 failures, or 15 seconds in which tsc is over the allowed value of 5 seconds.

We determined that for a day long simulation with 88 volume elements to be controlled we have:

86400 𝑠 × 88 = 7603200 (25)

This means 7603200 points to control during a day, i.e. as many possible failures.

We then performed a failure testing of all sensors for 24 h in the case of the 11 m pipeline geometry. In

figure 27, we can observe a homogenous progression of failure reduction as the number of sensors increases,

with approximately 1.2 % of failures happening with 20 or half the required sensors and 0.09 % of failures

occurring when 30 sensors are used, i.e. the best possible program result.

Figure 27: Percentage of volume elements without failure vs. number of sensors for 24h control of 11 m pipe.

98.8%

99.0%

99.2%

99.4%

99.6%

99.8%

100.0%

0 10 20 30 40 50

Co

ntr

olle

d p

erc

en

tage

Number of sensors

69

3.3. Pressure Station

This chapter will define the minimum amount of required sensors as determined by the created software for

various heuristics, while testing its redundancy with a failure based approach for the pressure station equipment

case.


The equipment to be controlled in this case is a compact pressure station used in gas compression. It

consists of a 1.8 meter high control unit with a 3 meter high cylindrical storage and a compressor coupled to an

engine as can be seen in figure 28.

Figure 28: Schematic of a pressure station. (WIKA 2015)

Due to the unusual shape and the software’s restriction of only being able to work with cubes, we

performed a cubical approximation to the model presented in figure 28. The control unit is extended to 2 meter

height and the space between it and the storage tank is considered obstructed for drone movement. The same

process is applied to the space between the storage and the pipe leading from it to the compressor. Furthermore

the engine exhaust generates a 3 meter high obstacle divided in three one cubic meter volume elements. The

ensuing shape of equipment occupied volume recognizable by the software is represented in figure 29.

70

Figure 29: Cubical volume occupation representation of the pressure station with units in meters.

The proposed shape for the pressure station generates a distinctive one volume element layer pattern than

can be observed in figure 30 as horizontal sections of the system. White squares represent control volumes in

which the drones can freely move, while greyed out squares represent occupied space or volumes further than

the one layer limit and are hence volume elements forbidden to drone movement.

Figure 30: Horizontal cross sections of the volume elements to be controlled (pressure station).

When adding up all free volumes as seen in figure 30, the number of total volumes to be controlled is 77

volume elements. According to the analytical loop configuration, the optimal sensor amount is a 6th

of 77, which

is 13 when rounded up.


As the analytical value for the system given by the loop configuration is 13, we can determine that the best

possible program result will be 26 sensors.

71

Since for the case of the 11 m pipe, heuristic 4 and 5 performed poorly, we ran the software with the three

first heuristics only. Likewise, as the value increase past 6000 s was inconsequent for comparison, but added

additional real time simulation, we decided to perform simulations with a maximum of 6000 s of simulation time

and compare the ensuing results presented in figures 31 through 33.

Figure 31: Sensor number needed vs. simulation time for non-random allocation pressure station control (H1).


0

5

10

15

20

25

30

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

0

5

10

15

20

25

30

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

72


The minimum sensors needed for each method can be viewed in table 10.

Table 10: Minimum sensors required for designed pressure station control with 3 heuristics for 6000 s.

Method

Analytical

loop

configuration

Best possible

program

result

Heuristic 1 Heuristic 2 Heuristic 3

Max.

sensors 13 26 27 26 27

Table 10 shows that for the pressure station configuration, the second heuristic is sufficient enough to

match the best possible program value, while heuristic 1 and 3 present very close results as well.

3.4. Distillation column

The following chapter describes all distillation column related simulations and ensuing results.


The dimensions chosen for the distillation column are equivalent to a cylinder with 10 m height and 2m of

diameter. The ensuing geometry for the control volume, shaped by a 1 m layer of volume elements around it,

forms a box with the dimensions 4x4x11 m, in which the column is creating an occupied volume of 2x2x10 m.

Since the column is resting on the ground, there is no possibility for the sensors to move under it and the final

shape of the control volume resembles a cubical bell cover encapsulating the distillation column, with a total

control volume composed of 136 volume elements as described by equation 26.

𝑣𝑜𝑙𝑢𝑚𝑒 𝑒𝑙𝑒𝑚𝑒𝑛𝑡𝑠𝑑𝑖𝑠𝑡 𝑐𝑜𝑙𝑢𝑚𝑛 = 4 × 4 × 11 − 2 × 2 × 10 (26)

0

5

10

15

20

25

30

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

73

The minimum amount of sensors needed according to the loop configurations is still a sixth of 136, or

approximately 22.7, which needs to be rounded up to 23 needed sensors. The ensuing best possible program

result is then 46 sensors.


Once more, we will ignore the fourth and fifth heuristic and only perform simulations with the three first as

the 11 m pipe case showed poor heuristic 4 and 5 performances. Similarly, we set the maximum of 6000 s of

simulation time and compared solely the ensuing results presented in figures 34 through 36.

Figure 34: Sensor number needed vs. simulation time, non-random allocation distillation column control (H1).


0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

74


The minimum sensors needed for each method can be viewed in table 11.

Table 11: Minimum sensors required for designed distillation column control with 3 heuristics for 6000 s.

Method

Analytical

loop

configuration

Best possible

program

result

Heuristic 1 Heuristic 2 Heuristic 3

Max.

sensors 23 46 51 53 51

Table 11 indicates a poor performance of the software for the distillation column control as all heuristics

provide a sensor minimum higher than the best possible program result.

3.5. Redundancy

In the following chapter we discuss the eventuality of failures and the ensuing redundancy requirements.

We also expose the limitations and positive redundant behaviours of the previously explained methods.

3.5.1. Introduction and definitions

Let us imagine the following scenario. One or multiple sensors stop functioning properly, but without

showing any signals of it. We can imagine the clogging of the sensor orifice in which the electronic equipment is

still intact and responds to operator tests as should, but where there is no physical possibility for the gases to

reach the sensor, therefore passing undetected in the event of a leak. Any other problem can lead to such a

malfunctioning and it is hence pertinent to test the sensor system for redundancy.

0

10

20

30

40

50

60

0 1000 2000 3000 4000 5000 6000 7000

Nu

mb

er

of

sen

sors

Simulation time

75

As explained in 3.2.8. a failure is considered each instant in which a tsc value of any non-occupied volume

is above the allowed value of 5 seconds. This means that a single volume unattended for twenty seconds will

present 15 failures as its tsc will be in the allowed range for the five first seconds but will then present a failure

each following second. The total amount of failures possible for a system composed of multiple volumes will be

the sum of each volume element’s failures. For example, a system of two volumes left unattended for twenty

seconds would present 30 total failures.

For testing purposes we will consider the sensor failure to happen before any testing begins, this means that

if we are testing a system with one faulty sensor, this sensor will be defective from the start even if we are

referring to the sensor “failing”.

With this knowledge, in the case of one sensor failing in the analytical loop configuration we will have six

failures multiplied by the simulation time minus the five initial seconds. This result is independent of the

geometry and is the same for the small and the big loop configuration. What is different between both

configurations is that the maximum tsc, obtained in the small loop configuration during the testing time, is equal

to the simulation time and this, for all six volume elements involved. This happens because in the small loop

configuration, redundancy is not present. Each sensor or drone controls its own sector with no interference of

other sensors.

On the other hand, in the big loop configuration, there is redundancy, as each sensor follows the other and

hence passes through the volume elements that have recently been controlled. Therefore, in this case, the

maximum obtained tsc is equal to 11 seconds, but every volume element present in the big loop will reach that

value as the faulty sensor progresses along the loop. This implies a propagation of the fault along the entire

system; whilst in the small loop configuration, only a section of the system becomes uncontrolled, but will also

never be controlled again.

3.5.2. 11 m pipeline

When using 40 sensors in the 11 m pipeline simulation with heuristic 1, for a simulation time of 600 s with

one defective sensor, we obtain varying total failure counts depending on the faulty sensor’s id as presented in

figure 37.

We can see from figure 37, that the higher the id of the sensor, the less failures it will induce if it becomes

faulty. Also, the maximum of failures induced by the worst case scenario is 595 failures, which is the equivalent

of leaving one volume element uncontrolled for the duration of the test. This value is approximately six times

less than the failures presented by the analytical loop configuration, which in this case is 3595.

76

Figure 37: Failures vs. defective sensor id for the 11 m pipeline test.

3.5.3. Pressure station

Figure 38 presents all failures for each individually defective sensor under heuristic 1. It is to be noted that

sensor number one, if defective, will not induce any failure at all during the testing time. It is most likely bound

in an optimal redundancy pattern. In other words, all volumes it controls are controlled once more by other

sensors before 5 seconds have passed. For the other sensors one can see a similar trend as for the 11 m pipeline

in which the higher the sensor id, the lower the failures.

Figure 38: Failures vs. defective sensor id for the pressure station test.

The maximum failure amount of 378 occurs with the malfunction of sensor 2 and is about 11 times lower

than the 3595 loop configuration failures.

0

100

200

300

400

500

600

700

0 10 20 30 40

Failu

res

Sensor id

0

50

100

150

200

250

300

350

400

0 5 10 15 20 25 30

Failu

res

Sensor id

77

3.5.4. Distillation column

The pattern observed in figure 39 is similar to the pattern of figure 37; the higher the sensor id, the lower

the failures. Sensors below id 10 present failure amounts above 200 and all other sensors are below or close to

the 200 failures mark.

Figure 39: Failures vs. defective sensor id for the Distillation column test.

The maximum failure value of 554 occurs when the sensor with id equal to 1 is faulty. This failure value of

554 is still six and a half times less than the 3595 failures obtained with the loop configuration.

3.5.5. Comparison

In table 12 we can see that redundancy is much more performant when using heuristic one then the

analytical loop configuration. We can also see that the pressure station performs much better than the other

geometries.

Table 12: Analytical loop configuration failures vs. maximum heuristic 1 failures for all equipment

Equipment 11 m pipe Pressure station Distillation column

Loop configuration

failures 3595 3595 3595

Maximum failures 595 378 554

0

100

200

300

400

500

600

0 10 20 30 40 50 60

Failu

res

Sensor id

78

4. Conclusions

This chapter will expose all the conclusions ensuing from the various simulations and test performed during

this thesis.

4.1. Analytical Loop configuration

According to the loop configurations, one sensor can cover six volumes at all times. This means that for

any given total volume, the total occupation percentage will be of one sixth or approximately 17 %.

Both the big and the small loop configurations offer the same level of efficiency but with different

outcomes in the event of sensor failure. While the small loop configuration keeps the failure localized, the big

loop configuration propagates the error through the entire system but with the added advantage of redundancy

and the regular control of the volumes screened by the faulty sensor. In fact it is better to detect a leak 11

seconds too late then to never detect it in the faulty sector and hope the gas diffuses to adjacent sensors.

A sensible approach to this problem would be to adopt both solutions partially and to apply varied length

loop configurations. For instance, one can create loops that involve two sensors controlling 12 volume elements.

This way, if one sensor fails it keeps the failure localized to only those volume elements and has a maximum tsc

time of 11 seconds, whit a periodic control of the volume elements by the second healthy sensor.

Any mixture of configurations can be applied to the operator’s discretion. If an area has less risk of a leak

and or less danger is involved in the event of a leak, then maybe a small loop configuration in that area is

enough. Instead, if an area is particularly risky, then a big loop configuration is to be envisioned. Even the

addition of extra sensors should be considered for added redundancy and decrease of maximum tsc obtained in

the event of a failure; i.e. by having two or more sensors in a 6 volume element loop.

Other considerations that we didn’t directly approach in our work should be taken into consideration as

well. For example, if the sensors require a regular return to a charging station, then a big loop configuration is

more viable as the station can be at or near the starting point of the big loop. Alternatively, if the drones are cable

powered and have limited range, then a small loop configuration is the only possible option due to the drone’s

ensuing limited range. Again, a mixture of multiple approaches is the best course of action as each configuration

has negative and positive aspects which the other configurations counterbalance.

4.2. Empty cubical volume

The empty cubical volume tests showed that for lower simulation times and smaller volumes, favourable

configurations can appear that are not stable over the long run. Therefore any simulations to be performed on

small volumes require high simulation times to ensure system stability, while much bigger volumes don’t need to

be simulated for as long to provide a good value of sensors required.

79

Also, since the analytical loop configuration offers ~17 % of total occupation, as seen in sub chapter 4.1,

the software with heuristic 1 used for empty cubical volumes is not efficient at all, as it offers results always

superior than 50 %. In this particular case, other more efficient options should be pursued.

Finally, according to the best possible program solution discussed in chapter 2.6.5., the best result given by

the software should have been two times the result given by the analytical loop configuration, i.e. ~34 %. The

obtained results are closer to three times the analytical loop configuration, which can be explained by the fact,

that, bigger volumes allow for more unbalanced geometrical configurations. This means that situations, in which

sensors end up choosing a path that will end up boxing them in, have a higher probability of occurring. This is

why the minimum required sensor amount is high.

4.3. Eleven meter pipeline

For heuristic 1 using random allocation we get a result of 38.58 % maximum coverage. This result is quite

close to the best possible program result of 34 %. The analytical loop configuration result being 15 sensors, a

sixth of the total 88 control volume elements existing, the random heuristic 1 result of 40 is different than the 30

best possible program solution. The most likely explanation for the discrepancy is the increased amount of

unfavourable drone configurations, which increases as the symmetry of the system raises. In fact, the 11 m pipe

geometry is very symmetric with multiple axes of symmetry.

The differences between the various heuristics applied to the non-random allocation tests are subtle. For

instance, the maxima of heuristic 2 is the same as for heuristic 1, leading to the conclusion that blocked sensors

are a rare occurrence when using heuristic 1 or their effect on the global performance is non-existent.

Heuristic 3 shows a very small improvement of one sensor, most likely due to the fact that by having some

multiple maxima resolved by previous sensors, the totality of sensors are working slightly better together to

obtain better results. Unlike the other heuristics where sensors are selfish and only act upon their greedy

requirements, heuristic 3 allows other sensors which are not in an ambiguous situation to move, which in turn

nullifies the first sensor’s multiple choice.

Heuristic 4 is less efficient than all the others, most likely due to the fact that by allowing movement only

after 3 seconds have passed, most volumes will be too far into the process of dead-zone and sensors will have

trouble catching up with the volumes that require verification. Therefore, trying to increase the average tsc

between passes artificially with the process described in heuristic 4 is not a viable option.

Heuristic 5 is even worse than heuristic 4, as removing diagonal movement, in an attempt to mimic the more

linear path configurations, only removes degrees of freedom to the sensors choice. It is only normal that we see

an early progression towards high numbers of minimum sensors required, data which led us to quickly abandon

further research with this heuristic.

80

4.4. Pressure station

The given best possible program result for the pressure station is 26 sensors. In the simulations performed

with heuristics 1 and 3 we obtained 27 sensors and for heuristic 2 we matched the analytical result. The

heuristics used being the same as in the 11 m pipe geometry and the distillation column; there are a few

explanations as for why these results are better than the previous ones.

In fact, the 11 m pipeline contains 11 volume elements more than the pressure station geometry and the

distillation column 59 more, which could hint at the scale having an adverse effect, but considering that from the

small loop containing 6 volume elements to the 77 volume element pressure station the results stayed coherent

and that the much bigger distillation column geometry performed similarly than the 11 m pipeline, it is unlikely

to assume that there is a size threshold at which the software diverges from the best possible program result.

The most likely explanation lies in the intricate geometry of the pressure station control volume as opposed

to the pipeline and distillation column. The more asymmetric geometry of the pressure station lowers the chances

of encountering equivalent tsc maxima from which to choose from and hence reduces the possibility for

unfavourable drone patterns. Therefore the path of the drones becomes more cyclic and less random, improving

the results.

This discovery can suggest that for highly intricate geometries, with little room for equivalent choices, our

software is likely to perform well. Further studies in that area should be considered for future research.

4.5. Distillation Column

The distillation column presents a geometry which is similar to the 11 m pipeline but instead of an infinite

cylinder surrounded by a layer of control volume elements it can be controlled on the top, creating a closed

section on one end. The column is also larger than the pipeline, creating a higher ratio between volume elements

in the plane versus edge volume elements than in the 11 m pipeline geometry. To be noted is the fact that edge

volume elements have more non-occupied neighbor volume element to choose from, than surface volume

elements.

The outcome of the three heuristics showed an average coverage of 37.5 % and 39 % respectively. The loop

configuration occupation average remains 34 %. Therefore the software is not a good tool for geometries

resembling the tested distillation column as once more it is a highly symmetric geometry with many possibilities

for disadvantageous drone configurations to arise.

4.6. Redundancy

For all three geometries, the results of sensor failure testing showed a trend of lower failures for defect

sensors with higher id, with the exception of sensor 1 in the pressure station geometry. The difference between

81

sensors with different id’s lies in their order of insertion into the system. A low id means an early incorporation

into the system and vice versa.

As early sensors are added because big areas of the control volume fail, the late added sensors are

introduced to compensate small tsc overflow situations instead, which occur due to unfavorable drone movement

patterns. Hence, a small id sensor has a larger control zone that is attributed to it, while higher id sensors’

purpose is to fill in on rare occasions when the low id sensors fail.

We can therefore outline a flock of primary and secondary drones. Primary drones, or low id sensors, have

a lower redundancy than secondary drones, or high id sensors. In figure 30 one can see very well the inflection

point that separates primary from secondary drones.

In the analytical loop configuration, only primary drones exist which perform at maximum efficiency.

Hence a sensor fault always induces the high 3595 amount of system failures. Through the failure testing, we can

conclude that the lower the efficiency of a sensor, i.e. the lower the tsc value of the volume elements it starts to

control, the higher the redundancy and the lower the system failures in the event of a defect on those specific

sensors.

The pattern of the failure graphs from figure 37 to 39 give a good indication on how the software performs

for that specific geometry. The 11 m pipeline presents an even share of primary and secondary sensors, but its

required sensor count is approximately 33 % higher than the best possible program result.

When observing the results for the pressure station test we can see a pattern almost identical to the

secondary sensors of the 11 m pipeline. This implies that the pressure station geometry consists almost solely of

secondary sensors, which in turn implies a higher redundancy for the system than if it had mainly primary

sensors. And yet, the high redundancy doesn’t inhibit the system to require only the amount of sensors predicted

by the best possible program result. Therefore, the software application with heuristic 2 is a success for this

specific geometry.

In the case of the distillation column, we have an in-between situation of both previous tests. The system

possesses very little primary sensors and mainly secondary sensors. The required sensors being 51 with a best

possible program result of 23, the result only requires approximately an extra 11 % of sensors, which is

relatively close, and hence explains why the distillation column geometry generates mainly secondary sensors

with a few primary sensors.

In conclusion, when successfully adapting to the geometry, the software will generate only secondary

sensors with higher redundancy and at the same time provide a closer result to the best possible program result.

Figure 37 can therefore be used as a pattern benchmark for future tests of different geometries. If the results

resemble the low sensor id range then the application of the software to that geometry is not recommended, but if

the outcome resembles the high sensor id range, then the software is performing at its best.

82

Nevertheless, results should only be implemented into practice at the operator’s discretion as more factors

than only redundancy and software adequateness should be taken into consideration, more so when considering

that the software is only one solution to the redundancy optimization problem.

4.7. Final conclusions

The premise of drones becoming a viable complement to gas controlling techniques showed to be justified

for a hypothetic future, due to the continuous improvements made in all areas of drone technology: autonomy,

range, payload, price, dimensions and connection security.

Regarding the sensor’s sensitivity substitute models developed in chapter 2.6., we determined that the

simplification of an instantaneous detection of hydrogen inside a one cubic meter volume surrounding the sensor

is a valid approximation in both the cubical and spherical approach.

We verified the possibility of dead-zones and the ensuing allowed dead-zone time for the designed leak and

hydrogen gas was determined to be 6.1 seconds. We restricted the time to 5 seconds for added security.

We found analytical solutions to the problem of mobile sensor minimization in the form of the small and

big loop configurations explained in chapter 2.6.3.

We successfully developed an agent based modeling software inspired in GRASP and SPO metaheuristic

techniques and obtained a range of poorly to well adapted solutions depending on the studied equipment

geometry.

More asymmetric equipment geometries showed to present less possible drone movement pattern variations

and presented therefore closer to the analytical results, while more symmetric equipment geometries performed

poorly due to increased possible permutations of drone movement resulting in higher negative outcome

probabilities.

4.8. Recommendations and further areas of study

Considering the actual state of drone technology, we do not currently recommend any implementation of

this thesis’ results into practice. We recommend waiting for drone technologies to improve in the areas pointed

out by this work before verifying the viability of mobile drone sensor control systems.

In the event of adequate drone technology, we advise any operator to consider pros and cons of the

installation to be controlled and to choose accordingly. If the equipment geometry is highly intricate and

possesses low symmetry, then we recommend the use of our software with heuristic 1 or 2. If the ensuing failure

patterns show low failure amounts for all sensors’ individual failures, then an implementation of the software as

83

is can be considered. Yet the amount of needed sensors can always be reduced if choosing any of the proposed

loop configurations.

It is possible to opt for a mixt small and big loop configuration with two sensors controlling 12 volume

elements and improve upon it by identifying high risk sections of the equipment geometry and adding extra

sensors in those high risk medium loops. Redundancy is then increased locally while still controlling all the

system for a close to minimum amount of required sensors.

The final choice remains at the operator’s discretion. We also point out that dead-zone times, leak geometry

as well as gas composition and hence LEL are parameters that can be modified to adapt the problem to each

operator’s case. If sensor quantity is still deemed too high, then the possibility of increasing the drones’

movement speed persists in accordance with the existing technological capabilities. This will reduce movement

times and allow for a control of more volume elements in a reduced time frame.

Further areas of investigation that we leave for additional study are many. The possibility to modify the

software’s metaheuristic and or sub heuristics exist. As well as studying any type of equipment geometry

imaginable.

The inclusion of diffusion and convection of the leak’s escaping gases can be considered, as well as the

rewriting of the MATLAB software in a more advanced language allowing for the solution of the unlimited

freedom movement system of equations.

Finally, testing high volumes with high simulation times for all in this work exposed geometries, as well as

performing equipment cost optimization analyses, are still possible fields of study.

In the end, the possibilities for expansion on this pioneer work on drone based mobile gas sensor system are

plentiful and only limited by the researcher’s imagination.

84

References

American Gas Association (2014). [www document]. [Accessed 15 September 2014].

http://www.aga.org/KC/ABOUTNATURALGAS/CONSUMERINFO/Pages/NGDeliverySystem.aspx

AR.Drone (2012). [www document]. [Accessed 13 June 2014]. http://ardrone2.parrot.com/ardrone-

2/specifications/

Burke E. K. & Kendall G. Search Methodologies Introductory, Tutorials in Optimization and Decision Support

Techniques, 2014.

DJI Store (2014). [www document]. [Accessed 13 June 2014]. https://store.dji.com/buy/phantom-2-vision-plus-

with-extra-battery

DJI (2014)a. [www document]. [Accessed 13 June 2014]. http://www.dji.com/product/spreading-wings-

s1000/feature

DJI (2014)b. [www document]. [Accessed 13 June 2014]. http://www.dji.com/product/spreading-wings-

s1000/spec

DJI Youtube (2014). [www document]. [Accessed 13 June 2014].

https://www.youtube.com/watch?v=VhDAILW9UAE

Glover F. & Laguna M. Tabu search. 1997.

Goldengorin B. & Jäger G. (2005) How to Make a Greedy Heuristic for the Asymmetric Traveling Salesman

Problem Competitive

Katta G. M. (2003) Optimization Models For Decision Making. University of Michigan, Ann Arbor.

Kukkola J. (2013) Gas sensors based on nanostructured tungsten oxides. University of Oulu. Oulu. Acta

Universitatis Oulensis C 462.

KVS Vakuum- und Lecksuchtechnik (2014). [www document]. [Accessed 16 September 2014].

http://www.leakdetection-technology.com/science/the-flow-of-gases-in-leaks

Lukszo Z., Nikolic I., van Dam K. (2013) Agent-Based Modelling of Socio-Technical Systems, volume 9,

Springer.

85

Zuckerberg M. (2014). [www document]. [Accessed 8 September 2014].

https://www.facebook.com/zuck/posts/10101322049893211

Matheson Gas (2014). [www document]. [Accessed 19 September 2014].

http://www.mathesongas.com/pdfs/products/Lower-(LEL)-&-Upper-(UEL)-Explosive-Limits-.pdf

Mathworks Inc. (2014). [www document]. [Accessed 18 July 2014].

http://www.mathworks.se/help/matlab/matlab_prog/calling-object-methods.html

Murvay P., Silea I. (2012). A survey on gas leak detection and localization techniques. Preprint version of the

article accepted in Journal of Loss Prevention in the Process Industries.

Parrot SA (2013). [www document]. [Accessed 13 June 2014]. http://ardrone2.parrot.com/

Parrot SA (2014). [www document]. [Accessed 13 June 2014]. http://www.parrot.com/usa/products/bebop-

drone/

Parrot Shop (2014)a. [www document]. [Accessed 13 June 2014].

http://www.parrotshopping.com/pt/p_parrot_listing.aspx?f=3377

Parrot Shop (2014)b. [www document]. [Accessed 13 June 2014].

http://www.parrotshopping.com/fi/p_parrot_listing.aspx?f=3377

Parrot Shop (2014)c. [www document]. [Accessed 13 June 2014].

http://www.parrotshopping.com/uk/p_parrot_product.aspx?i=250846

Parrot Shop (2014)d. [www document]. [Accessed 13 June 2014].


Parrot Shop (2014)e. [www document]. [Accessed 13 June 2014].


Parrot Blog (2014). [www document]. [Accessed 13 June 2014]. http://blog.parrot.com/2014/01/07/parrot-

minidrone/

PNGRB (2009). [www document]. [Accessed 16 September 2014]. http://www.pngrb.gov.in/GSR808(E).pdf.

Ren & Pearton, Semiconductor Device-Based Sensors for Gas, Chemical, and Biomedical Applications, 2011.

86

Rolling Spider (2014). [www document]. [Accessed 29 November 2014].

http://www.parrot.com/usa/products/rolling-spider/

Bocquet P., Gougis L., Science & Vie, N°1160, p54-68., March 2014.

Sletfjerding, E. (1999) Friction Factor in Smooth and Rough Gas Pipelines. Dissertation for the Partial

Fulfillment of the Requirements for the Degree of Doktor Ingeniør. Tronheim, Norwegian University of Science

and Technology, Department of Petroleum Engineering and Applied Geophysics.

Technetics Group (2015), [www document]. [Accessed 28 September 2015].

http://www.technetics.com/bin/leak_rates.pdf

WIKA (2015). [www document]. [Accessed 01 June 2015]. http://www.wika.us/an_1911_en_us.wika

Wolfram, equation 17 (2014). [www document]. [Accessed 23 September 2014].

http://mathworld.wolfram.com/Sphere-SphereIntersection.html

Zuckerberg M. (2014). [www document]. [Accessed 8 September 2014].

https://www.facebook.com/zuck/posts/10101322049893211

87

List of Appendices

Appendix I: First successful code: Multiple runs, 60 s stabilization time for empty cubic volume…...........p.89-92

Appendix II: Real time of simulations for 60 s empty room simulations of higher volumes……………...…...p.93

88

Appendix I

First successful software code: Multiple runs with stabilization time of 60 s on empty cubic volume

clear all

simulacao=1;

results=zeros(25,1);

while simulacao<=25;

hold all

%cycle generating volumes

ssa=6; %volume size

ssb=6;

ssc=6;

sensor=1;%input('input number of drones/sensors desired (positve value)');

v=vol.empty((2*ssa+1)*(2*ssb+1)*(2*ssc+1),0);

d=sens.empty(sensor,0);

ssa=ssa+1; %adds the extra layer of impermeable volumes

ssb=ssb+1;

ssc=ssc+1;

h=-ssc;

c=1;

%volume generation

while(h<=ssc)

i=-ssb;

while(i<=ssb)

j=-ssa;

while(j<=ssa)

v(c).id=c;

v(c).x=j;

v(c).y=i;

v(c).z=h;

%setting vols as impermeable if the edge of volume

if(h==-ssc)

v(c).occ=true;

end

if(h==ssc)

v(c).occ=true;

end

if(i==-ssb)

v(c).occ=true;

end

if(i==ssb)

v(c).occ=true;

end

if(j==-ssc)

v(c).occ=true;

end

if(j==ssc)

v(c).occ=true;

end

j=j+1;

c=c+1;

end

i=i+1;

end

h=h+1;

end

success=false;

while success==false

t=0;

89

stop=false;

%setting timers back to 0/is left out, increases simulation time and

%sensors don't chose a longest time since checked as efficiently.

%ti=1;

%while ti<=(2*ssa+1)*(2*ssb+1)*(2*ssc+1)

%v(ti).tsc=0;

%ti=ti+1;

%end

while stop==false

%cycle generating sensors and allocating them randomly

k=1;

while(k<=sensor)

d(k).id=k;

while(d(k).all==false)

if(rand(1)>=0.5)

l=round(rand(1)*(s-1));

else

l=round(rand(1)*(1-s));

end

if(rand(1)>=0.5)

m=round(rand(1)*(s-1));

else

m=round(rand(1)*(1-s));

end

if(rand(1)>=0.5)

n=round(rand(1)*(s-1));

else

n=round(rand(1)*(1-s));

end

if(v(s+1+l+(s+m)*(2*s+1)+(s+n)*(2*s+1)^2).occ==false)

if(v(s+1+l+(s+m)*(2*s+1)+(s+n)*(2*s+1)^2).sp==false)

d(k).x=l;

d(k).y=m;

d(k).z=n;

v(s+1+l+(s+m)*(2*s+1)+(s+n)*(2*s+1)^2).sp=true;

d(k).all=true;

end

end

end

k=k+1;

end

%runs cycle for chosing heading and targets the volume as well as

%generates the waiting list if space is occupied

hi=1;

volid=0;

while hi<=sensor

l=d(hi).x;

m=d(hi).y;

n=d(hi).z;

counter=0;

oa=-1; while oa<=1 ob=-1; while ob<=1 oc=-1; while oc<=1

if (v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).occ==false)

if (v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).sp==false)

if (v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).tar==false)

if (v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).tsc>counter)

90

counter=v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).tsc;

ab=v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).x;

ac=v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).y;

ad=v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).z;

volid=v(ssa+1+l+oa+(ssb+m+ob)*(2*ssa+1)+(ssc+n+oc)*(2*ssa+1)*(2*ssb+1)).id;

end

end end end oc=oc+1; end ob=ob+1; end oa=oa+1; end if(counter==0)

d(hi).hx=d(hi).x;

d(hi).hy=d(hi).y;

d(hi).hz=d(hi).z;

else

v(volid).tar=true;

d(hi).hx=ab;

d(hi).hy=ac;

d(hi).hz=ad;

end

hi=hi+1;

end

%cycle setting all sensors coordinates as their heading,

%also removing and allocating sensor presence to the corresponding volumes

mov=1;

while mov<=sensor

v(ssa+1+d(mov).x+(ssb+d(mov).y)*(2*ssa+1)+(ssc+d(mov).z)*(2*ssa+1)*(2*ssb+1)).sp=false;

d(mov).x=d(mov).hx;

d(mov).y=d(mov).hy;

d(mov).z=d(mov).hz;

v(ssa+1+d(mov).x+(ssb+d(mov).y)*(2*ssa+1)+(ssc+d(mov).z)*(2*ssa+1)*(2*ssb+1)).sp=true;

v(ssa+1+d(mov).x+(ssb+d(mov).y)*(2*ssa+1)+(ssc+d(mov).z)*(2*ssa+1)*(2*ssb+1)).tar=false;

v(ssa+1+d(mov).x+(ssb+d(mov).y)*(2*ssa+1)+(ssc+d(mov).z)*(2*ssa+1)*(2*ssb+1)).sid=mov;

mov=mov+1;

end

%cycle to reset volume timers or add 1 sec depending on sensor presence

ti=1;

while ti<=( 2*ssa+1)*(2*ssb+1)*(2*ssc+1)

if(v(ti).occ==false)

if(v(ti).sp==true)

v(ti).tsc=0;

else

v(ti).tsc=v(ti).tsc+1;

end

end

ti=ti+1;

end

t=t+1;

%verifying that all volumes are under tsc=5

fof=1;

if t>5

while fof<=( 2*ssa+1)*(2*ssb+1)*(2*ssc+1)

if(v(fof).occ==false)

if(v(fof).tsc>5)

sensor=sensor+1;

91

stop=true;

break

end

end

fof=fof+1;

if(fof==( 2*ssa+1)*(2*ssb+1)*(2*ssc+1)+1)

%Limit of how long the system must be stable

if t>=60

sensor

success=true;

stop=true;

break

else

break

end

end

end

end

end

end

results(simulacao,1)=sensor;

simulacao=simulacao+1;

end

92

Appendix II

Real time of simulations for 60 s empty room simulations of higher volumes

Volume in m3

2197 3375 4913 6859 9261 12167 15625 19683

Number of simulations performed 25 20 7 5 5 5 5 1

Time for each simulation 18 m 35 m 1 h 15 2 h 3 h 30 6 h 13 h 20 h

Total time 7 h 30 11 h 40 8 h 45 10 h 17 h 30 1 d 6 h 2 d 17 h 20 h

Documents

Design of Mobile Gas Sensor Systems for Industrial Processes · Design of Mobile Gas Sensor Systems for Industrial Processes David Simões da Silva Thesis to obtain the Master of