Forest fires pose a significant danger to both human settlements and forest ecosystems worldwide, with their occurrence largely linked to human activities. While many plants and animals need and benefit from wildfires, climate change has left some ecosystems more susceptible to flames. Warmer temperatures have intensified drought and dried out forests.
The resulting devastation often includes climatic changes and the exacerbation of the greenhouse effect. To mitigate these negative impacts, it is crucial to identify forest fires early on. This study suggests a wireless sensor network system that can detect forest fires at their initial stages.
How does forest fire work?Wildfires can fizzle out quickly or spread uncontrolled, consuming thousands of acres of land in a matter of hours. But the intensity and movement of a wildfire ultimately depends on three factors:
- fuel
- weather
- topography
These factors are collectively known as the "fire behavior triangle".
High temperatures and low humidity also dry out fuel sources, causing them to ignite and burn faster. This is why wildfires typically become more intense and spread fastest in the afternoon, when the air is hottest. Common causes for wildfires include: Arson, Campfires, Discarding lit cigarettes, Improperly burning debris, Playing with matches or fireworks.
My solutionThe Project aims to develop an IoT-based forest fire alarm system that utilizes a network of strategically placed sensors to continuously monitor environmental factors. When a potential fire hazard is detected, the system will send real-time notifications to authorities, automate emergency protocols, enable remote monitoring, and enhance coordination of firefighting efforts. This comprehensive solution enhances fire detection capabilities and facilitates swift and targeted response to combat forest fires.
See the Video Presentation on YouTube.
DESIGNComponentsOur infrastructure is composed of:
- Esp32-heltec-lora32-v2, for Sensor Board
- Esp32-wroom-32, for Actuator Board
- KY-028, temperature sensor module
- KY-026, infrared flame sensor
- MQ7 sensor, CO detector
- Buzzer, which is activated when fire is detected
- Led, which is activated when fire is detected
- Button, to stop the alarm
Here there is the Esp32-heltec-lora32-v2.
Sensor Board: it does the samplings (detecting possible fires), using KY-028 (temperature sensor module), KY-026 (infrared flame sensor) and MQ7 sensor (CO detector).
Esp32 Actuator BoardHere there is the Esp32-wroom-32 . It is possible to use another Esp32-heltec-lora32-v2 if you want.
Actuator Board: it receives the alert of fire and starts the alarm, using Buzzer and Led; it is possible to stop the alarm using a Button.
KY-028, temperature sensor module
The KY-028 Digital Temperature Sensor measures temperature changes based on thermistor resistance. This module has both digital and analog outputs, there’s a potentiometer to adjust the detection threshold on the digital interface. This module consists of an NTC thermistor, an LM393 dual differential comparator, a 3296W trimmer potentiometer, 6 resistors, 2 LEDs, and 4 male header pins. The specifications of the flame sensor include the following:
- Operating Voltage : 3.3V to 5.5V
- Temperature Measurement Range : -55°C to 125°C
- Measurement Accuracy : ±0.5°C
- Board Dimensions : 15mm x 36mm
- The output type is Digital o/p or Digital & Analog output
Infrared Flame sensor is used to monitor light intensity; the values of light intensity, equal to detection of fire, are periodicaly sent to the Cloud. This sensor is available in small size and is used to detect a source of fire or any other clear light source. Basically, this kind of sensor detects infrared light with 760 nm to 1100 nm range wavelength that is generated from the light source or fire or flame. This IR flame sensor includes a YG1006 Phototransistor sensor which has high sensitivity & high speed. The specifications of the flame sensor include the following:
- Operating Voltage: 3.3V to 5V
- Operating current: 15 mA
- Comparator chip used: LM393
- Type of sensor: YG1006 Photo Transistor
- The output type is Digital o/p or Digital & Analog output
- Red LED is for power and green LED is for output
- Range of the spectrum: from 760nm to 1100nm
- Detection angle: from 0 to 60 degrees
- Operating temperature ranges: -25℃ to 85℃
Carbon Monoxide Gas Sensor MQ-7 detects the concentrations of CO in the air and ouputs its reading as an analog voltage. The sensor can measure concentrations of 20 to 2,000 ppm.The sensor can operate at temperatures from -10 to 50°C and consumes less than 150 mA at 5 V. The specifications of the flame sensor include the following:
- Detection Gas: Carbon Monoxide
- Concentration: 20-2000ppm
- Supply Voltage: < 10V
- Heater Voltage: 5.0V ± 0.2V
- Load Resistance: Adjustable
- Heater Resistance: 31Ω ± 3Ω
- Heater Consumption: < 350mW
The network architecture using only MQTT is the architecture actually implemented in the prototype. It is focused on checking the actual state of the fire detection system.
The AWS architecture above shows the network design. In detail, data are generated from the prototype and sent to AWS through a MQTT-Bridge, that is a my personal computer. Meanwhile, always using MQTT, Sensor Board sends a message to Actuator Board, which starts the alarm (the alarm can be stopped with a Button). With a proper AWS Lambda function and an IoT-Rule, the data sent to AWS from the MQTT-Bridge are stored in two NoSQL DB. With another Lambda function, data are retrieved form DBs and associated to an API deployed with AWS API Gateway. The website frontend, taken data dynamically from API endpoint, has been deployed with AWS Amplify.
To see the tutorial of how I have created this infrastructure, go here.
Network Architecture with LoRa ProtocolIn a second part of the project I have worked with LoRa, which will be the protocol that I will use also in the future development of the project. This is not implemented yet in the prototype, due to some problems between Lora, Riot and Esp32. LoRa is a suitable technology for different reasons:
- It uses low bandwidth. In fact, I need to exchange simple data
- It can send data on long ranges. It is needed to allow the scalability of the project
- It works with low power consumption, and this is a crucial added value since the project is based on a battery-powered approach
The network architecture is focused on checking the actual state of the fire detection system.
The AWS architecture above shows the network design with LoRa Protocol. In detail, data are generated from the prototype and sent to AWS through The Things Network, that is the LoRa Gateway.
In this part I have not already implemented the sending to the Actuator, because in my system the second Esp32, that I own, has not the Antenna LoRa. To solve this issue, you can change the Lambda function that takes the data from TTN adding a mqtt publish to the topic in which the Actuator is subscribed.
Then, as before, with a proper AWS Lambda function and an IoT-Rule, the data sent to AWS from TTN are stored in two NoSQL DB. With another Lambda function, data are retrieved form DBs and associated to an API deployed with AWS API Gateway. The website frontend, taken data dynamically from API endpoint, has been deployed with AWS Amplify.
Website PageThe website shows the data sent to AWS, in particular it tells what happens during the actual fire showing graphs about Flame, Carbon Monoxide and Temp. There are also some aggregated data like Average, Min and Max of all the data.
EVALUATIONData of the problemMost fires have historically occurred between May and October. However, recent data has shown that the season is lengthening, with wildfires starting earlier in the year and lasting well into the fall and winter months.
The Copernicus Emergency Management Services is the fire forest system used in Europe. Similar to the other active fire maps, the European Forest Fire Information System (EFFIS) uses MODIS and VIIRS to track thermal anomalies.
The values of the actual system, with which I have to compare, are:
- 22 m resolution imagery over very large areas for the 2nd generation of this type of satellites (while the first generation is in space from 2002 to 2009 (only 32 m) and it lived for 7 years)
- Near real-time detection of fire, but it is not declared specifically
- A satellite has a useful lifetime of between 5 and 15 years depending on the satellite
From the data take before, I have observed that is not possible to set in a static way different analysis for the seasons. Indeed the forest fire are not linked anymore to the seasons.
It is possible to do some daily analysis observing the value of the temperature. Doing this, it is possible to understand a probabily of forest fire and beacuse of this, it is posssible to have a dynamic duty cicle, in which there are different sleep time:
- 5 minutes, for high temperature (high risk)
- 10 minutes, for middle temperature (middle risk)
- 15 minutes, for low temperature (low risk)
It is not suitable to sleep for more time because, in the case there is a fire, the system becomes unreliable.
With this system, there is also a different analysis (on average) between the seasons, and in the winter there will be usually a long duty cycle while in summer there will be a short duty cycle.
PayloadThis is a typical payload {"flame":"0","co":"359","temp":"22"}. In this case, the total volume will be of about 41 Bytes.
It is possible to reduce this. A possible solution is {"f":"0","c":"359","t": "22"}. In this second case, the payload will be of about 33 Bytes.
The worst case is when there is a fire for all day . In this situation, there is a possible message of 33 Bytes every 5 minutes. So, in the worst case, there are 288 messages per day. Finally, 9504 Bytes (approx 10000 Bytes) are sent to AWS.
This holds both for the MQTT Protocol and the LoRa Protocol.
Latency with MQTT ProtocolThe end-to-end latency for data collection using MQTT can be summarized as follows:
- Thing to MQTT Bridge (MQTT Protocol): the latency here is about 1 seconds
- MQTT Bridge to AWS IoT-Core: the latency in this stage is about 2-3 seconds
- AWS IoT-Core to Website: here the latency is about 2-3 seconds
So, on average, the latency is max 7 seconds.
Latency with LoRa ProtocolThe end-to-end latency for data collection using LoRa is defined by:
- Thing to TTN (LoRa Protocol): the latency in this stage is about 2-3 seconds
- TTN to AWS IoT-Core: here the latency is about 2-3 seconds
- AWS IoT-Core to Website: the latency here is about 3-4 seconds
So, on average, the latency is max 10 seconds.
Energy Performance with MQTT ProtocolIn this paragraph, there is the energy performance of only the Sensor Board which will be connected to a battery. The Actuator Board is connected via cables and also it consumes more or less depending on how many alarms there are.
To obtain the energy performance of the Sensor Board it is needed to analyse the consumptions of the different parts of the system:
- KY-028 (temperature sensor): 5 V - 15mA = 0.075 W
- Infrared Flame sensor: 5 V - 15 mA = 0.075 W
- MQ7 sensor: 5 V - 150 mA = 0.75 W
- Esp32 in active mode: 5 V - 180 mA = 0.9 W
- Esp32 Heltec in deep sleep mode: 5V - 800µA = 0.004 W
- mex AWS consumption, counted in the Active mode
- mex Alarm consumption, counted in the Active mode
TotalEnergy = KY028comsumption + FlameConsumption + MQ7consumption + ActivemodeConsumption + DeepSleepModeConsumption
It is important to analyse the system in the worst case scenario, so it always wakes up every 5 minute: it does 288 samplings per day.
On average it takes 3 seconds to do the test, so 864 sec (0, 24 h) in active mode and 85536 (23.76 h) sec in deep sleep mode.
TotalEnergyDaily= 0.527 Wh
TotalEnergyMonthly = 0.527 Wh x 30 days = 15.81 Wh
Due to the three sensors it uses and the Wi-Fi connection, it is highly energy consuming. To be used in larger environments, it is necessary to improve the energy efficiency.
The energy efficiency of the system can be improved using LoRa protocol (instead of MQTT and Wi-Fi) for the communication between nodes and with AWS.In particular it is possible to reduce the esp32 consumption in ActiveMode.
Energy Performance with LoRa ProtocolTo obtain the energy performance of the Sensor Board it is needed to analyse the consumptions of the different parts of the system. The consumption of the sensors remain the same:
- KY-028 (temperature sensor): 5 V - 15mA = 0.075 W
- Infrared Flame sensor: 5 V - 15 mA = 0.075 W
- MQ7 sensor: 5 V - 150 mA = 0.750 W
Using the Iot-Lab energy monitoring instrument, it is possible to say that the remaining consumptions are:
- Esp32 sending: 0.455 W
- Esp32 in deep sleep mode: 0.00075 W (lowest sleep for the ESP32 Series)
- Esp32 in ActiveMode: 0.28 W
TotalEnergy = KY028comsumption + FlameConsumption + MQ7consumption + ActivemodeConsumption + DeepSleepModeConsumption + MessageConsumption
TotalEnergyDaily= 0.28 Wh
TotalEnergyMonthly = 0.28 Wh x 30 days = 8.4 Wh
Also with this solution, the energy consumption is high. The conclusion is that the bottleneck is the MQ7 Sensor which is extremely energy demanding.
With a battery of 7,500mAh, the board can survive for 3 months (but this is not enough).
A possible solution to the problem is to use the infrared flame sensor to detect the fires, and you use the MQ7 Sensor only during the fire to give fundamental data to the firefighter (air quality and quantity of Carbon Monoxide in particular). In this case there is a larger consumption of energy during the fires, but it is not important because, probably, with the high temperature and the fires, the board will be destroyed.
ConclusionsBefore, I have suggested the actual solution EFFIS (my competitor) and its strengths. I will compare the two solutions:
- There are 22 m resolution for EFFIS; meanwhile for my system the resolution can be decided by the user, and the best detection is with a board every 2 m
- Then there is near real-time detection for EFFIS (but there is not a specific time); while my system has a dynamic approach, and the smallest time is 5 minutes
- A satellite has a useful lifetime of between 5 and 15 years depending on the satellite; the board I will use can have the same lifetime, but it is necessary to change the battery (actually you have to change the battery of each board every 3 months).
So, to conclude:
- My system has an higher resolution
- The time of detection is similar (near real-time intended as 5-10 minutes)
- For the life of the system, actually, EFFIS is much more efficient
- The economic difference will be evaluated on the basis of the quantity of sensors used per area
To see the future of the project, check the GitHub page.
Comments