# Industry 4.0 towards Forestry 4.0: Fire Detection Use Case +
## 5 Methodology
### Dynamic Query Window-Based Selector for Stream Rate Change
#### 5.3.2 The Proposed Dynamic Window-Based Selector
Then, we show the benefit of query window adaption in reducing the latency of reporting time while discussing the trade-offs regarding the alert losing due to the adaption process. The conducted experiments execute a stream query that monitors alerts based on sensors' values and then reports an event that is the alert type. In particular, the stream query joins two streams; weather stream including (temperature, humidity, CO, and CO\({}_{2}\)

\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Hour**} & **Avg. ** & **Avg. ** & **Avg. ** & **Avg. ** \\  & **Temperature** & **Humidity\%** & **CO (ppm)** & **CO\({}_{2}\) (ppm)** \\ \hline
0 & 23 & 40 & 3 & 152 \\ \hline
1 & 24 & 38 & 5 & 201 \\ \hline
2 & 2



and wind speed stream. Since not only the pattern of weather sensors thresholds is used to report the wildfires, the wind speed also is used to early notify the fires especially in case of the wind excess the high range, i.e., 20 km/h. For brevity and simplicity, we run our experiments by setting the data generator to produce streaming data for 100 nodes within 24 min using the predefined stream rate of 24 h to make our experiments more tractable. According to the listed experiments and the forest fire detection use case which concerns timely danger rating alerts, we measure these matrices; (1) output stream rate including the number of actual alerts, joined events/reported alerts, loss/missed alerts for each alerting category, (2) timeline latencies including queuing time, processing time, and end-to-end latency time (see Figure 16), (3) reduction of reporting time using dynamic window selector. For the output stream rate, the actual alerts measure the expected alerts resulted from join query based on the stream rate; the reported alerts measure the Flink resulted joined tuples, the loss/missed alerts measure the alerts which pass their time due to long waiting in Kafka queues. For the timeline latencies, the queuing time measures the consumed times by Kafka in two intervals; the first interval is when the event consumed from Kafka source (i.e., weather sensors) and the second interval is when the joined events/reported alerts are sent from Flink until reported (i.e., stored into MongoDB). The processing time measures when the event is ingested into Flink until the event was sent to Kafka again. The processing time also includes Flink join processing time which labels each event by the corresponding rating alert. The end-to-end latency time measures the time from the event is generated until the event/alert is reported, e.g., sent to the forest department authority. ### Comparison of Different Static Window Sizes

The static window experiments that are conducted by fine-tuning the window sizes such as 1, 5, 10, 15, 30, and 60 s. For each window size, we first measure the number of actual alerts, joined events/reported alerts, loss events and the end-to-end latency time that can be incurred for each window size. Figure 17 showcase the linear increase of the reported alerts and decrease loss alerts for each type of alert concerning the actual alerts using different window sizes. It is noted that the number of reported alerts converges towards the number of the actual alert with window size increasing. In contrast, the number of loss alerts has the opposite behavior. We attribute this incremental behavior of the reported alerts to the increasing window size. More specifically, the large window size can hold many ingested events to be joined within a window. Similarly, the decrease of loss alerts concerning the increasing window size is that the small window size fast joins the ingested events. Some queued events are lost by passing their timeout due to the long wait and couldn't be joined with next windows. Thereby, the large window size can hold a larger number of input events that be joined and then reported. It can be seen that the average of end-to-end latency times gradually increases due to the increasing former size for each alert.