**2.5 Assessing resilience an infrastructure during an adverse event: Functionality level (FL)**

The indicator-based approach is proposed by the SmartResilience and InfraStress projects also for modeling of the behavior of the infrastructure during a particular disruptive event (scenario). In this case, the (critical) functionality of an infrastructure is analyzed during scenario time (**Figure 2**). No matter how intuitively one might say that the critical functionality of an infrastructure is easy to define, in practice, especially quantitative terms, it is not. E.g., the functionality of an airport is to "keep the air traffic going" or that the critical functionality of a refinery is "to produce the gasoline", but these are often difficult to measure. E.g., in the air traffic, one can look at the number of passengers boarding and/or on cargo throughput, but should at the same time look at the compliance with, e.g., safety and environmental norms, because not satisfying the latter could also be a loss of critical functionality. In the concept, these are considered to be


Defining the functionality in the above way enables to precisely and quantitatively define the resilience curve in scenario time, e.g. for the main characteristic points in time [22]:

t0: time before the event or starting point of the scenario.

t1: time at which the event occurs.

t2: time at which the infrastructure reaches the minimum functionality level.

t3: time at which the infrastructure starts to recover.

t4: time at which the infrastructure reaches the initial functionality level or starting point of a new steady-state level.

t5: time at which the infrastructure increases its functionality through learning and adapting or at which the scenario ends.

Based on the resilience curve (or functionality curve), it is then possible to define the resulting macro-indicators, as illustrated in the notional diagram in **Figure 4**, such as:


*Resilience and Situational Awareness in Critical Infrastructure Protection… DOI: http://dx.doi.org/10.5772/intechopen.97810*


It should be noted that these are the RESULTING macro-indicators, and not the INPUT indicators as the resilience indicators and functional indicators mentioned above. These macro-indicators can also be used for "stress-testing", in which case these can be compared with the critical thresholds (e.g. for the maximum loss of functionality, duration or a combination of these, etc.).

**Robustness** characterizes the absorbing capacity of the smart critical infrastructure [23]. NL uses robustness as defined by the National Infrastructure Advisory Council (NIAC) [24], i.e. "the ability to maintain critical operations and functions in the face of crisis" [25]. It can be seen as the protection and preparation of a system facing a specific danger. The objective of the robustness component is to identify measures that can help the system withstand or adapt to a hazard. It emphasizes the ability of an infrastructure to withstand the incident if the protective measures fail. It also integrates the capacity of the infrastructure to function in a degraded state. The importance of robustness is not necessarily defined by how the infrastructure continues to function in the face of an incident but rather by how it is able to continue to accomplish its mission and to provide its products and services through preventative measures, mitigation, or absorption capabilities [25]. Robustness is defined as the capacity of the smart critical infrastructure to endure the effects of a negative event and thereby absorb its impact. As shown in **Figure 4**, it is measured as the ratio of the percentage of the lowest FL after the disruption, i.e. at time t2, to the FL during normal operation, i.e. at time t0.

$$\text{Robustness} = \frac{FL\_{t2}}{FL\_{t0}} \times \mathbf{100\%} \tag{1}$$

**Absorption time** is defined as the time during which the smart critical infrastructure absorbs a disruptive event while the smart critical infrastructure undergoes a decrease in its functionality level. As illustrated in **Figure 4**, it is measured as the difference between t2 and t1.

$$\text{Absorption time} = t\_2 - t\_1 \tag{2}$$

**Loss of functionality** is the functionality of the smart critical infrastructure lost in a given threat situation. It is measured by the area of the curve (an approximation) between the time when the smart critical infrastructure starts to lose its functionality (t1) to the time when it reaches the initial state (t4) (see **Figure 4**). The approximation is done for the area above the curve to a well-defined shape, e.g. a triangle. The output would be the percentage loss of functionality in time [26, 27], e.g. losing 10% in 10 hours.

$$\text{Loss of functionality} = \int\_{t\_1}^{t\_4} [FL\_{t\_1} - FL(t)]dt\tag{3}$$

