A Knowledge-Based Engineering System for the Planning of Networked Rainwater Harvesting and Distribution Systems

Abstract

Rainwater harvesting attracts growing interest from the field of municipal planning. When considering a rainwater harvesting system as a design object, questions include whether the system is designed for a single property or for a local water network serving multiple properties, what allows for the inclusion of buffer tanks and resource balancing among participants in the network, how to size the tanks, and how robust the system is in the face of changing demands. Knowledge-based engineering provides methods and a tool set for such planning objects. For this article, the authors applied techniques based on model-based and resource-based configuration and Bayesian decision networks to propose a knowledge-based engineering system for residential, networked rainwater harvesting and distribution systems. This enables designers to investigate the effects of different catchment areas, adjust or minimize the storage tank sizes in the grid and evaluate their effect on the individual harvest and the exchange with a central network buffer, evaluate the demands within a neighborhood based on a detailed consumer model also over time, and test the sensitivities of the single sinks and sources to the water grid. For urban planners, this offers the possibility, for example, to make design obligations for housing construction or for the refurbishment of settlements.

1. Introduction

The perception of water as a resource is undergoing dramatical change. As a consequence of climate change, on the one hand, drought even in temperate latitudes and the lowering of groundwater levels in many areas is an issue that now affects almost everyone [1,2]. On the other hand, the increase in extreme weather events and climate-related natural hazards poses a risk to more and more people [3,4]. It is not only the first United Nations Water Conference in almost 50 years in 2023 that is drawing attention to what has become a universal truth: water must be managed.

One source of water which has a significant impact on the sizing of water infrastructure systems is rainwater [5,6,7]. Storm water discharge to protect other infrastructure from damage, such as that seen, for example, in Los Angeles or Tokyo, is only one question for urban planners [8,9,10]. The integration of rainwater into the urban water cycle is a subject of water-sensitive urban design [11,12,13], with concepts such as green roof technology, living walls, and sponge cities as instantiations [14,15,16,17,18].

Rainwater harvesting (RWH) and use is a cornerstone of many of these concepts and contributes to influencing both peak water demands and storm water runoff [19,20]. In addition to simply installing a rainwater tank on a property, understanding neighborhoods or districts as local, decentrally managed water grids offers the possibility of resource balancing, as participants with low consumption or additional municipal buffers can make their harvest available to other participants in the network as needed [21].

Thus, when considering an RWH system as a design object, the questions are, first, how to size it according to the provision and consumption of rainwater [22], second, how to make it robust to changing requirements and premises over a long service life [23], and third, where to set the system boundaries for maximum benefit to all stakeholders. Current design practice and standards such as EN 16941-1 [24] tend to focus on individual aspects of the above. A widely used approach is the simulation of water mass balances based on yield and demand for each time step of the simulation for an isolated RWH system [6].

Considering the above questions, an appropriate design tool for RWH systems should generally be able to size the system components based on reliable and adequately resolved data, support the designer in detecting sensitivities in design parameters, e.g., due to changes in use patterns or premises, and compare different system configurations and boundaries. For such design tasks, the field of Knowledge-Based Engineering (KBE) offers methods and a comprehensive set of tools [25,26,27].

This article presents a modular KBE system for the design of residential rainwater harvesting and distribution systems, in which the authors apply KBE techniques such as model- and resource-based configuration and Bayesian decision networks. The following contributions are associated with this: First, the authors propose a probabilistic consumer model to make the prediction of water demand more robust and to also evaluate the effects of different influencing parameters over time. Second, the impacts of a networked RWH system in a neighborhood with a central buffer tank can be compared to those of isolated RWH systems so that appropriate design recommendations or design obligations can be made.

The article is organized as follows: First, in Section 2, the theoretical background of KBE systems in general, Bayesian Networks as tool for modeling uncertainties, and the sizing of RWH systems is presented. Section 3 then contains a description of the Bayesian network consumer model concept as well as the mental model and premises the authors used for system development. Afterwards, Section 4 presents the structure and setup of the implemented system, before Section 5 shows the application of the system for different configurations of a neighborhood as well as the generation of design knowledge by analyzing sensitivities of parameter changes for the provision and consumption of water. In Section 6, the application as well as the methodological approach are discussed before Section 7 concludes the article.

2. Theoretical Background and Related Work

2.1. Knowledge-Based Engineering

The idea of KBE is associated with a paradigm shift in computer-aided product modeling, away from documenting a single product variant to modeling solution spaces in which a variant can be found that fits a set of requirements [28]. Thus, the purpose of KBE is twofold: One is to automate the design or adaptation of products and their components based on artificial intelligence, e.g., a reasoning system, which is able to consider the design context, e.g., given requirements or restrictions [27,29]. The other is the automatic discovery of design knowledge about an artifact, e.g., through systematic investigation and evaluation of the sensitivities of design parameter changes and their dependencies with respect to the resulting product’s properties [30,31]. Both qualify KBE as toolbox for realizing digital twins and thus imply its utility for operating smart service systems [32,33].

Building a KBE system leads to two basic questions: first, how to model the solution space, and second, how to explore it to accomplish a design task. The design task may already imply answers to the above questions [34]. In product configuration, for example, the design task is to find a composition of predefined components to be assembled via known interfaces [26,35]. Thus, the model of the solution space may consist of a representation of the predefined components, their individual options and alternatives, and constraints describing the relationship between the components as well as with user input as domain knowledge. A common implementation approach is the formulation of a constraint satisfaction problem (CSP) [36]. The exploration is then the solution of the CSP by the respecting algorithms, which can be understood as control or inference knowledge in model-based reasoning [37]. With respect to RWH system design, inputs to the CSP could be catchment size, a rainfall pattern, and data about rainwater consumption so that the configuration system outputs a tank, pumps, and other necessary equipment of suitable sizes. Such systems can be found, for example, through individual RWH system manufacturer’s web presences as online configurators or sizing tools. For end users, this is a convenient decision support, as these tools are able to translate user requirements into the specification of a system, without requiring deeper product knowledge [38,39,40].

