Utilizing the Internet of Things (IoT) to Develop a Remotely Monitored Autonomous Floodgate for Water Management and Control

Abstract

In recent years, floods have increased in frequency and intensity, causing tremendous hardship. In badly affected regions, mostly the rural areas, Weir-type floodgates are the only measure against floods. However, these manually operated gates are numerous and scattered over vast areas. This makes flood mitigation efforts very challenging, which causes severe devastation. Current solutions to automate the floodgates are expensive, black-boxed, and focused on individual gates. In this paper, we present a Centralized Flood Monitoring and Coordination System developed through the Internet of Things (IoT) and other open-source technologies. For this work, we developed a working prototype of an autonomous floodgate that opens/closes according to the level of water. We also developed the required program to allow the gate controller to publish its data through the IoT gateway to the cloud. The data was then captured and viewed on a number of IoT clients, both for individuals and groups of floodgates, in real time. The developed system proved successful as the autonomous gates were monitored remotely through the established IoT framework, with room for future development and improvement. This paper serves as a proof of concept and a preparation for real, on-site implementation of the IoT-floodgates.

1. Introduction

In recent years, floods have increased in frequency and intensity all over the world, causing tremendous hardship in affected areas. This has increased the importance of flood mitigation measures and technologies, such as floodgates [1,2]. Floodgates vary in size and complexity; large and sophisticated gates can be found in hydro-dams, while small and simple ones are found on rivers or canals in rural regions, which are usually the most badly hit regions by floods [3]. Crude and simple in design, these manually operated gates prevent flash floods, protect paddy fields, and prevent damage to properties and local infrastructures [3]. However, these gates are numerous and often scattered over vast rural areas, making flood mitigation efforts and coordination very challenging. As a result, seasonal floods usually come with severe devastation in these regions [4,5].

In the current practice, there are a few main challenges that need to be addressed. The delivery of water gate information and other details from different locations to the management or the manager through the site workers is rather time-consuming. This leads to delayed decision-making from the manager, especially for the water gates that are significantly related and connected to each other. For example, the opening and closing of water gates that are installed in a line on the waterway will change the water level at the next area and the management of the next gates. Hence, quick information updates from each water gate is important in water management.

Furthermore, the manager needs an overall view from all the regions of the waterways to easily manage the water gates. In other words, all real-time information needs to be received by the management body at the same time to make the right responses with water gate controls. Currently, satellites provide the forecast data for water management and preparation, but the situation also needs real-time data for quick actions.

Hence, water management needs to be improved with quick information updates and full real-time monitoring. Apart from these aspects, the management also needs to be able to directly control or override the water gates from the management center. An automation system is not the only required function for management, but it also needs to be interactive so the manager can take action on the water gates based on the full picture from the monitoring system.

The proposed solution in this paper is able to manage the challenges above, and provide a quick information update of the water level and the gates, all information from multiple locations, and an action button function from the client center.

2. Previous Solutions

Some mechanisms to automate floodgates do exist [6,7,8], but these efforts are expensive and usually focused on automating individual gates. Furthermore, they do not allow centralized monitoring of a group of gates, something the flood mitigation authorities really need as they usually monitor tens or even hundreds of floodgates in a region.

Some previous systems only applied monitoring of water level or other water parameters. These systems have no automation function for water gate opening and closure. Through different methods and focuses including GPRS communication [9,10,11], with their own developed system [12,13,14], and water quality monitoring system [15,16,17], these solutions were only applied for water monitoring. However, these systems still need human labor to control the water gate and take the necessary action at the locations. Although some solutions managed to connect multiple nodes from rivers and reservoirs [18,19], the centralized function is focused only on monitoring water with no online gate control.

Other solutions combined the water gate automation and monitoring function [20,21,22]. The gate is automatically opened and closed by the system based on the warning level of water; then, the particular information is visualized in the wireless system. However, the override button from the client interface is not available, which is the most important feature or function required by the manager to decide when to control the water gates.

In this paper, those functions from different solutions are combined in one system in order to provide a complete function for the user, especially in these aspects: quick data update, full picture of IoT clients, and interactive command button. None of the aforementioned solutions evaluated the performance through these aspects, but only provided the online interface of the system with other types of performance evaluation.

3. Methodology

This section presents the steps needed to develop, implement, and verify the proposed system. The main steps needed to develop the proposed system include the following elements:

• Infrastructural requirements: Setting up the electrical power and connectivity at target floodgates.
• Floodgate automation: Installing the needed sensors, actuators, and network-ready controllers.
• Broadcasting gate data: Programming the controllers to publish their gate data to the cloud.
• Viewing gate data: Capturing, processing, and viewing the data through the IoT framework.
• Data interpretation: Evaluating the system performance with the data output.

