Abstract
This manuscript presents a novel state-of-the-art cyber-physical water testbed, namely the AI and Cyber for Water and Agriculture testbed (ACWA). ACWA is motivated by the aim to advance water resources' management using AI and cybersecurity experimentation. The main objective of ACWA is to address pressing challenges in the water and agricultural domains by utilising cutting-edge AI and data-driven technologies. These challenges include cyberbiosecurity, resources' management, access to water, sustainability, and data-driven decision-making, among others. To address such issues, ACWA is built consisting of topologies, sensors, computational clusters, pumps, tanks, smart water devices, as well as databases and AI models that control the system. Moreover, we present ACWA simulator, which is a software-based water digital twin. The simulator is based on fluid and constituent transport principles that produce a theoretical time series of a water distribution system. It creates a benchmark for comparing the theoretical approach with real-life outcomes via the physical ACWA testbed. ACWA data are available to AI and water sector researchers and are hosted in an online public repository. In this paper, the system is introduced and compared with existing water testbeds; additionally, use cases are described along with novel outcomes, such as datasets, software, and AI models.
HIGHLIGHTS
ACWA is a novel cyber-physical testbed for testing, validating, and experimenting with intelligent water systems and AI.
The testbed consists of multiple sensors, computational nodes, pumps, pipes, valves, tanks, and other computational components.
Open water domain datasets with multiple variables are publicly available via ACWA, including ones that enable the testing of Cyberbiosecurity and AI deployments in water systems.
ACWA is the first data generator of its kind (hardware and software) in the water domain.
INTRODUCTION
Water supply systems (WSS) are primary sources that provide and ensure water quality and availability, a prerequisite for flourishing economies, protecting public health, and promoting national prosperity (Batarseh & Kulkarni 2023). However, the lack of water availability has become a growing concern that requires increasing attention. The United Nations (UN) World Water Development Report of 2021 (UN 2021) states that the global population is experiencing severe water scarcity and will rise from 32 million people in 1900 to 3.1 billion people by 2050.
Additionally, cyber threats on WSS have been a critical threat to water resources in the United States and around the world. In WSS, it is common to use Supervisory Control and Data Acquisition (SCADA), a standard ‘legacy’ software infrastructure, making systems susceptible to cyber threats (CISA 2021). Recently, Hassanzadeh et al. (2020) reported 15 cyber incidents on WSS and mentioned that more sophisticated attacks, such as data poisoning, minimum perturbations, and botnets, require algorithms that can detect, classify, and counter adversarial actions. According to Batarseh & Kulkarni (2023), AI is the leading approach to such defences due to its ability to identify unwarranted pattern shifts in networks and datasets. Despite AI being the primary approach, there is an absence of historical data (Sobien et al. 2023) concerning cybersecurity measures in water resources management. The dissemination of water data is rare due to their lack of integration and interoperability across various data archives (Bustamante et al. 2021). Further, difficulties in data accessibility arise from challenges in locating, obtaining, and comparing data across different regions, given that various parties and agencies store and manage data in different formats and have different governance limitations. Additionally, there are inconveniences in data accessibility caused by political, economic, and cultural barriers, along with varying legal requirements. For instance, most WSS have restrictions that stop them from sharing their data, also especially with cyber-related data, there is a challenging scarcity of data points that could be used for identifying patterns via AI and other methods. Considering these challenges and their severity, the need to create an innovative testbed that can create data and validate scenarios in a dynamic manner is evident. ACWA therefore, is an innovative cyber-physical system designed to tackle these challenges by generating valuable scenarios and datasets through experimental procedures. The underlying concept of the ACWA laboratory involves creating a water testbed with varying topologies (i.e., dynamic structures) to simulate diverse water distribution scenarios. Moreover, a soil topology is also established to explore the impacts of water on irrigation and agricultural practices. This comprehensive setup will incorporate different sensors (water and soil) and chemical agents to enable seamless data collection, feeding directly into a database. The accumulated data within the database are visualised via real-time dashboards, offering proactive monitoring and evaluation capabilities.
RELATED WORK
A testbed can be defined as a ‘composite abstraction of systems used to study system components and interactions to gain further insight into the essence of the real system’ (Fortier & Michel 2003). This section reviews seven existing testbeds developed in the water domain for the simulation of monitoring and control processes. The reviewed testbeds are shown in Table 1, and the testbeds are also compared and contrasted with ACWA.
Water testbed . | Main declared purpose . |
---|---|
WaterBox (Kartakis et al. 2015) | Simulation of monitoring and control processes of smart water networks |
EARNPIPE (Karray et al. 2016) | Detection of leaks and localisation |
Secure Water Treatment (SWaT) (Goh et al. 2017) | Representation and simulation of scaled-down version of real-world water treatment |
Failure and Attack on interdependent Critical InfrastructurES (FACIES) (Bernieri et al. 2017) | Emulate a water system of a small city |
PLC-based water system (Laso et al. 2017) | Detection of anomalies and malicious acts in cyber-physical systems |
Water Distribution testbed (WADI) (Ahmed et al. 2017) and the Security Water Processing (SWaP) testbed (Calder et al. 2023) | Representation and simulation of scaled-down version of a large water distribution network in a city – SWaP, an add-on, is an industrial control system for security research and training |
Smart water campus (Oberascher et al. 2022a, 2022b) | Water systems for fault detection and utilisation of cross-system rainwater harvesting |
Water testbed . | Main declared purpose . |
---|---|
WaterBox (Kartakis et al. 2015) | Simulation of monitoring and control processes of smart water networks |
EARNPIPE (Karray et al. 2016) | Detection of leaks and localisation |
Secure Water Treatment (SWaT) (Goh et al. 2017) | Representation and simulation of scaled-down version of real-world water treatment |
Failure and Attack on interdependent Critical InfrastructurES (FACIES) (Bernieri et al. 2017) | Emulate a water system of a small city |
PLC-based water system (Laso et al. 2017) | Detection of anomalies and malicious acts in cyber-physical systems |
Water Distribution testbed (WADI) (Ahmed et al. 2017) and the Security Water Processing (SWaP) testbed (Calder et al. 2023) | Representation and simulation of scaled-down version of a large water distribution network in a city – SWaP, an add-on, is an industrial control system for security research and training |
Smart water campus (Oberascher et al. 2022a, 2022b) | Water systems for fault detection and utilisation of cross-system rainwater harvesting |
Karray et al. (2016) presented EARNPIPE to provide a low-power wireless sensor network (WSN) solution that detects leaks (and provides localisation). The meaning of localisation in this context is the sectional leaks in an otherwise leakage-free pipe. This testbed is constructed in a rectangular shape with polyethylene pipes, which support pressure up to 12 bar (1 bar = 100,000 pa). Further, two valves are installed as an inlet and outlet to vary water demand by varying the pressure. EARNPIPE also includes a 1,000 m3 reservoir for water storage and an electric pump with one Horsepower (hp) for pumping water from the reservoir to pipes. To induce leaks, two garden taps are used in their setup. The authors also have proposed and discussed the implementation of leak detection (Leak Detection Predictive Kalman Filter) and localisation algorithms (modified time difference of arrival) (Karray et al. 2016).
Laso et al. (2017) presented a dataset generated from the physical water testbed to enable the detection of anomalies and malicious acts in cyber-physical systems. This testbed utilises two tanks (one with a 7-L capacity and the other with a 9-L) for storing water or fuel, one ultrasound depth sensor, four discrete sensors, and two pumps. The physical components are controlled and monitored using a computer connected to a programmable logic controller (PLC). This water testbed simulates 15 unique situations affecting ultrasound sensors, discrete sensors, the underlying network, or the whole subsystem.
Ahmed et al. (2017) presented an architecture of a Water Distribution testbed (WADI), a scaled-down version of a large water distribution network of a city, in 2023, the same team released an additional SWaP testbed as indicated in Table 1. WADI consists of three stages (P1, P2, and P3), when in operation, it can supply 10 gallons/min of filtered water. The P1 is a primary grid that contains two water tanks (2,500 L each), a water level sensor, and a chemical system that maintains the water quality. Additionally, water quality sensors are also installed in P1. The second stage is P2, which indicates the secondary grid. This stage consists of two elevated reservoir tanks and six consumer tanks. The raw tanks from P1 supply water to these elevated tanks based on pre-set demand patterns set by the authors. Lastly, P3 deals with the return water grid, which is also equipped with a tank. When the demands of the consumer tanks are met in P2, the water drains to the return water grid. Detailed information on communication infrastructures and how they can help analyse an attack's impact is provided by Ahmed et al. (2017).
Oberascher et al. (2022a, 2022b) described the Smart water campus testbed for monitoring water networks that can be useful for fault detection in real-time along with involving cross-system improvements like rainwater harvesting. The authors noted that the Smart water campus is a network-based urban water infrastructure that integrates a water distribution network, an urban drainage network, and nature-based solutions. The testbed leverages perception, communication, middleware, and processing layers. A detailed description of the four layers used in the Smart water campus testbed and a demonstration of smart applications can be found in Oberascher et al. (2022a, 2022b).
The scope of most of the existing testbeds summarised in this section is either within one or two experimental spectrums. For example, WaterBox (Kartakis et al. 2015) focuses on the simulation of monitoring and control processes of water networks and EARNPIPE (Karray et al. 2016) is designed to detect leaks and localisation, ACWA (the new testbed presented in this paper) aims to provide a dynamic environment that allows for multiple scenarios, including related to irrigation and soil, a notion missing from existing testbeds. SWaT (Goh et al. 2017), WADI (Ahmed et al. 2017), and FACIES (Bernieri et al. 2017) are explicitly developed for studying the effects of attacks (cyber and physical) on water plants while Laso et al. (2017) presented a testbed for anomaly/malicious act detection. These testbeds involve components such as pipes, pumps, and valves along with flow and water level sensors, but these testbeds do not capture water chemicals and related parameters (which is commonly a manner of attack on water systems), the lack of such experimentation renders these testbeds limited. Smart water campus (Oberascher et al. 2022a, 2022b) is the only testbed focusing on water quality parameters and on capturing soil and climate-related variables, although it is spread across eight hectares and does not provide the ability to run distributed AI algorithms. Considering these aspects, the ACWA testbed differentiates from the reviewed testbeds via the following main characteristics:
- 1.
Modularity: The components of the testbed (multiple water networks) are designed modularly. This unique flexibility allows for the creation of new topologies and to add more nodes (such as pumps, valves, pipes, tanks, sensors, soil, and reservoirs) in any topology based on the experiment's design and goals.
- 2.
Sensors: The ACWA testbed has 14 water sensors that capture data on traditional water parameters, such as water level, water pressure, and water flow; and quality variables, such as pH, temperature, dissolved oxygen (DO), nitrate, and electrical conductivity (EC) – among other data points listed in this manuscript. Additionally, the soil topology is equipped with a soil moisture sensor, water turbidity, and two soil probes to capture EC and temperature data.
- 3.
Data: The big data created at ACWA are captured at 1-, 5-, and 30-s intervals and are stored in a local MongoDB database. This unique feature allows researchers to capture granular-level data and analyse minuscule changes in sensor values, including the deployment of AI and security algorithms. A data collection frequency not found anywhere else.
- 4.
Water and soil: The ACWA testbed is carefully designed and planned to accommodate a soil topology with four soil beds along with Line, Star, and Bus water network topologies.
Furthermore, there is a lack of existing software water simulators, the most commonplace water simulator is EPANET, a prolonged hydraulic and water quality dynamics simulator built within a pressurised piping systems environment; based on Rossman (2000), EPANET is also used in commercial software development – in our open access GitHub repository (https://github.com/AI-VTRC/ACWA-Data), we also share the EPANET model for ACWA (in Appendix E), accessible to other researchers. A main addition that we present via ACWA is also a digital twin, namely, the ACWA simulator, also presented in this paper. The next section presents the main parts of ACWA, the main contribution of this paper.
METHODS
To dynamically simulate and collect real-time data on different scenarios of WSS, the laboratory's sensors are built into four topologies to capture water and soil quality attributes, such as pH, temperature, DO, turbidity, nitrate levels, EC, soil moisture, water level, pressure, and flow rate. These data are stored in a MongoDB database for analysis, model development, and AI assurance, which can assist in tackling rising challenges in the water and agricultural domains as found in recent literature (Dobermann et al. 2004; Li et al. 2020; Saad et al. 2020; Batarseh & Kulkarni 2023).
The cyber-physical water topologies
A topology is a physical and logical arrangement of nodes and connections in a network. Literature (Peterson & Davie 2007; Liu & Liu 2014) indicates seven commonly used network topologies: Line, Bus, Star, Ring, Mesh, Tree, and Hybrid. These topologies are foundational in computer networks. However, literature on WSS indicates four main structures: grid-iron, ring, radial, and dead-end (Adeosun 2014). These four structures can be designed using the fundamental computer network topologies. In dead-end WSS (National Research Council 2007), the main line is at the centre, and sub-main lines are divided into branches. This structure can be developed using a Bus topology at ACWA in which the nodes are connected to a central line using a branch-like structure. Similarly, Ring WSS is a circular system, and a line topology can be turned into a Ring WSS if we connect the first and last nodes of a network. Also, in Radial WSS (National Research Council 2007), a reservoir is present at the centre, and water is distributed directly from it, which can be represented using ACWA's Star topology. Considering these aspects and motivation from computer networks, we have built Line, Star, and Bus topologies. In these topologies, nodes are represented by water tanks and they are connected to pumps and reservoirs using pipes and tubes. These topologies are placed independently on three tables of sizes 5 inches × 2.6 inches × 2.5 inches (length × width × height), which can also be connected into a hybrid topology using Poly Vinyl Chloride (PVC) or Chlorinated Poly Vinyl Chloride (CPVC) pipes. In our setup, we used two big water tanks (35 gallons) as reservoirs to provide water to the testbed. The detailed descriptions of these three topologies are as follows.
Line topology
Bus topology
In this topology, four rectangular tanks and two diaphragm water pumps are connected via ¾ inch C-PVC pipes, as Figure 4(b) indicates. In Bus topology, the C-PVC pipe is installed at the centre, alternatively distributing water to two tanks on each side. The water flow also can be changed using manual valves, which are installed for every tank and line. The four tanks in this topology are 16.25 inches × 8.375 inches × 10.5 inches (length × width × height) in size and have a 5.5-gallon water storage capacity. For data collection in real time, the water level and EC sensors are mounted while the pressure sensor is installed on a main line ¾ inch C-PVC pipe.
Star topology
The Star topology is developed by connecting one medium-size and four small-size water tanks via ½ inch C-PVC pipes. A schematic diagram for Star topology is shown in Figure 4(c). This topology is designed using four diaphragm water pumps and five cubical tanks. In this topology, one diaphragm water pump transfers water from the main water reservoir to the central tank (node), and then two additional diaphragm water pumps distribute this water to four other small tanks. The manual valves for each tank are provided to change or control the water flow. Lastly, at the end of the experiment, the fourth pump pulls water from all four tanks back to the reservoir. This process is performed using a four-way water splitter and tubes. The four tubes are immersed in four small tanks to pull the water and transfer it back to the reservoir. The water flow can also be controlled or turned on/off using the individual valves on the splitter. The central tank used in this topology is 15.25 inches × 15.25 inches × 15.25 inches (length × width × height) in size and has a 14-gallon water storage capacity. The four small tanks are 9.25 inches × 9.25 inches × 9.25 inches (length × width × height) in size and each tank has a 3-gallon water storage capacity. For data collection in real-time, water level, pH, temperature, and EC sensors are installed. Also, one water level sensor is mounted to capture data from the reservoir that provides water for this topology.
Soil topology
The mentioned topologies are connected to computational nodes and sensors, and via multiple communication protocols; the details of which are presented in the following sections. Appendix A shows other photos from the testbed.
Sensors, chemicals, and technologies deployed
This section includes details on the sensors built into the ACWA topologies, including their communication protocols, as well as the chemicals and solutions applied for AI and Cyber experimentation. The list of sensors is presented in Table 2. Table 3 lists the main experimental chemicals and chemical solutions at ACWA.
Label . | Name . | Communication protocol . | Type . | Topology . |
---|---|---|---|---|
S01 | S01_NCD_EcTempDo | Zigbee | EC/Temp/DO Sensor | Bus |
S02 | S02_NCD_EcTempDo | Zigbee | EC/Temp/DO Sensor | Star |
S03 | S03_NCD_PhTemp | Zigbee | pH/Temp Sensor | Line |
S04 | S04_NCD_PhTemp | Zigbee | pH/Temp Sensor | Star |
S05 | S05_NCD_MoistTempEC | Zigbee | Soil Moisture/Temp/EC Sensor | Soil, Pot 1 |
S06 | S06_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Line, Bus, Reservoir |
S07 | S07_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Star, Reservoir |
S08 | S08_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Soil |
S09 | S09_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Line |
S10 | S010_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Bus |
S11 | S011_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Star |
S12 | S12_Keyence_Pressure | Modbus | GP-MT | Bus |
S13 | S13_Keyence_Flow | Modbus | FD-H | Line |
S14 | S14_Lcom_Turbidity | Modbus | SRWQ100 | Soil, Water Tank |
S15 | S15_ECD_Nitrate | Modbus | S80 Nitrate Ion Sensor | Line |
S16 | Soil moisture probe | LoRa | Soilmote | Soil, Pot 1 |
S17 | Soil moisture probe | LoRa | Soilmote | Soil, Pot 2 |
Label . | Name . | Communication protocol . | Type . | Topology . |
---|---|---|---|---|
S01 | S01_NCD_EcTempDo | Zigbee | EC/Temp/DO Sensor | Bus |
S02 | S02_NCD_EcTempDo | Zigbee | EC/Temp/DO Sensor | Star |
S03 | S03_NCD_PhTemp | Zigbee | pH/Temp Sensor | Line |
S04 | S04_NCD_PhTemp | Zigbee | pH/Temp Sensor | Star |
S05 | S05_NCD_MoistTempEC | Zigbee | Soil Moisture/Temp/EC Sensor | Soil, Pot 1 |
S06 | S06_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Line, Bus, Reservoir |
S07 | S07_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Star, Reservoir |
S08 | S08_Senix_WL | LoRa | Tough Sonic 50 Level Sensor | Soil |
S09 | S09_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Line |
S10 | S010_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Bus |
S11 | S011_Senix_WL | LoRa | Tough Sonic 14 Level Sensor | Star |
S12 | S12_Keyence_Pressure | Modbus | GP-MT | Bus |
S13 | S13_Keyence_Flow | Modbus | FD-H | Line |
S14 | S14_Lcom_Turbidity | Modbus | SRWQ100 | Soil, Water Tank |
S15 | S15_ECD_Nitrate | Modbus | S80 Nitrate Ion Sensor | Line |
S16 | Soil moisture probe | LoRa | Soilmote | Soil, Pot 1 |
S17 | Soil moisture probe | LoRa | Soilmote | Soil, Pot 2 |
Type . | Concentration(s) . | Usage . |
---|---|---|
pH | 4.01 7 10.01 | Calibration of NCD pH and temperature sensor for three-point calibration |
Turbidity | 0 NTU, 100 NTU | Calibration of L-com Turbidity sensor for two-point calibration |
EC | 12.88 mS/cm 64 mS/cm | Calibration of NCD EC sensor for two-point calibration |
Nitrate | 10 ppm 100 ppm | Calibration of ECD Nitrate sensor for two-point calibration |
DO | Zero oxygen | Calibration of NCD DO sensor |
Sodium Hydroxide | 0.1 M | Experiment design and simulation |
Distilled Water | — | To remove mineral build-up from sensors |
Type . | Concentration(s) . | Usage . |
---|---|---|
pH | 4.01 7 10.01 | Calibration of NCD pH and temperature sensor for three-point calibration |
Turbidity | 0 NTU, 100 NTU | Calibration of L-com Turbidity sensor for two-point calibration |
EC | 12.88 mS/cm 64 mS/cm | Calibration of NCD EC sensor for two-point calibration |
Nitrate | 10 ppm 100 ppm | Calibration of ECD Nitrate sensor for two-point calibration |
DO | Zero oxygen | Calibration of NCD DO sensor |
Sodium Hydroxide | 0.1 M | Experiment design and simulation |
Distilled Water | — | To remove mineral build-up from sensors |
The sensors are connected to computers and GPU devices via three communication protocols, Modbus, Long Range, and Zigbee, as follows: (1) Modbus: A widely used communication protocol (Thomas 2008) in industrial automation and control systems. It allows different electronic devices, such as sensors, actuators, and PLCs, to exchange data and control commands over a network. Modbus is characterised by its simplicity and versatility, making it suitable for simple and complex applications in various industries. It operates over different physical layers, including serial connections like RS-232, RS-485, and Ethernet, making it adaptable to different communication needs. (2) Long Range: LoRa, or Long Range, is a wireless communication technology for long-distance data transmission with low-power consumption (Devalal & Karthikeyan 2018). It enables devices to communicate wirelessly over extended ranges. This makes LoRa useful for applications such as Internet of Things (IoT) devices, smart city solutions, and rural connectivity. LoRa uses spread spectrum modulation techniques to achieve reliable communication even in challenging environments, and its low-power requirements make it suitable for battery-operated devices, extending its operational lifespan. (3) Zigbee: A wireless communication protocol (Ergen 2004) developed for creating low-power, short-range networks among various devices. It is designed for home automation and industrial control. The Zigbee protocol enables efficient and reliable data exchange. It operates on the IEEE 802.15.4 standard and uses a mesh network topology. This allows devices to communicate directly or indirectly through other devices, enhancing coverage and reliability. Zigbee's focus on low-power consumption makes it well-suited for battery-operated devices in smart homes and IoT applications.
To manage data streams for AI development and Cyberbiosecurity measures, the following softwares are used (but not limited to): MongoDB, NodeRed, R Dashboards, Python, TensorFlow, Keras, and other data management technologies, more information on that is listed in the public access GitHub page: https://github.com/AI-VTRC/ACWA-Data. The next section presents the ACWA simulator and its structural details.
The ACWA simulator
The ACWA simulator generates a CSV file incorporating time series data of all the parameters for every simulation. The novel part of the simulator is that it provides a time series for both hydraulic parameters, such as water level and pressure, along with water nutrient parameters, such as pH, Nitrate, BOD, and NaOH, which change every second. These generated data can be used for calibration, validation, AI modelling, data poisoning experiments, and comparison with the physical system. Inputs to the simulator environment include pH, BOD, DO, Nitrate, NaOH, Water Level, Water Temperature, Water Density, Kinematic Viscosity, Discharge, Pipe Material, Pipe Length, Pipe Diameter, Tank Shape, Tank Size – the data outcomes of the simulator as presented in Table 4.
Variable . | Description . | Unit . | Data type . | Sample value . |
---|---|---|---|---|
Time | Timestep of the simulation | HH:MM:SS | Date/Time | 00:00:00 |
Reservoir water level | Water level in the reservoir | Meters (m) | Float | 9.01 |
Tank water level | Water level in the tank | Meters (m) | Float | 3.07 |
Pressure at reservoir bed | Pressure at the bottom of the reservoir | Pounds per square inch (psi) | Float | 18.96 |
Pressure at tank bed | Pressure at the bottom of the tank | Pounds per square inch (psi) | Float | 14.68 |
Water temperature (°C) | Temperature of the water | Degrees celsius (°C) | Float | 27.85 |
pH | pH value of the water | Unitless | Float | 6.49 |
BOD (mg/L) | BOD level | Milligrams per litre (mg/L) | Float | 2.88 |
DO (mg/L) | DO level | Milligrams per litre (mg/L) | Float | 7.79 |
Nitrate (mg/L) | Concentration of nitrate | Milligrams per litre (mg/L) | Float | 16.13 |
NaOH (mg/L) | Concentration of sodium hydroxide (NaOH) | Milligrams per litre (mg/L) | Float | 0.78 |
Variable . | Description . | Unit . | Data type . | Sample value . |
---|---|---|---|---|
Time | Timestep of the simulation | HH:MM:SS | Date/Time | 00:00:00 |
Reservoir water level | Water level in the reservoir | Meters (m) | Float | 9.01 |
Tank water level | Water level in the tank | Meters (m) | Float | 3.07 |
Pressure at reservoir bed | Pressure at the bottom of the reservoir | Pounds per square inch (psi) | Float | 18.96 |
Pressure at tank bed | Pressure at the bottom of the tank | Pounds per square inch (psi) | Float | 14.68 |
Water temperature (°C) | Temperature of the water | Degrees celsius (°C) | Float | 27.85 |
pH | pH value of the water | Unitless | Float | 6.49 |
BOD (mg/L) | BOD level | Milligrams per litre (mg/L) | Float | 2.88 |
DO (mg/L) | DO level | Milligrams per litre (mg/L) | Float | 7.79 |
Nitrate (mg/L) | Concentration of nitrate | Milligrams per litre (mg/L) | Float | 16.13 |
NaOH (mg/L) | Concentration of sodium hydroxide (NaOH) | Milligrams per litre (mg/L) | Float | 0.78 |
The software simulator has built-in physical assumptions that can be updated and tuned using the code; the following nine assumptions are set:
- 1.
Water is assumed to be an incompressible Newtonian fluid (Mott & Untener 2015).
- 2.
Water is in a steady state, i.e., the type of flow throughout the process will not change.
- 3.
Flow should either be laminar or turbulent. This is implemented in the constraints section.
- 4.
The reservoir and tanks are at atmospheric pressure.
- 5.
Only head loss due to friction, entry, and exit loss is considered.
- 6.
pH interacts with NaOH; BOD interacts with DO. No other mutual interactions are considered. The change in constituents is determined only by wall reaction, bulk reaction, and decay function.
- 7.
Temperature can change only due to differences in air temperature and convection.
- 8.
The model assumes a steady-state scenario, i.e., the conditions are not changing with time, only with position along the pipe. The fluid properties (like density, specific heat, and the heat transfer coefficient) are constant. This might not be the case, especially if the temperature changes significantly.
- 9.
The surface temperature of the pipe is assumed to be constant along the length of the pipe.
Additionally, multiple physical characteristics are built into the system, related to the input variables mentioned previously, those are presented in Table 5 (Simulator inputs are presented in Appendix C).
Input's physical representation . | Description . | Source for formulasa . |
---|---|---|
Water density | Auto-generated and constrained as a function of water temperature. | Kell (1975) |
Kinematic viscosity | Expressed as a function of temperature. | Guo et al. (2020) |
Overflow check | Overflow can occur when the volume of water pumped into a tank exceeds its maximum capacity. Mathematically speaking, the available volume in tank 2 must always be adequate to water transported from tank 1. | Modi & Seth (2019) |
Pipe flow safety factor | The diameter-to-length ratio is critical to prevent open channel flow and ensure the pipe remains full (avoiding ‘slug’ flow or a mix of air and water). There is no strict ratio for all systems, but it depends on the specifics of the setup; a general guideline for keeping pipes fully pressurised is to ensure sufficient inlet head or pressure. | Mays (2000) |
Flow type | Laminar and turbulent flows are two fundamental flow regimes in fluid dynamics, and they describe how fluid particles move within a conduit – pipe, open channel, or flow medium. Laminar or streamlined flow occurs when fluid flows in parallel layers (or laminae) with minimal mixing or lateral crossover between the layers. Turbulent flow is characterised by chaotic, irregular motion of particles in which fluid particles move randomly and swirl. It is necessary to determine whether the flow is laminar or turbulent. | Mott & Untener (2015) |
Elevation pressure | Conveys how a force is distributed over a particular surface. The water pressure depends on the height of the water column, i.e., how high the water surface is above the tank/reservoir bed. | Mott & Untener (2015) |
Energy loss | The hydraulic movement in the given system is governed by the energy equation derived from Bernoulli's equation of fluid flow. | Mott & Untener (2015) |
Pipe head loss | When pumped water goes through the pipes and due to friction generated in the pipe, the water will lose energy, resulting in decreased pressure in terms of head loss. | Mott & Untener (2015) |
Friction factor | The Colebrook–White formula can be used to find out the friction factor. | Brandt et al. (2017) |
Valves and joints loss | Entry and exit loss. | Mott & Untener (2015) |
Water level rise | Considering all the friction loss and other energy conditions, there will be a specific flow at the end of the pipe and pressure. This will, in turn, transfer into the tank, and the water level will rise depending on the tank area. | Modi & Seth (2019) |
Advective transport | Longitudinal dispersion is usually not a vital transport mechanism under most operating conditions. This means there is no intermixing of mass between adjacent parcels of water travelling down a pipe. | Chaudhry & Mays (2012) |
Mixing in storage facilities | It is convenient to assume that the contents of storage facilities (tanks and reservoirs) are entirely mixed. This is a reasonable assumption for many tanks operating under fill-and-draw conditions, providing sufficient momentum flux is imparted to the inflow. | Rossman & Grayman (1999) |
Heat transfer | For heat transfer of the fluid through pipe, convection theorem is used to model convective heat transfer from the outside environment to the water through the pipe. | Bergman (2011) |
Input's physical representation . | Description . | Source for formulasa . |
---|---|---|
Water density | Auto-generated and constrained as a function of water temperature. | Kell (1975) |
Kinematic viscosity | Expressed as a function of temperature. | Guo et al. (2020) |
Overflow check | Overflow can occur when the volume of water pumped into a tank exceeds its maximum capacity. Mathematically speaking, the available volume in tank 2 must always be adequate to water transported from tank 1. | Modi & Seth (2019) |
Pipe flow safety factor | The diameter-to-length ratio is critical to prevent open channel flow and ensure the pipe remains full (avoiding ‘slug’ flow or a mix of air and water). There is no strict ratio for all systems, but it depends on the specifics of the setup; a general guideline for keeping pipes fully pressurised is to ensure sufficient inlet head or pressure. | Mays (2000) |
Flow type | Laminar and turbulent flows are two fundamental flow regimes in fluid dynamics, and they describe how fluid particles move within a conduit – pipe, open channel, or flow medium. Laminar or streamlined flow occurs when fluid flows in parallel layers (or laminae) with minimal mixing or lateral crossover between the layers. Turbulent flow is characterised by chaotic, irregular motion of particles in which fluid particles move randomly and swirl. It is necessary to determine whether the flow is laminar or turbulent. | Mott & Untener (2015) |
Elevation pressure | Conveys how a force is distributed over a particular surface. The water pressure depends on the height of the water column, i.e., how high the water surface is above the tank/reservoir bed. | Mott & Untener (2015) |
Energy loss | The hydraulic movement in the given system is governed by the energy equation derived from Bernoulli's equation of fluid flow. | Mott & Untener (2015) |
Pipe head loss | When pumped water goes through the pipes and due to friction generated in the pipe, the water will lose energy, resulting in decreased pressure in terms of head loss. | Mott & Untener (2015) |
Friction factor | The Colebrook–White formula can be used to find out the friction factor. | Brandt et al. (2017) |
Valves and joints loss | Entry and exit loss. | Mott & Untener (2015) |
Water level rise | Considering all the friction loss and other energy conditions, there will be a specific flow at the end of the pipe and pressure. This will, in turn, transfer into the tank, and the water level will rise depending on the tank area. | Modi & Seth (2019) |
Advective transport | Longitudinal dispersion is usually not a vital transport mechanism under most operating conditions. This means there is no intermixing of mass between adjacent parcels of water travelling down a pipe. | Chaudhry & Mays (2012) |
Mixing in storage facilities | It is convenient to assume that the contents of storage facilities (tanks and reservoirs) are entirely mixed. This is a reasonable assumption for many tanks operating under fill-and-draw conditions, providing sufficient momentum flux is imparted to the inflow. | Rossman & Grayman (1999) |
Heat transfer | For heat transfer of the fluid through pipe, convection theorem is used to model convective heat transfer from the outside environment to the water through the pipe. | Bergman (2011) |
aAll formulas are presented in Appendix B.
ACWA data
The data created from all the mentioned parts in this section are the main outcome of ACWA; the data variables are presented in Table 6 (data samples are available in the mentioned public GitHub repository; other datasets are available upon demand from the authors).
EC temperature DO sensor (S01, S02) . | ||
---|---|---|
Field value . | Description . | Example value . |
Addr | Device Address | 00:13:a2:00:42:29:e7:3d |
Battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
Counter | Counter | 113 |
firmware | Firmware version | 2 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,2,3,255,113,0,66,0,0,0,0,0,0,0,0,0,0,0,0,0,8,121,0,0,1,213,0,0,20,243,8,194] |
original.mac | Mac Address | 00:13:a2:00:42:29:e7:3d |
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
Rssi | RF signal strength | 40 |
sensor_data.DO | DO | 4.69 |
sensor_data.DO_Saturation | DO saturation | 53.63 |
sensor_data.EC | EC | 0 |
sensor_data.Salinity | Salinity | 0 |
sensor_data.TDS | TDS | 0 |
sensor_data.Temp | Temperature | 21.69 |
sensor_data.Temp_DO | Temperature of DO | 22.42 |
sensor_name | Name | EC and DO and temperature sensor |
sensor_type | Sensor Type | 66 |
Type | Type | sensor_data |
pH temperature sensor (S03, S04) | ||
Field value | Description | Example value |
addr | Device address | 00:13:a2:00:42:29:e7:06 |
battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
counter | Counter | 1 |
firmware | Firmware version | 4 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,4,3,255,1,0,61,0,3,120,8,85] |
original.mac | Mac address | 00:13:a2:00:42:29:e7:06 |
original.receive_options | ||
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
rssi | RF signal strength | 40 |
sensor_data.Temp | Temperature | 21.33 |
sensor_data.pH | pH | 8.88 |
sensor_name | Name | pH and temperature sensor |
sensor_type | Sensor Type | 61 |
type | Type | sensor_data |
Soil moisture temperature EC Sensor (S05) | ||
Field value | Description | Example value |
addr | Device Address | 00:13:a2:00:42:29:e7:43 |
battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
counter | Counter | 123 |
firmware | Firmware version | 4 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,4,3,255,123,0,69,0,0,0,0,0,0,0,8,122,0,0,0,0,0,0,0,0] |
original.mac | Mac address | 00:13:a2:00:42:29:e7:43 |
original.receive_options | ||
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
rssi | RF signal strength | 40 |
sensor_data.EC | EC | 0 |
sensor_data.Moisture | Moisture | 0 |
sensor_data.Temperature | Temperature | 21.7 |
sensor_name | Name | Soil moisture temperature EC sensor |
sensor_type | Sensor Type | 69 |
type | Type | sensor_data |
Water Level Sensor (S06, S07, S08, S09, S10, S11) | ||
Field value | Description | Example value |
Counts | Sensor counts in the latest cycle | 20,365 |
DI | 1 | |
Distance | Target distance in mm | 275.660634 |
FWVer | Transmitter firmware version | 1.12 |
FaultMsg | Displayed message if any | |
Flags | 0 | |
FriendlyName | Displayed sensor name | AirWire 1005 |
Hyst | Hysteresis in units, alarm to reset | 0 |
LOffset | Linear Offset in units, number line zero | 0 |
LScale | Scale, Units to sensor Counts | 0.013536 |
LUnits | Linear Units displayed as Tag | Inches |
Lat | Latitude of sensor (not used) | 44.3315392 |
LifeCount | Lifetime count of transmitter | 29,993 |
Log | Log text displayed | AirWire 1005 measured 275.66 Inches on May 3 @ 14:08:03 |
LogSpace | 7,373 | |
Lon | Longitude of sensor (not used) | −73.111984 |
OnTime | Transmitter time at full power, D- | 1-06:01:11 |
HH:MM: SS | ||
RSSI | RF signal strength | −59 |
RangeMax | Max range displayed on Bar Graph | 600 |
RangeMin | Min range displayed on Bar Graph | 0 |
RateTime1 | Start SampleRate1 (24 h mode) | 8:00 |
RateTime2 | Start SampleRate2 (24 h mode) | 17:00 |
RawCounts | Sensor counts in the latest cycle (unfiltered) | 20,593 |
RetryMax | Maximum transmit retries | 0 |
SNR | – | 12.2 |
SampleRate1 | Sample Rate 1 in seconds | 60 |
SampleRate2 | Sample Rate 2 in seconds | 60 |
SensorFWVer | Sensor firmware version | 47 |
SensorHardwareId | Sensor hardware identification | 1,017 |
SensorProductId | Sensor model identification | 4,006 |
SensorProductName | Sensor brand name | ToughSonic 50P |
SensorTemp | Sensor internal temperature (°F) | 68.44 |
ShotCount | Measure cycles since last reset | 29,993 |
Time | Date and time of latest data | 08:03.2 |
TransmitterBat | Voltage level, transmitter (v) | 3.657 |
TransmitterTemp | Temperature, transmitter (°F) | 60.6 |
TxFaultCount | Sum of transmit retries since reset | 2,632 |
UTCmsec | Universal time from 1 Jan 1970 | 1.68 × 1012 |
_id | – | 6452a304f5626fa35f3c08a5 |
alarm | Current alarm displayed | – |
cmd | – | 64 |
ecode | – | 20 |
eui | End unit identifier of transmitter | 00-80-00-00-00-01-99-bf |
filename | Path and filename of current active log in receiver gateway | /media/card/senix/00-80-00-00-00-01-99-bf/AirWire_00-80-00-00-00-01-99-bf_2023.05.03 |
gweui | End unit identifier of gateway | 00-80-00-00-a0-00-6d-0d |
icon | – | wifi |
time | Date and time of latest data | 2023-05-03T18:08:03.175498Z |
timetext | Timestamp on display | May 3 @ 14:08:03 |
tstr115 | – | Critical H |
tstr67 | – | AirWire 10 |
Pressure Sensor (S12) | ||
Field value | Description | Example Value |
pressure | Pressure | 0 |
pressure_unit | Pressure unit | psi |
temperature | Temperature | 24.2 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
Flow sensor (S13) | ||
Field value | Description | Example value |
flow | Flow rate | 0 |
flow_acc | Flow accumulation | 7.3 |
flow_acc_unit | Flow accumulation unit | Gallon |
flow_unit | Flow rate unit | g/min |
temperature | Temperature | 31.8 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
Lcom – Turbidity sensor (S14) | ||
Field value | Description | Example value |
current | Output (4–20 mA) | 16.875 |
current_unit | Output unit | mA |
temperature | Temperature | 25.109993 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
turbidity | Turbidity | 3,232 |
turbidity_unit | Turbidity unit | NTU |
Nitrate ion sensor (S15) | ||
Field value | Description | Example value |
current | Output (4–20 mA) | 16.875 |
current_unit | Output unit | mA |
temperature | Temperature | 25.109993 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
nitrate_ion | Nitrate Ion | 45.14 |
nitrate_ion_unit | Nitrate unit | ppm |
Soil Probes (S16 and S17) | ||
Field value | Description | Example value |
mostRecentData.soilmoisture.t | Time of day | 2023-09-16 T17:30:00 + 00:00 |
mostRecentData.soilmoisture.u | Moisture percentage | % |
mostRecentData.soilmoisture.v | Moisture value | 6.66 |
mostRecentData.soilmoisture.i | Index | 5 |
mostRecentData.soilmoisture.via reportingInterval | data collection frequency | 5 |
reportingVia | Unit | Mqtt |
EC temperature DO sensor (S01, S02) . | ||
---|---|---|
Field value . | Description . | Example value . |
Addr | Device Address | 00:13:a2:00:42:29:e7:3d |
Battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
Counter | Counter | 113 |
firmware | Firmware version | 2 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,2,3,255,113,0,66,0,0,0,0,0,0,0,0,0,0,0,0,0,8,121,0,0,1,213,0,0,20,243,8,194] |
original.mac | Mac Address | 00:13:a2:00:42:29:e7:3d |
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
Rssi | RF signal strength | 40 |
sensor_data.DO | DO | 4.69 |
sensor_data.DO_Saturation | DO saturation | 53.63 |
sensor_data.EC | EC | 0 |
sensor_data.Salinity | Salinity | 0 |
sensor_data.TDS | TDS | 0 |
sensor_data.Temp | Temperature | 21.69 |
sensor_data.Temp_DO | Temperature of DO | 22.42 |
sensor_name | Name | EC and DO and temperature sensor |
sensor_type | Sensor Type | 66 |
Type | Type | sensor_data |
pH temperature sensor (S03, S04) | ||
Field value | Description | Example value |
addr | Device address | 00:13:a2:00:42:29:e7:06 |
battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
counter | Counter | 1 |
firmware | Firmware version | 4 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,4,3,255,1,0,61,0,3,120,8,85] |
original.mac | Mac address | 00:13:a2:00:42:29:e7:06 |
original.receive_options | ||
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
rssi | RF signal strength | 40 |
sensor_data.Temp | Temperature | 21.33 |
sensor_data.pH | pH | 8.88 |
sensor_name | Name | pH and temperature sensor |
sensor_type | Sensor Type | 61 |
type | Type | sensor_data |
Soil moisture temperature EC Sensor (S05) | ||
Field value | Description | Example value |
addr | Device Address | 00:13:a2:00:42:29:e7:43 |
battery | Battery voltage | 3.29 |
battery_percent | Battery life | 99.64 |
counter | Counter | 123 |
firmware | Firmware version | 4 |
nodeId | Node ID | 0 |
original.data | Raw data | [127,0,4,3,255,123,0,69,0,0,0,0,0,0,0,8,122,0,0,0,0,0,0,0,0] |
original.mac | Mac address | 00:13:a2:00:42:29:e7:43 |
original.receive_options | ||
original.rssi | Raw RF signal strength | [object Object] |
original.type | Type | receive_packet |
received | Data received size | 1.68 × 1012 |
rssi | RF signal strength | 40 |
sensor_data.EC | EC | 0 |
sensor_data.Moisture | Moisture | 0 |
sensor_data.Temperature | Temperature | 21.7 |
sensor_name | Name | Soil moisture temperature EC sensor |
sensor_type | Sensor Type | 69 |
type | Type | sensor_data |
Water Level Sensor (S06, S07, S08, S09, S10, S11) | ||
Field value | Description | Example value |
Counts | Sensor counts in the latest cycle | 20,365 |
DI | 1 | |
Distance | Target distance in mm | 275.660634 |
FWVer | Transmitter firmware version | 1.12 |
FaultMsg | Displayed message if any | |
Flags | 0 | |
FriendlyName | Displayed sensor name | AirWire 1005 |
Hyst | Hysteresis in units, alarm to reset | 0 |
LOffset | Linear Offset in units, number line zero | 0 |
LScale | Scale, Units to sensor Counts | 0.013536 |
LUnits | Linear Units displayed as Tag | Inches |
Lat | Latitude of sensor (not used) | 44.3315392 |
LifeCount | Lifetime count of transmitter | 29,993 |
Log | Log text displayed | AirWire 1005 measured 275.66 Inches on May 3 @ 14:08:03 |
LogSpace | 7,373 | |
Lon | Longitude of sensor (not used) | −73.111984 |
OnTime | Transmitter time at full power, D- | 1-06:01:11 |
HH:MM: SS | ||
RSSI | RF signal strength | −59 |
RangeMax | Max range displayed on Bar Graph | 600 |
RangeMin | Min range displayed on Bar Graph | 0 |
RateTime1 | Start SampleRate1 (24 h mode) | 8:00 |
RateTime2 | Start SampleRate2 (24 h mode) | 17:00 |
RawCounts | Sensor counts in the latest cycle (unfiltered) | 20,593 |
RetryMax | Maximum transmit retries | 0 |
SNR | – | 12.2 |
SampleRate1 | Sample Rate 1 in seconds | 60 |
SampleRate2 | Sample Rate 2 in seconds | 60 |
SensorFWVer | Sensor firmware version | 47 |
SensorHardwareId | Sensor hardware identification | 1,017 |
SensorProductId | Sensor model identification | 4,006 |
SensorProductName | Sensor brand name | ToughSonic 50P |
SensorTemp | Sensor internal temperature (°F) | 68.44 |
ShotCount | Measure cycles since last reset | 29,993 |
Time | Date and time of latest data | 08:03.2 |
TransmitterBat | Voltage level, transmitter (v) | 3.657 |
TransmitterTemp | Temperature, transmitter (°F) | 60.6 |
TxFaultCount | Sum of transmit retries since reset | 2,632 |
UTCmsec | Universal time from 1 Jan 1970 | 1.68 × 1012 |
_id | – | 6452a304f5626fa35f3c08a5 |
alarm | Current alarm displayed | – |
cmd | – | 64 |
ecode | – | 20 |
eui | End unit identifier of transmitter | 00-80-00-00-00-01-99-bf |
filename | Path and filename of current active log in receiver gateway | /media/card/senix/00-80-00-00-00-01-99-bf/AirWire_00-80-00-00-00-01-99-bf_2023.05.03 |
gweui | End unit identifier of gateway | 00-80-00-00-a0-00-6d-0d |
icon | – | wifi |
time | Date and time of latest data | 2023-05-03T18:08:03.175498Z |
timetext | Timestamp on display | May 3 @ 14:08:03 |
tstr115 | – | Critical H |
tstr67 | – | AirWire 10 |
Pressure Sensor (S12) | ||
Field value | Description | Example Value |
pressure | Pressure | 0 |
pressure_unit | Pressure unit | psi |
temperature | Temperature | 24.2 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
Flow sensor (S13) | ||
Field value | Description | Example value |
flow | Flow rate | 0 |
flow_acc | Flow accumulation | 7.3 |
flow_acc_unit | Flow accumulation unit | Gallon |
flow_unit | Flow rate unit | g/min |
temperature | Temperature | 31.8 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
Lcom – Turbidity sensor (S14) | ||
Field value | Description | Example value |
current | Output (4–20 mA) | 16.875 |
current_unit | Output unit | mA |
temperature | Temperature | 25.109993 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
turbidity | Turbidity | 3,232 |
turbidity_unit | Turbidity unit | NTU |
Nitrate ion sensor (S15) | ||
Field value | Description | Example value |
current | Output (4–20 mA) | 16.875 |
current_unit | Output unit | mA |
temperature | Temperature | 25.109993 |
temperature_unit | Temperature unit | Celsius |
timestamp | Timestamp | 1.68317 × 1012 |
nitrate_ion | Nitrate Ion | 45.14 |
nitrate_ion_unit | Nitrate unit | ppm |
Soil Probes (S16 and S17) | ||
Field value | Description | Example value |
mostRecentData.soilmoisture.t | Time of day | 2023-09-16 T17:30:00 + 00:00 |
mostRecentData.soilmoisture.u | Moisture percentage | % |
mostRecentData.soilmoisture.v | Moisture value | 6.66 |
mostRecentData.soilmoisture.i | Index | 5 |
mostRecentData.soilmoisture.via reportingInterval | data collection frequency | 5 |
reportingVia | Unit | Mqtt |
Additionally, data collected via the simulators includes the following variables: Time (seconds), Tank 1 Water Level (m), Tank 2 Water Level (m), Tank 1 Pressure (Pa), Tank 2 Pressure (Pa), Nitrate Concentration (mg/L), BOD Concentration (mg/L), DO Concentration (mg/L), pH, Temperature (°C). All data are visualised in multiple data dashboards (presented in Appendix D).
RESULTS AND DISCUSSION
The scope of the ACWA laboratory is extensive, covering a diverse range of applications relevant to its design and operation. It includes various concepts, such as data creation and collection, benchmark scenarios for Cyberbiosecurity research (Sobien et al. 2023), AI assurance techniques to address adversarial attacks, fine-tuning process of soft sensors, innovative ideas for water and agricultural-related public policies, and more. Considering these aspects, the potential use cases that can be developed in the ACWA laboratory include (but are not limited to):
- 1.
Digital twin: A digital twin is a replication of a physical sensor that allows monitoring, visualisation and prediction of its physical counterpart (Eckhart & Ekelhart 2019). The data collected from water and soil sensors could be used for the development of digital twins (besides the presented ACWA simulator). This can help in different applications, such as soil quality, systems' simulation, along with other potential agriculture and water-related uses (Eckhart & Ekelhart 2018).
- 2.
Data poisoning: The EPA (Environmental Protection Agency) has established water regulation limits, and water distribution plants use sensors to control the level of chemicals (such as Phosphorus) in the water. The ACWA laboratory allows the simulation of data poisoning via advanced AI algorithms that can help simulate cases where the data used for decision-making are compromised, similar to the many cyber incidents presented by Hassanzadeh et al. (2020).
- 3.
Water quality: WSSs use filtration and chlorination processes to remove turbidity from water (Stevenson & Bravo 2019). The use of high chlorination forms trihalomethanes (THMs) and Haloacetic acids (HAAs), which can create human health hazards (Lowe et al. 2022). In these scenarios, AI can be used to develop an early warning system for predicting reclaimed water (U.S. Environmental Protection Agency 2023) turbidity. This may help WSS in planning the use of the chlorination process efficiently.
- 4.
Pump operations: These operations, such as determining capacity, number of pumps, and when to start them, can be determined optimally. This can assist pump operators by providing actionable recommendations on pump operations and reducing pump usage and energy consumption.
- 5.
Simulation: The ACWA simulator generates different scenarios to showcase water flow from a reservoir to a tank. The simulator provides complete control of inputs such as selecting material for the pipe, tank dimensions, and chemicals. This simulator can be used to study the effects of different conditions (chemicals, pipe materials, etc.) on the water.
- 6.
Decision-support system: A decision-support system represents the role of technology, such as AI, to provide the stakeholders with intuition, insight, and understanding (Keen 1980; Brill et al. 1990). These systems can be developed by combining advanced AI techniques with AI assurance for different water and agricultural stakeholders.
- 7.
Process monitoring: ACWA data visualisations can represent the information and act as a diagnostic tool to bring situational awareness (Few 2007). This can help monitor different agricultural and/or water plant processes in real-time to check for subtle accuracies ingested into sensor networks.
- 8.
Data generation: The need for more datasets for securing cyber-physical systems (CPS) (Goh et al. 2017) can be tackled by generating data from the ACWA laboratory topologies. ACWA laboratory provides a facility to generate realistic datasets for network, physical properties, and soil and water nutrient data with sufficient complexities of WSS, a notion not found in any other testbed.
- 9.
Fertigation: Fertigation is injecting fertilisers and other soil products into the soil. ACWA laboratory allows experimentation of different fertiliser concentrations along with other parameters such as pH, and moisture content. This can be useful for instance for developing a recommendation system using AI models for farmers.
- 10.
Economics and policy-making: The use of AI, specifically Deep and Reinforcement Learning (DL and RL) – subfields of AI – has been increasingly assisting farm, forest, and ranch managers in decision-making (Environmental Protection Agency, n.d.). In ACWA, advanced AI methods with causal aspects will be researched focusing on applications such as water quality, agricultural market structures, agricultural production, resource allocation, and international trade.
- 11.
Anomaly detection: It is common in smart farms to have physical devices such as sensors, actuators, network cables, and routers outdoors. Also, these devices do not have tamper-resistant boxes, and the changes of intentional or unintentional physical modifications of these devices can occur (Rettore de Araujo Zanella et al. 2020). These anomalies can be identified using AI, and data generated from these devices can be detected in real time, a cyber scenario that can be tested at ACWA.
- 12.
Network attack detection: A report published by the US Council of Economic Advisors (2018) reported >11 large-scale cyber incidents in the food and agriculture sector in 2016 for instance. This creates a need to provide robust security solutions, mainly when digital systems and IoT-based technologies are heavily used in the agriculture and water domains. The advanced sensors used in the ACWA laboratory can help create various anomalous datasets with a combination of different network attacks such as denial of service (DOS), man-in-the-middle, and address resolution protocol (ARP) Spoofing that may help in the development of assured AI models for network attacks' mitigation and detection.
- 13.
Soft sensors: In various industrial and scientific applications, accurate and reliable sensor measurements are crucial for making informed decisions and maintaining high-quality processes (Wang et al. 2022). However, hardware sensors are subject to environmental conditions, calibration drift uncertainties, expensive prices, hard set up, and other unreliable aspects (Geng et al. 2015). One solution to this problem is the development of soft sensors, which are mathematical models that output specific target parameters using hardware sensor data (Ching et al. 2021). This solution can be explored in ACWA considering the availability of advanced high-quality water and soil sensors.
Other novel use cases will be researched considering the need and advancement of water technologies. Additionally, the ACWA laboratory actively collaborates with external organisations, industry partners, and academic institutions, fostering a collaborative community dedicated to addressing other potential complex challenges in water and agriculture.
CONCLUSION
This manuscript presents the new ACWA testbed, a novel cyber-physical system designed and developed to test, simulate, and experiment with cutting-edge technologies such as AI and cyber solutions for intelligent water systems. As established in the literature review section, ACWA is the first of its kind in the domain, and it fills a needed gap for evaluating existing challenges and validating some of the proposed solutions in academia and industry. It is rather difficult to represent all potential AI applications in the water sector, for that reason, the four ACWA topologies (line, bus, star, and soil) are developed in a modular manner that allows researchers to manipulate the structure, expand on it, and collect different forms of datasets based on the desired outcomes.
DATA AVAILABILITY STATEMENT
All relevant data are available from an online repository or repositories. ACWA data samples are available in our open access GitHub repository (https://github.com/AI-VTRC/ACWA-Data). More detailed datasets including requests for specific simulations and complete timeseries are available upon request from the authors.
CONFLICT OF INTEREST
The authors declare there is no conflict.