Integrating river basin DSSs with model checking

Abstract

This paper presents a decision support system (DSS) based on formal methods for the management of complex river basins in flood scenarios. The DSS is the result of integrating two different DSSs: first, a DSS for dam management that uses the Spin model checker to produce the manoeuvres and the discharged water over time to satisfy user-defined constraints; second, a DSS that performs numeric simulations of rainfall and water flow along the river basin, taking into account the water discharged by dams. By integrating these two DSSs, the user can define constraints over the parameters of the river basin and all the dams. We use Spin to find the sequences of dam manoeuvres that mitigate the effect of floods along the river basin, according to these constraints. This work is part of the SAID project, a European demonstration project whose main goal is to smartly manage river basins by means of the integration of different DSSs. The demonstrator basin is the Guadalhorce river basin, located in the south of Spain. We apply the method to develop a DSS for this river basin in particular, but the approach is general enough that it can be applied to any river basin.

1 Introduction

Mediterranean countries, like Spain, have built many big dams which ensure the water supply to the population during typical long drought periods and also limit the damage caused by floods by means of their flood discharge capacity (Spain is the fourth country in number of big dams, following USA, China and India). However, experience has demonstrated [17] that during a flood episode, the incorrect management of a dam can produce disasters worse than if the dam did not exist. This problem is even more complex when there are several dams in the same river basin, because of the difficulty to predict the cumulative effect of water discharging at several points in parallel.

The most common way to manage dams during flood episodes is based on the combination of weather forecasts and ad hoc decision rules. The dam operators usually estimate the input of water over time (the input hydrograph) with official forecasts and employ a pre-designed catalogue of management rules to decide water discharges. These rules take into account different parameters, e.g. the reservoir level, the weather forecast and the current downstream drainage capacity. One recent trend is the development of software systems that act as reliable decision support systems (DSSs) to assist dam managers in floods [13, 14]. These DSSs make use of simulation models that allow a detailed and faithful representation of a real-world system with complex mathematical models. However, they can only show the effect of applying a specific management policy. With this approach, a large number of trials are necessary to establish an optimal policy, which can drastically reduce the time to react to the flood.

In this work, we take advantage of a subset of the DSSs developed within the SAID project [1]. Each DSS covers a different concern, such as water quality or dam management, and its functionality is provided as a web service. In this way, the DSSs can be integrated to perform complex tasks that span multiple concerns. In addition, web services also enable the integration of the DSSs to cover use cases that were initially not considered in the project.

In this paper, we propose such an integration: a DSS for flood management that can produce a suitable (optimal) policy at the river basin level (with multiple dams), instead of at the dam level. That is, the DSS will propose manoeuvres for each dam of the basin considering any number of constraints both in the dams and in the basin. To this end, we flexibly integrate the dam management DSS with a basin hydrological model or basin DSS.

In [9], we introduced the use of model checking as a promising novel approach to build more powerful DSSs for flood management in a single dam. The proposal works as follows. We describe the dam’s physical components (like spillways and other types of outlet elements) with Promela, as well as a non-deterministic process simulating the dam manager’s actions on the physical discharge elements. An external tool provides the representation of the expected input water flow to the dam over time as a hydrograph. Finally, we add constraints over dam parameters, for instance, to keep the dam level between a minimum and maximum value or to discharge a maximum flow downstream. Constraints are encoded as a never claim, a special Promela process. Spin uses these inputs and generates a counterexample that corresponds to the manoeuvres over dams that satisfy the constraints. These counterexamples are always finite sequences of manoeuvres since the never claim processes correspond to safety properties.

Our previous work focused on managing a single dam. Thus, to manage a complex river basin with more than one dam, the dam operator must manually run our DSS for each dam and the hydrological basin models, appropriately linking the inputs and outputs to simulate the state of the basin. However, this is unfeasible in practice. In the conference version of this paper [7], we extended our previous work to use Spin as the core engine of a DSS for the coordinated management of all the dams in a river basin. We reuse the initial work in [9] to model every dam in the basin in a single Promela model, and we integrate an external hydrological river basin model to simulate the effects of the dams downstream. The managers can define constraints over the dams’ parameters or the basin flow downstream in different locations. Constraints over basin parameters are checked outside of the never claim, and the result of the evaluation directly affects the Spin exploration algorithm. The Promela model of the river basin now includes several dams and integrates different external (hydrological) models and safety constraints over the basin, and the management rules modelled as a non-deterministic process. We make extensive use of embedded C code in Promela, tracking a minimal number of variables and abstractions to reduce the state space. The embedded C code is also used to deal with discretized continuous variables and to propagate the effects of dam manoeuvres throughout the basin, using different time references. The output of the verification process is a sequence (or several sequences) of coordinated manoeuvres for all the dams to assist the manager in the decision making process.

