3.1. Water treatment facility revisited. Challenges
An efficiency increasing solution cannot be researched without real data and real industrial scenarios. The hypothesis that guided the current research relied on a water treatment facility that represented the testbed for previous status of the proactive historian. The water treatment facility consists of 6 water wells that are foreseen with flow based main local control loops and a level based secondary control loop. The water enters into the treatment plant on a common pipe. It is aerated and filtered with sand and charcoal filters, respectively chlorinated in 3 points before distributed in the network.
Figure 1 depicts the mentioned components within the process aware setting interface of the proactive historian, where all process components are represented, with all constraints and objective function.
The historian is using the collected data to establish well priorities and flow set-points according to estimated water quality indicators (water quality based on the previous impact over the energy consumption) and functioning times (impacting the future availability of the water well), respectively to current and predicted water demand (output flow in the distribution network and water accumulation necessities in the reservoirs for peak consumption hours).
As mentioned in [
20], the previous research was focusing on reducing energy consumption in the context of all process components functioning in automatic regime, limited historian deployment (only selecting the water sources but without setting the calculated flow set-points within the control loops of the wells), respectively limited-time testing. The results were very satisfactory, reducing the energy consumption in the plant by 30%. Throughout the following years, the situation changed within the water facility. Targeting minimal energy consumption and following several observations regarding water demand and components functioning (including the inability to automatically establish flow set-points within the water wells), the automatic activation and selection of water sources based on functioning hours and level in the reservoirs was stopped by the operators. Therefore, the current situation provided several challenges for research:
- -
The close to minimal room for energy reduction. The operators are selecting the water sources choosing the best available options according to previous research and observations. Depending on the season and the weather, some situations allow minimal number of well selection (e.g. the test scenario within the current work covered a situation when only 2 water sources were able to assure the necessary water for normal expected demand, using flow set-points that determine close to optimal frequencies for the drives).
- -
The number of selected wells are functioning all day at the same flow set-point regardless of the water demand. This behavior benefits energy consumption pricing due to lower night tariffs. But, the manual water well selection regime will not cover situations of varying water demand, nor situations where faults occur. The outcome would be either wasted water (usually water is wasted) or lack of water for the population (later accumulation of water can be difficult in some periods of time).
- -
The manual regime cannot distribute the functioning time correctly for the water sources. This may lead to faulty behavior or defects within the well. Currently, the first water source cannot function on flow-based control loops anymore because of slower provision of water, and the fourth water well is not able to keep the flow set-point, having large fluctuations. This leads to an even more limited room for energy efficiency improvement, but considerable necessity for a complete automatic regime.
Besides the mentioned challenges, a supplementary challenge is to tailor and to stress the proactive historian for longer testing periods in an autonomous functioning and a non-invasive interoperation with the legacy system.
Therefore, these challenges are transformed into historian tailoring and testing tasks, briefly presented as follows:
- -
To assure the automatic selection of water wells according to accumulated data with the energy efficiency increase as primary objective function but considering also functioning hours of the water wells.
- -
To assure the automatic activation of the water wells according to varying current water demands, but considering the accumulation perspective for peak hours, the varying flow set-points in the local control loops of the water sources, and other constraints as the upper, lower and optimal limits in pumps driving frequencies.
- -
To interoperate with the legacy system in order to set the flow references and to start/stop the pumps. These task assumes multiple checking and protection functions according to the current manual regime and other functioning regimes at the water source level (e.g. steps in starting and stopping the pumps, level-based regime check, faulty behavior check, faults detected in the local systems, interoperation sampling periods proper setting, etc.).
- -
To generate general safety procedures to deactivate properly the historian-based interference that provides the automatic regime in case of malfunction signs or on operator demand, with an option to reestablish the previous settings within the local system before decoupling.
- -
To evaluate the overall performance in the current suboptimal regime and longer-term functioning.
3.2. Architecture and Solution Deployment
The proactive historian solution developed in [
21] formed the basis for the practical implementation of the current research, but special tailoring for the current case-study was required, in order to fit the software solution to the specific particularities of the tested scenario. All 5 tasks identified at the end of the previous subsection were considered and the adjustments made to the historian software solution in order to meet those aforementioned requirements are briefly described below.
Firstly, the optimizing algorithm described in [
21] was adjusted in order to include a hysteresis
h, as percent of the minimum flow of the water source. More specifically, if the difference from the total flow delivered towards population and the sum of the water flows offered by the sources that are running is not greater than ½ of the minimum flow that can be offered by the next idle source (in the order of its priority), then the respective water source is not started, to avoid excessive water pump wear down. The same hysteresis limit applies for stopping a water source.
if
or
The percent was established at a fixed value using the historian and it proved to be more efficient than varying hysteresis correlated to the water accumulation necessities and minimal values of the flow for a specific water source. A varying h value for each water well is requiring a proper frequency of updating and proper correlation with the evolution of each water source. No benefit was encountered for a varying h.
Secondly, the Historian was updated in order to read the minimum and maximum flows that can be offered by each water source from a configuration file, so that those limits can be easily adjusted by operators if necessary. The limit values are important as it was noticed that through time, these limits were changing for each water well. Also, the automation from the drinking water treatment plant (DWTP) used in this research takes into account a specific OPC UA tag for determining when to start or stop the water pump of a source, instead of using a 0-based convention for the reference flow tag, which led to the necessity of adjusting the algorithm from [
21] in order to properly set this start/stop command tag value as well when it is required. Taking the manual selection of the water wells towards the automatic regime required more condition checks and further reaction towards the local functioning of the legacy solution. As examples, the names of the OPC UA tags used for start/stop command, sources reference flows and total flow delivered towards population had to be set (together with proper verification procedures), as well, particularly for this DWTP. Comparing to [
21], the magnitude of algorithmic and protection structures referring to local system interoperation following the efficiency recipes provided by the historian increased significantly.
Lastly, in the targeted DWTP the filters washing operation takes place at approximately 24 hours intervals and it consumes around 50 m3 of water from the water tank containing the treated water which will be sent in the network. The respective water tank has a maximum capacity of around 400 m3 and the filters washing operation takes just around 30 minutes to complete. So, in order to compensate for this significant drop in the distribution tank’s water level in a short time interval, the historian was adjusted to compute the target water flow (total flow that must be offered by the water sources) not as equal to the water flow towards the distribution network, but as:
flow_required_from_sources = p%* DWTP_output_flow.
(where p% was set for 120%, but it can change between 110%-130% depending on the the actual value of the treated daily volumes within the DWTP that is varying according to the season).
This way, the water level in the tank is slowly, but constantly rising, compensating the big drop during filters cleaning. In this context, all experiments were monitoring the frequency of the filter washing cycles and filters clogging status.
The interfacing between the specifically developed version of the historian application and the legacy system from the DWTP targeted by the current research is presented in
Figure 2.
The historian implementation has 2 loops through which it communicates with the legacy system: monitoring loop and optimizing loop. The monitoring loop is used by the historian to collect data, reading the OPC UA tags values at 20 seconds intervals from the OPC UA Server that is functioning in the DWTP. The values are collected inside the legacy system from the field equipment (pumps, air blowers, filters, chlorine injectors, flowmeters, etc.) and exposed into the OPC UA Server, where only real time values are available. Those real time values are being read by the Historian at 20 seconds intervals and the values are being stored within a SQLite database, thus collecting historical data about DWTP’s functioning parameters. The values associated with OPC UA tags are components of internal DWTP control systems. For example, the reference flow for water sources represents the set-point of the flow-based control loop within each water source (primary closed-loop control system for each well), and the actuators are frequency converters that are adjusting the revolution speed of the pumps (see simplified scheme of the flow-based closed-loop control within each water source of the legacy system in
Figure 3).
The optimizing loop starts by reading from historian’s database the most recent value recorded for the water flow distributed towards population, which is fed into the optimizing algorithm described in [
20,
21], resulting the optimized reference flows for each water source, which are being written alongside the necessary command tags values (for start/stop) on the OPC UA Server from the legacy systems. The consequence of writing new values on the OPC UA Server is that DWTP’s automation takes the new values into consideration, thus the historian being able to influence the functioning of the DWTP in a non-invasive manner regarding the legacy system’s existing automation. The operations from the optimizing loop are repeating at 60 seconds intervals. The historian can run in 2 separate regimes: monitoring only (monitoring loop runs and optimizing loop does not run) or optimizing (both loops are running), the applying of the optimization over the monitored system being a decision left at the historian’s user choice,
Figure 4 showing the settings area from the historian’s graphical user interface (GUI) which allows this choice to be made.
In advance of running the optimizing loop, the historian must analyze the recorded data and identify the water sources priority indices (by running the algorithms described in [
18,
20]), this analysis operation being started manually by the user clicking a button in the ‘Analyzer’ tab from
Figure 4. Because the quality of the water from sources changes over time, the historian’s user has the possibility of repeating this analysis periodically, when considered appropriate, so that the energy optimizing strategy is not considering some outdated priority indices.
From a more physical standpoint, the historian is installed on a Raspberry Pi 4 Model B hardware platform, which is located inside the DWTP’s command room, alongside the existing computers hosting the local SCADA software and OPC UA Server. The Raspberry Pi is connected to an uninterruptible power supply (UPS) and secure remote access to historian’s GUI was implemented as well, through SSH tunneling.
The deployed software solution represents not just a simple data collecting tool, but a step forward, in the form of a process-aware historian, that understands the meaning of the monitored OPC UA tags and also possesses proactive capabilities. The historian can autonomously analyze the stored data, compute an optimizing recipe and apply it to the monitored system in a fully automated and non-invasive manner. The optimizing strategy applied by the historian starts by analyzing the stored data, considering the water flows of water sources and the total energy consumption of the DWTP, the data dependencies identification algorithm detailed in [
18] offering an output based on which a priority indicator regarding water quality can be computed for each water source. Afterwards, a priority indicator regarding equipment wear down is computed for each water source based on the functioning hours recorded for each water source. Those 2 priority indicators are used to compute a global priority indicator for each water source, which is then considered in the optimizing algorithm for deciding the usage of the water sources. The algorithm attempts to match a specific total water flow that must enter the DWTP, which is computed based on the water flow distributed into the network from the station, and also keep the running water sources closest possible to a computed optimum flow for each. The target water flow that must be matched represents the sum of the flows of the water sources, the algorithm maximizing the usage of the highest priority water sources to the detriment of lower priority water sources, thus obtaining better energy efficiency and equipment wear down balancing, depending on the weights of the 2 priority indexes when computing the global priority indicator for a water source. More details regarding the optimizing strategy and algorithm are available in [
18,
20].
Furthermore, the process of tailoring the historian solution developed in previous researches supported an increase of the software application’s technological readiness level (TRL) at level 7.
The historian software solution described in the current section was deployed at a DWTP located in Timiș, Romania, supplying a population of around 8000 people. The historian was operational for the current testing and validation purposes, in monitoring only regime since 30 August 2022, continuously gathering data from the DWTP until the current moment. Following previous testing experiments, the presented testing of the optimizing regime was realized during a 50 hours long interval, between 27 February 2023 at 13:30 local time and 01 March 2023 at 15:30 local time. During the aforementioned interval, the local operators did not make any adjustments to the functioning of the DWTP, which was left entirely under the control of the historian application with regards to the water sources usage. The results of the test conducted in the optimizing regime are presented and discussed in the following section.