For resource balancing, this approach was adapted to model resource provision and consumption by constraints, keeping the resource concept abstract, e.g., so that installation space or technical interfaces can also be considered as resources [41]. Framing this for RWH systems, designers can use this approach to develop, simulate, and control a super system of multiple properties each with its own catchment, tank, and pumping system and mediate between the individual participants’ needs and water demands.

In contrast, a geometric knowledge-based computer-aided design model that adapts the shape of a product or its components to changed requirements uses a variety of different domain knowledge implementations, i.e., among others, parameter constraints, design rules and templates, as well as more complex control strategies [28,42].

The aforementioned approaches belong to solution-centric, explicit solution space modeling. A fundamentally different strategy, popular in, e.g., architecture, is a process-oriented, implicit modeling of the solution space. Here, the development of a KBE system focuses on the automation of the design process itself rather than a variety of pre-formulated product solutions [43]. Such approaches rely on an algorithmic formulation of, e.g., design rules of the product and laws for deriving product properties based on requirements, but also include transformation models from external data sources or numerical simulation [44,45]. The concept has thus disseminated, e.g., into Design for Additive Manufacturing in the mechanical engineering domain, as it aims to generate an individual product for each set of customer requirements without relying on an existing configurable product model, which is particularly favorable for complex geometries [46,47,48].

There are hybrid forms which combine the strengths of both concepts. One of them is the propose-and-revise approach that uses an explicit solution space model to propose an initial system configuration which is near to matching the given requirements. The algorithmic part then automatically alters the configuration according to a usually rule-based reaction pool to improve requirement fulfillment [49,50]. Complementing such systems with an automated parameter study then provides the ability to evaluate how a design reacts to changes in the requirements and following them to formulate new explicit design knowledge.

2.2. Bayesian Networks

The above argumentation of discovering new design knowledge by investigating the effect of parameter changes on a design introduces another perspective for engineering disciplines. KBE systems are also valuable for finding a design that is insensitive to a (limited) change in requirements, which opens up opportunities for dealing with uncertainties in the requirements themselves, thus contributing to complexity management [51,52,53]. If uncertainty is understood as a modeling object of a design artifact, it can be implemented using implicit and explicit modeling. In the first option, designers do not model uncertainty as such but represent the system to be analyzed as a model. This follows a multi-objective optimization, such as Latin Hypercube Sampling, in which the sensitivity of changes in the design variables can be inferred by varying the inputs to reveal the objective function of the optimization [54]. In contrast, explicit modeling directly associates uncertainties, e.g., in the form of probabilities, with parts of the model of the design artifact. Since such probabilities are usually dependent, and approaches such as Bayesian networks (BNs) have been formulated [55]. BNs are used when representing missing or uncertain data. They find applications, e.g., in diagnosis tasks, which can model expert knowledge as the effect of a cause with probabilities [56].

Assume two statements A and B with the possible binary states true (T) and false (F). If statement A is true and statement B can be deduced from statement A, then statement B is also true. In contrast to this is induction, where it is a matter of inferring the error from the symptom. This can then lead to uncertainty if, e.g., several errors trigger the same symptom. If a statement A is not independent, but only true under the premise that another statement B is true, this is called the conditional probability $P(A\mid B)$ [57]. This conditional probability may already represent intrinsic expert knowledge. BNs make use of connecting this knowledge expressed by conditional probabilities into a knowledge base by using the so-called Bayesian rule because evidence (B) is often perceived as an effect of an unknown cause (A) and the goal is to determine the cause [58].

A key advantage of BNs is reasoning against the causal chain. Directed acyclic graphs are used to visualize knowledge, with nodes corresponding to uncertain variables and edges corresponding to the conditional probabilities of those variables. The probabilities within the BN are based on random trials and represent intrinsic knowledge or uncertain information. Korb and Nicholson [59] proposed a two-step approach for modeling a BN: (1) building the structure (nodes with values and arcs) and (2) assigning the parameters (probabilities). After the associated graph has been created in the first step, the probabilities can be added. First, the size of the individual nodes must be defined. CPTs (conditional probability tables) are used to implement the conditional probabilities [60]. These are arrays in which the probabilities for the individual nodes are stored. To calculate the inference, one can choose between several algorithms, for example the junction tree algorithm.

The example from [58] illustrates this with with the observation of wet grass (W) and the possible causes of having applied a sprinkler (S) and rainfall (R). Both causes receive a parent node, cloudy (C) (Figure 1). When evidence is added, the model is enriched with prior knowledge. If the probability that the sprinkler is responsible for the wet grass is to be determined, the probability W = 1.0 is set for the node wet grass. This results in a probability of occurrence of 42.9% for the sprinkler to be the source of the wet grass, regardless of cloudy weather.

In the literature, BNs are used in product development, e.g., to span a design solution space by manipulating deterministic and probabilistic data to perform product architecture generation and exploration. By using templates to model the random nodes, the design variables, constraints, and confidence levels, among others, are represented so that the compatibility of components for a product can be verified. In addition, BNs are used for set-based collaborative design, where different design departments model, share, and combine their promising regions in the design solution space for an unmanned aerial vehicle to find solutions of common interest [61]. Wang et al. [62] also span a solution space with BN to assist the engineer in the Design for Additive Manufacturing (DfAM) decision process. To achieve this, they consider parameters of the manufacturing process in terms of the machine and the part to be printed, as well as possible materials, based on which a conclusion can be drawn about the product properties. BNs can also be built and updated by analyzing data so that they can be used to predict future designs based on data about past products [63,64].

2.3. Rainwater Harvesting Systems

