Keywords

1 Introduction

The INFRARISK Decision Support Tool (IDST) version 2.0 [1] is an information system tool that allows urban planners, civil engineers, crisis managers, urban development agencies and enterprise consortia to assess potential multiple risks from natural hazards to which critical infrastructure may be exposed. These may include earthquakes, landslides, floods or a combination of all. The IDST hosts specialized databases with supporting scenario simulations derived from models of a number of natural hazards allowing their likelihood of occurrence and intensity levels for different statistical return periods to be estimated at the locations of critical infrastructure elements. Two exemplar case studies have been considered using the IDST. These consist of two large European transport networks (road and rail), located in Italy and Croatia respectively. They demonstrate the use of the adopted generic and overarching INFRARISK methodology for the evaluation of risks which are engendered by natural hazards on critical infrastructure. The IDST has options for applying the risk methodology to other transport networks of interest, provided that the necessary input data is uploaded into the system. The development of the IDST required the deployment of phase driven software development tasks using an agile approach. The first version [2] of the IDST specification was initially developed through consultation with a large number of domain knowledge experts and end-users, both within the project partnership and externally. The IDST specification v1.0 was focused on capturing the functionality requirements for the IDST decision-support system. This exercise has led to the development of the IDST System [3] with its basic functionalities. Version 2.0 of the IDST was then extended to include more advanced functionalities of the IDST [4]. Specifically, it includes the following modules:

  1. 1.

    Web Framework technologies;

  2. 2.

    Database engines;

  3. 3.

    User authentication and authorization, management functionalities;

  4. 4.

    GIS Map Engine; and

  5. 5.

    Visualization and Reporting tools.

The following sections, highlight the agile IDST architecture design and implementation of IDST v2.0 [1].

2 Agile IDST System Design and Development

The IDST has been specified to integrate tools, databases and user interfaces in consultation with end users and knowledge experts in crisis management under INFRARISK. It is primarily a web-based system (or portal) which is user-accessible via a web browser on multiple client platforms (laptop, tablet, etc.) and operating systems (Windows, Linux, etc.). For the IDST v2.0, commonly used browsers are supported (e.g. Internet Explorer, Firefox), and run on Windows or Linux operation systems. The design of the graphical user interface (GUI) took into account multiple platforms, by exploiting the latest platform independent user interface (UI) toolkits.

The IDST software system is deployed on a central server, which has secure remote access available for registered users and selected stakeholders. Access is enabled via HTTPS and, for the main IDST pages, the user will be required to be logged in using their existing user account information. The initial welcome page of the IDST is available to all users, therefore providing some background information about INFRARISK and the IDST while providing links to the secure parts of the portal. The IDST system is modular, i.e. based on multiple autonomous and interacting components. These include:

  • Database (local or remote, PostgreSQL, with PostGIS modules)

  • Flat files (e.g. shape files, OpenStreetMap data)

  • Software module (e.g. Python code)

  • Application (e.g. a command line executable)

  • Remote web service

  • Client-side tool (e.g. JavaScript jQuery, Bootstrap)

The IDST uses the Django framework which allows multiple components to be incorporated easily, while we integrated the GUI features of these modules concurrently. Certain components were included as modules (or executables) and launched by the main IDST component (i.e. IDST Process Workflow Engine). The components were executed with their required inputs and the results returned either by direct visual display or indeed as input to a subsequent module within the workflow. Certain components were deployed as a web service, either on the same host as the IDST or another remote server. Modules which require significant processing time (e.g. greater than one minute) were made available as results in a pre-populated database since it would not be appropriate for the user to practically experience running these simulations dynamically. Some components have been included as look-up tables and provide fast access to pre-run simulation results. In any case, the GUI made use of Ajax calls to the IDST server for any browser requests (e.g. page updates) that require more than a few seconds to perform. The agile development of the IDST system scaled successfully by supporting a large number of concurrent users. Its databases are also scalable since they can handle a mix of structured and unstructured data. Additionally, the data is made available to authorized users, so that they can extract information for their own specific applications.

2.1 High Level Architecture Design Architecture

