Annals of Operations Research

https://doi.org/10.1007/s10479-020-03754-x

S.I. : DESIGN AND MANAGEMENT OF HUMANITARIAN SUPPLY

CHAINS

Wireless sensor network for AI‑based flood disaster detection

Jamal Al Qundus1 · Kosai Dabbour2 · Shivam Gupta3 · Régis Meissonier4 ·

Adrian Paschke1

© Springer Science+Business Media, LLC, part of Springer Nature 2020

Abstract
In recent decades, floods have led to massive destruction of human life and material. Time
is of the essence for evacuation, which in turn is determined by early warning systems.
This study proposes a wireless sensor network decision model for the detection of flood
disasters by observing changes in weather conditions compared to historical information
at a given location. To this end, we collected data such as air pressure, wind speed, water
level, temperature and humidity (DH11), and precipitation (0/1) from sensors located at
several points in the area under consideration and obtained sea level air pressure and rain-
fall from the Google API. The collected data was then transmitted via a LoRaWAN net-
work implemented in Raspberry-Pi and Arduino. The developed support vector machine
(SVM) model includes a number of coordinators responsible for a number of sectors (loca-
tions). The SVM model sends the binary decisions (flood or no flood) with an accuracy
of 98% to a cloud server connected to monitoring rooms, where a decision can be made
regarding the response to a possible flood disaster.

* Régis Meissonier
[email protected]
Jamal Al Qundus
[email protected]
Kosai Dabbour
[email protected]
Shivam Gupta
shivam.gupta@neoma‑bs.fr
Adrian Paschke
[email protected]
1
Data Analytic Center (DANA), Fraunhofer Institute for Open Communication Systems (FOKUS),
Kaiserin‑Augusta‑Allee 31, 10589 Berlin, Germany
2
EVA Electronics Co., Al Muthanna St, Hawally, Kuwait
3
Department of Information Systems, Supply Chain and Decision Making, NEOMA Business
School, 59 Rue Pierre Taittinger, 51100 Reims, France
4
IAE Montpellier, Montpellier Research in Management, University of Montpellier, Place Eugène
Bataillon, 34000 Montpellier, France

13
Vol.:(0123456789)
 Annals of Operations Research

1 Introduction

Worldwide, floods are the most frequent and costly of all natural disasters (Mousa et al.
2016). Between 1980 and 2014, natural disasters caused 21,700 loss events worldwide,
36% of which were caused by floods, with approximately 226,200 fatalities (excluding
famine) and total losses of US$ 4200 billion, 40% of which was caused by floods (Munich
2015). In 2016, 2017, and 2018, the share of floods and mass movements increased to 50%,
47%, and 45%, respectively (Munich 2019). In developing countries, floods lead to massive
losses of life and goods. To monitor floods, the most vulnerable areas are identified so that
the authorities can prepare suitable solutions for them. To give people enough time to evac-
uate themselves and their property, the most effective solution is to warn them as early as
possible before the damage occurs. There are a variety of early warning systems, but they
cannot be generalized due to different requirements, costs, and reliability. Various factors
(e.g. technology, society, and politics) pose problems for such systems in developed coun-
tries and are real obstacles in developing countries. Furthermore, due to climate change
and the development of urban areas with less emphasis on sufficient systems for drain-
age and evacuation of rainwater, floods in many parts of the world usually have dramatic
human and material consequences. Even in places where a great deal has been invested,
such disasters happen again and again. In these places, where heavy rain is uncommon and
that are therefore seasonally dry, even relatively little rain seems to cause disasters.
In December 2018, heavy rainfall and continued flooding in northern Syria destroyed
2214 tents inhabited by 2329 households. In January 2019, severe storms and flooding in
Lebanon affected 70,000 refugees, as reported by the Qatar Red Crescent Society on 31
December 2018 (OCHA 2018) and the Norwegian Refugee Council (NRC) on 10 Janu-
ary 2019 (Yamin 2019). Heavy rainfall and flooding claimed at least 12 lives in Jordan in
November 2018 and forced the authorities to evacuate more than 3500 tourists from the
ancient city of Petra and other tourist destinations. Flash floods from the country’s worst
natural disaster in decades in mid-October of the same year killed 21 people, most of them
children, on a school trip to the Dead Sea region (Al Jazeera 2018).
As mentioned above, the authorities need systems to prevent disaster consequences, and
with today’s state-of-the-art technology in particular, this should be easily feasible. For-
tunately, there are many approaches to such systems that work well in general. However,
there is no universal alarm system for all regions of the world, nor can there be, because a
disaster can only be measured by its possible consequences. Depending on the infrastruc-
ture, geographical location, historical data, etc., certain levels of rainfall in a certain region
can cause floods with fatal consequences, while in other regions this can lead to less seri-
ous consequences or even none at all. As already mentioned, rainfall in December 2018
was comparable to the rainfall in Syria, Jordan and Lebanon (OCHA 2018). Although parts
of Jordan are much lower, for example, 420 meters below sea level, than large parts of
Syria and Lebanon, such rains led to flooding in Syria, but not in Jordan or Lebanon.
One possible solution is to adopt the treatment style used to treat common colds. Cer-
tain medications are available to treat the common symptoms of a cold, but for each cold,
the patient must be re-examined to identify the virus and receive the correct medication.
Like viruses, disasters can occur in many ways. It therefore makes sense to develop suit-
able alarm systems for affected regions. Even if it is possible to have an alarm system with
99% accuracy, several alarm systems should be installed in vulnerable areas, as the damage
to human lives and infrastructure can be irreversible. As the risk is very great, the best pro-
tection is to have multiple level of protections.

13
Annals of Operations Research