To the best of our knowledge, there is no work on the use of model checking to synthesize the manoeuvres in flood episodes. Compared with other works in this domain, like FCROS [11] in Poland, DESMOF [2] in Canada, or IMSFCR [4] in China, our approach offers several novelties. While FCROS and DESMOF only include simulation of flood policies, our DSS and IMSFCR also calculate the necessary operations. IMSFCR makes multi-objective optimization based on fuzzy iteration, but it does not consider hydrological models downstream. Finally, Kars [12] presents one of the first applications of Spin model checker to the water management domain. In particular, the author uses Spin to verify the correctness of the control system of the storm surge barrier in Rotterdam.

This work extends the conference version of this paper [7]. We use the integration mechanism to replace the dummy model of the river basin used in [7] with the final model of a basin [5]. This basin model is calibrated for a real river basin in the south of Spain and uses weather forecasts and real historical data. The result is a DSS for flood management that considers the complete basin and its dams. The integrated DSS analyses longer flood episodes and produces more accurate results. However, it can produce larger state spaces, and the execution of this model takes longer than the dummy model.

The rest of the paper is organized as follows. Section 2 presents the SAID project’s objectives and some background to dam management. In addition, it introduces the river basin used as the case study. Section 3 describes our approach based on model checking, while Sect. 4 details how to build the different Promela models that form the river basin. Section 5 explains how to define constraints over the dam parameters and the basin flows. Section 6 describes the integration of our DSS for coordinated management of dams with a river basin model to produce a powerful DSS for basin management. Section 7 is devoted to the evaluation with the case study, and we present the integration with an initial dummy basin model and with the final hydrological model. Finally, Sect. 8 presents the conclusions and future work.

2 SAID: Smart Water Management with Integrated DSS

The work presented in this paper is part of the SAID (Smart Water Management with Integrated DSS) project, a European project under the 7th Framework Program, with partners from Spain, Germany, Portugal and France. The project focuses on the deployment and evaluation of a complex demonstrator, composed of several heterogeneous and innovative DSSs in the same river basin. The demonstrator basin is located in the south of Spain and is representative of many similar basins in Europe. The SAID consortium is developing and validating innovative DSSs and methodologies that can benefit to all stakeholders and in particular to water authorities.

One of the objectives is to integrate DSSs with different purposes into a single DSS capable of supporting decisions, considering different management aspects. Figure 1 shows the approach of the project. In the first phase, different DSSs have been developed/adapted and calibrated for the demonstrator basin. In addition, the SAID sensor network has been deployed to enhance the existing sensor network, which provides the observed data. In the second phase, an integration platform has been developed to integrate the existing DSSs as modules of a complete river basin management DSS. In this way, the final user (dam or basin manager) has access to all the functionality via a unified interface and can define management objectives in different domains. One instance could be releasing the water demanded with a maximum salinity and optimizing the energy produced by the hydroelectric power plants of the basin. The user is not concerned about how each isolated DSS works, their input data and their outputs, or if it is necessary to chain the execution of different DSSs.

Fig. 1

SAID project approach

The integration platform coordinates the executions of all DSSs assuming two different management scenarios of the demonstrator basin: (1) basin management in flood episodes and (2) basin management in ordinary operation. For each scenario, the chain of DSSs executed and the data exchange between them is defined. In the work presented here, we use the integration platform and extend the flood management scenario with a model of coordinated dam management. Thus, the management policy takes into account the objectives of all basin dams globally, instead of managing each dam separately to satisfy its objectives.

2.1 Background to flood management

Flood management is a complex task, especially in Mediterranean basins, which are characterized by long drought periods and short but intense rainfalls. Dams are an important element in this kind of basin, as they store water for two main purposes: to supply water to the population in drought periods and to control floods. With correct management, a dam can smooth the peak rainfall and avoid downstream flooding.

Fig. 2

Dam discharge elements

Dams are equipped with different types of discharge elements. Figure 2 shows the discharge elements of the Conde del Guadalhorce dam, which is included in our case study. Spillways are gates for flood regulation. They usually have the highest discharge capacity. In our case study, intakes are connected to a hydroelectric power plant and are not used in floods, so they are not in the model. Outflows can be used for flood regulation or other water uses (supply, irrigation or energy production), and their discharge capacity is lower. In general, the outflow capacity of a dam’s outlets depends on their location, which is fixed, their opening degree, which is variable, and the dam level, which changes following Equation 1, where V(t) and $V(t-1)$ are respectively, the water stored at instant t and $t-1$, $Inflow(t)$ represents the water input and $Q_{s_i}(t)$ is the water discharged by outlet $s_i$. Equation 2 shows the discharge capacity of a spillway gate, where $h_{s1}$ and $h_{s2}$ are the water level and the position of the gate evolving over time. The other components, C and L, depend on the geometry of the gates and can be considered constant.