Figure 1 below, presents a high level conceptual view of the IDST modular architecture. This shows the main components in the system and how they fit together and interact. The IDST system consist of three layers. These are: (1) Presentation Layer; (2) Data Processing Layer; and (3) Data Storage Layer. The Presentation Layer is responsible for the creation of all of the content (as HTML) for the user’s browser. It consists of a main component called the ‘Portal’, which handles user requests and delegates to various sub-components within the ‘Visualisation Engine’ to create specific pieces of content for the requested IDST page. The Data Processing Layer contains any computational components that are required in the IDST system. This includes the Process Workflow Engine (PWE) module (for evaluating multiple risks), as well as the various associated computational modules. These are: (a) Domain Computation (e.g. fragility functions); and (b) Data Analysis (e.g. analytics algorithms). The Data Storage Layer is responsible for handling all access to and from all databases within the IDST system. The computation and presentation components communicate with this layer via a GeoDjango Data Access Layer (ORM). It provides user-friendly APIs to the underlying data which encapsulate lower level database access statements (e.g. SQL).

Fig. 1.
figure 1

High level conceptual architecture of the IDST

Full size image

3 The IDST Information System

3.1 Authentication Services

The authentication of access of users in the IDST is based on the following services: 1- Local user account authentication (exclusive for administrators); and 2- Third party authentication services (for other users), e.g. Google, Yahoo, LinkedIn. Once the authentication mechanism is selected, the user is redirected to the respective site for login in. After a successful login, users access the IDST portal profile. The full profile information is required for completing user authentication. If permission is given by the administrator, then the IDST portal associates the user’s profile with the provided account details and enabled access to the portal.

3.2 IDST Dashboard

After a successful login, the user is presented with the IDST Dashboard page (Fig. 2). The dashboard enables the users to create and manage their own stress tests data, as well as access to exemplar case studies.

Fig. 2.
figure 2

IDST Dashboard

Full size image

3.3 The IDST Process Workflow Engine

The IDST Process Workflow Engine (PWE) is designed around the Overarching Risk Management Framework (ORMF) concept [5, 6]. The ORMF describes the various steps involved in carrying out a stress tests for an infrastructure network [7]. The ORMF consists of the following enacting steps as shown in Fig. 3 below:

Fig. 3.
figure 3

IDST Workflow

Full size image

3.4 IDST Data Storage

The IDST stores various datasets in its database system. The database system is preloaded with datasets to support the basic case studies, e.g. geometry and characteristics of the Northern Italian road network. In addition, users can upload the necessary datasets in order to run their own stress tests. Generated results for stress tests can be also exported and used outside the IDST workflow for further analysis. The type of datasets the IDST system supports are:

  • Infrastructure element characteristics such as road, rail lines, bridges, tunnels, embankments, intersections, etc.

  • Hazard models/maps (e.g. seismic, landslide, flooding)

  • Simulation results from stress tests

  • Analysis results.

3.5 IDST Models

The risk evaluation in the IDST is based on specialized models which are pluggable modules that compute transport network elements of various stages of the IDST workflow. These are classified into (a) hazard and (b) vulnerability models. Hazard Models provide information derived from numerical models of different hazards. This information specifies the relevant intensity levels, depending on the model inputs specified by the user for a particular scenario. Network Models estimate the probability of the various infrastructure elements experiencing different levels of damage, given the occurrence of a particular hazard scenario. During this step, fragility curves (Fig. 4) are assigned to the network elements. Fragility curves, specific to a particular infrastructure element (e.g. bridge, tunnel, road segment, etc.), describe the vulnerability of that element to a particular hazard [8]. In order to estimate the probability of having a defined Damage State (DS) in any given network element, these fragility curves are used, in combination with the information from the hazard models, to estimate the likelihood of experiencing different levels of damage. Table 1 provides an overview of the typical damages states considered.

Fig. 4.
figure 4

Illustrative bridge element fragility curves

Full size image
Table 1. Damage state (DS)
Full size table

3.6 Network Element Characteristics

The user must define the individual characteristics for each type of element being considered within the stress test. These characteristics must be defined for each hazard that is deemed to affect the different types of elements on the network (hazards will affect different types of elements in different ways). For example, the user might choose to consider the effect of ground acceleration (from an earthquake) on bridges, or the effect of landslides on road segments. In each case, the appropriate hazard models and vulnerability models must be available within the IDST. Once the characteristics have been defined the user proceeds by clicking the “Upload Network Elements” button.

3.6.1 The IDST Hazard Scenario

The IDST hazard scenario is used to define a set of cascading hazard events to be considered for a particular stress test. In particular, a hazard event is the combination of (a) a hazard source, e.g. an earthquake; (b) a hazard event, e.g. a ground shaking caused by the earthquake; and (c) a model that describes that hazard event. In most cases the hazard model will require a detailed configuration and a dataset to operate upon, depending on the complexity of the model used. The hazard source in the first hazard event is considered as the primary hazard source which can trigger secondary hazard events, e.g. a landslide caused by the occurrence of an earthquake.