3.1. Infrastructural Requirements

Power requirements depend on the gate size and the torque needed to lift it up, as well as the frequency of fluctuation of the water levels and, therefore, the need to raise and lower the gate [23,24]. A solar cell can be installed near the gates, or it can be connected to the grid. Connectivity can be established through wireless hotspots, which have become more capable and cost-effective in recent years. Wired connection could also be established by extending the LAN cables along with the power cables discussed above.

This step could be the most challenging of all due to the expected costs. However, the authorities and city officials could consider this as a long-term investment for their region. Aside from enabling the proposed IoT-floodgates, the established infrastructure (extended power and connectivity) would greatly benefit the local communities. It could help boost commerce, enhance social interaction, and further improve development in these regions.

3.2. Floodgate Automation

There are different types of floodgates and mechanisms; the most common type is the Weir gate mechanism, shown in Figure 1. In this mechanism, a power screw is used to lift the gate door up or down. The screw is turned using a wheel mounted on top of the gate. For the purpose of this paper, a working prototype of this mechanism was developed and built by the authors [25,26]. This weir-type gate has been commonly used in other works [27,28,29].

The developed prototype shows how this mechanism could be automated. The screw is connected to an electrical motor through a gearing system. The motor is controlled by a network-ready controller, which is also connected to the sensors measuring the water level and facilitating the gate automation [30].

Three water gate prototypes were developed in this work to demonstrate the centralized system with the full information. The two water gate models are in-lab models that were basically modified from an early stage to improve the gate stability after frequent usage and to make it able to control the water flow. Both gates were named Gate V1 and Gate V2 as shown in Figure 2 and Figure 3.

The third prototype, Gate V3, is a large-scale prototype that was built on the site at the Malaysian Agricultural Research and Development Institute (MARDI) to test the prototype with actual water flow (Figure 4). This prototype consisted of a 5 kg sliding gate, steel platform, and linear actuator with 150 N payload. The three water gate prototypes demonstrate multiple gate nodes at different locations. The data from those locations will be transferred to the cloud through a wireless network-ready controller. The hardware components of these three prototypes are shown in Figure 5, Figure 6 and Figure 7.

3.2.1. Capturing Water Level

To measure the water level of the river/canal, the HC-SR04 ultrasonic sensor was used. This sensor shoots an ultrasound ping in the direction of an object, and by measuring the time it takes for its echo to return, the distance between the sensor and the object can be found, as shown in Figure 8.

As successfully demonstrated by Texas Instruments [31], when the sensor is positioned to face the water (by being placed on a pole or a similar fixture), the water height can be found. The frequency of the ultrasonic ping can be set programmatically, as discussed below. Several works were done by using the ultrasonic sensor to measure the water level [14,18,32].

For the sensor part, the type of the sensor is not the highlight of this work; it can be modified and improved with other types of sensors that are more suitable and accurate based on the condition of the location. In addition to that, the component itself is available and is not the unique method in this work. However, the utilization of the components with an IoT framework are the main focus to achieve the centralized and interactive system.

3.2.2. Controller Selection and Programming

For the controller, the authors opted to use Raspberry Pi 3 (RPi). The RPi is a network-ready, cost-effective computer-on-chip. This allowed the authors to program it to perform the tasks of the proposed system: capturing and processing sensor data, actuating the gate motor, and publishing the gate data to the cloud. The Arduino does not have the network capability without a physical network adaptor [33,34]. Figure 9a shows a schematic diagram of the developed system.

Aside from connecting all the input/output devices, the RPi has a built-in network adaptor, which allows it to connect to the Internet via Wi-Fi, a cable, or Bluetooth; the authors opted for a Wi-Fi connection. Figure 9b shows the algorithm of the RPi controller program developed for the purpose of this work. The figure shows only the pseudo code, methods, and libraries used. The actual program can be found in [35]. Excerpts from the developed program are shown in Figure 10, Figure 11, Figure 12 and Figure 13. The figures show the key elements of the developed code, namely the sensor data processing, motor control, and IoT.

As seen in Figure 10, the sensor shoots the ping for just 0.00001th of a second and then, it measures the time for the echo to return. Next, knowing that the speed of the ping is 343 s (speed of sound at sea level), as also provided by the sensor manufacturer, the distance can then be calculated. The time needs to be divided by two because the echo_duration is the time of the ultrasonic pulse travel in one trip to the water and back again. Hence, the distance calculation in the python script follows the method in Figure 11. This, in turn, facilitates the opening and closing of the water gate.