For the reasons given above, there is not much competition in this field of research.
Although we should apply the best approach, in this field of research we must proceed
according to the principle of regional coverage, i.e. the first priority is to equip regions
with little or no disaster alarm systems with such systems. Good disaster alert systems
in certain regions should be improved. Perhaps someone will eventually find a general
formula that is not dependent on the region, but unfortunately this is not yet the case.
Until then, this field remains open for further research and development.
According to Sinha et al. (2019), disaster management planning depends heavily on
the topology, climate conditions, habitat, etc. of the area as well as available machinery
resources (Sinha et al. 2019). Duhamel et al. (2016) proposed the heuristics of opera-
tional research and management science to optimize the resilience of relief operations,
taking into account the impact of the distribution of relief resources to the population
(Duhamel et al. 2016). Wang et al. (2016) advocated combining proactive response
methods and logistical expertise for effective relief efforts. Logistical planning includes
decisions concerning supply sources and amounts of deliveries (Wang et al. 2016;
Dubey et al. 2015). Shareef et al. (2019) conducted a disaster management survey that
outlined several interrelated reasons that may prevent proper forecasting, procurement,
storage, identification of affected persons, and distribution. Such factors serve to iden-
tify actual needs during a disaster to reduce damage to people and other living things as
well as natural resources (Shareef et al. 2019; Dubey et al. 2017b).
Wireless sensor networks (WSN) are widely used for data acquisition and transmis-
sion as well as application control, monitoring, and fields such as supply chain manage-
ment (SCM) (Mousa et al. 2016; Dubey et al. 2018; Mousa and Claudel 2014; Dubey
and Gunasekaran 2016; Suryadevara and Mukhopadhyay 2012; Dubey et al. 2017a, b;
Manopiniwes and Irohara 2017). WSNs are a technology that consists of interactions
between a reasonable, power-saving group of sensors and microcontrollers that could
offer ubiquitous computing (Poslad 2011) to discover the environment and process the
collected data wirelessly on a central remote server (Gangopadhyay and Mondal 2016).
In natural disaster scenarios, WSNs are becoming essential tools for providing effective
early warning systems. Dersingh (2016) developed a flood warning system that offers a
web application. Flood information is generated by collecting environmental data with
the help of sensors via the GSM/3G mobile phone network and sent to smartphones and
PCs in the form of push notifications to users in the area affected by flooding (Dersingh
2016). WSNs are mainly used in this context to capture environmental parameters such
as temperature data, humidity, precipitation, etc. over a long period of time. In this way,
environmental phenomena such as climate change can be analyzed in relation to the pre-
diction or occurrence of disaster events (Maspo et al. 2018).
In this paper, we present a flood alarm system that we developed and applied in
Kuwait. Kuwait has no such alarm system, or at least not in the places we installed it.
In addition, the Kuwaiti climate is a desert climate; even though the cities have good
infrastructure, sometimes rain is sufficient to cause flooding. The system we developed
takes various measurements, makes predictive calculations, and provides a probability
of flooding in the form of a statement (flood or no flood). The responsible authorities
use this information to take appropriate actions.
The idea of multiple, independent terminals was developed based on the concept of
WSN with the Radio Frequency model for Long Range communication LoRaWAN. A
point-to-point communication protocol was developed to simulate the case in which sev-
eral LoRaWAN-based terminals (Endpoints) communicate with one LoRaWAN-based

13
 Annals of Operations Research

coordinator station. Several coordinator stations were also implemented to cover as

many areas and sectors as possible.
Support vector machine (SVM) models are often used to predict various events inlcud-
ing credit risks (Al Qundus 2016; Doumpos and Zopounidis 2007; Al Qundus et al. 2019),
sports (Edelman 2007), disasters such as wildfire (Yang et al. 2019) or earthquakes (Singh
et al. 2019), methane production in wastewater (Kusiak and Wei 2014), etc. SVM models
are used to process collected data and to make predictions (Al Qundus et al. 2020). Com-
pared to most other learning techniques, SVM models lead to increased performance in
pattern recognition, regression estimation, etc. SVM models produce a binary classifier,
i.e. the Optimal Classifier. They construct a linear model to estimate the decision function
using non-linear class boundaries based on support vectors (Evangelopoulos et al. 2012;
Shin et al. 2005; Al Qundus and Paschke 2018).
The rest of this paper is structured as follows: it begins with a brief overview of the
“Related work” section (Sect. 2). In the “Research materials” section (Sect. 3) we illustrate
the third-party hardware used, i.e. Raspberry Pi, and a few sensors and software programs,
i.e. LoRaWAN. The “Research methods” section (Sect. 4) describes the approach in greater
detail, e.g. building of WSN based on LoRaWAN, Endpoints including sensors, and the
Arduino receiver. The results are given in the “Results and discussion” section (Sect. 5),
and finally, our “Limitations and the future scope of research” are presented in Sect. 6.

2 Related works

Flood warning systems are popular and in demand (He and Zhuang 2016; Rodríguez-
Espíndola et al. 2018; Wex et al. 2014). Several previous studies have investigated such
systems and their development, which are also being followed closely by governments,
industries, and academics. The design and methods used are basically comparable, but dif-
fer in terms of the areas of application, which can be broken down1 as follows: indoors,
i.e. in closed locations (home, factory, etc.) and outdoors, i.e. in public areas (river, desert,
city, etc.) (Kunz et al. 2014; Müller et al. 2016; Chatterjee et al. 2018). Depending on these
fields of application, the warning systems differ in terms of the technology used, the com-
munication medium and the form of the results. The technology used and the communica-
tion medium depend on the challenges (accuracy of the forecast, duration of data trans-
port, interference/noise, number of endpoints, etc.) that the application area imposes on
the warning system. The desired type of user interaction influences the form of the warn-
ing system results. For indoor applications, little attention is paid to the energy consump-
tion of the hardware, data loss due to long distances between the transmitter and receiver,
the amount of data to be transported and other environmental factors (sun, wind, etc.) that
may affect communication. On the other hand, outdoor warning systems consider data cor-
rection procedures, energy-efficient hardware, and efficient data transport when they are
implemented.
Teixidó et al. (2018) presented an early acoustic warning system against water leaks in a
Smart Home. Optimized for cost, installation and maintenance, the system provides a soft-
ware application that remotely measures water levels, fluid type, sensor battery, and general

1
Other breakdowns can be made based on region and geographical structure, but this would be too granu-
lar.

13
Annals of Operations Research

network information. The structure consists of a control center (gateway or control center)
for the coordination and processing of data in the wireless (IEEE 802.15.4 technology)
network and five flood sensors with integrated radio modules that can communicate over
the Internet or 2G/3G/4G via the control center and are therefore accessible via an external
network. In a similar context and as part of the development of the Internet of Things (IoT)
with a focus on flood forecasting and early warning systems, Maspo et al. (2018) examined
the performance of the Internet of Things (IoT) in disaster control applications. The authors
propose an IoT technology that uses wireless sensor networks (WSNs), cameras, mobile
phones, and weather stations as key components for collecting water level and water flow
data. The weather station records temperature, wind speed, and direction. Cameras capture
images of environmental information. Wifi and Zigbee are used in the network layer to
transmit the collected data to the middleware layer for data processing and analysis. The
middleware then performs data management functions, such as processing the collected
data and analyzing the flood event in the cloud service, to present key information such as
flood extent, time and location in the form of a flood map. Users can access information
from their smartphone and receive push notifications when an emergency occurs. Although
the approaches of the two publications above are interesting because they follow a concept
similar to ours, these approaches work in a limited environment and cannot be applied, as
claimed, to larger areas such as cities. In the event of a disaster, the probability of a power
outage is high, and the probability of an Internet outage is very high. Using them as a
power source or for data transmission is therefore not the best choice.
Hughes et al. (2006) described a flood-predicting sensor network with Gumstix sensor
nodes. The tested system consisted of 13 nodes along 1 km of the river. Similar to Basha
et al. (2008), who presented an architecture for predictive environmental sensor networks
over large geographical areas, the focus was on the flood event of a river, and the sensor
network solution consisted of two communication levels, four node types, and a variety of
sensor types. They described a flood prediction algorithm that was experimentally tested
with radio antenna towers to demonstrate system functionality. The use of the sensor net-
work is relevant for our work, even if the prediction model is not obvious. The communi-
cation and data exchanges between the nodes is particularly interesting. Nevertheless, the
subject of investigation (a river) differs here, and the delivered and measured values are in
the form of continuous values instead of binary values (flood, no flood).
Chen et al. (2018) used the availability of large amounts of data in smart cities to effec-
tively predict urban flood disasters. They developed a novel decision support system for
flood protection (NFDDSS) based on historical hydrological data. The focus was on the
temporal and spatial correlation of the water level prediction model based on a classifica-
tion and regression tree. The authors claim that water levels can be effectively predicted in
1–6 h. Due to the strong dependence of this approach on the availability of historical and
large sets of data in smart cities, this approach achieves its best accuracy only when flood-
ing has already occurred. Therefore, new regions under consideration may not be equipped
with this approach to effectively predict flood catastrophes.