RWH systems are used to collect and store rainwater, preferably from roof surfaces [65]. The collected rainwater is suitable both for indoor use, e.g., laundry, toilet flushing or hot water purposes, and outdoor use, e.g., garden irrigation and cleaning [22]. RWH systems consist mainly of rain gutters, which collect the water from the roof, piping system, storage tank, and pump. Depending on the individual consumers and their water quality requirements, additional filters or a first-flush diverter are recommended [66,67]. A discussion of different RWH system configurations may be obtained from [7].

As an upper-level framework, the European standard EN 16941-1 was created to harmonize different national codices of practice, such as the British BS 8515 or the German DIN 1989-1, and to provide a reference for the design, installation, and maintenance of RWH systems [24,68,69]. A critical point is the physical sizing of the rainwater storage tank. The standards as well as the literature distinguish three different categories of sizing methods, which differ in their complexity and precision.

Empirical relationship methods rely on correlations of easily measurable data, such as mean annual rainfall, catchment size, and mean water demand per consumer. Usually they are realized as simple look-up charts, e.g., catchment versus storage curves [23,65]. The applicability is somehow restricted in terms of precipitation levels, daily water demand, and the adaption of the curves to other regions [6]. A well-known drawback is that such simplified methods do not resolve rainfall patterns and demand variations more accurately than one year. As a consequence, tank volumes are usually overestimated compared to other methods [67]. The old version of DIN1989-1 included a related abbreviated procedure, which has since been withdrawn.

The second category consists of approaches that use the continuous simulation of water mass balances. The mass balances represent inputs, outputs, and losses of an RWH system, making it possible to reason about the tank volume based on the calculated volume of the stored water at each time step of the simulation [6]. Within this category, there are several algorithmic models, e.g., the basic methods of yield before spillage or yield after spillage [70]. A crucial point is the choice of the time step. EN 16941-1 allows a simplified simulation with yearly values [24]. In contrast, the detailed simulation, as well as other state-of-the-art simulation models, uses a daily time step [67]. Especially for small tank sizes, an inadequate temporal resolution leads to a considerable underestimation of annual rainwater yields [71].

Methods of the third category take into consideration a drawback of the other approaches, which is the uncertainty about future supply and demand patterns. Especially on the supply side, probabilistic and stochastic procedures have been increasingly used and are often subsumed as rainfall generators [6,65]. The probability of rainfall is analyzed based on data on historical precipitation records and an estimation on the future development of climate variables that allow predictions even on large time scales relevant to water infrastructure systems [23,72]. These data are then commonly taken as input for the calculation of mass balances [67].

A different point of view in designing an RWH system is the economic perspective. With regard to an isolated system for an individual building, over- or underestimation might not result in severe economic losses [5]. Nonetheless, increasing the tank size does not necessarily increase efficiency, but leads to a possible increase in service costs and a decrease in operational safety, e.g., when a cistern is not able to overfloat for self-cleaning [73]. However, when considering the RWH system as part of the water infrastructure, the impacts on water supply and stormwater drainage are actually measurable and can be calculated even up to the level of pipe diameters [19].

3. Model Development

Although several approaches that account for uncertainty about future parameters have been reported in the literature, they seem to focus heavily on the supply side [65]. The demand side is commonly modeled as average water consumption per person, supplemented by models for, e.g., garden irrigation during the summer months [66].

To assess the robustness of RWH systems, the authors aim to provide new impetus by introducing a probabilistic consumer model and a comparative assessment of isolated and networked RWH systems on multiple properties, allowing resource balancing between the individual systems. Therefore, a BN will represent the user behavior and allow the calculation of water demand. A model- and resource-based configuration approach for the RWH system then enables the comparison of different system configurations and reasoning about single design parameters.

3.1. Consumer Model

The consumer model consists of a BN with four layers, where the fourth layer represents a person’s total consumption based on their habits and behaviors. Figure 2 shows the topology of the network and all influencing factors.

In the model, the single consumptions for shower, toilet, laundry, and car washing are represented and divided into six discrete areas for a first approximation. Sensitivities of $\pm 7.5\%$ are considered to better assess transitions between discrete areas. The attributes of a person are set as nodes in the graph. Each node contains a CPT, where the size of the table depends on the number of parent nodes. The conditional probabilities themselves were deposited on the basis of real statistical data from market and opinion research, as well as from economic and official statistics for the year 2021 with reference to the Federal Republic of Germany. The CPTs for the part consumptions used for the model are included in the appendix in

Table A7. Conditional Probability Table for the Shower Node.

Work Location	Home								Away
Hygiene	Yes				No				Yes				No
Sportiness	Yes		No		Yes		No		Yes		No		Yes		No
Hair Length	long	short	long	short	long	short	long	short	long	short	long	short	long	short	long	short
0–19											0.5	1.0	0.5	1.0	1.0	1.0
20–39						0.16	1.0	1.0	1.0	0.5		0.5
40–59				1.0		1.0	0.84
60–79		0.16	1.0		1.0
80–99		0.84
>100	1.0

,

Table A8. Conditional Probability Table for the Toilet Node.

Irritable Bowel	Yes				No
Work Location	Home		Away		Home		Away
Hygiene	Yes	No	Yes	No	Yes	No	Yes	No
0–19				1.0			1.0	1.0
20–39			1.0			1.0
40–59		0.5			1.0
60–79		0.5
80–99	0.5
>100	0.5

,

Table A9. Conditional Probability Table for the Laundry Node.

Hygiene	Yes		No
Sportiness	Yes	No	Yes	No
0–19		1.0	1.0	1.0
20–39	1.0

and

Table A10. Conditional Probability Table for the Car Cleaning Node.

Car Available	Yes				No
Work Location	Home		Away		Home		Away
Gender	Female	Male	Female	Male	Female	Male	Female	Male
0–19	1.0	1.0			1.0	1.0	1.0	1.0
20–39			1.0
40–59				1.0

