The LOTUS International Multifunctional Digital Twin ^†

Abstract

The LOTUS project was concerned with the development of low-cost innovative technology for water quality and resource management in urban and rural water systems in India. This paper is concerned with the development of a digital twin for the public water distribution network of Guwahati that will enable researchers from the Guwahati Institute of Technology to develop and test leak detection algorithms.

1. Introduction

The LOTUS project [1] was concerned with the development of low-cost innovative technology for water quality and resource management in urban and rural water systems in India. The project consisted of the development of the LOTUS sensor, a novel multi-function water sensor, which collected and stored data in the LOTUS box and could be accessed through the LOTUS platform using FIWARE [2] as an underlying data management/transport solution.

For this project, the University of Exeter (UNEXE) partnered with the Indian Institute of Technology Guwahati (IITG) in India to develop a FIWARE-based platform to manage and process water sensor data that were collected from the LOTUS sensor and other sensors placed in the Guwahati water distribution network.

The initial functional goal of the platform was to provide a visualisation solution for LOTUS sensor data. However, as the project developed, it became apparent that there was an emerging digital twin role for the platform in terms of being able to generate typical sensor data for the Guwahati WDN which could then be used to develop leak detection algorithms by researchers from IITG.

2. Method

Our usual approach for developing WDN-based digital twins is to consider them from the perspective of a model–view–controller architecture, with EPANET [3] providing the simulation/controller implementation, FIWARE providing the model and a web client providing the view. That way, EPANET will simulate the entire WDN with users defining pressure and flow sensor locations based on the underlying EPANET model with sensor data managed through the FIWARE broker, allowing data to be accessed, via the ngsi-ld/v1 [4] HTTP interface, in a manner that is in keeping with use in physical systems.

Our approach is predicated on a Linux environment, typically with components realised as Docker containers, a Python backend and a web frontend. However, our partners at the IITG were keen to use Windows-based platforms, and, when this work was initially undertaken, the Windows WSL2 infrastructure was not as mature as it is today, effectively removing Docker and Docker containers from our architecture.

The digital twin application was still built as a client–server application, as shown in Figure 1, using Flask as a webserver and owa-epanet [5] as the EPANET simulation. An FIWARE semi-compliant broker was developed from scratch in Python using the nsgi-ld/v1 specifications to create a micro-interface and an SQLite server to store sensor data, and a user interface was developed in HTML/JavaScript that would enable users to define sensors within the WDN, simulate the network and create leaks, of varying severity, on demand. As the platform simulated the WDN, sensor data would be stored in the broker which could then be accessed via an HTTP interface for leak detection algorithm development by IITG researchers.

Figure 2 shows the three functional operations of the platform, with (a) showing the ‘normal’ leak simulation operation. The platform server component (to the left) maintains the model (FIWARE) and controller functionalities, allowing the Guwahati WDN to be simulated with EPANET and results stored in the UNEXE broker. The two platform clients (to the right) show how users can interact with the platform either as a web client or through the ngsi-ld/v1 interface for leak detection algorithm development.

Figure 2b shows the LOTUS box visualisation mode of the platform, a simplification of the leak simulation functionality. In this instance, data are collected from a remote FIWARE broker that serves the LOTUS box and then routed through the visualisation functionality, allowing sensors to be viewed both geographically and temporally.

Figure 2c shows the LOTUS box simulation mode of the platform. This is a refactoring of the leak simulation functionality, in that the core of the leak simulation (EPANET and FIWARE) has been moved into a LOTUS box simulator, allowing for multiple boxes to be simulated with their results collected and visualised through the platform server.

3. Results

Overall, our digital twin development project has been a success, in that we have been able to create synthetic WDN data using EPANET, visualise the results for users and create and store data in an FIWARE compatible broker that can be used to develop leak detection algorithms. We have also been able to connect to LOTUS sensors in the field via the LOTUS box to demonstrate the overall data pipeline and to be able to simulate multiple LOTUS boxes (and virtual sensors) to demonstrate the scalability of the solution.

3.1. Digital Twin Functionality

Using FIWARE has allowed us to work with non-trivial data structures without the need to learn or develop strong SQL skills and has provided a very straightforward interface for the IITG researchers.

Wrapping EPANET functionality through a web interface has removed much of the complexity and tacit knowledge associated with the EPANET application, allowing researchers to concentrate on sensor location and leak generation.

3.2. Leak Detection Development

IITG staff were able to develop leak detection algorithms using data from FIWARE and to use the digital twin server to create novel sensor configurations. Whilst this work is still on-going, a previous leak detection algorithm [5] has been demonstrated through the digital twin.

3.3. Live Data Visualisation

A common challenge with developing research demonstrators is the limited functionality and extendibility of the test application. With this project, however, we were able to extend the initial simulation-only functionality to include live data visualisation from on-site LOTUS boxes at the project’s Paris-based test facility.

This was realised through the modular/model–view–controller approach of the digital twin, with the LOTUS sensor data ‘in the field’ and remote LOTUS box using a Stellio [6] installation which was effectively ‘just’ a different model source, as shown in Figure 2b.

3.4. Multiple LOTUS Box Simulation

Once live, LOTUS data could be visualised as per Section 3.3., and it was possible to create and duplicate virtual LOTUS boxes using the core of the platform server architecture, as shown in Figure 2a, with multiple locations simulated from existing EPANET files. Whilst this was not purely within the LOTUS remit, as we used EPANET files from previous projects, it did demonstrate the scalability of the LOTUS box and FIWARE broker solution.

3.5. Technology Suitability

Once again, FIWARE has proven to be an ideal alternative to SQL or no-SQL databases, providing a simple-to-master API that generally works straight out of the box. Whilst the decision to work on a non-Docker Windows platform initially created a few issues, once the development framework was in place, it was generally not an issue. However, this may cause issues with scaling to operational levels in the future.