FL in all the formulae (incl. Eq. (3), is calculated as the aggregated score on indicators, in the particular case of FL, as functionality indicators, such as those presented in the sample list in **Figure 7**).

Next in the scenario is the **recovery** state of the smart critical infrastructure. The concept of recovery explains the passage of an infrastructure's functionality from a degraded state to one of acceptable operation. This concept builds on the concept of robustness in that, if measures of robustness fail to fully prevent, mitigate, or allow the asset to absorb the damage event, recovery constrains the impacts of the event to keep the CI functional. For the purpose of modeling the impact of a disruptive event, **recovery** refers to the ability to not only return to acceptable operating levels but also to recover fully from the effects of an event [25] in the maximum allowable/acceptable recovery time (as described in the stress test methodology [12, 28]).

**Downtime** is defined as the time duration for which the system is not functional. In Ref. to critical infrastructures, this could apply if the CI stops functioning. In this case, the functionality level of the infrastructure remains below the **threshold level** of functionality [25]. It can be measured as the difference in time between t3 and t2 (see **Figure 4**).

$$\text{Downtime} = t\_3 - t\_2 \tag{4}$$

Recovery time ¼ *t*<sup>4</sup> � *t*<sup>3</sup> (5)

**Note:** Since the functionality level at the end of the scenario may be different from at the start of the scenario, the recovery time may have to be measured at a

**Recovery rate** is defined as the rate at which the smart critical infrastructure recovers from a disruptive event and gets back to its initial functionality level [23]. It characterizes the recovery trajectories of the smart critical infrastructure from the point it starts recovering from the scenario to the final recovery. It is measured as

Recovery rate <sup>¼</sup> ð Þ *FL*<sup>4</sup> � *FL*<sup>3</sup>

**Improvement/adaptation/transformation:** Final recovery of the FL of a smart critical infrastructure could be equal to, better than, or worse than the original FL [29]. Hence, the model allows for the calculation of the "improvement/adaptation/

*An example of a report of one of the resilience assessments – FL curve comparing the response of FL with scenario time for case studies ECHO and CHARLIE, including the comparison of the FL curves with the acceptance level*

Another measure considered for modeling the impact is **disruption time**. The disruption time is defined as the total time taken by the CI to recover. It is also seen as a measure for recover capacity of the smart critical infrastructure to return to the desired functionality level [23]**.** In the functionality level over time (FL-t) curve, it is the time between when the event occurs, i.e. at time t1, and time when

the smart critical infrastructure has fully recovered, i.e. t4 (see **Figure 4**).

ð Þ *t*<sup>4</sup> � *t*<sup>3</sup>

Disruption time ¼ *t*<sup>4</sup> � *t*<sup>1</sup> (7)

(6)

the ratio of change in functionality level between time t3 and t4.

*Resilience and Situational Awareness in Critical Infrastructure Protection…*

new steady-state level [28].

*DOI: http://dx.doi.org/10.5772/intechopen.97810*

**Figure 8.**

**71**

*(shown in pink, can be used for stress-testing, too).*

**Note**: This calculation is conducted when the threshold level of functionality is defined (Here it is assumed that the threshold level is FLt2 (=FLt3)).

**Recovery time** is defined as the time at which the smart critical infrastructure recovers from the disruptive event and gains its initial or desired functionality [23]. It can be measured as the time taken to recover the functionality level, i.e. the time between time t3 and t4.

#### **Figure 7.**

*Example of creating a DCL by combining generic (CORE DCL), typical (RECOMMENDED DCL) and specific issues/indicators into the final DCL.*

*Resilience and Situational Awareness in Critical Infrastructure Protection… DOI: http://dx.doi.org/10.5772/intechopen.97810*

$$\text{Recovery time} = t\_4 - t\_3 \tag{5}$$

**Note:** Since the functionality level at the end of the scenario may be different from at the start of the scenario, the recovery time may have to be measured at a new steady-state level [28].

**Recovery rate** is defined as the rate at which the smart critical infrastructure recovers from a disruptive event and gets back to its initial functionality level [23]. It characterizes the recovery trajectories of the smart critical infrastructure from the point it starts recovering from the scenario to the final recovery. It is measured as the ratio of change in functionality level between time t3 and t4.