. These part consumptions are in turn dependent on the user’s characteristics, which can be divided into coarse and fine filtering. Coarse filtering includes the distribution according to age and gender. Age was divided into six discrete ranges (

Table 1. Probability of Age of the Residents.

Age	0–5	6–13	14–24	25–39	40–59	≥60
Probability	0.06	0.07	0.11	0.19	0.28	0.29

), which are not equally distributed to take in account the greater mobility and fluctuation of residents of a younger age.

For fine filtering, the focus is more on the influencing factors for water consumption itself. These include digestive system diseases, hair length, sportiness, hygiene, place of work, and availability of a car, all broken down to their impact on single part consumption. E.g., if a person works more in a home office it is likely that this increases water consumption from toilet flushing but reduces consumption from laundry. In the same way, a high sportiness is likely to increase the consumption from showers and laundry. The CPTs for the fine filtering are attached in the appendix in

Table A1. Conditional Probability Table for the Irritable Bowel Node.

Age	0–5	6–13	14–24	25–39	40–59	≥60
Yes	0.033	0.033	0.083	0.093	0.105	0.119
No	0.967	0.967	0.917	0.907	0.895	0.881

,

Table A2. Conditional Probability Table for the Hair Length Node.

Gender	Female						Male
Age	0–5	6–13	14–24	25–39	40–59	≥60	0–5	6–13	14–24	25–39	40–59	≥60
Short	0.5	0.3	0.3	0.4	0.7	0.75	0.9	0.7	0.7	0.7	0.85	0.9
Long	0.5	0.7	0.7	0.6	0.3	0.25	0.1	0.3	0.3	0.3	0.15	0.1

,

Table A3. Conditional Probability Table for the Sportiness Node.

Age	0–5	6–13	14–24	25–39	40–59	≥60
Yes	0.2	0.75	0.6	0.3	0.3	0.25
No	0.8	0.25	0.4	0.7	0.7	0.75

,

Table A4. Conditional Probability Table for the Hygiene Node.

Gender	Female						Male
Age	0–5	6–13	14–24	25–39	40–59	≥60	0–5	6–13	14–24	25–39	40–59	≥60
Yes	0.75	0.75	0.75	0.75	0.8	0.7	0.6	0.6	0.6	0.65	0.65	0.6
No	0.25	0.25	0.25	0.25	0.2	0.3	0.4	0.4	0.4	0.35	0.35	0.4

,

Table A5. Conditional Probability Table for the Work Location Node.

Gender	Female						Male
Age	0–5	6–13	14–24	25–39	40–59	≥60	0–5	6–13	14–24	25–39	40–59	≥60
At Home	0.8	0.5	0.3	0.75	0.5	0.7	0.8	0.5	0.3	0.45	0.45	0.75
Away	0.2	0.5	0.7	0.25	0.5	0.3	0.2	0.5	0.7	0.55	0.55	0.25

and

Table A6. Conditional Probability Table for the Car Node.

Age	0–5	6–13	14–24	25–39	40–59	≥60
Yes	0.0	0.0	0.552	0.675	0.791	0.813
No	1.0	1.0	0.448	0.325	0.209	0.187

. For adapting the model to other locations, the CPTs need to be updated with the probability distributions of that location by substituting the corresponding values.

In the first stage of implementation, binary values were assumed for the user characteristics, so that the more probable value was assumed for the update of the BN. Based on this, the conditional probabilities of the consumers are updated. The initial level of the BN represents the statistically likely consumption for an individual. The inference of the BN is performed using a junction tree algorithm, which takes the nodes as intersections and divides the graph into small decision trees so that it can update the probabilities step by step. Therefore, from the BN, which is modeled as a directed acyclic graph (DAG), first, an undirected graph, named moral graph, is constructed, where the parent nodes of a common child are connected [56,74]. Subsequently, more edges are added to divide the graph into triangles of nodes. From these triangles, clusters are determined which consist of subsets of nodes from the triangulated graph. In the last step, a junction tree is formed from the clusters, which allows minimization of computational time [75]. Figure 3 shows first a BN in the form of a DAG, second the undirected triangulated graph, and third the junction tree derived from it.

Based on the determined junction tree, the conditional probabilities can be calculated. According to Huang and Darwiche [75], the junction tree is initialized with the probabilities of the nodes and the observations are introduced so that this junction tree can be regarded as inconsistent. Propagation using message passing, for example, can ensure consistency within the junction tree. In the last step, the conditional probabilities have to be marginalized and normalized so that the sum of the posterior variables is 1 again. This form of algorithm works well for smaller BNs, as in this example, where few discrete values are used. As soon as the BN becomes larger or even continuous, the inference must be performed using sampling algorithms. Now that the BN has been modeled, the user-induced water consumption can be determined by updating the probabilities for the user property nodes. For example, if it is known that the person is female and between 14 and 24 years old, the probability of long hair increases from 29.87% to 70% and so does the assumed water consumption for showering.

As an simplified alternative to the BN, a second calculation model uses a virtual tree diagram, which is composed of the properties of a resident to show a statistically probable water consumption. For this purpose, the calculated path probabilities of all possible property combinations of a person are determined. The six combinations with the highest probability are set as possible standard residents.

3.2. System Dynamics Model and Premises

The basis of the KBE system for networked rainwater harvesting and distribution systems is a model of the respective water grid. In this context, the representation of stocks and flows emphasizes the resource-based modeling approach that considers sources and sinks of the network as well as different characteristics for inflows and outflows. Figure 4 shows a single residential unit as a System Dynamics model, while Figure 5 presents the System Dynamics model for a neighborhood consisting of 10 properties, each instantiating the single residential unit model above. At this stage, it was not the aim to fully reproduce the urban water cycle, e.g., as introduced in [11], but to visualize the grid and the premises explained below.