3 Research materials

In this work, we used a number of third-party hardware systems, i.e. Raspberry Pi, and
a few sensors as well as software programs, i.e. LoRaWAN that we will explain in this
section.

13
 Annals of Operations Research

Fig. 1  Arduino Uno R3 Front (Source: https​://www.ardui​no.cc/en/uploa​ds/Main/Ardui​noUno​_R3_Front​

.jpg)

Fig. 2  Arduino Uno R3 Back (Source: https​://www.ardui​no.cc/en/uploa​ds/Main/Ardui​noUno​_R3_Front​

.jpg)

Arduino Uno R3 hardware comprises an open hardware design that allows it to build
or modify. Several third-party manufacturers have developed shields (add-on boards) to
extend the basic functionality of Arduino, such as wireless communication, speed sen-
sors, 3-axis accelerometers, etc. Arduino hardware is designed to be a complete, flexible,
and easy-to-use device. The hardware is illustrated in Figs. 1 and 2. In addition, numer-
ous hardware variants based on the Arduino concept have been launched. The software is
implemented with a standard programming language and firmware that runs on the board.

13
Annals of Operations Research

Fig. 3  Raspberry Pi 3 Model B (Source: https​://www.allie​delec​.com/m/d/4252b​1ecd9​2888d​bb9d8​a39b5​

36e7b​f2.pdf)

The software is then compiled and loaded on-board. Arduino boards are also compatible
with Flash, Processing, MaxMSP and MATLAB, and a few lines of code are often enough
to provide quite a powerful performance (D’Ausilio 2012).
Raspberry Pi 3 Model B, as shown in Fig. 3, was used to control several Arduino inte-
grated devices with a series of sensors. According to Imteaj et al. (2017), it can smoothly
and efficiently process a large amount of Arduino data with sensors and is able to pro-
cess the data received between the Arduino devices via the LoRaWAN network for further
actions. The Raspberry Pi 3 acts as a client and is both a micro-controller and a CPU that
includes a 1.2 GHz 64-bit quad-core ARMv8 Cortex A53 CPU along with 1 GB RAM of
900 MHz, 4 USB ports, 1 HDMI port, 1 audio I/O port, and 1 Ethernet port, including 40
GPIO pins that can be configured as a digital input or output. The Raspberry Pi 3 board has
a built-in radio module that includes both 802.11n wireless LAN and Bluetooth 4.1 (Imteaj
et al. 2017). Data is received serially from the Arduino devices and sent to the cloud-server.
We chose the Raspberry Pi because of its high compatibility with LoRaWAN, which is
described below.
The LoRa Shield is a long-range transceiver with an Arduino shield form factor and
is based on an open source library. Figure 4 illustrates the LoRa Shield that allows the
user to send data and achieve extremely long ranges (up to 12 km) at low data rates. The
LoRa Shield handles low-level communication and low-level network access (registration,
authorization, etc.). It forwards data traffic to the Arduino device, by which the data traffic
can be sent to the network via the Arduino interface (Brindha et al. 2019).
LoRa and LoRaWAN Gateway: According to Wixted et al. (2016) and Khutsoane et al.
(2017), the LoRa Wireless for LPWAN (Low-Power Wide Area) uses Chirp Spread Spec-
trum (CSS) modulation, which is primarily implemented in a characteristic low-power,
wide-range communications infrastructure commercialized via CSS. CSS has been used
by military and space agencies in long-range communications because it is resistant to

13
 Annals of Operations Research

Fig. 4  LoRa shield showing the pin mapping for LoRa (Source: https​://wiki.dragi​no.com/index​.php?title​
=File:LoRa_Shiel​d_Pin_Mappi​ng.png)

Table 1  Shows a brief comparison of LoRaWAN vs 2G/3G

Techno. Data rate (kbit) Range Power Frequency (MHz) Requirements
consumption
(mA)

LoRaWAN <1 200 m to 20 km 20 868, 433 or 915 Router

2G/3G > 10 < 35 km 2000 900 SIM card

interference. It provides options for various Spreading Factors (SF) and bandwidths to
adapt modulation to range and data requirements. It provides a low-power, long-range
wireless technology platform that uses unlicensed radio spectra in the industrial, scientific,
and medical (ISM) band. LoRa uses ISM bands of 433 MHz, 868 MHz (EU) or 915 MHz
(USA), depending on legislation, whereby the band is divided into channels. Table 1 shows
the comparison of LoRaWAN communications with 2G/3G (Internet) communications.
The combination of SF and bandwidth affects the speed for the range. LoRa aims to elimi-
nate repeaters, reduce device costs, extend device battery life, improve network capacity,
and support a large number of devices. It is a physical layer that is used for communication
over long distances. To achieve low frequency, most wireless technologies use FSK (Fre-
quency Shift Key) modulation.
LoRa Alliance developed LoRaWAN as a media access control layer protocol for man-
agement and wireless communication between LPWAN gateways and endpoint devices
over kilometers. Arduino offers the necessary gateway and uses Raspberry Pi for further
processing such as forwarding data. The gateway contains a receiver concentrator that can
decode 10 simultaneous transmissions and deal with at least 1000 nodes at the same time.
With its long ranges at low transmission power and thus a long battery life, LoRaWAN

13
Annals of Operations Research

influences the lifetime of other factors such as node battery, network capacity, etc. that
serve the network (Khutsoane et al. 2017; Wixted et al. 2016).
MATLAB Simulink is widely used and is suitable for Model-Based Designs from which
complex hardware-related code can be generated in order to test prototypes in real time and
then deploy the code in an embedded system.
In terms of hardware communication, our proposed hardware and circuit-based solution
is divided into two main terminals: the sender terminal and the receiver terminal. In the
sender terminal, we use an Arduino Uno R3 microcontroller and included LoRa Shield,
Water Level Sen, DHT11 Temperature and Humidity Sensor and Wind Speed Sensor
components. In the receiver terminal, we use an Arduino Uno R3 with Raspberry Pi and
included the LoRa Shield and USB Serial Port components for communication between
Arduino and Raspberry Pi. No other hardware connections are implemented on the receiver
side.
The data collection and sending processes on the sender terminal consist of several
phases:

