Abstract: The invention is an Alert Mechanism for rainfall induced disaster management with sensors, smartphones and IoT devices. In this invention participating machines recording continuous reading and analyze them within a fixed time interval. After finding an event, it issues alert to its neighboring machines. Mechanism generates alert by analyzing aggregated results obtained through various machines. An embodiment in invention provides an algorithm to classify and issue a alert message within the network. The invention utilizes IoT and networking applications in order to issue alert messages. Invention provides a method to minimize risk by issuing alert messages during rainfall induced disasters. The proposed work has steps as modeling of sensing data and design of a mechanism to issue alert.
DESCRIPTION
1. BRIEF DESCRIPTION OF THE DRAWINGS
• Figure I is a graphical representation to understand effect of day, weak and hour for
modeling of sensing data for Flood Alert.
• Figure 2 is a graphical representation to understand effect of day, weak and hour for
modeling of sensing data for Flood Alert.
• Figure3 represents a flowchart for landslide alert decision to design alert mechanism.
• Figure 4 represents a flowchart for flood alert decision to design alert mechanism.
• Figure 6 describes phases of Alert decision method.
• Figure 5 showing phases in the methodology for Alert decision.
2. DETAILED DESCRIPTION
4.1 Modeling of sensing data
Data modeling is performed on the basis of mean, median and mode of the data; collected.
Mean of number of events per interval is represented as A,, median of events per interval is
represented as d9 and mode of events is represented as 8. In this document, modeling of data
comprises only mean number of events per interval, however, median and mode might be
helpful to analyze the acquired data. Median is helpful to divide the data into two parts
while mode provides the point of maximum concentration.
4.1. (A) Modeling of sensing data for Flood Alert: Following notations have been used in
modeling,
• O(t) = Number of observations • S = Sensor,
in one hour interval,
• 0(x) = probability of happening , • Me= a transition probability matrix,
• Oo(t)=amount of observation, • Os(t) = Observation due to a sensor
• 0£ (^Observation of event, • X = mean number of events per
interval
• OF(0 ^amount of observations • X(t) = mean number of events per
due to Flood, interval(t)
• e = A mathematical constant
i.e. value ~ 2.718282
1
In the proposed methodology, the observatory data in sensor observations represented by
number of observations in one hour interval is denoted as O(t), for each sensor/ machine S.
After receiving first symptoms of events, researchers assumed that next signal will depend
on previous one. In this situation, process of data acquisition is just like a markov process.
>
Hence, assumptions are made according to the two state Markov chain, with normal sensor/
machine observation. Value of state 0(x)= 0 where in a danger, 0(T) S= 1 in case of higher
water level as shown by equation (1.1) and (1.2). Equation (2.0) assumed to work during
transition change. It is assumed that
0(T) = 0, if flood does not happen (1.0)
0(T) = 1, if flood happen (1.1)
From equation (1.1), and (1.2) the transition probability matrix can be derived as:
In equation (2.0), probability 0O assumed for 0(T) = 0; while 0X assumed when 0(x)=l.
Here, hidden variables are the amount of observation Oo(t) and the amount of observations
due to flood event Op(t). The definition of Os(t) for a sensor S is given by the summations ,
of hidden variables OQ(0 a n ^ Op(t) as shown in equation (3.0).
Os(t) = Os
0(t} + om (3-0)
When observation O, follows a poisson distribution with parameter ^(parameter of
distribution), it can be written as equation(4.0). The probability of observing O events in a
given interval is written as
P(<9)= e~x(X°/Ol) (4.0)
So on the basis of equation (4.0), It is assumed that number of observations are generated
through a heterogeneous poison distribution Po(<9, X(t)) with the rate value that is the
function of time X(t) as per equation (5.0), transition from 0 to 1 in observations are modeled
every hour.
Po(6U(t))= e-ACt)(A(t)°/0!) (5.0)
The normal observation pattern of a sensor S is increase in water level in a day (i) of the
weak 8? and the hour (j) of the day df§i and XQ represent average rate of sensing data for
sensor (S) in one week. The model is represented in figure 1.
2
n o(t)
Figure 1 : Functional flow to find effect of day, weak and average sensed data
We can formulate the rate of poison distribution Xs (t) as the product of the initial rateAo,
the daily effect 8*, and the hourly effects dfti. To formulate the models for event detection,
it is important to have data from different sensors of the suspected region of landslide.
4.1. (B) Modeling of sensing data for landslide Alert : Following notations have been used
in modeling,
• O(t) = Number of observations
in one hour interval,
• 0(x) = probability of happening ,
• Oo(t)=amount of observation,
• 0£ (t) Observation of event,
• S = Sensor
• M 0 = a transition probability
matrix,
• Os(t) = Observation due to a sensor
• Oo(t)=amount of observations due
to displacement
Just like section A(i) for flood, modeling of data for landslide is illustrated in this part. The
observatory data in sensor observations represented by number of observations in one hour
interval is denoted as O(t), for each sensor/ machine S. These assumptions are made
according to the two state Markov chain, with normal sensor/ machine observation. Value of
state 0(x)= 0 whereas in danger or soil movement value of state, 0(x) = 1 that is shown
by equation (6.0) and (6.1) . Equation (7.0) assumed to work during transition change. It is
assumed that
0(T) = 0, if slide does not happen (6.0)
0(x) = 1, if slide happen (6.1)
From equation (6.1), and (6.2) the transition probability matrix can be derived as:
"»= ( V° ?\) (7.0)
I
J
I
G) X 14- 2 0
In equation 7, probability 0O assumed for 0(x) = 0; while 0X assumed when 0(x)=l. Here,
hidden variables are the amount of observation Oo(t), and the amount of observations due
to displacement event Oo(t). The definition of Os(t) for a sensor S is given by the
summations of hidden variables OQ(0 an<^ ODOO a s shown in equation (8.0).
(?(t) = Os
Q(t) + Os
D(t) (8.0)
It is assumed that number of observations are generated through a heterogeneous poison
distribution . Po(<9, X(t)) with the rate value that is the function of time X(t) as per
equation (4), transition from 0 to 1 in observations are modeled for every hour.
Po(6>, X(t)) = e"A(t)( A(t)°/0!) (9.0)
The normal observation pattern of a sensor S is dependent event of displacement on day (i)
of the weak 6* and the hour (j) of the day dft and A£ represent average rate of sensing by
sensor (S) in one week. The model represented in figure 2.
Oft)
Figure 2 : Functional flow to And effect of day, weak and average sensed data
We can formulate the rate of poison distribution A5(t) as the product of the initial rateA^,
the daily effect 8?, and the hourly effects dft. To formulate the models for event detection,
it is important to have data from different sensors of the suspected region of landslide.
4.2 Design of Alert mechanism
Designing of an alert mechanism, just is a decision making problem. This document
comprises two kinds of decision selection, one for Landslide alert and second for flood
alert. However, this document uses approximate same flowchart for both decisions with
different conditions. Decision of disaster type just will depend on the outputs taken from
data model and on the threshold for both the cases respectively.
# - 2 0 1 7 • 1
4.2 (a) Landslide alert decision: Alert mechanism proposed in the work is a method to issue
alert for sensor/ IoTV wireless sensor network / or data capturing devices so that possible
victims can be informed in advance. After observing the sensor reading periodically,
flowchart in figure 3 shows the method to decide to issue alert.
Start
Sensor Reading
i
End
Figure 3 : Flowchart to send alert for landslide disaster
In this procedure, O(t) are the number of observations in one hour interval which is
assigned only binary values including 0 and 1. In this, the value 1 is assigned only for
value measured more than the level of danger while 0 is only when no danger situation
measured by sensor i.e. no event measured by sensor device. Here, Oo(t) assumed for
the amount of observations started due to displacement while it is assumed to be
studied, recorded and compared with displacement threshold D(Th). Analysis for
decision making is explained in detail in figure 5(a) and 5(b).
2-* 1 6
4.2 (b) Alert decision for Flood: Flood alert mechanism is similar to alert mechanism
proposed for landslide as shown in figure 4. This is also useful to issue alert from
sensor/ IoTV wireless sensor network / or data capturing devices. The plow chart
proposes in figure 4 imposes issue of alarm if water level increases than its threshold.
BZS3K "
A f t e r D e c i s i o n m a k i n g A n a l y s i s .
^ + ^
Figure 4 : Flowchart to issue alert message for flood disaster .
In this procedure, 0(t) is the number of observations in one hour interval which is
assigned only binary values is 0 or 1. O(t) will have value 1 only if value measured is
higher than the level of danger while 0 if no danger situation measured by sensor i.e. no
event measured by sensor device. Here, OF(X) is the amount of observations just after
water level reaches higher than normal. It is recorded and compared with water level
threshold Wi/Th) value. If <9(t) value is high then after analysis of recorded data alarm is
issued accordingly. Analysis for decision making is explained in detail in figure 5 and
figure 6.
6
HX 14-S&-2817 16 : 54
4.3 Analysis for decision making
Alert network works on the basis of readings taken by various machines deployed in the
network, at different locations. Figure 5 represents various phases to issue alert after data
acquisition from a machine after analysis on aggregated result, through mathematical
tool.
Phase 1 Phase 2 Phase 3 Phase 4
Conclusion
Drawn — •
Decision
making
Figure 5 : Methodology for Alert decision
The figure 5 is further elaborated in figure 6. Figure 6 includes WSN/ IoT/ or smartphone
as machine used to record events. All the machines continuously record data while
aggregates it within a fixed interval. These machines are allowed to record data as per
sensors integrated with them i.e. a machine can record a specific symptom or symptoms
common with other machines. For example a sensor may record displacement that is
common with other machines or only temperature depends on sensor type. In this
invention, this is assumed that machines deployed to sense temperature, water level,
displacement, slope and sound. These machines transmit data to network only after
finalizing its output based on data aggregation. With the help of concluded output of
these machines, monitoring station decides RID type and generate alert to provide alert
signal to the client machines.
4 - 0 8 - 2 . 0 1 7 16 : 34
Phase 1 Phase 2 Phase 3 Phase 4
t i
i i
Result
Machine (1)
Result
Machine (2)
Result
Machine (3)
Result
Machine (n-1)
Result
Machine (n)
Heavy water
No empty
reservoir
Slope
Displace
ment
Cloud
burst
Hill area
Plain
Failed waten
exit way
Decision
based
alert
Figure 6 : Description of phases of Alert decision method
On the basis of conclusion given by machines, possible disaster type will be decided and
warning message will be issued for mudslide, flash flood, flood, landslide and long term
flood. And in the last of the process network will send the message for possible victims
of that particular disaster.
4.4 Alert Broadcasting
With the help of the following algorithm an application can be designed for the
smartphones to issue alert. The algorithm is based on observatory results from monitoring
stations. It takes input as type of rainfall induced disaster (RID) from Rainfall Induced
Disaster Classification Algorithm (RIDCA) and produces the type of alert to be displayed
on device like smartphone, smart watch or laptop.
Input:
Output:
Measured data value for flood.
Alert decision about disaster.
8
LHI 1 2817 1
4.4(a) Alert Selection Algorithm
If (p(flood) >= p( noflood))
{
Alert (flood);
If (flood 1)
Normal flood
else if (flood 2)
flood with heavy water
elseif (flood 3)
flood with heavy water due to Cloud burst
elseif (flood 4)
Flash flood
elseif (flood 5)
Long duration flood
}
If (p(landslide)) >= ( p(nolandslide));
. {
Alert (landslide);
}
Note: Here, P(flood ) is the probability of flood whereas P(noflood ) is the probability of
normal water level. Simultaneously, P(landslide) is the probability of landslide whereas
P(nolandslide) is the probability of not a landslide event.
4.4(b): Rainfall Induced Disaster classification Algorithm (RIDCA)
RIDCA plays an important role in this invention this algorithm is applicable to installed
on powerful machine such as monitoring station. After receiving information from
sensor node it provides output to the Alert selection algorithm on client machine.
Input: Sensor reading of sensor node that will be stored in chosen variable in
the algorithm.
Output: Alert type signal.
9
PO E5-ELKI 1 4 - - & 8 - 2 - & 1 7 1 6 : 5 4 •
Steps (i)
(1) Variable
Initialization
mm
(2) Alert
Loop
(3)
Algorithm: RIDCA
Velocity of water at instance (tj) = Vj
Cross Sectional area of mouth of the source of water = X
Maximum possible velocity at time tj on spot (Sj) = V
Distance travelled by water at instance (tj) = Dj
If(R>=Rmm)
If(Vi=>Ran[vj])
Alert (flood 1),
Goto step 3;
If(X>=Xmax)
If(Vi=>Ran[Vi])
Alert(flood 2),
Go to Step 3;
IfCCVi^RanhD&CV-V^))
if (Level[Wi]>=Ran[Levelwi] & Aud[cld]>=Aud[cldnor])
Alert (flood 3),
Goto step 3;
If (Vi => RantVj])
if (Level[Wi] >= Ran[Levelwi] & temp <= Ran[temp])
if ((S16p=> range(Slop) & (D/Tj => Vmm))
Alert (flood 4),
Go to step 3
else
if ((Level[wR]>=Ran[Level(wR)])&(temp <= Ranftemp]))
if (reservoir = noempty)
Alert(flood 5),
Go to step 3
else
if((Slop = 1) & (Dspl(Slop) =1))
check (P(landslide))
Alert (P(landslide));
If (Route =1)
Send Alert(sennext)
Go to step 4
else
for(i=l; i=n;i++)
for( sen(i)=sencheck; seriche^Monitornode; sen(i)=sennext)
Explanation
R= rainfall
Rmm= maximum normal
rainfall
Xmax
= maximum normal
cross ectional area of mouth
of the source of water
Aud[cld]= Sound recorded
from cloud
Aud[cldmax] = Maximum
normal sound recorded
Ran[vJ= threshold range of
velocity
Level[wj]=water level
Ran[LevelwJ= threshold
range of water level
Ran[temp]= threshold range
of temperature
Level [wij=water level at
reservoir
Temp= temperature
Slop= Slope of land
Dspl(Slop)=Displacement
of slope
P(landslide)= Probability of
landslide
sencheck-sensorCheckpoint
sennext— sensor nextnode
Monitornode= Monitoring
node
i= lA
Sennext= node on next level
10
AODVCserWk)
Send Alert(sennext)
Go to step 4
(4) End Stop.
Step (1) of algorithm initializes the variables including velocity(Vi) of water at any
instance, cross sectional area of mouth(X) of the source of water, maximum possible
velocity(Vmm) at time ti on spot (S*), and Distance travelled by water at instance (ti) as
(Di). In step (2), algorithm checks conditions for flood types with options including
normal flood, heavy flood, and heavy flood due to cloud burst, flash flood, long duration
flood and landslide and after checking the condition sent back the control to step (3).
In the end of step 3, machine deployed in the network will flood the short message
through a routing algorithm AODV (Adhoc On-demand Distance Vector) in the network
with the destination address. In the first part of step (3) it will simply send the message if
route exists and recorded but if not then existing second part of step (3) will apply. In this
part it will find just route to send the message through hop by hop searching.
Note: Here, We have used AODV (Adhoc On-demand Distance Vector Routing)
protocol to flood alert message in the network.
Claim 1: We Claim RIDCA (Rainfall Induced Disaster Classification Algorithm) that
classifies flood and landslide of various types, this algorithm also sent
information to monitoring station with the help of AODV algorithm.
Claim 2: We claim ASA (Alert Selection Algorithm) that selects Alert message sent by
RIDCA, which comes as an input to ASA. ASA generates message at the
monitor end, to broadcast in the network.
Claim 3: We claim Figure 5 and 6. Figure 5 is a process to decide rainfall induced
disaster type while Figure 6 presents a detailed view of figure 5..
Claim 4: We claim figure 5 involve in decision making in figure 3 and 4. Here, the
decision methodology involved in figure 5 at the monitoring station to decide
about flood or landslide according to the result of flowchart shown in figure 3 or
4, respectively. The decision methodology^ shown in figure 5 helps at the
flowchart, for decision making at the monitoring station.
Claim 5: We claim figure 3 is a flowchart to decide landslide disaster through analysis of
observation and issuing alert to smartphone devices.
Claim 6: We claim figure 4 is a flowchart to decide landslide disaster through analysis of
observation and issuing alert to smartphone devices.
Claim 7: We claim Poison distribution for sensed data modeling for flood. Poison
distribution is used for data modeling for sensed data by the individual devices
can be done through Poison distribution as per equation (5.0) and figure 1, for
flood.
Claim 8: We claim Poison distribution for data modeling landslide for sensed data by the
individual devices.can be done through Poison distribution as per equation (9.0)
and figure 2, for landslide.
Claim 9: We claim Alert Procedure for disaster alert which involves two steps including
modeling of Sensed data using poison distribution and design of an efficient alert
algorithm submitted through this document fully or partially.
| # | Name | Date |
|---|---|---|
| 1 | 201711028829-Form 9-110118.pdf | 2018-01-17 |
| 1 | 201711028829-Other Patent Document-140817.pdf | 2017-08-21 |
| 2 | 201711028829-Form 5-140817.pdf | 2017-08-21 |
| 2 | 201711028829-Other Patent Document-110118.pdf | 2018-01-17 |
| 3 | 201711028829-Form 1-140817.pdf | 2017-08-21 |
| 3 | 201711028829-Form 3-140817.pdf | 2017-08-21 |
| 4 | 201711028829-Form 2(Title Page)-140817.pdf | 2017-08-21 |
| 5 | 201711028829-Form 1-140817.pdf | 2017-08-21 |
| 5 | 201711028829-Form 3-140817.pdf | 2017-08-21 |
| 6 | 201711028829-Form 5-140817.pdf | 2017-08-21 |
| 6 | 201711028829-Other Patent Document-110118.pdf | 2018-01-17 |
| 7 | 201711028829-Form 9-110118.pdf | 2018-01-17 |
| 7 | 201711028829-Other Patent Document-140817.pdf | 2017-08-21 |