Rainwater, cleaning water, and tap water are assumed to be the main sources for water collection considering a single residential unit, while toilet flushing, shower, laundry, car cleaning, and garden irrigation are assumed to be the main consumers. Rainwater was modeled on the historical data from the German Weather Service (DWD) on a day-based resolution for the past 5 years (1.1), so that seasonal fluctuations could also be taken into account. These data are publicly available and can later be automatically retrieved from the KBE system after the designer enters the location of the RWH system to be designed. To model the actual yield of rainwater, the roof yield coefficient (2) represents different roof types and is stored as an efficiency table based on the values of EN 16941-1. Additionally, the authors introduce a catchment yield coefficient (2.1) as different commercially available rainwater collectors have their own efficiencies, which are also stored as tables based on real provider data. As an option, a first-flush diverter (3) reduces the yield from each rainfall event by 0.33 $\frac{l}{m^2}$, according to [66], so that no contaminants enter the storage tank.

The second source of water is a household internal water cycle that reuses water, e.g., from cleaning vegetables, where no chemical detergents occur. Therefore, it is assumed that the water is collected in a small tank in the kitchen and then manually transferred into the storage tank. Cleaning water depends on the number of people and the probability of cooking in the household itself (4.1) and how often the water is supplied to the tank, e.g., twice a week (4.2).

The tap water (5) represents the water from the mains water supply, e.g., provided by the local distributor. Tap water is added when the consumption (5.1) exceeds the collected water from the other sources. Its amount is a design parameter to be minimized by the system. To be able to integrate further water sources into the system, a respective placeholder is included. The water from all sources is first led into the water tank (7) before it is transferred from there to the various sinks. Losses due to leakage and evaporation (7.1) could be considered to model the efficiency of the RWH system but are neglected in this stage of implementation as they are not considered as a design-determining variable. To clean the water tank in regular cycles, the tank is allowed to overflow (8). The overflow is considered as a design variable here, in the sense that the cistern should overflow at least a given number of times per year by a given volume. This is included in the later calculation of the mass balances.

As for user-induced consumers, the model integrates toilet (9), shower (10), laundry (11), and car cleaning (12) with their daily water demand, based on either values from standards or provider data. The influencing factors (10.1, 11.1, and 12.1) map the characteristics from the consumer model described above. The garden (13) is considered a context-specific consumer, as it depends on the garden size and needs to be watered differently depending on the outdoor temperature (13.1). The current implementation uses an average irrigation demand of 2.5 L per square meter per day, which is integrated into the mass balances when the temperature is above 15 °C. To be able to expand the system on the consumer side, it is also possible to model additional consumers (14). For evaluating different scenarios for tank size and for resource balancing procedures, an additional buffer tank (15) is implemented in the model.

Another System Dynamics model represents the super system of a neighborhood with ten residential units (Figure 5). The use of a central buffer to balance resources between individual housing units plays a key role in this. Note that the central buffer does not have its own catchment, such as sidewalk gutters, but is fed only by the connected residential units. Each residential unit contains its own water tank, into which the entire water collection of the residential unit enters as input and the total consumption of the residential unit leaves the tank as output. Surplus water can be fed into the buffer tank by the individual housing units and can also be retrieved when the buffer tank is filled (15.1). In addition, the piping network (15.2) has to be filled before the water reaches the consumers so that the length and pipe dimensions are also stored.

4. Implementation

The system was implemented in MATLAB, version R2022a, as it offers many toolboxes, a high number of numerical algorithms, and a simple visualization [60]. Figure 6 shows the basic program flow chart.

After starting the program, the input window opens, where the user can select the location (Figure 7a). The possible locations result from the location list of the measuring stations of the German Weather Service (DWD). The script downloads the corresponding local precipitation and temperature data and prepares them in the targeted resolution. In addition, the approach for the consumption calculation is requested in this tab where the designer selects between the BN and the simplified virtual tree diagram. Furthermore, the designer chooses whether the multifamily house mode (MFHM) should be activated. If so, the frame of reference changes from a neighborhood with ten properties to a multifamily house with ten flats so that the demand of the residents can be calculated accordingly. In the MFHM, only the roof area of house one is considered, and the interconnection of several tanks is deactivated. Figure 7b shows the input window for the respective houses/apartments, where the number of inhabitants, roof area, roof coefficient, size of the garden, and the single consumers of rainwater are requested. The last option allows the developer to compare different scenarios, e.g., when no car cleaning is allowed, and thus investigate the sensitivity of such measures on the system’s behavior.

Afterwards, the yield is calculated using the building specifications, the precipitation data, and first-flush diversion. The system also instantiates the household’s internal water cycle. Depending on the number of people, it is therefore estimated that between 12 and 30 L of cleaning water is produced per week and returned to the storage tank. Based on statistics for the monthly number of home-cooked meals, a weighted random generator maps cooking behavior week by week for each household.

In the next step, the demand for the units is calculated. The system populates the residential units based on the chosen demand calculation method. The consumption per day and person for toilet flushing (24 L), showering (35 L), laundry (15 L), and car cleaning (400 L) are assumed as a starting point. These values are factorized by the generated user portfolios so that the user-induced influence can be considered to a greater extent. To create the BN in MATLAB, version R2022a, a library called Bayes Net Toolbox (BNT) was used, which was developed by Kevin Murphy in 1997 and kept up to date until 2014 [60]. The graph of the BN is represented in BNT as a matrix, where the rows and columns represent the nodes and the entries within the matrix represent the connection between these nodes as arcs. Once each consumer’s individual factors are determined based on user characteristics, they are added together to create a total water consumption per person. This step is performed for all individuals in a household, which in turn leads to a total water consumption for a residential unit. Once all water consumptions per person and per unit have been determined, all occupant profiles and the resulting consumptions of all houses are saved in a text file for documentation purposes.