1. Water level sensor calibration process A simple averaging process was implemented to
determine the absolute zero (origin measurement) of the sensor readings. The water level
sensor produces readings between (0v–5v) and scaled to the numerical range (0–1023)
due to manufacturing inconsistency, as not all sensors give approximately the same read-
ing on the same water level. A calibration process is therefore essential to harmonize
the readings across all of the measurement stations. One thousand readings were taken
from sensors with no water effect and the average of the readings was calculated and
considered as the absolute zero of the water level sensors.
2. Wind speed sensor calibration process the same process was also applied to the wind
sensor for the same purposes and the average readings were calculated and considered
as absolute zero of the sensor readings with no air or wind effect.
3. Importing the DHT11 sensor Library (DHT.h) the core of the DHT11 sensor is built
based on analog processing and signal generation, but in Arduino this sensor is consid-
ered to work as a digital sensor. The DHT.h library was then developed and implemented
by the manufacturer to support the sensor on Arduino boards. The sensor primarily
requires a BEGIN process in the setup configuration void function to start producing
readings on temperature and humidity. The temperature values are extracted through a
pre-defined library function and are in the range of − 5 to + 65 Celsius.
4. Initializing the LoRa module and its modulation procedure the LoRa module acts like
a radio frequency module so that data that need to be sent by this module must be
modulated over the communication channel. LoRa is supported by different types of
modulation functions, and in our proposed design, we have chosen the ASK modulation
function to modulate the sent data. The maximum data packet size that can be sent by
LoRa for the communication process is 128 Byte.
5. Initializing the Arduino serial and setup function The Arduino microcontroller requires
a very clear serial initialization and startup communication value between Arduino and
all of the connected and integrated components on the board. The built-in default setup
function has to be implemented, and within this function we started serial communica-
tion on 9600 bit/s, as this communication speed is the most suitable speed for all of the
previously mentioned sensors and modules, including LoRa.

The main logic process specification of the sender terminal can be found in Appendix 1.

13
 Annals of Operations Research

On the receiver terminal (Arduino side), data collection and receiving processes build
on the following phases:

1. Initializing the LoRa module and its demodulation procedure as mentioned previously,
the LoRa module acts like a radio frequency module so that the receiver side should
have the ability to demodulate the received data packet. The modulation function of the
receiver was implemented using the ASK function, and at the receiver end we also need
to demodulate the data using the same ASK demodulation function. Therefore, the ASK
library is included and prepared for the demodulation process.
2. Initializing the Arduino serial and setup function the Arduino microcontroller requires
a very clear serial initialization and startup communication value between Arduino and
all of the connected and integrated components on the board. The built-in default setup
function has to be implemented, and within this function we started the Serial commu-
nication on 9600 bit/s, as this communication speed is the most suitable speed with the
LoRa shield.

The main logic process specification of the receiver terminals can be found in Appendix
2.

4 Research methods

We built a wireless sensor network (WSNL) based on LoRaWAN to measure the rise in the
water level. WSNL follows the sender-receiver modulation function principle called Ask,
where the senders are Raspberry Pi with sensors (referred to as endpoints) and the receiver
is Arduino (referred to as the coordinator). We used 24 sensors and 6 coordinators located
in 6 sectors, and each endpoint and its coordinator are called a cluster.
Each Endpoint was considered as a single station, so the conditions and environmental
parameters of each station are completely independent of any other station. This means that
a calibration process based on statistical readings must be applied to each sensor. For ini-
tialization, 105 readings were taken from each sensor and the mean, variance, and standard
deviation values were calculated and applied. These initialization values were used to set a
threshold value for the sensor station and eliminate any extreme readings that could be read
by each sensor.
Each Endpoint then generates 5 readings from 5 sensors and replicates them for 1 min
in a period of 10 min and forms a data packet. The generated data packet is sent with the
LoRaWAN client module, where LoRa uses its own modulation function (ASK) to modu-
late and encode the data. The data is transmitted by LoRa via the RF channel with a fre-
quency of 933 MHz. After each Endpoint has sent its data packets to the LoRaWAN server
station, they are further processed on the LoRaWAN server station.
The LoRaWAN server coordinator performs demodulation and decoding to manage
the reception of the data packet from each Endpoint. Once the data has been received on
Arduino by LoRaWAN, Arduino establishes a serial connection with the Raspberry Pi
(RPI) via the serial port and sends the data to RPI. The Raspberry Pi executes Python
scripts to Google Weather API to request two additional values and adds them to the 5
Endpoint readings. These values are the atmospheric pressure at sea level and the rain-
fall value of the sector in which the current Endpoint is located. During communication
phases over the radio frequency channel and/or serial channel, some of the readings are

13
Annals of Operations Research

missed or corrupted, resulting in NULLs in the data set. These are corrected by apply-
ing data pre-processing and a Z-score model for normalization.
The limited number of sensors and thus the amount of data supplied did not allow
for prediction or pattern recognition, so we decided to increase the number of read-
ings from each sensor. Each Endpoint sends a package of readings during a period of
time. An Arduino can generate one impulse every 200 ms, so we defined the clock as
total-tick duration of 10 min, i.e. 60 s are 12 impulses that build the maximum tick
length before moving into the position for the next tick, etc. We take 7 readings in each
impulse in 1 min and consider them as one instance that then contains 5040 readings
and can be generated into one package. This package of instances is then transferred.
The calculation is as follows:

A PACKAGE = ONE CLOCK

A CLOCK = 10 MINUTES
AN INSTANCE = ONE MINUTE
A TICK = 12 IMPULSES
AN IMPULSE = 7 READINGS
AN IMPULSE = 200 MILLISECONDS
A TRANSFERRED PACKAGE = 10 INSTANCES (MINUTES) * TICK * NUM-
BER OF READINGS PER IMPULSE * 60 = 10 * 12 * 7 60 = 50,040 READINGS IN
EVERY PACKAGE OF EACH ENDPOINT.

4.1 Receiver (coordinator)

A LoRaWAN and a Raspberry Pi with 2 G RAM and flash of 128 are located at the
receiver side and form our Coordinator. The coordinator applies serial communication, i.e.
byte-by-byte relying on LoRaWAN that automatically performs the management process
of receiving the packages of each Endpoint. LoRaWAN performs the modulation at the
Endpoint, the demodulation or the signal at the Coordinator as well as error detection and
correction, e.g. an error such as changing the sine wave or sinusoidal such as flipping the
value of 15–15G due to noises in the air. LoRaWAN will correct this automatically as well.
In addition, the sine wave is a continuous wave that supports detection of missing values or
Endpoint failures.

4.2 Collected data

We collected data over the year 2018 (daily data) and calculated the average on each of
the sensor readings per day (12 readings of each sector, i.e. 12 × 6 sectors = 72 readings in
total). Based on this, the training dataset was created as illustrated in Fig. 5.
The dataset considered the six different sectors in the country and each sector’s reading
or average was considered as a completely individual instance in the training data set. The
collected sensor data were temperature, humidity, wind speed, and water level.
As previously mentioned, LoRaWAN conducts auto-correction where empty/error val-
ues are filled/corrected using Z-Score normalization. The Z-score represents the number
of standard deviations from the mean and is considered to be a measure that reflects the
number of values below or above the mean.