$$\begin{aligned}&V(t)= V(t-1) + \left( \mathrm {Inflow} (t) - \sum _{i=1}^n Q_{s_i}(t)\right) \end{aligned}$$

(1)

$$\begin{aligned}&Q_s(t) = C L \left( \root ~ \of {h_{s1}(t)^3}-\root ~ \of {h_{s2}(t)^3}\right) \end{aligned}$$

(2)

Basin and dam management is a controversial issue, especially in flood scenarios. Dam management has been traditionally carried out by a human operator, who has to manage in parallel the different outflow elements. In addition, a basin can include several dams in parallel and/or cascade, and the management of one dam can have a direct impact on the other dams and on the population downstream. Moreover, in Mediterranean basins, with short and intense rainfalls, dam managers have little time to decide how to operate to ensure dam safety considering the management of the other dams.

2.2 The Guadalhorce case study

In this work, the case study is the Guadalhorce river basin, located in the province of Málaga, in the south of Spain. The basin has a total area of 3175 km$^2$ and is responsible of supplying water to the city of Málaga, a touristic city with a population of more than 500,000 inhabitants. In addition, the basin supplies water for human consumption and irrigation to other small cities of the province. The Guadalhorce basin has a short concentration time: water flows from the headwater to the mouth in approximately 8 h.

Figure 3 shows the basin area. The Guadalhorce is the main river of the basin. Its flow is controlled by means of three dams (Guadalhorce, Guadalteba and Conde del Guadalhorce), which are located at the confluence of the Guadalhorce with the Turón and Guadalteba rivers. The three dams are managed by the Andalusian Regional Ministry (Consejería de Medio Ambiente y Ordenación del Territorio) and are used for flood management and water supply. Table 1 shows the main data of the three dams.

Table 1 Main characteristics of the dams

Fig. 3

Guadalhorce river basin and dams

The management of the Guadalhorce and Guadalteba dams is special. These dams are separated by a wall measuring 355 masl (metres above sea level) from the base (see bottom half of Fig. 3). During the flood season, water is usually over this level and both dams are managed as a single dam. In fact, they have been designed to share the spillway, which is located in the Guadalteba dam. From now on, we will refer to the Conde del Guadalhorce dam as CGH and to the Guadalhorce and Guadalteba dam jointly as GH-GT. Since the three dams and their outlets are very close, an important aspect of their management is the synchronization of peak discharges to avoid downstream flooding. In the main river channel, there are no other dams downstream, but there are many tributaries that flow into the Guadalhorce River. The largest tributaries in volume are the Grande River, which flows into the Guadalhorce 35 km downstream, and the Campanillas River, which merges near the river mouth.

From the point of view of flood management, the basin has four locations in which water flow must be monitored. The first one is La Encantada hydroelectric power plant, which is located 7 km downstream of the dams. The second and third locations are at the confluence of the Grande River and the Campanillas River with the main river channel. Finally, the fourth point is the river mouth, which is located in the city of Málaga, near the international airport.

In this work, we present a DSS for this basin based on model checking. The basin manager has to define constraints that describe the desired behaviour of the basin for a specific flood episode. Then, the DSS produces a sequence of manoeuvres that satisfies the constraints. Figure 4 shows an example of the results produced by the DSS, with the level (left axis) and total outflow (right axis) of each dam at the top. Then, the evolution of gates’ openings is displayed. Finally, at the bottom the water flows in the basin are shown.

Fig. 4

Synthesis of manoeuvres

3 Approach with model checking

As it has been already mentioned, we use model checking in order to synthesize management recommendations that meet the constraints given by the dam manager. In particular, we use Spin  [10] as the underlying model checker and, in consequence, Promela as modelling language. In addition, the Promela model we built also uses an external model for the river basin, developed independently. Given a set of constraints over the variables of the dams and the river basin, Spin will explore exhaustively all possible manoeuvres and produce a suitable set of recommendations for the dam manager that fulfils the constraints.

Figure 5 shows an overview of our approach and how the Promela model and the external river basin model interact. First, we must model the dam (or dams) which will be operated by the dam manager.

The management of the dam outlets is defined in a non-deterministic model, which determines when the gates should be opened or closed according to the operation rules, affecting variables such as the water outflow and the dam level over time and, consequently, the outflow across the river basin. The latter is provided by an external river basin model, which is not modelled in Promela. The external river basin model takes the outflow of the dams and other environmental aspects as input and computes the flow at several points across the river basin. All these models will be described in Sect. 4. Finally, the user may set restrictions on the dam parameters or at points of interest across the river basin, using timed automata or upper and lower curve bounds, as explained in Sect. 5.

Fig. 5

Overview of synthesis of recommendations for dam management

Once the models and the restrictions are in place, the analysis can proceed. The management rules, modelled in Promela, are evaluated periodically to select and apply one manoeuvre from those available. Then, the dam model computes the water discharged between manoeuvres. This will serve as input for the external river basin model, which is also executed periodically to compute the outflow along the basin.