The context-specific consumptions are then calculated according to the user-induced factors. For the application example, the temperature distributions for the selected location are analyzed to calculate the water consumption for garden irrigation at temperatures above 15 °C. As an intermediate result, the water consumption per household is output in a monthly resolution so that, on the one hand, tank sizes can be determined on this basis and, on the other hand, resource balancing can be performed.

Considering the calculated yields and consumption, the monthly tank volumes are calculated based on the mass balances for the residential units according to EN 16941-1, the self-sufficiency period is also considered as a design variable and set to a default of 21 days following the standard. Finally, the median volume of the individual monthly volumes is selected. Yields, consumption, and tank volumes are plotted per house and displayed as bar graphs. The tank must overflow regularly to drain off contaminants on the water surface, the so-called floating layer, such as leaves and pollen. It is assumed that the tank should overflow three times a year and drain two percent of the nominal volume. To accomplish this, the year is divided into three sections and the maximum fill level is determined in each section. The difference between the current tank content and the target volume (the 102%) is then covered with tap water. A monthly approach is taken for the final assessment of tank size for a unit so that fluctuations and outliers can be compensated for.

Up to this point, the program has viewed each RWH system as an isolated individual. For the networked view of the water grid, the program follows the model shown in Figure 5 with the central buffer tank. For resource balancing, a daily resolution is used to better analyze when and how much water can be exchanged and how many days can be covered with the buffer tank. A balanced matrix is created in which all relevant data are stored. The consumptions are divided into A, B, and C categories. The classification is based on the priority with which the individual consumptions are to be covered. A consumptions are toilet, shower, and laundry and should be covered with high priority. B consumptions are for garden irrigation and are fed when there is still water left after feeding the A consumptions. C-category water is used for car washing. It has the lowest demand priority and is fed only when A and B consumptions are covered. In the case of water rationing, B and C consumers can be blocked.

To be able to investigate and evaluate the aspect of resource balancing, two scenarios are distinguished, one being the allocation of shared water evenly according to per-head consumption and the other being allocation using prioritization. For the per-head allocation scenario, the current amount of water in the buffer tank is allocated proportionally to the total number of users. If a deficit remains in the user’s balance despite the allocated amount of water, the tank must be refilled with tap water. If the household has more water than it needs, the unused balance remains in the buffer tank.

The prioritization scenario considers both demand and the composition of the single sources and sinks, so that a bonus or malus can be set. For example, for the bonus, small differences are served first or the water that is supplied from external sources and cleaning water is subtracted from the difference so that the delivery of additional water is rewarded with a higher score. If the user uses most of their water for B and C consumption, they will again receive less water as a malus. The daily score is stored in the balanced matrix. On each day that households request water from the buffer tank, these requests are sorted by their score and served in order until all requests are met or the buffer tank is empty.

5. Evaluation and Application Examples

The system was tested on a neighborhood consisting of 10 one-family houses located in Hanover, Germany. Figure 8 shows the composition, numbering, and in the grey fields the individual yield areas in square meters. Moreover, the indicated population was generated by the consumer model following the BN approach, broken down by gender and age.

According to EN 16941-1, the weather data for the last five years were taken as input from the German Weather Service. Figure 9 shows the mean precipitation and temperature data for these five years, as well as the daily precipitation and temperature for 2020, which are the median of the data set (

Table 2. Overview of the evaluation results of House 4.

	2018	2019	2020	2021	2022	Average
Yield chance/BN [l/a]	31,625	42,382	35,658	46,953	32,910	37,906
Demand chance [l/a]	72,672	67,872	70,272	70,272	67,872	69,792
Demand BN [l/a]	63,156	58,356	60,756	60,756	58,356	60,276
Tank Volume [l]	1489	2052	1784	2461	1638	1885

). Because the extreme precipitation events are cut off in the mean, but these data are relevant to the resource balancing considered later, the 2020 data were used for the following simulations.

5.1. Comparison of the Demand Calculation Approaches for an Individual RWH System

To evaluate the influence of the demand calculation approach, the neighborhood referred to in Figure 8 was populated once using the BN approach and once by using the virtual tree diagram. Figure 10 shows the monthly evaluation for a household with four people, indicating the capacity of the tank, the amount of rainwater and cleaning water collected as income, and the calculated demand. This constellation is consumption-dominant, so that a self-sufficient supply of rainwater is not always given.

Additionally, Table 2 shows the annual yield and calculated demands for House 4 for the years 2018 to 2022. Comparing the two demand calculation approaches, the consumption in the chance calculation by using the virtual tree diagram is on average 15$\stackrel{.}{\%}$ higher than in the BN approach.

The consumer model also allows designers to create demand projections over time. In another scenario, the BN approach created an initial population of a two-person household consisting of a male aged 24 and a female aged 22, neither of whom owns a car. The data for the projection over 40 years can be taken from

Table 3. Projection over 40 years of a household.

Year	1	5	10	15	20	25	30	35	40
Age Man	24	28	33	38	43	48	53	58	63
Age Woman	22	26	31	36	41	46	51	56	61
Age First Child (male)			1	6	11	16	21	26	31
Age Second Child (female)				4	9	14	19	24	29
First Car	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
Second Car	No	No	No	Yes	Yes	Yes	No	No	No

. In year 9, the first child is born and two years later the second. In year 5, the first car is purchased, which remains in the household until year 37. Since with two children one car is no longer sufficient, another car is bought in year 12, which is sold after 18 years.

Figure 11 shows the water consumption for shower, toilet, laundry, and car washing in this projection. It can be seen that peak water demand is more than twice that of the initial setup.

5.2. Initial Networked Water Grid in the One-Family-House Neighborhood