13
 Annals of Operations Research

Fig. 5  A subset of the normalized scaled collected data in 2018 of the sectors 1, 3 and 5

4.3 Data pre‑processing

Two pre-processing phases were applied and implemented on the data set before the
training model was started. The first was outlier detection and handling, for which we
used the Z-score method and for outlier replacement we used the Mean method. The
second was the features scaling and normalization process, where we applied data nor-
malization between 0–1 and data scaling around the standard deviation.

4.4 Model training

The model builds on the radial basis function (RBF) kernel in the support vector
machine (SVM) binary level implemented in MATLAB running on the Raspberry Pi.
The response of the model is binary, i.e. flood or no flood.
The processing phase was performed in several steps, dividing the data set experi-
mentally into training and testing sets, as described in Sect. 5. This experimental
approach is important to get as close as possible to real scenarios in which the model
is so stable that it can perform with good accuracy in its predictions despite fewer data.

5 Results and discussion

The use of SVM in this application appears to be very successful as a method for clas-
sifying data in relation to the number of data split into training and test data sets. It is
worth noting that the attempt to use normal regression or standard machine learning
methods on the same data did not produce a beneficial model, resulting in little or no
use for this purpose.
The experiment was started with 2000 instances as a data set, divided and marked
into 1640 instances as no flood and 560 instances as flood, generated from the wireless
sensor network. The results are presented and discussed below.

13
Annals of Operations Research

Table 2  Illustrates the applied ML models and their performance

ML model Training Testing accuracy Tolerance Training in s Prediction time (s)
accuracy

ANN (MLP) 0.87 0.72 1e−6 6278 Real time

Logistic regression 0.89 0.84 1e−5 4222 Real time
SVM binary 0.92 0.90 1e−3 1034 Real time
Decision tree 0.67 0.65 1e−3 7991 22–28 s

5.1 Classification models

Several models of machine learning were applied to the training dataset. Furthermore,
the results of the best SVM model were used to achieve the best prediction performance.
Table 2 below shows the models with the associated training and testing accuracies of each
ML model:
The SVM model offered the best accuracy in the training and testing phase. This can be
explained by the fact that SVM models usually work perfectly with data that have a large
number of correlated characteristics. To determine the best SVM parameters, the Grid
Search model (Viola et al. 2019) was applied to the binary SVM model to find and extract
the best parameters using various training test distribution criteria.
Various distribution criteria were used to evaluate the SVM classifier and extract the
model with the best parameters. For the best SVM parameters and tuning procedures, the
grid search model was used to estimate the best tuned SVM parameters. A kind of fused
process between data division and the tuning process was implemented to estimate the best
classifier with the highest classification rate and accuracy. The criteria and accuracy results
are listed in Table 3.
The grid search optimizer concluded that the best SVM parameters could be achieved
with the highest accuracy by the polynomial kernel-based SVM. The classification rate
could be higher if we could provide more realistic data. However, the challenge of data
collection is twofold: on the one hand, due to droughts in this region, not much data may
be available throughout the year. On the other hand, also due to drought, the data over the
years hardly differ and the seasonal weather conditions are stable over the years.

5.2 Feature analysis

Based on the available data set, which contains only four features (temperature, humidity,
wind speed, and water level), the water level value could be seen as an important indica-
tor as a tautological result. Water level is therefore not only significant for predicting flood
events, but also in connection with wind speed. In Table 4, it was found that the water level
feature was fully related to the predicted value.

5.3 Communication over the LoRa network

The maximum distance between the measuring stations and the central data acquisi-
tion and processing station was approximately 18 km. At this distance, the LoRa module

13
13
Table 3  Represents SVM model performance on different splitting criteria
Splitting criteria Training Testing accuracy Poly-degree Tolerance Kernel Max iterations Random state Training (s)
accuracy

80–20 0.78 0.76 None 1e−4 RBF 100 1 1759

70–30 0.98 0.96 8 1e−3 Poly 100 1 3176
60–40 0.91 0.88 4 1e−3 Poly 100 0 1011
50–50 0.92 0.90 5 1e−3 Poly 100 0 1882
Annals of Operations Research
 Table 4  shows the readings in terms of food or non-flood
Station-ID Normalized temperature Normalized humidity Normalized wind speed Normalized water level Flood

1 1.475064283 0.670349661 2.147435126 0.011146199 0

2 1.475064283 0.670349661 1.817558044 0.044584797 0
3 1.290681248 0.670349661 2.438503141 0.037153997 0
4 1.659447318 0.670349661 2.360885003 0.078023394 0
5 1.475064283 0.603314695 2.341480469 0 0
Annals of Operations Research

6 1.475064283 0.670349661 2.367353182 0.081738794 0

1 1.382872765 0.737384628 2.37382136 0.490432763 0
2 1.382872765 0.737384628 2.587271237 0.412409369 0
3 1.382872765 0.737384628 2.600207593 0.371539972 0
4 1.475064283 1.273664357 2.729571155 0.334385975 0
5 1.475064283 1.206629391 2.5096531 0.326955175 0
6 1.290681248 1.206629391 2.516121278 0.364109173 0
1 2.304787942 1.206629391 3.454007101 2.37785582 1
2 2.304787942 1.206629391 3.589838841 2.229239832 1
3 2.39697946 1.474769255 3.518688882 2.307263226 1
4 2.304787942 1.675874154 3.622179731 2.489317812 1
5 2.489170977 1.206629391 3.654520622 2.452163815 1
6 2.39697946 0.938489526 3.104725484 2.637933801 1
1 2.489170977 0.134069932 1.791685331 0.007430799 0
2 2.489170977 0.067034966 1.836962578 0.011146199 0
3 2.489170977 0.067034966 1.727003551 0.007430799 0
4 2.39697946 0.067034966 1.720535372 0.007430799 0
5 2.304787942 0.134069932 1.811089866 0.0037154 0
6 2.39697946 0.067034966 1.811089866 0.0037154 0
1 3.134511601 0.201104898 1.080185741 0 0

13
 Table 4  (continued)
Station-ID Normalized temperature Normalized humidity Normalized wind speed Normalized water level Flood

13
2 3.318894636 0.201104898 1.073717563 0 0
3 3.318894636 0.268139865 1.080185741 0 0
4 3.226703119 0.268139865 1.106058454 0 0
5 3.411086154 0.268139865 1.086653919 0 0
6 3.411086154 0.268139865 1.099590276 0 0
1 3.872043743 0.067034966 1.002567604 0 0
2 3.872043743 0.067034966 1.138399344 0 0
3 3.872043743 0.134069932 1.073717563 0 0
4 3.96423526 0.134069932 1.073717563 0 0
5 3.96423526 0.134069932 1.080185741 0.0037154 0
6 3.96423526 0.134069932 1.047844851 0.0037154 0
1 4.148618296 0.469244763 2.166839661 0 0
2 4.148618296 0.469244763 2.367353182 0 0
3 4.148618296 0.402209797 2.263862332 0 0
4 4.240809813 0.402209797 2.231521442 0 0
5 4.333001331 0.402209797 2.231521442 0 0
6 4.425192849 0.536279729 2.225053264 0 0
1 4.425192849 1.809944086 2.153903305 0 0
2 4.333001331 1.944014018 2.147435126 0 0
Annals of Operations Research
Annals of Operations Research