Figure 12 shows a snippet of the program that controls the opening of the gate, namely the open_gate() function. As seen in the figure, the open_gate() function first checks if the gate is not already opened; only then, it would proceed by turning the motor in the direction needed to lift the gate up, clockwise or counter-clockwise, based on its mechanical configuration.

As for the gate data, which includes gate id, status, water level, and other related data, it is broadcasted through the IoT framework using the update_iot() function, as shown in Figure 13.

The gate_id is a unique number assigned to each gate to differentiate it among other gates in the target region. After packaging the gate data in a JSON (JavaScript Object Notation) object, which is a data format understood by all cloud services, browsers, and databases, the data is then published to the cloud through Dweet.io, an open-source IoT service, as discussed in detail in the next section.

3.3. Broadcasting Gate Data

In order to allow the stakeholders to remotely monitor the floodgates through the IoT framework, the controller needs to publish its data to the cloud. The process is shown symbolically in Figure 14. As shown in the figure, publishing gate data to the cloud involves the following processes:

Restructuring the data: As the data is to be transferred over webservers and clients, it needs to be packaged in one of the two standard IoT messaging formats: the JSON format, as shown in Figure 13, or the MQTT (message queuing telemetry transport) protocol [37,38]. There are operational differences between the two formats, but most IoT clients/services can handle both.

IoT gateway: It is a network-ready device that connects the controller to IoT services and applications. For the Raspberry Pi, which is network-ready, there is no need for a separate device, but rather a configuration patch, as discussed in [38]. For non-network-ready controllers, such as the popular Arduino controllers, a physical gateway is needed.

Publishing web-ready data to the cloud: Once the networking setup is completed and the IoT protocols are implemented, the JSON or MQTT formatted data are published to the cloud by hard-coding the JSON or MQTT publish commands into the controller program. This can be further automated using a number of IoT data publishing services, such as Dweet.io. As seen in Figure 13, with Dweet.io, all the programmer needs to do is declare the structure of the data. Be it JSON, MQTT, or others, Dweet.io (through its Python client, Dweepy), will do the rest; it would Dweet, or Data Tweet the needed information.

3.4. Viewing Gate Data

Once converted to a web-ready format (JSON, MQTT, or others), the gate data can then be viewed in any client that supports and understands these formats. This includes most operating systems, web-applications, as well as android and iOS apps, as shown in Figure 10. Once again, a web developer or an app developer could create a custom-client to view the IoT data or utilize any of the available open-source IoT solutions for viewing data, such as ThingsBoard.io, FreeBoard.io, or others; both approaches have advantages and disadvantages. For this work, especially in the early testing stages, the authors opted to use FreeBoard.io, as shown in Figure 15.

Using Freeboard.io is similar to using social media such as Facebook. The developer logs into Freeboard, adds the data source, and selects the viewing options. Referring to Figure 9, the multiple gates are shown with different names: Gate V1, V2, and V3. From the cloud, the information including water level, gate status, temperature, humidity, and location of those water gate prototypes are published in Freeboard.io.

3.5. Data Interpretation

To prove that the centralized water management system is effective, the data must be collected, and the developed system needs to be evaluated from the data. There are three main parameters that need to be tested on the water gates and the system, which are the data update rate, percentage of data completion, and response time (Figure 16).

Data update rate is the delay time of the system when the data from the controller terminal is updated to the IoT Client, Freeboard.io. The average data update rate of each water gate is calculated from the collected data of the delay time of the water level update. From that result, the authors can evaluate how fast the developed centralized water monitoring system functions compared to the current practice as well as the previous solutions.

The percentage of the data completion is evaluated by how many features/data in the IoT Client are updated compared to the number of the total aspect features in one system. The IoT Client should demonstrate 100% of data completion to show the full picture of the monitored data.

The response time is the opposite of the data update rate, which is the time of signal update from the developed open and close buttons from the IoT Client to the controller of each water gate. In other words, it is the time between clicking the override button and the motor response.

4. Results and Discussion

4.1. Data Update Rate

The data below were collected from the three different water gates: Gates V1, V2, and V3. Gates V1 and V2 were from the lab location and Gate V3 was from the in-field location. For every water level update and gate status update, the update rates were collected during a few cycles of gate opening and closure.

In Figure 17, Gate V1 opened four times with a longer update rate of over 7 s compared to the data update rate when it is closed. The opening of the gate takes a few seconds before updating the data to the IoT Cloud. In the IoT framework, the open command was set with 5 s of the motor rotation. The average data update rate was calculated as 2.57 s for every update.