The neighborhood shown in Figure 8 is considered for this simulation with a networked water grid. To enable the exchange of surplus water, a central buffer tank with a capacity of 10,000 l was included in the simulation. At the beginning of the simulation period, the buffer tank is completely filled. The self-sufficiency period was selected as 21 days in accordance with the above standard. The area of the garden to be irrigated was assumed to be 30 m² for all one-family houses. Irrigation is activated when a temperature of 15° is reached for five days.

Table 4. Simulation data of the one-family-house neighborhood.

Design Variables					Autarky Period of 21 Days
No.	Yield Area [m${}^{\mathbf{2}}$]	Inhabitants	Income [l]	Consumption [l]	Buffer [l]	Pipeline [l]	Tank Capacity [l]
1	100	1	35,682	10,920	80.89	3516	210
2	100	2	36,489	22,080	80.36	3381	840
3	100	4	35,759	36,960	314.63	10,596	1680
4	95	4	34,369	60,061	2112	27,721	1784
5	40	4	14,936	71,611	15,268	41,234	796
6	100	4	36,669	48,750	989.68	16,485	1884
7	100	4	36,333	60,301	2413	25,095	1926
8	100	4	36,249	67,501	2907	31,948	1901
9	100	5	36,183	102,150	12,700	54,457	1842
10	100	6	36,183	93,931	10,983	48,458	1842
${\sum }_{}$			338,852	574,265	47,849	262,891	14,705

shows the simulation data of the one-family-house neighborhood and the calculated replenishments from buffer and mains water supply, as well as the calculated tank size for each property.

To assess the resource balancing, Figure 12 shows the balance sheet for the entire neighborhood. In particular, it can be seen that Houses 1 and 2 generate a surplus throughout the year, which is due to the small number of inhabitants, whereas Houses 5 and 10 consume significantly more than they generate, either due to a small yield area or due to a high number of inhabitants.

The daily resolved capacity of the central buffer tank is shown in Figure 13. The peak that occurs above the 10,000 l mark is due to the high rain amount around day 40 (refer to Figure 9). It indicates the overflow of the tank for cleaning purposes. The high water demand of the neighborhood becomes visible, as the injected water is immediately consumed in the following rain-free days. For the long self-sufficiency period of 21 days, the size of the buffer tank of 10,000 l is significantly large.

Figure 14 shows the daily resolved filling level of the tank of House 4. In addition, the replenishment from the mains water supply (red) and the buffer tank (green) is plotted over the entire year. It is noticeable that the major part of the replenishment is tap water. The regularly occurring small declines in the replenishment curves, such as on day 98 and on day 105, result from the weekly refeeding of cleaning water into the storage tank and thus visualize the household internal water cycle mentioned in Section 3.2. It now could be considered to reduce the size of the storage tank of House 4 as the mean filling level is way below 50%.

5.3. Optimized Networked Water Grid in the One Family House Neighborhood

The system now basically offers three avenues for optimizing the RWH systems within the grid. The first is to examine the exclusion of single sinks, like e.g., car cleaning. Since this is not a true design variable but rather a calculation scenario, it is not considered below. The second is to include additional yield areas such as carport or terrace roofings. And the third is to adjust the self-sufficiency period to increase the exchange between the single properties and the buffer. To increase the yield in the given neighborhood, House 4, House 5, and House 10 will receive additional water harvesting options such as terrace roofing (15 m²) and a carport with two parking spaces (25 m² each). Houses 8 and 9 also expand the catchment area with a double carport. Figure 15 shows the updated balance sheet. The mean value has improved compared to the initial configuration, although it is still far in the negative range, so a further increase in the yield area would be advisable.

The effect on the buffer tank is also visible (Figure 16). Now, there are more overflows and the periods when the tank is completely empty are reduced. However, the inflow and outflow continue to occur at less than regular intervals.

Figure 17 shows the filling level of the rainwater tank and the replenishment of House 4 with the increased yield area. The size of the rainwater tank increased about 65 %, so the demand could be met independently for longer. As a result, the replenishment from the buffer tank and the in particular the mains water supply can be almost halved compared to the first scenario.

In addition to increasing the yield area, shortening the self-sufficiency period is another lever. Figure 18 and Figure 19 show the related data. It is clearly visible that the exchange between the rainwater tanks on the individual properties and the buffer tank has increased significantly. Nonetheless, the buffer tank still is used only to a little degree during the summer months.

Due to the generally smaller tank sizes, the replenishment both from the buffer tank and from the mains water supply has increased. In the case of House 4, the tank is now 977 l, and has nearly halved compared to the 1784 l in the initial scenario and decreased by only a third compared to the increased yield area with self-sufficiency period of 21 days. Nonetheless, the mean filling level is still below 50%.

Table 5. Quarter data of one-family-house neighborhood with increased yield area.

Design Variables					Autarky Period of 21 Days			Autarky Period of 7 Days
No.	Yield Area [m${}^{\mathbf{2}}$]	Inhabitants	Income [l]	Consumption [l]	Buffer [l]	Pipeline [l]	Tank Capacity [l]	Buffer [l]	Pipeline [l]	Tank Capacity [l]
1	100	1	35,682	10,920	254.74	3343	210	1461	3823	70
2	100	2	36,489	22,080	83.25	3378	840	1518	6573	280
3	100	4	35,759	36,960	585.51	10,325	1680	2847	12,832	560
4	160	4	57,334	60,061	908.26	15,412	2932	3598	20,580	977
5	105	4	37,902	71,611	8884	28,443	1993	13,083	28,531	664
6	100	4	36,669	48,750	3058	14,417	1884	5216	17,025	628
7	100	4	36,333	60,301	6640	20,868	1926	9306	22,638	642
8	150	4	53,915	67,501	1985	21,538	2822	5757	24,707	941
9	150	5	53,849	102,150	1286	40,308	2764	18,668	40,805	921
10	165	6	59,148	93,931	8310	34,466	3,040	13,569	36,027	1013
${\sum }_{}$			443,080	574,265	31,995	192,498	20,091	75,023	213,541	6096