can operate and transmit data without interruptions or malfunctions. The frequency of
433 MHz at which the LoRa module was set to operate and the small data rate size pro-
vided the best communication method with virtually no data loss.

5.4 Conditions and SVM model

Recurrent extreme precipitation events in the dry Middle East can have destructive social
consequences. They often result from precipitation and drought interactions, with desert-
like land and infrastructure playing a key role. In this study, we developed a system for
predicting extreme precipitation events with WSN. WSN approaches have been used as
an important method for collecting distributed data at closed sites. However, their use in
remote collection sites has been less widespread. The limited range and risk of data loss
have prevented such applications, especially in critical applications. Our approach was car-
ried out in Kuwait, covered six sectors distributed across the country, and made it possible
to estimate precipitation to predict possible flooding.
The data set was generated with 2000 instances from the wireless sensor network and
considered as input for our classification model. The dataset contains 1640 instances
based on historical measurements referred to as “no flood” and 560 instances referred to
as “flood”. With this dataset, we performed various machine learning models in this study
and evaluated the accuracy of these models by comparing their classifiers with training
datasets as shown in Table 2. The SVM model provided the highest accuracy in the train-
ing and testing phase, which can be explained by the fact that SVM models usually work
perfectly with data that have a large number of correlated traits. This study evaluated SVM
parameters using the Grid Search model to improve the potential accuracy of classifiers,
as shown in Table 3. The Grid Search optimizer concluded that the best SVM parameters
with the highest accuracy of 98% can be achieved using the polynomial core based SVM
model. Four features (temperature, humidity, wind speed, and water level) were consid-
ered, as shown in Table 4. The most important indicators for predicting flood events were
water level and then wind speed.

5.5 Model validation

The implementation of many works is interesting and even efficient in this type of envi-
ronment (see Sect. 2). Nevertheless, they are of limited use in achieving a comprehensive
solution for disaster detection. This is because the coverage of a broad use case (e.g. a city)
may require the incorporation and interaction of different conditions (e.g. energy supply,
mobile connection, environmental factors, etc.).
Validation by comparison with another system is difficult, because there are no such
systems (at least at the time of this work) in the application area (Kuwait). Different data,
climate, geography, etc. prevent the comparison of the developed system with systems
from other areas.
However, to validate the effectiveness of the proposed model, four categories of
machine learning models (ANN (MLP), logistic regression, support vector machine binary
and decision tree) have been used to verify the predictive model, followed by various dis-
tribution options for the integrity of the data to improve the best model. The implemented
classifier achieved an accuracy of 98%, which is obviously an improvement over many
approaches, and perfect prediction is of course not yet possible.

13
 Annals of Operations Research

5.6 Discussion

In the following sub-sections, we consider the implications of our research findings regard-
ing our investigation of weather information with respect to a specific area and the devel-
opment of a WSN disaster decision model and its infrastructure for high-quality informa-
tion transport. Two aspects are discussed that explore practical and policy implications.

5.6.1 Practical implications

There are two key implications for managers. First, they can use this work to understand
how historical information and currently observed changes in weather conditions at a given
location can be used to create a WSN decision model. Each area has specific factors influ-
encing the weather at this area. Considering Kuwait as a representative for the region, this
work shows which information—historical and current—is appropriate when undertaking
disaster detection projects.
Secondly, it shows how a WSN decision model can be developed to improve communi-
cation, transport, and quality of data over long distances, especially under unusual condi-
tions caused by disasters. Managers can use the developed WSN infrastructure to deliver
the information regardless of environmental conditions such as internet, electricity, dis-
tance, etc.

5.6.2 Policy implications

Government agencies across the world are becoming more and more stringent with regards
to data storage and privacy laws. The European Commission’s General Data Protection
Regulation (GDPR), which has been in force since May 2018, is an example of this. The
GDPR is constantly being updated with new amendments, and wireless sensor network
design and manufacturing companies must comply with these laws. Although our work
was developed in a non-European country, our study complies with this new European data
protection regulation. The data we collect is not personal data and the information does not
concern individuals (see Table 4). We store data that is accessible to the public. Historical
weather information is accessible to everyone and the sensor data are readings that refer to
open areas and not to a person.

6 Limitations and future scope of research

Thresholds are relative values that are set based on the measurement history at a particular
location, so these thresholds may not apply at a different location and must be determined
each time the location is changed. As a result, our work cannot be used in any location, for
example, in places where there are no historical records of the required readings. Readings
can however be collected at such locations to determine the thresholds, though this can
take time.
In reality, there are no sharp boundaries or clear separations between locations, which
means that in the case of crossing or over-lapping locations (intersection) where End-
points are located, it is not possible to decide which reading to accept, especially if these

13
Annals of Operations Research

Endpoints also provide different readings. In such cases, the mean value is currently calcu-
lated from the measured values. Future work should cluster the locations or Endpoints in
order to achieve a clear separation of the measured values in relation to the locations.
We hope that this research will offer managers deeper insight into and a better under-
standing of the Kuwait region in terms of environmental data collection and transport. As
neighboring countries have similar land structures and weather conditions, our work can be
adapted with few adjustments.

Appendix 1

Main logic process: In the main loop function, we have called 6 customized functions:

• getHumidityValue(): this function uses the DHT.h library to extract and give the cur-
rent Humidity value in the range of (0–100%).
• getTemperatureValue(): this function also uses the DHT.h library to extract and give
the current temperature value.
• getWindSpeedValue(): This function reads the output on analog pin A1 where the wind
speed sensor is connected and returns the output voltage scaled in a range of (0–1023).
• getWaterLevelValue(): this function reads the output on analog pin A0 where the water
level sensor is connected and returns the output voltage scaled in a range of (0–1023).
• createDataPcket(): this function creates a struct where all of the readings are stored
inside the struct along with the station ID and returns this struct in the sending process.
• sendDataPacketUsingLoRa(): this function initializes the data packet and assigns the
struct payload to the LoRa packet and sends it over the RF channel modulated using
the ASK modulation function. We have to consider that the sending procedure using
any LoRa module requires exactly 3 s to finalize the sending of the entire packet over
the modulated channel, so the next reading will happen at least 3 s afterwards in order
to avoid any data overlapping or interference during the communication process with
the receiver. One more point that must also be considered during LoRa communication
is that the data is sent as a payload packet and not as a byte array because of the LoRa
communication protocol. This feature is considered as a positive point because on the
receiver side, in case of multiple senders, the probability of having multiple mixed and
interfering serial data is very high if the data is sent serially, but with the payload/API
mode, the receiver will accept each data packet individually and this data packet can
be parsed easily. The ID of the sender can also be extracted to determine what packet
belongs to what sender.