Depending on the state of the dams and the set of management rules, the management model may have several options available whenever it has to make a decision. These options constitute the state space to be explored. Thanks to the exhaustive exploration provided by Spin, the analysis can obtain all possible manoeuvres that the dam manager can choose during the course of an episode. If a particular series of actions leads to a state that violates the constraints over the dams or the basin, Spin will backtrack and try different manoeuvres, until the end of the episode is reached while fulfilling specified constraints. This will produce a counterexample that contains the manoeuvres that satisfy the constraints.

4 Dam and basin modelling

The management of the river basin is based on the analysis of a Promela basin model against a set of properties that describes the constraints of dam and basin parameters, such as dam level or water flow. It is worth noting that some of these parameters have a continuous evolution over time and have to be properly represented to avoid state-space explosion problems.

The global model of the basin comprises different sub-models, such as the model of the dams and their outlets, or the model of the water flow downstream. As mentioned above, in this work, we have used Promela as the modelling language, embedding C code to describe some complex mathematical equations. In addition, we have used C code to embed the interaction with external models developed by third parties.

In this section, we describe the main structure of these sub-models and some specific issues for the case study.

4.1 Dam model

There are two main aspects that must be taken into account by a dam model. First, it must describe the evolution of the main variables of the dam over time and how they are related, e.g. the relation between dam volume and dam level (dam’s bathymetry) and the relation of the stored water volume and the water inflow and outflow over time. Second, it must provide a mechanism to change the state of the dam outlets, i.e. their opening degree, during the analysis.

In [9], we presented a simplified version of a dam model. We describe the dam as a Promela proctype that receives commands from the dam manager (another proctype) to change the opening degree of the outlets. After updating the state of the outlets, the model computes the flow discharged by means of embedded C code that describes the outlet equations. The dam model is executed periodically with a discrete time step. The model assumes that the variables evolve linearly over time between two time steps. The length of the time step directly affects the precision of variables values and the number of states. In previous and current work, we select a time step of one minute, which can be considered small. In this work, we have improved the dam model such that it is now possible to describe and analyse the behaviour of dams with more outlets, more outlet opening degrees and longer flood episodes. In addition, we also allow non-operative outlets, i.e. outlets whose state cannot be changed. Figure 6 shows the skeleton of the dam model used in the case study.

To reduce the state space to be explored, we make extensive use of embedded C code and export some of the C variables into Spin ’s state. Some of these variables have been declared as UnMatched, i.e. outside the scope of Spin ’s state matching algorithm, to reduce the number of states. In other cases, we have abstracted the values of several UnMatched variables into a single variable in Spin ’s state. For instance, from the point of view of management, an outlet with two identical gates can be in three different states: (1) both gates open, (2) both gates are close or (3) one gate is open and the other close. To work out the discharged water, it is not relevant which specific gate is open (the left one or the right one), only the number of open gates. Thus, we set as UnMatched the specific opening degree of each outlet gate and only set as Matched the number of outlet gates in each possible opening degree.

Fig. 6

Promela dam model

Finally, to improve the portability of our proposal to other basins, we have defined a systematic way of defining dam models, which has been implemented in a prototype tool as part of the SAID project. Using the tool, called DamMod, it is possible to easily and quickly develop models of new dams without errors. Figure 7 shows some screen shots. DamMod has an intuitive graphical user interface based on forms that let the user define the main dam characteristics, such as operational and extraordinary levels, basic parameters and the characteristics of the discharge elements (equations, number of gates, etc.). With this information, the tool automatically generates the Promela code of the dam model, which contains embedded C calls, and the C functions to support these calls. In addition, it produces other files used by the DSS graphical user interface, which are beyond the scope of this document. The models generated can be customized by an expert modeller with knowledge of Promela and the algorithms of Spin.

Fig. 7

DamMod Tool

4.2 River basin model

To manage a complete river basin, we need a hydrological model that simulates the water inflow to the dams and the flow downstream. There exist different hydrological models and simulation engines that fulfil our needs. Other partners in the SAID project have developed a tool to run hydrological and hydrodynamical models of the Guadalhorce river basin. Section 6 provides more details on this tool, the basin models and how the execution and results are integrated in the Spin analysis. In this section, we treat the basin model as a black box that, given the water released by the dams, produces the water flow at different locations.

We assume that the basin model can be used to obtain the inflow hydrographs of each dam for the flood episode. Thus, before the analysis, we manually run the black box basin model to obtain the required inputs. In our case study, dams are not in cascade, and their inflow hydrographs are independent of the manoeuvres performed during the analysis. Then, during the analysis with Spin, the black box model will be executed periodically, using embedded C code, to simulate the water flow downstream for different sets of manoeuvres. The model will return the resulting hydrographs at predefined locations in the basin, showing how the manoeuvres affect the flow along the river basin.