summarizes the data for the simulated scenarios. It is noticeable that even for the reduced self-sufficiency period the amount of water that needs to be taken from mains water supply is reduced by 50,000 l compared to the initial configuration of the neighborhood, but with tank capacities more than halved. There seems to be a proportional correlation between the self-sufficiency period and house tank sizes.

6. Discussion

The above examples show the applicability of the implemented KBE system for the design of networked RWH systems. The consumer model allows conclusions to be drawn about the total water consumption of a household based on the composition and behaviors of its inhabitants. It thus allows the demand side of the mass balances to be simulated with a consideration of uncertainties in the requirements and extends the possibilities from the standards and most of the systems in the literature. A question that remains is the quality of the data used for modeling the probabilities. For this work, statistical assumptions obtained from available databases allowed the differentiation of different profiles according to age, gender, and individual habits. The installation of smart meters and recording their data on the resource streams within the water cycle of a standardized sample neighborhood would, of course, make the sizing more accurate. Additionally, the choice of the weather data set also has a direct impact on the calculation and represents an uncertainty for the inflow prediction. In the above scenario, the median data set of the last five years was chosen, but calculations can also be performed and compared for the median, wettest, and driest years. Complementing this with a fully functional rainfall generator, such as that mentioned in Section 2.3, would then allow for assessing the robustness of the RWH systems, e.g., with calculated mass balances ten, twenty, and forty years in the future.

The actual premises result in different avenues for model refinement. Regarding the catchment, the implementation of a first-flush model, such as that proposed in [66], instead of the fixed value, as well as a model for the gutter capacity, which limits the catchment during heavy rain, such as that mentioned in [20], seems promising to raise the precision of the inflow prediction. Regarding the consumers, a model for predicting the garden irrigation to a more sophisticated level, that distinguishes different types of beds and fields and integrates evaporation to calculate the irrigation water demand more precisely, would be interesting, as well as in the sense of an integrated simulation of a smart irrigation control. Additionally, a calculation of the evaporation rates of pools or ponds in the garden and the thus required replenishment is conceivable. Finally, the efficiency of the RWH system in terms of leakage and losses could be integrated. In the context of model refinement, it would generally be interesting to determine the effects of data resolution. As is known from the literature, especially for small storage tanks below the size of a cubic meter, a resolution at a sub-hour level improves the calculation quality of the mass balances significantly. In the above examples, several tanks pose this challenge.

In thinking about a completely decentralized water supply and the degree of self-sufficiency for a quarter, it is also possible to consider a wider range of sources and sinks. The goal must then be to further reduce or even replace the amount of tap water from the mains water supply. In addition to the obvious options of further increasing yield, drilling a well on the individual properties or connecting a well to the buffer tank, local wastewater treatment facilities are particularly interesting from the point of view of sustainability to increase water recycling. An alternative way to increase utilization here would be to sequence the different consumers. For example, the initially collected rainwater can be used for showering, and after the surfactants have been filtered out the water could still be used for toilet flushing or garden irrigation. As for additional sinks with a focus on residential districts, the necessary regular flushing of the sewage system could be integrated and also linked to times when the buffer tank is well filled. However, new applications from the construction sector might also be interesting, especially under the aspect of ecological building, e.g., the idea of adiabatic building cooling. In this natural cooling principle, rainwater is injected into the exhaust air of the building and cools it by evaporation. An air-to-air heat exchanger thus cools down the building’s supply of air. As a result, the energy required for building air conditioning can be reduced by up to 70%. Per cubic meter of rainwater, 700 kWh of cooling capacity is possible [76].

A further step in the development of the presented KBE system beside model refinement is the extension with configurable instrumentation data, including commercially available tanks, the choice of available pumps in accordance to the water demands of the individual consumers, and a calculation of necessary pipe diameters. In this way, the KBE system would output a basic bill of materials with the main components of the water grid. Coupling this to a 3D computer-aided design system and adding information about the geometric configuration of the properties, their buildings, and down pipe positions, for example, would then allow for building a design generator for water grids. The piping is then part of the output geometric data and could further be used for hydraulic simulations and for visualization of the resource streams in the grid itself. Adding relevant data about maintenance intervals, wear parts, and consumables, such as filter inlays, for the single water grid components, would then allow the quality of service cost estimations to be improved [77].

7. Conclusions

The authors successfully applied methods and tools from KBE to the design objects of RWH systems with different system boundaries. Designers are able (1) to investigate the effects of different catchment areas or alternatively calculate needed catchment areas according to the occurring demands, (2) to adjust or minimize the storage tank sizes and evaluate their effects on the individual harvest and the exchange with the central buffer, (3) to evaluate the demands within a neighborhood either with respect to maximum peak water demands or the temporal development over the yearly projection, and (4) to test the sensitivities of the single sinks and sources to the water grid. For urban planners, this offers the possibility, e.g., to make design obligations for housing construction or for the refurbishment of settlements.

In this increment, the KBE system is intended as design support system in which the necessary measures for optimization and the comparison of different system configurations are still performed by a human designer. However, the optimization of the local water network still requires experience. Some of the individual design variables influence each other, while individual measures such as shortening the self-sufficiency period appear counterintuitive at a first glance. To fully automate the design, the different viewpoints that occur in the design need to be mapped into the system. Following the principle of distributed artificial intelligence, a multi-agent system approach could be an interesting option. It would additionally allow the discussion and negotiation of the individual agents to be followed, in order to find the global optimum of the system configuration and to be explainable and trustworthy. The multi-agent system approach could also be of interest for the online management of existing water networks, e.g., integrating revenue models for surplus water offered to other network participants.