Appendix 2

Main logic process: In the main loop function, we have called 4 customized functions:

• receiveDataPacket(): this function is a kind of interruption process that runs while all other
functions in Arduino are processing and outputting. The main process here is to listen to
the RF port to see if any data packet has arrived and if a data packet has arrived, then a

13
 Annals of Operations Research

payload packet is defined and prepared to receive the incoming payload from the sender.
The packet will be demodulated and stored in the receiver payload automatically.
• parseReceivedDataPacket(): this function will parse the payload packet and mainly extract
the sender ID with all incoming readings and store them directly in a pre-defined struct to
prepare for serial communication with the RPI device.
• createSerialPacket(): once the data packet is parsed and stored in the custom struct, then
another data packet with a serial type (Bytes Converted) will be implemented. This means
that the incoming sender ID, humidity value, temperature value, wind speed value, and
water level value will be converted to a byte array and stored in a buffer to be sent to the
RPI.
• sendBytesArrayToRPI(): this function simply goes through the byte array byte by byte and
writes it directly on the serial port where the connection between Arduino and RPI hap-
pens.

On the receiver terminal (Raspberry Pi side), data collecting and receiving processes build
on the following phases:

• Initializing the Serial Port: on Raspberry Pi, serial data can be received in 2 different
modes: the first is to use UART (Rx, Tx) Pins on the GPIO PINOUT, and the second is
to use the USB port for serial communication. We chose the second way. The data comes
from Arduino over the USB port in a serial byte array mode, so this requires initializing
the RPI serial port using the following Python-developed functions:
• setSerialBaudRate(): this function sets communication speed with Arduino to 9600 bit/s
as defined by the Arduino receiver.
• setParityBitCheck(): this function applies the parity check OS function over any serial port
to check for any bit error during serial communication.
• setMaxBufferSize(): this function specifies the maximum size of the received byte array at
1 byte per CPU tick.

Receiving the data: once the serial port communication has been initialized and prepared
for receiving data, this process will accept the incoming bytes and store them in a list structure
in Python. Once the data packet array is completely received, then the list will be converted
back to string data and then to numerical data using the following functions:

• receiveSerialBuffer(): this function stores all incoming bytes in list structure until the data
packet is completely received.
• convertBufferToString(): this function converts the buffer array to string and passes it to
the numerical conversion function.
• convertStringDataToNumericalValues(): this function converts the string data to double
temperature value, double humidity value, integer wind speed value, integer water level
value, and finally integer station ID.
• storeDataInCSVFile(): all data is stored and saved in a CSV file for future classification
procedures and processes.

13
Annals of Operations Research

References
Al Jazeera. (2018). Jordan rains and floods kill 12, force tourists to Flee Petra. Aljazeera. 2018. https​
://www.aljaz​eera.com/news/2018/11/jorda​n-rains​-flood​s-kill-force​-touri​sts-flee-petra​-18111​00544​
04195​.html. Accessed 9 Sept 2019.
Al Qundus, J. (2016). Generating trust in collaborative annotation environments. In Proceedings of the
12th international symposium on open collaboration companion (Vol. 3). ACM.
Al Qundus, J., & Paschke, A. (2018). Investigating the effect of attributes on user trust in social media.
In International conference on database and expert systems applications (pp. 278–288). Springer.
Al Qundus, J., Paschke, A., Gupta, S., Alzouby, A. M., & Yousef, M. (2020). Exploring the impact of
short-text complexity and structure on its quality in social media. Journal of Enterprise Informa-
tion Management. https​://doi.org/10.1108/JEIM-06-2019-0156.
Al Qundus, J., Paschke, A., Kumar, S., & Gupta, S. (2019). Calculating trust in domain analysis: Theo-
retical trust model. International Journal of Information Management, 48, 1–11.
Basha, E. A., Ravela, S., & Rus, D. (2008). Model-based monitoring for early warning flood detection.
In Proceedings of the 6th ACM conference on embedded network sensor systems (pp. 295–308).
Brindha, S., Abirami, P., Srikanth, V. P., Aravind Raj, A., & Karthik Raja, K. (2019). Efficient water
management using LoRa in advance IoT. International Journal of Research in Engineering, Sci-
ence and Management, 2(3), 834–837.
Chatterjee, S., Byun, J., Dutta, K., Pedersen, R. U., Pottathil, A., & Xie, H. (2018). Designing an Inter-
net-of-Things (IoT) and sensor-based in-home monitoring system for assisting diabetes patients:
Iterative learning from two case studies. European Journal of Information Systems, 27(6), 670–685.
Chen, G., Yang, T., Huang, R., & Zhu, Z. (2018). A novel flood defense decision support system for
smart urban management based on classification and regression tree. International Journal of Secu-
rity and Networks, 13(4), 245–251.
D’Ausilio, A. (2012). Arduino: A low-cost multipurpose lab equipment. Behavior Research Methods,
44(2), 305–313.
Dersingh, A. (2016). Design and development of a flood warning system via mobile and computer net-
works. In 2016 international conference on electronics, information, and communications (ICEIC)
(pp. 1–4). IEEE.
Doumpos, M., & Zopounidis, C. (2007). Model combination for credit risk assessment: A stacked gener-
alization approach. Annals of Operations Research, 151(1), 289–306.
Dubey, R., Altay, N., Gunasekaran, A., Blome, C., Papadopoulos, T., & Childe, S. J. (2018). Supply
chain agility, adaptability and alignment. International Journal of Operations & Production Man-
agement. https​://doi.org/10.1108/IJOPM​-04-2016-0173.
Dubey, R., & Gunasekaran, A. (2016). The sustainable humanitarian supply chain design: Agility, adapt-
ability and alignment. International Journal of Logistics Research and Applications, 19(1), 62–82.
Dubey, R., Gunasekaran, A., Childe, S. J., Papadopoulos, T., & Wamba, S. F. (2017a). World class sus-
tainable supply chain management: Critical review and further research directions. The Interna-
tional Journal of Logistics Management. https​://doi.org/10.1108/IJLM-07-2015-0112.
Dubey, R., Gunasekaran, A., Papadopoulos, T., Childe, S. J., Shibin, K. T., & Wamba, S. F. (2017b).
Sustainable supply chain management: Framework and further research directions. Journal of
Cleaner Production, 142, 1119–1130.
Dubey, R., Gunasekaran, A., Sushil, & Singh, T. (2015). Building theory of sustainable manufacturing
using total interpretive structural modelling. International Journal of Systems Science: Operations
& Logistics, 2(4), 231–247.
Duhamel, C., Santos, A. C., Brasil, D., Châtelet, E., & Birregah, B. (2016). Connecting a population
dynamic model with a multi-period location–allocation problem for post-disaster relief operations.
Annals of Operations Research, 247(2), 693–713.
Edelman, D. (2007). Adapting support vector machine methods for horserace odds prediction. Annals of
Operations Research, 151(1), 325.
Evangelopoulos, N., Zhang, X., & Prybutok, V. R. (2012). Latent semantic analysis: Five methodologi-
cal recommendations. European Journal of Information Systems, 21(1), 70–86.
Gangopadhyay, S., & Mondal, M. K. (2016). A wireless framework for environmental monitoring and
instant response alert. In 2016 international conference on microelectronics, computing and com-
munications (MicroCom) (pp. 1–6). IEEE.
He, F., & Zhuang, J. (2016). Balancing pre-disaster preparedness and post-disaster relief. European
Journal of Operational Research, 252(1), 246–256.

