# 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
For example, the green alert, which has the lowest stream rate, has the shortest latencies with respect to the other alerts for all window sizes. In contrast, the red alert, which has the largest stream rate, has the longest latencies

Figure 16: Timeline of stream-stream joins in the conducted experiments. with respect to the other alerts for all window sizes. The long latency of red alerts happens by increasing of stream rate over larger window size. ### Comparison of Static and Dynamic Window Sizes Results

Based on the experimental results using static window sizes, we chose the static window size experiment of 60 s to compare with a dynamic window selection experiment which adapts the window size between 1 and 60 s. More specifically, this experiment has the lowest number of loss alerts concerning the other static window size experiments, making it the proper one to compare its performance with dynamic window selector performance. As the IoT-based forest fire monitoring use case is considered one of the latency-sensitive IoT-based application, the proposed dynamic window selector recommends the tumbling window type based on the built knowledgebase. Accordingly, the window size is initially configured using tumbling window and 60 s. The dynamic window selector slightly adapts the window size to maintain timely reported alerts for various stream rate while keeping the window type as tumbling because of its superiority for the latency reduction. As can be seen, Figure 17(a),b depict that the proposed window selector achieves lower latencies to the static window size. By introducing a streaming data pipeline, it is noticed that the latencies including queuing time, processing time and end-to-end latency time are significantly reduced compared to the static window size experiment by dynamically change window sizes for the sudden stream rates. Mainly, the dynamic window selector gradually decreases the window size based on the stream rate increments. The lower window size performs multiple short join intervals, leading to quickly consuming data from Kafka and decreasing the queuing time (see Figure 17(b)). Figure 17: Comparison of static experiments for 100 nodes with respect to the number the reported events, the number of loss events and the end-to-end latency time. Considering the reality of the desired contribution, Figure 19a shows that our dynamic window selector can adapt the window size according to time-varying input stream data rates based on 24-h monitoring of weather conditions in the forestry areas. For afternoon hours (i.e., 12, 13, and 14 o'clock) which are the most latency-sensitive for fire probabilities, our dynamic window selector can achieve the highest reporting delay reduction relative to the rest hours per day (see Figure 19b). Furthermore, Figure 19c shows the significant end-to-end latency time, E2E, improvement relative to window size which leads to faster alerting the forest department authority to protect the forests from fire spreading and huge damages. In Figure 20, we analytically and experimentally summarize the performance gained from window size adaptation, showing their superiority over the static window size configuration for each danger rating alert. However, the results show the trade-off between the end-to-end latency time improvements and the loss alerts ratios. For example, the red alerts have the highest number of loss alerts concerning another type of alerts which is on average is 85%. Still, its reporting time (i.e., end-to-end latency time improvement) is reduced by 74%. In particular, the proposed dynamic window selector has deployed a query with a smaller window size to perform fast joins using a smaller number of ingested events to trigger the early red alerts. The early notification using a smaller number of ingested events is better than deploying a query with a larger window size to perform late joins using delayed events having similar sensors values.