While the Promela model simulates the dam behaviour when the manoeuvres are applied in a short time period, e.g. every hour, external river basin models are usually meant to simulate longer periods of time, e.g. several hours or days. In addition, the execution of a hydrological model can take longer. Thus, executing the external river basin model for each new manoeuvre to find out their effect downstream can be very time-consuming. To reduce this problem, the execution of the external model can be configured for a longer period, for instance, to simulate the effect of the manoeuvres for the last few hours or to fit with its minimum simulation time.

In addition, we are only interested in the portion of the simulation which was affected by the chosen manoeuvres. The external model provides hydrographs at several points of interest along the river basin, which are increasingly further away from the dam. Although the distances are constant, the time elapsed between the manoeuvres and the water affecting these points downstream varies dynamically depending on several conditions. For our analysis, we use the estimated minimum of these times for each point (provided together with the river basin model) to determine which part of the basin flows can be safely analysed. If a property is violated in this part, Spin will backtrack and try another set of manoeuvres, as explained previously.

It is worth noting that we do not check the constraints in a portion of the basin flows that has not been affected by the water discharged from the dam. If we did, Spin could detect a constraint violation in an unaffected portion of the basin flows and then incorrectly assume that the chosen manoeuvres had a negative impact. This would lead to backtracking and choosing a different set of manoeuvres, while in reality the discarded set could be valid. If these manoeuvres did in fact have a negative impact, this will be eventually detected by the analysis, and they will be discarded during backtracking.