13
 Annals of Operations Research

Hughes, D., Greenwood, P., Blair, G., Coulson, G., Pappenberger, F., et al. (2006). An intelligent and
adaptable grid-based flood monitoring and warning system. In Proceedings of the UK EScience all
hands meeting (Vol. 10).
Imteaj, A., Rahman, T., Hossain, M. K., Alam, M. S., &Rahat, S. A. (2017). An IoT based fire alarming
and authentication system for workhouse using Raspberry Pi 3. In 2017 international conference on
electrical, computer and communication engineering (ECCE) (pp. 899–904). IEEE.
Khutsoane, O., Isong, B., & Abu-Mahfouz, A. M. (2017). IoT devices and applications based on LoRa/
LoRaWAN. In IECON 2017-43rd annual conference of the IEEE Industrial Electronics Society (pp.
6107–6012). IEEE.
Kunz, N., Reiner, G., & Gold, S. (2014). Investing in disaster management capabilities versus pre-posi-
tioning inventory: A new approach to disaster preparedness. International Journal of Production
Economics, 157, 261–272.
Kusiak, A., & Wei, X. (2014). Prediction of methane production in wastewater treatment facility: A
data-mining approach. Annals of Operations Research, 216(1), 71–81.
Manopiniwes, W., & Irohara, T. (2017). Stochastic optimisation model for integrated decisions on relief
supply chains: Preparedness for disaster response. International Journal of Production Research,
55(4), 979–996.
Maspo, N., Harun, A. N., Goto, M., Nawi, M. N. M., & Haron, N. A. (2018). Development of Internet of
Thing (IoT) technology for flood prediction and early warning system (EWS). International Jour-
nal of Innovative Technology and Exploring Engineering (IJITEE), 8(4S), 219–228.
Mousa, M., & Claudel, C. (2014). Energy parameter estimation in solar powered wireless sensor net-
works. In K. Langendoen, et al. (Eds.), Real-world wireless sensor networks (pp. 217–229). Berlin:
Springer.
Mousa, M., Zhang, X., & Claudel, C. (2016). Flash flood detection in urban cities using ultrasonic and
infrared sensors. IEEE Sensors Journal, 16(19), 7204–7216.
Müller, O., Junglas, I., vom Brocke, J., & Debortoli, S. (2016). Utilizing Big Data analytics for infor-
mation systems research: Challenges, promises and guidelines. European Journal of Information
Systems, 25(4), 289–302.
Munich, R. E. (2015). Schadenereignisse Weltweit 1980–2014. NatCatSERVICE. 2015. https​://www.
preve​ntion​web.net/files​/44281​_19802​014pa​ketwe​ltusd​d4zu3​.pdf. Accessed 9 Sept 2019.
Munich, R. E. (2019). Geo risks research. NatCatSERVICE. 2019. https​://www.iii.org/graph​-archi​
ve/21806​9. Accessed 9 Sept 2019.
OCHA. (2018). Middle East: Floods and Cold Wave - Dec 2018’. ReliefWeb. 2018. https​://relie​fweb.int/
disas​ter/st-2019-00000​2-lbn. Accessed 9 Sept 2019.
Poslad, S. (2011). Ubiquitous computing: Smart devices, environments and interactions. Hoboken:
Wiley.
Rodríguez-Espíndola, O., Albores, P., & Brewster, C. (2018). Disaster preparedness in humanitarian
logistics: A collaborative approach for resource management in floods. European Journal of Oper-
ational Research, 264(3), 978–993.
Shareef, M. A., Dwivedi, Y. K., Mahmud, R., Wright, A., Rahman, M. M., Kizgin, H., et al. (2019). Dis-
aster management in Bangladesh: Developing an effective emergency supply chain network. Annals
of Operations Research, 283(1), 1463–1487.
Shin, K.-S., Lee, T. S., & Kim, H.-j. (2005). An application of support vector machines in Bankruptcy
prediction model. Expert Systems with Applications, 28(1), 127–135.
Singh, J. P., Dwivedi, Y. K., Rana, N. P., Kumar, A., & Kapoor, K. K. (2019). Event classification and
location prediction from tweets during disasters. Annals of Operations Research, 283(1), 737–757.
Sinha, A., Kumar, P., Rana, N. P., Islam, R., & Dwivedi, Y. K. (2019). Impact of Internet of Things
(IoT) in disaster management: A task-technology fit perspective. Annals of Operations Research,
283(1–2), 759–794.
Suryadevara, N. K., & Mukhopadhyay, S. C. (2012). Wireless sensor network based home monitoring
system for wellness determination of elderly. IEEE Sensors Journal, 12(6), 1965–1972.
Teixidó, P., Gómez-Galán, J. A., Gómez-Bravo, F., Sánchez-Rodríguez, T., Alcina, J., & Aponte, J.
(2018). Low-power low-cost wireless flood sensor for smart home systems. Sensors, 18(11), 3817.
Viola, M., Sangiovanni, M., Toraldo, G., & Guarracino, M. R. (2019). Semi-supervised generalized
eigenvalues classification. Annals of Operations Research, 276(1–2), 249–266.
Wang, X., Yunfei, W., Liang, L., & Huang, Z. (2016). Service outsourcing and disaster response meth-
ods in a relief supply chain. Annals of Operations Research, 240(2), 471–487.
Wex, F., Schryen, G., Feuerriegel, S., & Neumann, D. (2014). Emergency response in natural disas-
ter management: Allocation and scheduling of rescue units. European Journal of Operational
Research, 235(3), 697–708.

13
Annals of Operations Research

Wixted, A. J., Kinnaird, P., Larijani, H., Tait, A., Ahmadinia, A., & Strachan, N. (2016). Evaluation of
LoRa and LoRaWAN for wireless sensor networks. In 2016 IEEE Sensors (pp. 1–3). IEEE.
Yamin, A. (2019). 70,000 refugees at risk after heavy snow and floods—Lebanon. ReliefWeb. 2019. https​://
relie​fweb.int/repor​t/leban​on/70000​-refug​ees-risk-after​-heavy​-snow-and-flood​s. Accessed 9 Sept 2019.
Yang, Z., Guo, L., & Yang, Z. (2019). Emergency logistics for wildfire suppression based on forecasted dis-
aster evolution. Annals of Operations Research, 283(1), 917–937.

Publisher’s Note Springer Nature remains neutral with regard to jurisdictional claims in published maps and
institutional affiliations.

13