3.2. Case Study Results
Following the phases outlined previously in Figure 3
, a great understanding of the water SoS is achieved through applying CONOPs methods such as rich picture diagrams (Figure 1
and Figure 6
) and causal loop models (Figure 7
). The advantages of causal loop diagrams are that it helps analyse complex systems and helps identify key dynamic variables for later simulations. Cause and effect diagrams are a crucial aspect of designing resilience systems, particularly for understanding the dynamics between key variables. The loops which are created show an overall effect on the system and this is one of the elements of a causal loop diagram as illustrated in Figure 7
, where the overall effect is a decrease in water available due to damaged infrastructure in times of a flood event. Although this seems a basic construct, reducing to this level of complexity is beneficial in exploring potential solutions, and determining the types of data sets required for simulating later in the process. Thus, from the causal loop it can be determined that the solution that needs exploring is the flexibility of the current systems in place to search for strategies and also architectural solutions which regulate the availability of water and hence, the supply of water to those that require it.
The rich picture and causal loop models helped define the requirements for this case study, and eliciting requirements for resilience in this case was done in collaboration with a range of stakeholders via small workshops, including; water companies, water consultancies and academics interested in water applications.
A subset of architecture models has been provided here to illustrate the type of modelling, but the reality is there would be numerous instances of some models from different stakeholders’ standpoints to describe the CSs and to elicit further resilience requirements. The two models here show a general Operational Viewpoint (OV-5b) of the water processing procedure and a Systems Viewpoint (SV-1) of the water companies’ systems arrangement and connectivity (Figure 8
and Figure 9
, respectively). Figure 8
shows a high-level process model of taking raw water and passing it through a series of stages such as initial water storage, water screening, filtering etc. prior to being supplied for water customers and consumption. Figure 9
shows four high level components of a water system; a water company, distribution network, customers and consumers and waste water distribution network. Again, these are then populated with further subsystems which must be present to make the systems functional. Multiple instances of each model type can be created to model specific system structures, but these are for demonstration purposes.
Evolutionary development of the SoS architecture should be addressed by iteratively updating the specific constituent systems with the overall SoS in mind. The reference architecture is only as good as the quality of the information it holds and therefore, it is crucial that quality information is captured in its views/models. These static architectural representations go a long way in the design phases, allowing effective communication with stakeholders who have an influence on shaping the CS and the requirements definition process for future phases of the SoS evolution.
Subsequently, modelling the system using the resilience viewpoint (more specifically, Resilience View 2—RV-2) allows the engineer to highlight which nodes are critically dependent on each other and also to show which nodes are vulnerable if failure was to occur at some point in the network. For instance, modelling the case study example, shown in Figure 6
, the viewpoint shows the four demand points being critically dependent on the functioning of the pump, and vice versa, the demand points being vulnerable on the pump failing. Similarly, the water storage component, or the primary service reservoir becomes vulnerable if the pump is no longer working, because that clean water has a set period which it can be stored for before becoming unsafe to distribute. Figure 10
shows the capability of RV-2 to model further details of each SoS component, for instance, the main supply pipeline has certain attributes which can be assigned to that element. These may include important parameters such as flow rates, flow direction, capacity, and others which are important in later simulation phases.
How would this look on the resilience curve? Referring back to Figure 2
, the outage of a pump in a single pump supply system could result in curve 2b (ii), the performance dropping off to zero until that pump was restored. Alternatively, an architectural solution to the problem could be to add a secondary pump (Figure 11
), that could be turned on immediately after failure, and performance would again increase back to a lower level of performance, or back to ideal performance P0. On the other hand, a decrease in performance could be avoided altogether if the failure of Pump 1 was anticipated, and Pump 2 switched on prior to failure.
At first glance, this may seem like an obvious problem with some obvious solutions to increase the resilience of supplying water to the consumers. Resilience here is considered as a redundancy issue. However, resilience can be a set of operational strategies implemented during a time of disruption to solve the supply problem. For example, prioritizing which demand points are more critical, decision-makers can set constraints on where to supply water and for which certain periods of time. For instance, it may be acceptable to supply the two domestic areas from say 6.00 am to 10.00 am and then from 3.00 pm to 10.00 pm in attempt to cut back on water consumption and resultant water waste. Another solution would be to decrease the pressure of which water is supplied to these points which would decrease the overall volume of water available to be used. Furthermore, depending on what is prioritised, the system may gracefully degrade its capacity to supply the two domestic points and the industrial point, reducing its supply to agriculture completely for a given period of time. This is one resilience strategy, although there will be many like this which should be explored architecturally and simulated to evaluate the feasibility of each one. These are just a few of many strategies which could be implemented to resolve the problem and, in the short-term at least, solve some issues of increasing resilience against flood scenarios.
From a risk perspective, the resilience viewpoint offers a model (Resilience View 3, RV-3) to capture risks which can be communicated with all stakeholder groups. Additionally, the risk view as illustrated in Figure 12
, permits the architect or engineer to allocate the risks to constituent systems or stakeholders within the water SoS. This allocation of risks establishes responsibility of each identified risk and provides accountability to whom or to what is responsible for mitigating against that risk. The advantage from an architectural perspective is that risks can be avoided if mitigation strategies are embedded within the design of constituent systems. An example of an RV-3—Risk View Description—is shown in Figure 12
. The example shows the risk of failure (or partial failure) of the water pump from the above example. Although this a simple example for demonstration purposes, the number of risks in a scenario like this are likely to be in the tens or hundreds, and this is a valued way to manage these risks as the complexity can be captured in multiple instances. This view (RV-3) within the resilience view package is a novel inclusion to the architecture framework which historically does not consider risks (in this way) as part of the architecture modelling phases of systems lifecycle modelling or development.
The final phase to be applied is simulation of architectures. Due to the nature of an SoS such as the water SoS, it is extremely important to simulate as much of the SoS and with as many of the CSs included as possible. The purpose of simulation in our case is to determine whether the overall resilience goals of the SoS can be satisfied by evaluating the interactions between the constituent systems and to understand where the current system falls short in terms of resilience. Since we cannot always rely on the CSs being modelled with the same tools, special techniques must be used to transform the architecture into a set of system models that can be executed within the same co-simulation [32
] environment. Whilst it seems convenient for all CSs to be modelled using the same tool this is not always possible, nor desirable, due to commercial restrictions i.e., different water companies use different modelling tools and languages to design future capabilities. Also, it is highly probable that certain existing CSs have already been created and tested using other tools and provision should be made to use these wherever possible.
System dynamics (SD) [33
] is an approach applied to understand the behaviour of complex, dynamic, nonlinear systems. Defining variables is a key step in creating an SD model, as these are assigned to specific model elements to simulate how changes in the system occur over time, and thus provide understanding of the basic structure of a system and the rationale for its behaviours. A positive of employing such a method in the SoS context comes from the need to understand the behaviour of the whole through understanding the behaviour of the interconnected parts. Numerical values can be assigned to the model and the dynamics can be simulated through execution of the variables. This study used the software tool, Simulink to create the model and simulation for our case study that stemmed from the specifications defined within IBM Rhapsody.
The Simulink model as seen in Figure 13
shows the element that reflects the problem scenario outlined in Figure 6
, which looks at the use of pumps and valves to carry water from a primary reservoir, against gravity, to four service reservoirs which supply different types of customers (domestic, industry and agricultural). The model enables the user to set desired tank levels and the prescribed levels and to then manipulate the pumps and valves to direct water to specific service reservoirs depending on the resilience strategy in place. This specific strategy focussed on keeping the supply high to the two domestic customer groups i.e., service reservoirs 1 and 2, and to drop the amount of water being supplied to agriculture for the short term in order to maintain water to the domestic and industry customers. Preliminary results for this simulation run can be seen in Figure 14
where the domestic customers and their respective service reservoirs remain constantly at a high water capacity and the agricultural service reservoir (service reservoir 4) remains low. Service reservoir 3, the industry service reservoir fluctuates depending on the demand.
In order to test the model further, real data from the demand of customer groups and the volume and capacity of real reservoirs from specific locations will enable more accurate simulations to be run that are reflective of incidents in times of flooding. A great advantage of running a model like this is Simulink, in that it enables the engineer or decision maker to manipulate the parameters and variables using sliders and other input types to assess the response of the system in real time. Thus, allowing trade offs to be made in real time with respect to the events of a flood and the resilience strategies which are being tested and implemented.