$$\text{Recovery rate} = \frac{(FL\_4 - FL\_3)}{(t\_4 - t\_3)} \tag{6}$$

Another measure considered for modeling the impact is **disruption time**. The disruption time is defined as the total time taken by the CI to recover. It is also seen as a measure for recover capacity of the smart critical infrastructure to return to the desired functionality level [23]**.** In the functionality level over time (FL-t) curve, it is the time between when the event occurs, i.e. at time t1, and time when the smart critical infrastructure has fully recovered, i.e. t4 (see **Figure 4**).

$$\text{Disruption time} = t\_4 - t\_1 \tag{7}$$

**Improvement/adaptation/transformation:** Final recovery of the FL of a smart critical infrastructure could be equal to, better than, or worse than the original FL [29]. Hence, the model allows for the calculation of the "improvement/adaptation/

#### **Figure 8.**

*An example of a report of one of the resilience assessments – FL curve comparing the response of FL with scenario time for case studies ECHO and CHARLIE, including the comparison of the FL curves with the acceptance level (shown in pink, can be used for stress-testing, too).*


**Table 1.**

*The macro indicator values for the cases in Figure 8 - the macro indicators calculated from the FL curve provide a quantitative way of comparing alternatives of system recovery supporting decision making and optimization [1].*

transformation." This is the capacity of the smart critical infrastructure to learn from a disruptive event (e.g. a revision of plans, modification of procedures, introduction of new tools and technologies [10]) (see **Figure 4**). It is measured as the ratio of change in FL during and after the event over the initial FL.

$$\text{Improvement/adapitation/transformation} = \frac{\text{FL}\_{t5} - \text{FL}\_{t0}}{\text{FL}\_{t0}} \times 100\% \tag{8}$$

7.Checking resilience: Stress-testing

**Figure 9.**

practice solutions can be re-used.

and presentation tools).

**73**

**multi-level resilience assessment**

8.Optimizing resilience: Multi-Criteria Decision Making (MCDM)

*Applying the methodologies in order to assess resilience and obtain practical (quantitative) results.*

*Resilience and Situational Awareness in Critical Infrastructure Protection…*

*DOI: http://dx.doi.org/10.5772/intechopen.97810*

For its users, the methodologies are embedded into the interactive, web-based and freely available "ResilienceTool". Applied in different case studies, dealing with energy, transportation, health, smart cities, water, sensitive installations, etc., the methodology and tool provide the user with different options when using the approach and the system by showing how benchmarking can be done and the best-

When applying the concept and the methodologies practically, it is important to understand that the flexibility of the concept and the methodologies necessarily demand for domain expertise in "configuring" the resilience model for a specific area/city or critical infrastructure. A fixed list of critical infrastructures for cities in Europe does not exist, and it must be up to each user of the concept, methodologies and the software tool, to decide which feature of respective infrastructures should be analyzed and how. Similarly, no fixed list of threats exists, neither on the area level nor for the single critical infrastructures. Thus, it will be up to the users to define which threats (scenarios) they consider relevant. Domain experts are needed in order to define the important issues, and how to measure these issues, i.e. identifying the indicators. They are in a way "configuring" the resilience model, which largely is a one-time effort prior to using the model for calculating the resilience levels, although some adjustments, tuning, and reconsiderations are expected. Thus, in the implementation phase, it is important to have close collaboration between the users, the method developers, and IT developers (of calculation

**3.1 Resilience index/cube, resilience level (RL), functionality level (FL) and**

Per default, assessing resilience in the concept is based on scoring (other ways of upwards aggregation are possible, but used only in "expert mode"), the scores being

Such macro indicators are ideal for comparing the FL responses for multiple case studies, infrastructure, entities etc. They allow an objective evaluation of not only how the functionality level of a system might react to an event but also how and when it can recover. Using a theoretical acceptance level, a stress-test can also be performed. An illustrative example comparing the FL response for two SmartResilience case studies (ECHO and CHARLIE) is shown in **Figure 8** and **Table 1**.