Similarly, as shown in Figure 18, some data update rates of the in-lab Gate V2 were higher during the gate-opening phase because the motor rate was set for a few seconds to ensure the gate was fully opened. As the water level was higher than 5 cm, the water gate opened to reduce the water level. The average update rate for this gate was 2.93 s per update.

Figure 19 shows the three long cycles of the water gate opening and closure. This in-field water gate updated the water level data together with other information with an average of 2.14 s of update rate, from the controller terminal to the IoT Client. The maximum water level was set at 45 cm, which caused the water level to increase slowly. During the closed phase, the water level increased over time and reached the maximum limit, and then the gate opened with 10 s of the motor rate.

From all of the data update rates of those three water gates, the authors can conclude that the data transmission from each location to the Freeboard.io only takes less than 3 s, which proves that the developed water management system can monitor the information faster than the current practice, which is through human updates to the management body.

4.2. Percentage of Data Completion

In this subsection, the results are only the images from the IoT client that show the updated features in one time. The images show whether the data completion is full or partial.

Figure 20 shows the update was only from one active node at Gate V3, including the data of water level (gauge and level trend), temperature, and humidity of air. The other two nodes only showed the previous update of the water level, implying that the status of both gates were not active at that time. The IoT Client in Figure 14 only demonstrates that 1/3 of the required data were updated from the controllers. Thus, the data completion was only 33.33%.

Compared to Figure 21, only two gates updated the particular data, which were Gate V2 and V3. Gate V1 stopped updating after publishing the information to the cloud several times. Although the water pump was switched on, the water level did not increase over time because of the disconnected system. The IoT Client from Freeboard at that time showed 2/3 of data completion.

Figure 22 demonstrates the full picture of the IoT Client, which showed all parameter updates from different nodes of the water gates including water level, gate status, temperature, humidity, and location of the individual gate. Hence, the IoT Client basically showed 100% of data completion when each node actively updated the information through wireless connection. From that, the authors can state that this developed system is suitable for the user from the water management to get a full picture of all the water properties.

4.3. Response Time

Response time is the rate of the signal from the IoT Client to the controller at the water gate location. The override button is under development by using Netpie.io (Figure 23), another ready-made IoT Client that can provide the button feature compared to Freeboard.io. The response time is the same as the rate of data update because both conduct a two-way data transmission. Hence, the response time also averages between 1 to 3 s in order to send the open and close command from the IoT Client to the controllers.

From the results presented in Section 4.1, Section 4.2 and Section 4.3, the authors can conclude that the developed system manages water through multiple water gates. The developed system is centralized because it can monitor the related information of different water gates in real-time with a quick data update and a full picture from the IoT Client. Additionally, the system not only implemented an automation feature, but also provided a two-way communication that facilitates the interaction between the client and the water gates. The client can control the water gates after getting and evaluating the full picture from the IoT Client, through the override button that sends the command to each water gate. Thus, the developed water management system is not only centralized and automated, but also interactive.

5. Conclusions

This paper presents the development steps needed to utilize the IoT to develop a Centralized and Interactive Water Management system. Apart from the cost of equipment, the technology used is completely open-source, and thus, it is open for customization, extension, and future development and improvement. The HC-SR04 ultrasonic sensor was used to measure the level of water in real time. This information was captured by the Raspberry Pi, where it was packaged in JSON format, and published to the cloud.

Extensive use of IoT solutions and services was implemented in this work. However, a custom IoT client was developed for the centralized monitoring platform. This combination made it possible to develop parts of the proposed system.

The success of the working prototype provided a working ground for the on-site implementation and testing. Aside from the hardware implementation, more robust sensor choice and infrastructural setup, the developed software, IoT solutions, and networking protocols remain the same.

There is plenty of room for improvement in this work: more sensors could be added to capture more relevant data, and remote control of the gates could be developed once the required networking setup is achieved. Other than that, the power source setup can be improved by adding a solar power system after the power usage research, battery consideration and transformer selection.

In the real application, the system should use a suitable sensor that can withstand the environmental effect, especially the rain and storm effect. Thus, the selected sensors need to be waterproof for deployment.

The available data transmission technologies can be selected based on the situation of the application/field, the advantages and shortcoming of the technologies. Some aspects need to be considered including the cost, range, and battery life. This project was started with Wi-Fi technology in the early stage for the water gate test. For future works, the utilization of LoRa technology is expected in order to manage multiple gates that are scattered over a large area.