3.6.2 The IDST Network Scenario

The IDST network scenario allows the user to define multiple sets of network events. A network event is defined by a combination of a network type, e.g. a road network, a hazard event deemed to impact that element type, and a network model that assigns fragility functions to that element type. For each network event a dataset of network elements (bridges, road segments, tunnels, etc.) has to be considered. That set of network elements can be selected from the pre-populated IDST datasets for the case study regions which are confined by stress the test boundary polygon, or uploaded directly from the user, e.g. as a shape file. Risk estimation, i.e. damage state calculation, for each network event is carried out by using the appropriate hazard model along with the vulnerability models for each of the network elements to estimate the potential damage to each of the associated infrastructure elements. Risk evaluation can then be carried out considering the calculated damage state for each infrastructure element.

4 Case Study Using the IDST

In this section, a case study is presented which comprises a road network around Bologna in Northern Italy, see Fig. 5 below. Full details of this case study can be found in [9]. The region covers approximately 990 km2 and is located around the city of Bologna.

Fig. 5.
figure 5

Northern Italy case study borders

Full size image

For this road network, the hazard source was an earthquake, with ground acceleration considered as the primary hazard event. In addition, earthquake-triggered landslides were considered as a secondary, cascading, hazard for this stress test hazard scenario. Figure 6 shows the hazard scenario as defined through the IDST. The primary hazard event is a ground motion event which has assigned the INFRARISK GM hazard model [10] assigned to it to allow the ground acceleration within the case study region to be calculated at the location of the various road infrastructure elements. An earthquake-triggered landslide hazard event is defined as a secondary event which utilizes a pre-loaded model for calculating locations where landslides may occur due to ground shaking.

Fig. 6.
figure 6

Northern Italy case study hazard scenario

Full size image

The impact of ground motion on bridges and tunnels is considered along with the effects of earthquake-triggered landslides on road sections. Figure 7 shows the network scenario for this stress test. The targeted infrastructure is the road network. Selected network element types are bridges and tunnels, where the associated hazard event is the ground motion and the assigned vulnerability models are bridge and tunnel fragility functions. The whole area around Bologna shown in Fig. 7 is defined as the spatial boundary.

Fig. 7.
figure 7

Northern Italy case study network scenario

Full size image

The network element datasets used for this case study are selected from the IDST case study database which has been pre-populated with relevant characteristics for the elements in the region of the Italian case study. As shown in Fig. 8, the system has identified 328 bridges and 30 tunnels included within the spatial borders of the region considered for this stress test. Figure 9 shows the locations of each of these elements, a heat map of ground acceleration values which correspond to the ground motion for an earthquake scenario considered for the stress test.

Fig. 8.
figure 8

Stress test infrastructure datasets

Full size image
Fig. 9.
figure 9

Stress test PGA map with marked infrastructure elements

Full size image

At this point the system proceeds with risk estimation for this stress test. The appropriate fragility functions are assigned to each identified network element, i.e. tunnels and bridges and the likelihood of each element experiencing different levels of damage is calculated. This information can then be used to calculate direct and indirect consequences associated with the earthquake. Figure 10 shows the levels of Damage States and the statistical aspects of some of the respective direct consequences by the IDST.

Fig. 10.
figure 10

Stress tests damage state analysis and statistics

Full size image

5 Conclusion and Future Work

The IDST as a decision-support tool has concretely enabled civil engineers and critical infrastructure management stakeholders set up cascading risk scenarios with low probabilities of occurrence and high impact on and damages to Critical Infrastructure (CI). The IDST was successfully demonstrated to the referred communities of specialised CI engineering firms and stakeholders at a large scale INFRARISK project conference [11]. The integration of the heterogeneous data sources, information and outputs under specialised databases and modelling tools in the IDST gives a unique common operational picture for the engineering communities who specialise in the management of CIs. Furthermore, the overarching risk assessment methodology which provides an automated Process Workflow Engine in the IDST clearly enables crisis management experts to usefully set “what if” scenarios on exposure of urban CIs to extreme natural hazards. The next step of this research and development work is for testing the scalability the IDST system towards architectures for supporting very large spatial coverages, mining of big data sources and extreme analytics for the computation of highly complex cascading risks of extreme and rare natural events on CIs. This is clearly a big data problem and challenge which can be met with supporting cloud and high performance computing infrastructure in the future. This will be our research goal for advancing our understanding and quantification of the socio-economic impact of very complex cascading natural hazards on CIs in Europe and beyond.