This approach to timing allows us to synchronize the simulations of the external river basin model and the Promela model. The approach is shown in Fig. 8, which shows a dam and two basin locations (#1 and #2) along the river basin. The Y axis shows the minimum distance in hours between the dam and the two points. The dots along the dam line represent manoeuvres chosen by the management model. The dashed lines show the minimum time it takes the water released from the dam to reach and influence the two basin points. For instance, water released in $t_0$ will reach points #1 and #2 at $t'_0$ and $t''_0$ at the earliest, respectively. A flow is shown for each element above its line, e.g. showing how the peak discharge in the dam is smoothed as it flows downstream. Also note that any flow from the river basin model before $t'_0$ and $t''_0$ will not be affected by any of the manoeuvres.

Fig. 8

Timeline of different basin elements

In this example, the dam manager chooses a manoeuvre every hour, but the external model is executed every three hours. Between $t_1$ (inclusive) and $t_2$ (non-inclusive), the manager performs three manoeuvres. The shaded area shows the part of the river basin that will be affected by these manoeuvres, i.e. interval $[t'_1, t'_2)$ for point #1 and $[t''_1, t''_2)$ for point #2. The constraints set by the user in the river basin will be checked for these intervals. If one of the constraints is not met in these intervals, Spin will backtrack and try a different set of manoeuvres. If the water is slower than the minimum time, possible constraint violations will be detected later, but will result in backtracking to try new manoeuvres as well. Finally, if a constraint is violated before $t'_0$ for point #1 (or $t''_0$ for point #2), Spin will explore the possible manoeuvres at $t_0$ and determine that there are no manoeuvres that satisfy the constraint.

4.3 Management rules

The management rules define how the dam manager has to act in flood episodes. These rules are included in the dam manual and consider average and maximum rainfalls. Rules are usually described as if-then statements to simplify their application during flood episodes. Our objective is to provide the dam (basin) manager with a set of manoeuvres that leave the basin and its dams in a safe and desired state. To this end, we have extended and modelled the management rules defined for the three dams of the Guadalhorce basin. Figure 9 shows the skeleton of the current management rule model. The model monitors the dams and operates (or not) periodically to model the real management and also reduce the state space. In this case study, the model can operate the dams each one or two hours (e.g. lines 37 and 44) depending on dam’s state.

This model includes most of the original if–then rules included in the dam manual. In extreme situations, that is, when the dam level is very high or low, the rules are deterministic. For instance, lines 14–17 implement a rule that closes all outlets if the Conde del Guadalhorce level is under $MNO\_C - SHELTER\_C$ and the dam level is decreasing. Similarly, lines 28–30 describe the rule for the Guadalhorce–Guadalteba dams. In addition, the management rule model includes non-deterministic choices, making it possible to synthesize manoeuvres that satisfy different constraints. The number of non-deterministic choices directly affects the state space of the model. In addition, the coding of the model directly affects the analysis performance and the results. For instance, we have used the order of non-deterministic choices to first explore sequences of manoeuvres with a lower cost; that is, the DSS will return solutions with fewer operations if possible, which are more suitable in real flood management. Thus, this model can be refined to produce appropriate manoeuvres in a short period of time with the resources available. Figure 10 shows an example of non-deterministic choices. In the example, when the level is in the interval $(lower\_1, upper\_1)$, three different choices are available. The manoeuvre with the lowest cost is to leave the gates in their previous state (line 5). If constraints are not satisfied, Spin backtracks and tries the second or third branch. The second branch opens four gates if they were not previously open (line 6). The last branch opens only two gates. Using this branch, it is possible to open two gates and then the other two, which can have a higher cost.

Fig. 9

Promela Operation rules

Fig. 10

Promela non-deterministic rules

5 Constraints for synthesis of management decisions

The objective of our DSS is to provide different alternatives to manage the dams of the basin in flood episodes. Given a particular flood scenario, the DSS has to synthesize a set of manoeuvres that preserve the safety of the dams and the basin. For each scenario, we describe the safety of the dams and the basin as a set of constraints. In our case study, during the flood season it is desirable to maintain dam levels lower than in other seasons and keep the flow at the river mouth under a threshold to avoid flooding the airport. These constraints are then transformed into safety properties that are analysed against the model using Spin. The non-deterministic behaviour of the operation rule model, presented in Sect. 4.3, allows the DSS to come up with different basin management alternatives.

In [8], we described the constraints as LTL formulas that Spin automatically translates to a never claim proctype that represents the Büchi automaton associated with the LTL. However, LTL is not suitable for describing properties that refer to precise time instants. In [15], we defined the constraints as Timed Automata [3], which are automata extended with real-valued clocks, and we proposed a translation from Timed Automata to never claims, using a discretized clock variable. In both cases, constraints were always relative to dam parameters, such as the dam level or the outflow. The state space of the discretized automaton is a subset of the original; thus, we ensure that in this discrete time instant the dam model satisfies the constraints. However, given the nature of the variables modelled (dam level, water flow, etc.) and the small time step used we can consider the variables linear between two time steps (with a small precision error). Thus, we can guarantee that the constraints are also satisfied between two discrete time instants.

Fig. 11

Constraint described as (a) timed automaton and (b) never claim

In this work, we allow the definition of constraints over dam parameters and flows at locations of interest in the river basin. The evaluation of these two types of constraints is slightly different. We use the approach presented in [15] to define and evaluate constraints over dam parameters. In this case, the constraint is described as a timed automaton and translated into a never claim with an acceptance state that is only reached if the constraint is satisfied. When Spin analysis reaches the acceptance state, the analysis ends and returns the sequence of states leading to this error state. The sequence of states includes the scheduling of manoeuvres performed by the management rule model. Figure 11 shows an example of a timed automaton and never claim used to synthesize a set of manoeuvres. The constraint is to maintain the dam_level under a threshold level1 in period [0, t1] and under threshold level2 in period [t1, t2]. When the never claim reaches the state accept_st3, the analysis will stop and return the execution trace of the basin model, including the management rules applied to dams. If the state accept_st3 is never reached, the analysis eventually ends but without manoeuvres that satisfy the constraint.

To analyse constraints over basin flows, we have to extend this approach. The main reason is that the external hydrological model returns the temporal evolution of the flows for future time instants that are not easily synchronized with the timing of the Promela model. The constraints over basin flows are described as curves that serve as the upper or lower limit for some of these flows. In Sect. 4.2, we explained how the hydrological model is periodically executed to compute the effects of the manoeuvres downstream. Figure 12 shows how the external model is called (line 5) and how the constraints over basin flows are evaluated (line 8). When execution of the external hydrological model finishes, its results are stored in hidden C structures. These values are checked by the function basin_check_constraints, which compares the results against the constraints set by the user. Only the interval affected by the manoeuvres since the last time the external model was executed is checked, taking into account the distance from the dams to each basin point of interest. Observe that the function is called using the primitive c_expr instead of c_code. If the checks succeed, the analysis can continue, but if the checks fail, the instruction is not executable and Spin has to backtrack to a state where different operation rules can be selected.

Fig. 12

Evaluation of constraints over basin flows

When constraints are only specified over the basin flows, the never claim has to check that time t reaches the end of the episode.

6 Integration with hydrological basin models

This section presents the final basin model integrated with our approach and explains the differences with respect to the initial dummy model.

One of the objectives is to combine different models and DSSs to achieve the integrated management of a complete river basin. As a result, an integrated tool [5], based on REST Services [6], transparently executes the different DSSs (dam and basin management, energy production, etc.) and produces a unified result.

We take advantage of the REST service to integrate the DSS for basin management with our DSS for coordinated dam management. The DSS for basin management is based on the tool Hydroview [18], which uses two different types of models and simulation engines: WiMMed [16] simulates distributed hydrological models and GuadalFortran [19] simulates 1-D hydrodynamic models. The SAID partners are currently calibrating these models with historical data from the Guadalhorce basin to produce accurate simulations.

To integrate the different DSSs, each one offers an API with its functionality. Hydroview offers a simplified REST API to configure and run simulations, based on JSON messages. Figure 13 shows an example of interaction between a client and the Hydroview service. Hydroview is automatically updated to a date that determines the start of the simulations. This date cannot be modified using the REST API. We can configure the number of simulated days (n) from that date. Currently, the maximum number of days is 3, which corresponds to the longest weather forecast available. In addition, we can define the flow discharged by the dams as data time series. Hydroview simulations take longer than the black box simulations and depend on the execution platform. In our case, it takes on average 2 min and 30 sec to simulate 3 days. For this reason, after a simulation request, the service replies with the $simulation\_id$. The client has to periodically check whether the simulation has ended using the simula $tion\_id$. While the simulation is running, the service replies with an empty JSON. When the simulation ends, it replies with a JSON containing the flows of all basin locations.

Fig. 13

Hydroview Service API

To simplify the integration of the Spin analysis and the Hydroview service, the basin model in Fig. 5 is extended with an adapter. The initial dummy model of the basin runs on the same machine and provides a set of C code functions that Spin can call to obtain the flows and to check if they satisfy the constraints. The adapter provides the same C code functions, in such a way that the Spin models remain the same. The adapter communicates with the Hydroview service, which can be hosted on a different machine. It launches simulations on the service, waits for the results and returns only the flows at the locations that are considered in the Spin analysis. Figure 14 shows these elements.

Fig. 14

Integration with Hydroview service

7 Evaluation

In this section, we present the analysis of two flood episodes using, in each case, a different river basin model. In Sect. 7.1, we evaluate the approach using the black box basin model. In Sect. 7.2, we evaluate the performance using Hydroview to simulate the basin flows.

7.1 Evaluation with the dummy basin model

We analyse a flood episode of 60 h to evaluate the performance of the DSS. Figure 15 shows the dam inflows and their initial state. Since the levels of the Guadalhorce and Guadalteba were above the separation wall, we can manage them as a single dam.

Fig. 15

Flood episode inflow (graph) and initial dam state (table)

Using this initial configuration and the inflow hydrographs, we carry out different analyses. The first one checks that the model (Promela plus embedded C code) does not end in invalid states. For this analysis, there are no constraints over the basin or the dam; thus, Spin explores all the possible execution branches produced by the non-deterministic behaviour of the management rule model. The analysis ends without errors and thus without counterexamples. However, using the log information, we can identify 15 different manoeuvre sets for this episode.

For the same management rule model, the number of manoeuvre sets varies with each flood episode.

The following analyses include constraints to synthesize specific manoeuvres. To this end, we configure Spin to analyse the system plus a never claim and to stop when the first error occurs. Constraints can be defined over dam parameters and the basin flows, in an independent or combined way. The objective of the second analysis is to limit the outflow of GH-GT and CGH and the flow at the four locations to under 310 $\mathrm {m^3/s}$. Figure 16 shows the never claim used to describe these constraints. The analysis ends with an error, which means that there is at least one set of manoeuvres that satisfies the constraint. Figure 4 shows results: the evolution of dam parameters, the flow downstream in different locations and the manoeuvres of the different outlets. In this case, the spillway of the GH-GT dam remains closed, and the other gates are opened at different degrees over time.

Fig. 16

Never claim for constant constraints

Fig. 17

Timed automaton for variable constraints

Table 2 Spin statistics with black box basin model

Table 3 Spin statistics with Hydroview basin model and the new management policy model

Fig. 18

Synthesis of manoeuvres—integration Hydroview

Finally, there are two ways of defining variable constraints over dam parameters. One approach is to define constraints as curves that define the upper and lower bounds of the parameters. These curves are stored in UnMatched C structures. The never claim is modified to compare the parameter with the curves. For example, the definition of inv1 in Fig. 16 can be modified to check that outflow_c is always under the curve stored in curve[0] as follows:

$$\begin{aligned} {\texttt {\#define~inv1~e\_expr\{outflow\_c<~curve[0][t]\}}} \end{aligned}$$

Another approach is to define constraints as a timed automaton that represents sequences of intervals. This approach does not require C structures, which reduces the memory and time required, but the constraint has to be constant in each interval. The timed automaton is transformed into a never claim, as explained in Sect. 5. The last analysis (the third one) uses the second approach to restrict the level of CGH dam at four different time intervals. Figure 17 shows the timed automaton that represents the variable constraint. The analysis ends with an error that corresponds to the manoeuvres, which are very similar to the previous ones. In this case, the CGH spillway is completely open in two steps, while in the previous analysis, it is opened in three steps. Since the spillways are the gates with greatest discharge capacity, this small change has a great influence on constraint satisfaction.

Table 2 shows the statistics of Spin for each analysis. Note that the state space is fairly small, this is thanks to the use of UnMatched C variables and the abstraction of outlet states described in Sect. 4.1. The time elapsed in each analysis depends on the calls to the external model. We have measured the execution time of the external model to determine how much time is spent on these calls. If we do not consider the execution time of the external river basin model, the time consumed by Spin in the first analysis (that explores the complete state space) is 1 min and 26 seconds, in the second analysis is 10 s and in the third 12 s Observe that the depth in the second and third analysis has increased, because of the interleaved execution of the Promela model and the never claim that defines the constraints. Finally, note that the number of matched states is 0 or 1, which means that there are no repeated states. This is mainly because of a global timer in the Promela model, which is defined as a C Matched variable that counts the number of minutes of the flood episode. In addition, when Spin backtracks to a state, the management rule model operates the dam outlets in a different way, which causes a different evolution of the other model variables.

7.2 Evaluation with the Hydroview basin model

In this section, we evaluate our DSS integrated with the Hydroview service. We use the same initial state of the dams, but not the same hydrograph. Since Hydroview only simulates complete days, we have extended the inflow hydrograph up to 72 h. We have added 4 h of zero inflow at the beginning of the hydrograph and 8 h of zero inflow at the end. In addition, because of Hydroview’s minimum simulation step and the time it takes to perform a simulation, the external model is executed every 24 h instead of every 3 h. In this way, we reduce the number of Hydroview executions and the total time elapsed in the analysis. There are also some changes that affect the dam model. In the last few months, the SAID project has carried out enhancement and calibration tasks, which have principally affected the discharge equations of some outlets and the management rule model.

We have carried out an analysis similar to those presented in Sect. 7.1 with the black box model. Specifically, we have (1) checked that the models have no invalid end states and (2) synthesized manoeuvres that maintain the dams’ outflows and basin flows below 310 $\mathrm {m^3/s}$. Table 3 presents the statistics of the three analyses, and Fig. 18 shows the manoeuvres and evolution of the dam parameters for the second analysis. In this case, the DSS proposes to completely open the two low level outlets of CGH dam and open only 20% the two spillway gates, in particular the lateral gates.

Since there are changes in the outlet equations and the management rule model, the manoeuvres obtained are different to the solutions proposed in Sect. 7.1. The same occurs with the statistics of Spin. We can conclude that the integration with the real hydrological model drastically increases the total execution time, but the rest of Spin ’s statistics are in the same magnitude. In addition, we have observed that the management rule model should be calibrated according to the calibrated hydrological model (order of the rules, guards and number of non-deterministic choices, etc.) to improve the performance of the DSS.

8 Conclusions and future work

We have provided a complete case study to show how the Spin model checker can be a central part of a DSS to help in mitigating the effects of floods in river basins. The methodology to generate the dam and management rule models, which exports a reduced number of C variables into Spin ’s state and reduces the interleaving of the different processes, makes the approach effective enough in regard to both the effort to write the Promela models for each specific river basin and also the time needed to synthesize the appropriate manoeuvres. In addition, to improve the portability of the proposal, we have developed a modelling tool that automatically generates the code of the model from a simple description of the dam and its discharge elements.

We have defined a mechanism to integrate an external hydrological basin model, considered as a black box, in the DSS based on Spin. This mechanism has been applied to integrate the tool Hydroview into the analysis to include different basin models. The integration is based on an adapter element that offers the Promela dam model the set of required C functions and also knows how to configure and run the basin model. In this case, the adapter configures and executes the basin model using the REST API of Hydroview. During the integration with the final basin model, the management rule model, used to synthesize the manoeuvres, was calibrated to improve the quality of the synthesized manoeuvres and reduce the time needed to find the manoeuvres. Calibration is an important task that should be performed when the hydrological basin model changes to ensure an acceptable performance.

This novel application domain opens the use of the Spin model checker as a central component of (commercial) DSSs demanded by the authorities that manage big dams in many countries. This is a real need identified in the current European Research Project SAID.

Future work will include the analysis of time step impact in the results of the simulations, that is, the error introduced in the calculations of flows in the basin. In addition, the work could be further extended to introduce additional optimization when there are many dams in cascade in the same basin. In this kind of basin with dams in cascade, we cannot compute in the same “simulation step” the state of each dam and the flow at all points of the basin. For instance, when the upper dam changes the opening degree of an outlet, it is necessary to transform its outflow in the inflow of the lower dam. Using the current approach, this implies the execution of the external basin model. Although we have not modelled a cascade basin yet, it is clear that the analysis time will increase since we have to run more simulations of the external river basin model to obtain the state of the complete river basin in a time interval.

We are also working on a different way of building the models in order to exploit parallel execution of Spin for very complex river basins. Finally, we are working on integrating the proposed DSS into the integration platform of the SAID project. To this end, we are developing a web service with a simple REST API, which will allow us to configure the initial state of the dams, define constraints over dam parameters and a predefined set of locations and launch the analysis.