deliverable d7.2 idst system specification v2 · python a general purpose programming language ram...

© The INFRARISK Consortium

FP7 2013 Cooperation Work Programme

Theme 6: Environment (Including Climate Change)

Novel indicators for identifying critical

INFRAstructure at RISK from Natural Hazards

Deliverable D7.2

This project has received funding from the European Union’s Seventh Programme for research,

technological development and demonstration under grant agreement No 603960.

Primary Authors Panos Melas and Zoheir Sabeur/ University of Southampton IT

Innovation Centre (IT Innov)

WP 7

Submission Date 12th

January 2016

Primary Reviewer Bryan Adey/ Eidgenössische Technische Hochschule Zürich (ETHZ)

Dissemination Level PU

IDST System Specification v2.0

INFRARISK

Deliverable D7.2


Project Information

Project Duration:

Project Coordinator:

Work Programme:

Call Topic:

Project Website:

Partners:

IDST System Specification v

1/10/2013 - 30/09/2016

Professor Eugene O' Brien

Roughan & O’ Donovan Limited

[email protected]

2013 Cooperation Theme 6:

Environment (Including Climate Change).

Env.2013.6.4-4 Towards Stress Testing of Critical Infrastructure

Against Natural Hazards-FP7-ENV-2013-two stage

www.infrarisk-fp7.eu

Roughan & O’ Donovan Limited, Ireland

Eidgenössische Technische Hochschule Zürich

Dragados SA, Spain.

Gavin and Doherty Geosolutions Ltd., Ireland

Probabilistic Solutions Consult and Training BV, Netherlands

Agencia Estatal Consejo Superior de Investigaciones Cient

Spain.

University College London, United Kingdom

PSJ, Netherlands.

Stiftelsen SINTEF, Norway.

Ritchey Consulting AB, Sweden.

University of Southampton IT Innovation Centre

Kingdom.

DST System Specification v2.0

i

4 Towards Stress Testing of Critical Infrastructure

two stage.

Eidgenössische Technische Hochschule Zürich, Switzerland.

Gavin and Doherty Geosolutions Ltd., Ireland.

Probabilistic Solutions Consult and Training BV, Netherlands.

Agencia Estatal Consejo Superior de Investigaciones Científicas,

University College London, United Kingdom.

IT Innovation Centre, United

INFRARISK

Deliverable D7.2 IDST System Specification v2.0

© The INFRARISK Consortium iii

Document Information

Version Date Description Primary Author

Rev01 14/09/2015 Initial update and extension from first

version (D7.1) with new IDST

functionalities

Panos Melas and Zoheir

Sabeur (IT Innovation)

Rev02 18/09/2015 Additional IDST functionalities

included with request for WP7

partners contributions



Rev03 22/09/2015 Further actions for sections 5, 6, 7, and

8



Rev04 29/09/2015 Updates to section 8 NEXTA for traffic

assignment

Khaled Taalab (UCL)

Rev05 02/10/2015 Updates to sections 6 and 7 Panos Melas (IT Innovation)

Rev06 05/10/2015 Further updates to section 6, 7, 8 Panos Melas and Zoheir


Rev07 05/10/2015 Updates to section 6 Julie Clarke (ROD)

Rev08 16/10/2015 Further updates to section 6 Panos Melas(IT innovation)

Rev09 20/10/2015 Updates to sections 1, 8, 9 Panos Melas(IT innovation)

Rev10 26/10/2015 Introduction, conclusion and exec.

Summary


Sabeur(IT Innovation)

Rev11 14/12/2015 Updates to document based on Bryan

Aday/ETZH comments


Sabeur(IT Innovation)

Rev12 04/01/2016 Format updates. Final for submission. Panos Melas (IT Innovation)

This document and the information contained herein may not be copied, used or disclosed in whole

or part except with the prior written permission of the partners of the INFRARISK Consortium. The

copyright and foregoing restriction on copying, use and disclosure extend to all media in which this

information may be embodied, including magnetic storage, computer print-out, visual display, etc.

The information included in this document is correct to the best of the authors’ knowledge.

However, the document is supplied without liability for errors and omissions.

All rights reserved.

INFRARISK


© The INFRARISK Consortium v

Executive Summary

This document specifies the design of the second version of the INFRARISK Decision Support Tool

(IDST v2.0) software. The IDST architecture is modular in design and reflects the user requirements,

which have been established through consultation with the INFRARISK project partners and the

INFRARISK advisory board members. As a result, the advanced functionalities of the IDST have been

specified in this document. They require the integrated workflow processes for defining the risk due

to natural hazards, their geospatial coverage and their likely impacts on critical infrastructure.

INFRARISK


© The INFRARISK Consortium vii

Table of Contents

Glossary .......................................................................................................................................... ix

1 INTRODUCTION .................................................................................................................... 1

2 IDST Software Design ............................................................................................................ 2

2.1 High Level Design and Architecture ...................................................................................... 3

2.2 IDST Portal Component ......................................................................................................... 4

2.3 Process Workflow Engine ..................................................................................................... 5

2.4 GIS Databases ....................................................................................................................... 6

2.4.1 Hazard Maps ............................................................................................................ 6

2.4.2 Infrastructure Components ...................................................................................... 8

2.4.3 Simulation and Analysis Results ............................................................................. 11

2.5 Knowledge Base of Major Global Infrastructure Failures ................................................... 11

3 IDST Implementation .......................................................................................................... 11

3.1 IDST Graphical User Interface ............................................................................................. 13

3.2 IDST GUI Design Process ..................................................................................................... 14

3.2.1 IDST Welcome Page ............................................................................................... 14

3.2.2 IDST Authentication System ................................................................................... 15

3.2.3 Authorization and User Roles within the IDST ....................................................... 16

3.3 The IDST Dashboard ............................................................................................................ 17

3.3.1 IDST: New PWE Case Study .................................................................................... 19

3.3.2 IDST System Definition: Locating an Area of Interest ............................................ 21

3.3.3 IDST Risk Identification........................................................................................... 26

3.3.4 Gathering Data for Network Elements ................................................................... 26

4 Road Case Study Risk Analysis in IDST.................................................................................. 27

4.1 Earthquake Hazard Damage State Estimation .................................................................... 27

4.2 Landslide Hazard Damage State Estimation ....................................................................... 29

4.2.1 Implementation to IDST ......................................................................................... 31

4.3 Estimation of Repair Times, Costs and Functional Losses .................................................. 33

4.4 Restoration Model .............................................................................................................. 34

4.4.1 Simulated Damage States over Restoration Period ............................................... 34

4.4.2 Implementation in the IDST ................................................................................... 34

4.5 Estimate Direct Consequences ........................................................................................... 34

4.6 Estimated Indirect Consequences Functionality ................................................................. 35

INFRARISK


© The INFRARISK Consortium viii

4.6.1 NEXTA Implementation in the IDST ....................................................................... 35

5 CONCLUSION ...................................................................................................................... 36

6 REFERENCES ....................................................................................................................... 37

APPENDIX A NEXTA Traffic Assignment Software

INFRARISK


© The INFRARISK Consortium ix

Glossary

Table 1 outlines the terminology and abbreviations that are used in this document. These also

include certain terms defined in INFRARISK D4.1 (Adey et al., 2014) in an effort to achieve

consistency within the project.

Term Description

CI Critical Infrastructure

CSS Cascading Style Sheets

CSV Comma-separated values

database A collection of data, their related data structures (schema), and relationships. There

may be one or more data structures required to encapsulate all the data.

DBV2 Former name for the ISTD (referred to in WP7)

DEM Digital Elevation Model

Django Web application framework

DoW Description of Work (for the project)

DS Damage State

DTALite Dynamic Traffic Assignment engine

GEM Global Earthquake Model

GIS Geographic Information System

GUI Graphical User Interface

HTML Hypertext Markup Language

HTTP(S) Hypertext Transfer Protocol. This is the application protocol that all devices

connected to the WWW use to communicate. The “S” variant is secured via SSL.

IDST INFRARISK Decision Support Tool – the main integrated software output for the

INFRARISK project.

IDST system The set of interacting or interdependent software components forming the

integrated whole IDST

JavaScript A high-level dynamic untyped and interpreted programming language

ISTD Integrated Spatio-Temporal Database

JSON JavaScript Object Notation

INFRARISK


© The INFRARISK Consortium x

Term Description

KB-MGIF Knowledge Base of Major Global Infrastructure Failures

Ky Yield acceleration

LOD Linked Open Data

Mock-up Sometimes known as a “wireframe”. A visualisation/model of a UI or web page.

NetCDF Network Common Data Form

NEXTA Network Explorer for Traffic Analysis

OD Origin-destination

ORM Object-Relational Mapper

ORMF Overarching Risk Management Framework

OSM Open Street Maps

PGA Peak Ground Acceleration

PostGIS A spatial database extender for PostgreSQL

PostgreSQL An object-relational database management system (ORDBMS)

Python A general purpose programming language

RAM Random Access Memory

PWE Process Workflow Engine

R Software environment for statistical computing and graphics

requirement A requirement is a single documented functional need that the system must perform.

This is then translated into one or more use cases.

SRA Single Risk Analysis

SSL Secure Sockets Layer

SQL Structured Query Language

Stakeholder An individual, group or organization that can affect, be affected by, or perceive itself

to be affected by, a risk. Also used to refer to a user of the IDST.

System A set of interacting or interdependent components forming an integrated whole

UI User Interface

INFRARISK


© The INFRARISK Consortium xi

Term Description

URL Uniform Resource Locator

use case A list of steps, defining interactions between people, to describe a specific goal. In

terms of computer processes this is a series of steps that can be programmed and

thus are quite specific.

workflow A workflow is a series of connected steps to a goal.

WP Work-Package

Table 1: Glossary

INFRARISK


© The INFRARISK Consortium 1

1 INTRODUCTION

The INFRARISK Decision Support Tool (IDST) is a prototype information system tool that allows urban

planners, civil engineers, crisis managers, urban development agencies and enterprise consortia to

assess multiple risks from natural hazards to which critical infrastructure may be exposed. These

may include earthquakes, landslides, floods or a combination of these hazards. The IDST is an

information management system that hosts specialized databases with supporting scenario

simulations for natural hazards and their likelihood of occurrence in relation to critical infrastructure.

Two example case studies are showcased using the IDST. These consist of two large European

transport networks (road and rail), located in Italy and Croatia respectively. These case studies

demonstrate the generic and overarching INFRARISK methodology for the evaluation of the risk dues

to natural hazards for critical infrastructure. The IDST user will have the option to apply the

INFRARISK methodology to other transport networks of interest provided the necessary data is

uploaded to the system. The development of the IDST requires the deployment of phase driven

software development tasks using an agile approach.

The first version (v1.0) of the IDST specification (Meacham K. & Sabeur Z., 2014) developed through

consultation with domain knowledge experts and end-users, both within the project consortium and

external to the project consortium. In addition, 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 v1.0 (Meacham K. & Sabeur Z., 2014) with its basic functionalities.

Version 2.0 of the IDST specification, as outlined in this document, is extended to include the basic

functionality of IDST. This was conducted in conjunction with the various other INFRARISK work

packages, as their requirements in terms of the IDST design and functionalities became apparent.

More specifically, v2.0 of the IDST specification integrates the INFRARISK modules that have been

defined in Work-Packages 2, 3, 5 and 6. Furthermore, v2.0 of the IDST specification describes all the

core technologies that are required to support and develop the integration of these modules within

the IDST. The modules included are as follows: Web Framework technologies, Database engines,

user authentication and authorization, management functionalities, GIS, map engine, and

visualization issues. The implementation of the Overarching Risk Assessment Process (ORAP) is

based on the proposed process described in D4.1 (Bryan Adey, 2014). To support the INFRAFISK

databases and the necessary data models, database schemas were designed to perform the required

functionalities.

In addition to the two specification versions of the IDST, more frequent prototypes of the IDST will

be produced to provide focus for INFRARISK and to drive the user requirements process. This will be

conducted using a ‘semi-agile’ approach, whereby new features can be included relatively quickly

and tested by INFRARISK partners.

Software design is often ‘chicken and egg’ in nature, i.e. the software engineers need to understand

fully what the users require for the eventual system. However, the software users often don’t have

the complete grasp of the software requirements, and therefore, benefit from experiencing a

prototype software at an early state in the project.

In the following sections, the necessary specifications for the implementation of IDST v2.0 will be

described.

INFRARISK



2 IDST Software Design

The IDST is the main software output for the INFRARISK project, and, therefore, the IDST integrates

tools, databases and user interfaces produced in the INFRARISK work packages. The IDST is a web-

based system (or portal), accessible to users via a web browser, preferably on multiple client

platforms (laptop, tablet, etc.) and operating systems (Windows, Linux, etc.). For the IDST v2.0,

commonly used browsers will be targeted (e.g. Internet Explorer, Firefox), and it will be possible to

run the IDST either on Windows or a Linux operation system. The design of the graphical user

interface (GUI) for the IDST will take into account multiple platforms, by exploiting the latest

platform independent user interface (UI) toolkits.

The IDST software system will be deployed on a central server, which will have secure and, remote

access available for all project partners and other selected stakeholders. Access will therefore be via

HTTPS and, for the main IDST pages and the user will be required to be logged in using their user

account information. The initial welcome page of the IDST will be available to all users, therefore

providing some background information about INFRARISK and the IDST and, providing links to the

secure parts of the portal.

The IDST system will be modular, i.e. based on multiple components, which provide distinct

functionality (originating from the different work packages). Contributions from project partners

may come in a variety of formats. These may include:

• Database (local or remote)

• Flat files (e.g. shape files)

• Software module (e.g. Python code or MATLAB library)

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

• Remote web service

• Client-side tool (e.g. JavaScript tool)

Initial versions of the IDST will incorporate these contributions in a fairly raw form (e.g. using flat

files), however these will be more consistently integrated (e.g. as a database) in later versions of the

IDST. The aim is to integrate components in a consistent manner, (e.g. using common APIs, etc.).

The IDST will use a framework that allows multiple components to be incorporated easily, and that

also integrates GUI features of these modules. This will be described in more detail in the following

section.

Certain components will be included as modules (or executables), which will be launched by the

main IDST component (i.e. the Process Workflow Engine, to be developed in Task 7.3). The

components will be executed after providing them with their required inputs and the results will be

returned either by direct display to the user or as input to a subsequent module within the

workflow. Certain components may be deployed as a web service, either on the same host as the

IDST or another remote server. Interim results will most likely be stored in a database.

Modules the require significant time to process (e.g. greater than one minute) will be made available

as results in a pre-populated database since it would not be appropriate for the user to experience

running these simulations dynamically. Some components may therefore be included as look-up

tables, providing fast access to pre-run simulation results. In any case, the GUI will make 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.

INFRARISK



The IDST system will potentially need to support a large number of concurrent users and, therefore

the databases will need to be scalable and be able to handle a mix of structured and unstructured

data. Additionally, the data will eventually be made available to authorized users, so that they can

extract information for their own application. The technologies will, therefore, need to be able to

support these numerous requirements.

2.1 High Level Design and Architecture

Figure 1 presents a high level conceptual view of the IDST architecture. This shows the main

components in the system and how they fit together and interact. The IDST system will consist of

three layers, as follows:

• Presentation Layer

• Data Processing Layer

• 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 – see

section 2.3), as well as the various associated computational modules. These include modules for:

• Domain Computation (e.g. fragility functions)

• Data Analysis (e.g. statistics functions)

The Data Storage Layer is responsible for handling all access to and from any databases within the

IDST system. Computation and presentation components will communicate with this layer via the

GeoDjango Data Access Layer (ORM), which provides user-friendly APIs to the underlying data that

encapsulate lower level database access statements (e.g. SQL). This will be described further in

section 2.4.3.

INFRARISK



PWE DB

Multiple Risks

Evaluation (PWE)

GeoDjango Data Access Layer (ORM)

Portal (GUI)

Case study

definitions, e.g.

system definition,

scenarios,

user parameters

Case study

simulation and

analysis results

Data Processing

Layer

Data Storage

Layer

Presentation

Layer

Visualisation Engine

Domain Computation Modules

Fragility functions

Data Analysis Modules

Statistics

Portal DB

Users

UI data (e.g. for

dropdown menus)

UI config

GIS layers

Infrastructure

Hazard maps

Simulation results

Analysis results

Figure 1: High level conceptual architecture of IDST

2.2 IDST Portal Component

The IDST portal component is the main driver for the IDST. It handles user requests (i.e. from their

browser via specific URLs) and delegates to various sub-components within the ‘Visualisation Engine’

to create specific pieces of content for the requested IDST page. This component is responsible for

the overall layout and presentation of the IDST portal, including the high level menus, page

templates and styling (via CSS).

The IDST portal database stores data related to the general operation of the portal, which includes

the following:

• User accounts (including roles, user home area, etc.)

• Session information

• IDST system/portal configuration (e.g. taxonomies for drop-down menus)

• The IDST portal component will create UI components (or widgets) related to entering or

displaying some of this data (e.g. critical infrastructure elements on map)

INFRARISK



• Portal configuration (e.g. management of values for drop-down menus)

2.3 Process Workflow Engine

The IDST Process Workflow Engine (PWE) will be designed and developed within INFRARISK Task 7.3.

The PWE is essentially the realization of the ORAP within the IDST, as conceptualized in WP4. This

basic ORAP is described in D4.1 (Bryan Adey, 2014) and consists of the following steps:

1. Problem Identification

2. System Definition

3. Risk Identification

4. Risk Analysis

5. Risk Evaluation

6. Risk Treatment

As described by Adey et al., (2014), the IDST user (e.g. the infrastructure manager) will, in general

have undertaken the first step, ‘Problem Identification’ prior to using the IDST, as they have already

identified the infrastructure elements under their management that might be prone to natural

hazards. The IDST will most likely support Steps 2-4 in the risk assessment process (‘System

Definition’, ‘Risk Identification’ and ‘Risk Analysis’). The final steps in the risk assessment process

(‘Risk Evaluation’ and ‘Risk Treatment’) will not be considered in the IDST (Bryan Adey, 2014).

The PWE database will store data related to the case studies so that ORAP stages can be executed,

including the following:

• System definition (spatial and temporal boundaries, system elements, etc.)

• Risk identification (i.e. scenario set-up, e.g. event intensities)

• Risk analysis (e.g. probability calculation results)

The PWE will require an associated component in the IDST presentation layer for creating UI

components (or widgets) related to entering or displaying this data. Figure 2 shows in more detail

the PWE model used in the portal. A PWE run is stored as a PWE case study object which can store

all the necessary information to conduct the following:

• Define the system (e.g. system boundaries, hazards)

• Manage sessions in a PWE for a case study (e.g. create, edit, delete)

• Execute the PWE workflow (e.g. identify and analyse risk)

INFRARISK



Figure 2: IDST PWE

2.4 GIS Databases

The IDST will support the following types of GIS data, including:

• Hazard maps

• Infrastructure elements

• Simulation results

• Analysis results

2.4.1 Hazard Maps

Information will also be required in relation to the hazards considered for the case study regions in

order to carry out the risk assessment. The hazards considered include the following, as well as their

interactions:

• Earthquake

• Landslide

• Floods

The hazard maps will take the form of GIS Shape files. For the case study region there will be an

option to use the prepopulated hazard maps available within the IDST.

INFRARISK

Deliverable D7.2


Figure 3, and Figure 4, illustrate the current hazard models and database schemas used in the portal

derived from GIS shape files and PGA data for earthquake events.

Figure

Figure 4: The PGA Data Model and Visualization as heat


, illustrate the current hazard models and database schemas used in the portal

m GIS shape files and PGA data for earthquake events.

Figure 3 IDST Hazard Maps Data Models

The PGA Data Model and Visualization as heat-map


7

, illustrate the current hazard models and database schemas used in the portal

map

INFRARISK



2.4.2 Infrastructure Components

The tools and methodologies developed as part of the INFRARISK project will be applied to two

exemplar case studies of critical infrastructure in Europe. The first case study consists of a road

network in Italy and the second case study comprises a rail network in Croatia (Ni Choine &

Martinovic, 2014).

To conduct the ORAP methodology for each of these case studies, data is required for the case study

regions (e.g. geographical location of network elements). This information is provided in the form of

GIS Shape files and will be imported into the IDSTS’s GIS database. At a later stage, it will be possible

to users of the IDST to import GIS Shape files for any region to the IDST.

The GIS Shape files for the case studies consist of the following information:

• Roads

• Railways

• Bridges

• Tunnels

• Embankments

• Intersections

• Buildings

An example of Shape file of the Italian road network is illustrated in Figure 5.

Figure 5: GIS Shape file of the Italian road network

INFRARISK



Figure 6 presents the IDST database schemas currently used to model and store OSM GIS data of

infrastructure components (e.g. roads, bridges, tunnels, etc.) for the area of interest. GIS data are

currently used to visualize infrastructure components on IDST maps, as well as to create heatmaps

to visualize the state of the network.

Figure 6: GIS Infrastructure element models are based on OSM Data

In addition, the IDST stores structural information about the main infrastructure components such as

bridges and tunnels. The structural information of such components is necessary in order to assess

and evaluate the risk of an applied hazard to the infrastructure elements.

Figure 7 shows the current structural model of a bridge. The bridge model contains detailed

structural information about a bridge (e.g. bridge width, length, material, deck type, etc.). The IDST

can link the OSM databases with the more detailed structural component databases during the PWE

analysis to determine the damage state of each network element structure.

INFRARISK



Figure 7: IDST Bridge Structural Model

The IDST structural tunnel model is similar to the bridge structural model and is illustrated in more

detail in Figure 8. Tunnel structural data and road section data will be used by the PWE to analyse

tunnel and road section damage states for particular hazards.

INFRARISK



Figure 8: IDST Tunnel Structural Model

2.4.3 Simulation and Analysis Results

The IDST will provide storage for results derived through the execution of the PWE workflow. The

results will be available to the authorized user, either through a visualization tool (within the IDST) or

downloadable in their raw format for further processing outside IDST.

2.5 Knowledge Base of Major Global Infrastructure Failures

The IDST will provide direct or indirect access to the knowledge base of major global infrastructure

failures database created in WP2. The knowledge base is currently under development in WP2. Early

prototypes of the knowledge base database are accessible via https://datagraft.net.

3 IDST Implementation

The IDST system will be built using the Django web framework (Django Web Framework). Django is a

popular open source web application framework, written in the Python programming language

(Python Programming Language). One of the central aims of Django is to allow developers to build

complex, database-driven websites in an efficient manner. In addition, Django is designed to be

scalable and has been used in some very high performance web sites (e.g. Instagram, NASA). These

have been achieved via a well-designed framework which emphasizes code reuse and modularity.

Much of this is achieved by separating the business logic of the code from the presentation and

control layers. This is a design pattern known as ‘model-view-controller’ (Wikipedia Model View

INFRARISK



Controller). Django provides many useful features ‘out of the box’, e.g. the ‘object-relational

mapper’, which provides a database access layer.

Figure 9 illustrates how the various INFRARISK databases and models can be integrated, within a

Django framework. In Django, user requests (from their browser) are mapped onto ‘views’ in Django

(written in Python). Each view is responsible for generating the HTML to be presented back to the

user’s browser. This is achieved via a combination of HTML templates and Python code. The HTML

may also contain JavaScript for performing Ajax requests to the server, enabling parts of the client’s

display to be refreshed. Django views can also return JSON objects, to be consumed by client

browser Ajax requests.

For accessing databases, Django uses an Object-Relational Mapper (ORM) (Object Relational

Mapping). Models are created in Python which can automatically populate or query the underlying

database (e.g. MySQL, PostgreSQL), so a good way of working with a database is to create the

Django model directly and let the system handle the creation of the necessary schema.

More specifically, GeoDjango (A world-class geographic web framework) will be used, which

provides additional useful features (on top of a basic Django framework) tailored to GIS-based

databases, allowing us to develop the IDST as a GIS (Wikipedia) web application.

We propose to use PostGIS (PostGIS -- Spatial and Geographic Objects for PostgreSQL) for underlying

GIS databases. Although the INFRARISK databases are conceptually shown as separate systems, they

may well be implemented as different schemas within the same physical database system (e.g.

PostGIS).

INFRARISK



User’s browser

URL

Mapper

Views HTML templates

Portal

Portal

PWE

PWE

GIS

GIS

Object-Relational Mapper (ORM)

HTTP request

HTML (or JSON)

response

Models

Databases

(Geo)Django

Figure 9: Integration of IDST databases using GeoDjango

Whilst Django provides the overall framework for mapping user requests to HTML, the main

construction of the HTML itself (other than the templating features, etc.) is left to the developer. For

this, off-the-shelf solutions such as Bootstrap (Bootstrap) will be employed to for provide platform-

independent layouts and UI widgets, along with jQuery (jQuery Foundation) and native JavaScript for

additional dynamic features.

jQuery is a library built on top of JavaScript, and is designed to make user interaction, page effects,

and data passing as simple as possible. In essence, it makes it easier to build complex user interfaces

than to do so in plain JavaScript. This adds to the richness of the webpages and adds to the user

experience in generally. In addition to the base library there are numerous plugins for graphing,

mapping, and visualisation purposes.

Further graphical or GIS-based tools will be investigated for their potential use within the IDST, as

part of Task 7.4.

3.1 IDST Graphical User Interface

The IDST will be supported with a web-based graphical user interface (GUI). This will be developed

within Task 7.4 using the Django web framework, as described in Section 2.4.3. The design of the

IDST web pages will be described in the following sections.

INFRARISK



Authentication will be employed to provide secure, controlled access to the IDST. This will be

achieved either via Django’s own authentication services, or other third-party authentication

modules (to be evaluated within Task 7.4).

The IDST GUI will allow realistic scenarios involving extreme events and multiple risks to be

configured in a graphical fashion. Specific scenarios can then be analysed and the outcome

presented using the GUI. A number of visualisation methods will be explored. Specifically, GIS

overlays will be examined (such as kernel density estimation) with geographically aligned data and a

variety of graphical techniques for numerate data. Central to these visualisations will be approaches

to make the data more accessible to typical users of the system.

3.2 IDST GUI Design Process

The design of the IDST GUI is of paramount importance since the IDST may be utilised by multiple

users who are specialized in the protection of various types of critical infrastructure. Once ideas

have been reasonably well developed within the consortium, the project advisory board and

associated stakeholder communities will be consulted, for further expert opinions and feedback.

To help achieve mutual understanding of requirements, a useful approach is to develop GUI ‘mock-

ups’. These are purely visual representations of web pages, rather than being fully functional (as a

real web page), and can quickly show the intended layout of a page, its main controls and displayed

data. For this, we use Balsamiq Mockups (Balsamiq Studios). This tool allows a user to quickly create

visualisations of web pages, by dragging and dropping various available components and graphical

features onto a page. Common web page features can be quickly set up (e.g. menus, drop-down

lists, text boxes). Other annotations can be added to demonstrate how the web page should work.

Another useful feature is that any hyperlinks or buttons can be demonstrated by navigation to a new

mockup page. This gives the appearance of a working system, helping to show the workflow through

several pages.

After some early discussions and meetings with partners, an initial set of mockups was generated,

purely as quick ideas about how we thought the IDST system might look and behave. These mockups

were discussed, and it was quickly apparent which features were interesting or missing for the users.

The overhead of redesigning mockups is clearly much lower than that of redesigning a working

system.

The following sections show the latest screenshots and mockups that have been developed for the

IDST system, as outlined in the previous section. The functionality and usage for each web page is

described.

3.2.1 IDST Welcome Page

Figure 10 illustrates the main home page of the IDST. This page is available to all users and serves to

provide some background information about the INFRARISK project, as well as the IDST itself. A link

to the INFRARISK project site will be provided on this page (and vice versa).

INFRARISK

Deliverable D7.2


The welcome page provides a “Login

entry point (link) into the main IDST itself.

authenticated via a user login session

3.2.2 IDST Authentication S

The IDST will run over HTTPS and will support two main ways in which users can login. The first

method involves using local user accounts. Local accounts will be l

portal only. The second authentication mechanism is via authenticated accounts provided by third

party authentication services (e.g.

IDST users will use the later authentication mechanism.

Figure 11:


Figure 10: IDST welcome page

Login in” button to allow a user to log in to the IDST system, and an

ink) into the main IDST itself. Portal pages will be secured under HTTPS and

a user login session.

Authentication System


using local user accounts. Local accounts will be limited to administrative


(e.g. Mozilla Persona, Google, Yahoo, etc.), as outlined in

IDST users will use the later authentication mechanism.

: Third party authentication mechanism in IDST


15

button to allow a user to log in to the IDST system, and an

secured under HTTPS and


to administrative use of the


), as outlined in Figure 11.

INFRARISK

Deliverable D7.2


An example of the IDST login page is illustrated in

attempting to access a secure IDST page

redirected to the page they were previously on.

(Note that, for the actual implementation, the login feature appears as a modal pop

separate page.)

3.2.3 Authorization and User R

The IDST portal is using roles as the authorization mechanism for users to

various tasks. The IDST roles are illustrated in

administrator role, which has complete control and access to everything in the portal. For security

purposes the administrator role is assigned to loca

pyramid is the moderator role. This role allows users take more active

IDST (e.g. approve database entries, etc.


An example of the IDST login page is illustrated in Figure 12. This page will also appear

to access a secure IDST page but not logged in at the time. In this case,

he page they were previously on.

Note that, for the actual implementation, the login feature appears as a modal pop

Figure 12: IDST Login-in modal page

and User Roles within the IDST

The IDST portal is using roles as the authorization mechanism for users to control execution of

various tasks. The IDST roles are illustrated in Figure 13. At the top of the pyramid there is the

complete control and access to everything in the portal. For security

purposes the administrator role is assigned to local users only. The next level in the

pyramid is the moderator role. This role allows users take more active role in content created in the

e.g. approve database entries, etc.).


16

also appear when a user is

In this case, the user will be

Note that, for the actual implementation, the login feature appears as a modal pop-up instead of a

control execution of

. At the top of the pyramid there is the

complete control and access to everything in the portal. For security

l users only. The next level in the authorization

in content created in the

INFRARISK

Deliverable D7.2


Figure

The author role is automatically assigned to all authenticated users. This role allows users to create

content in their user area (e.g. create PWE case studies

unauthenticated users and they can access the pu

3.3 The IDST Dashboard

The initial view of the IDST ‘Dashboard’,

logged in. This page, along with all other secure IDST pages,

button, which would log the user out of the IDST and return to the welcome page.


Figure 13: Authorization roles in IDST


e.g. create PWE case studies). The anonymous role is used for

unauthenticated users and they can access the public content of the IDST.

view of the IDST ‘Dashboard’, is illustrated in Figure 14, which appears after the

ith all other secure IDST pages, will provide the user



17


The anonymous role is used for

which appears after the user has

user with a ‘Log out’


INFRARISK

Deliverable D7.2


Figure

Under normal circumstances, the user would be presented with one or more case studies that they

have previously set up and are working with (this view has not yet been developed).

logging in for the first time after creating an account

to start creating a new case study and associated scenarios.

This main Dashboard view is likely to be more complex and feature ric

for example showing a quick over

The menu at the top of the page provides links to return to the main home (welcome) page, plus

other areas of the IDST, for example to view various databases (e.g. the KB

tools and services (to be defined).

The user profile page,Figure 15,

tools and processes (e.g. PWE case studies


Figure 14: IDST Dashboard – Initial View

circumstances, the user would be presented with one or more case studies that they

have previously set up and are working with (this view has not yet been developed).

time after creating an account, this initial Dashboard view will guide the user

start creating a new case study and associated scenarios.

This main Dashboard view is likely to be more complex and feature rich in later versions of the IDST,

overview of the general state of the user’s managed infrastructure.


other areas of the IDST, for example to view various databases (e.g. the KB-MGIF), or access other

fined).

, presents a summary of the user status including the usage of

PWE case studies).


18

circumstances, the user would be presented with one or more case studies that they

have previously set up and are working with (this view has not yet been developed). However, after

board view will guide the user

h in later versions of the IDST,

he user’s managed infrastructure.


MGIF), or access other

a summary of the user status including the usage of IDST

INFRARISK

Deliverable D7.2


3.3.1 IDST: New PWE Case S

From the home area, the user can choose to

of existing IDST case studies, and allows the user to create new ones, as

summary list provides the name, status, and actions for each

State field gives what part of the IDST

IDST process workflow engine has the following states listed in

PWE state

1 NOT STARTED

2 SYSTEM DEFINITION

3 SYSTEM ELEMENTS

4 RISK IDENTIFICATION

5 RISK ANALYSIS

6 COMPLETE

Table


Figure 15: IDST user profile page

Case Study

the user can choose to access the IDST PWE initial page. This page shows a list

of existing IDST case studies, and allows the user to create new ones, as illustrated in

the name, status, and actions for each of the user’s case studies

gives what part of the IDST process state is up to or “COMPLETE” for a finished study.

IDST process workflow engine has the following states listed in Error! Reference source not found.

tate name Description

NOT STARTED Case study not started

SYSTEM DEFINITION Define system boundaries

SYSTEM ELEMENTS Gather infrastructure elements

RISK IDENTIFICATION Identify scenarios

RISK ANALYSIS Analyze risk

COMPLETE Case study complete

Table 2: IDST process workflow engine states


19

This page shows a list

illustrated in Figure 16. The

of the user’s case studies. The PWE

process state is up to or “COMPLETE” for a finished study. The

Error! Reference source not found..

INFRARISK

Deliverable D7.2


The following actions on an IDST case study are allowed:

• "Execute" allows the user to continue where they left off in an existing survey

• "View" allows the user to see a report based on the in

• "Delete" allows a survey to be removed

Finally, to create a new study, the user

16.

After clicking “New Case Study” in the Dashboard, the user is guided to follow a series of steps in

order to create a new case study. The initial view is

general details about the new case study

study itself), then click “Next” to proceed with


IDST case study are allowed:

"Execute" allows the user to continue where they left off in an existing survey

"View" allows the user to see a report based on the information entered

"Delete" allows a survey to be removed

Finally, to create a new study, the user may click the "New Case Study" button as illustrated in

Figure 16: IDST PWE dashboard page


order to create a new case study. The initial view is illustrated in Figure 17. The

general details about the new case study here (e.g. name, and a short description about the case

, then click “Next” to proceed with the System Definition phase.


20

"Execute" allows the user to continue where they left off in an existing survey

formation entered

as illustrated in Figure


. The user can enter some

and a short description about the case

INFRARISK

Deliverable D7.2


Figure

3.3.2 IDST System Definition: Locating a

After the creation of the case study, the user can start the execution of the PWE process.

The workflow phases indicated in the view follow the con

• System Definition

o Spatial boundaries

o Temporal boundaries

o Hazard type

o System elements

� Hazard type

� Infrastructure events

� Network use events

� Social events

• Risk Identification

• Risk Analysis


Figure 17 IDST: New Case Study – General Settings

IDST System Definition: Locating an Area of Interest


phases indicated in the view follow the convention of the ORMF stages, as follows:

Spatial boundaries

Temporal boundaries

System elements

Hazard type

Infrastructure events

Network use events

Social events


21


vention of the ORMF stages, as follows:

INFRARISK

Deliverable D7.2


The user cannot navigate to RISK IDENTIFICATION

the System Definition (i.e. the options would be initially disabled).

Figure 18: IDST System Definition: Locating a

For the System Definition, the user needs to enter details about System Boundaries and System

Elements. These are shown as separate tabs

First, the user is presented with a map (similar to a Google Map), which would allow him/her to

locate the region of interest for the case study.

to locate this region, using regular map controls (e.g. dragging the

1 The map would probably be initialised to show a map of Europe in the first instance (configurable in the IDST)


RISK IDENTIFICATION or RISK ANALYSIS PWE stages before setting up

the System Definition (i.e. the options would be initially disabled).

IDST System Definition: Locating a Region of Interest


Elements. These are shown as separate tabs, as illustrated in Figure 18.

presented with a map (similar to a Google Map), which would allow him/her to

locate the region of interest for the case study.1 They would be directed to drag and zoom the map

to locate this region, using regular map controls (e.g. dragging the map, clicking zoom buttons, etc.

The map would probably be initialised to show a map of Europe in the first instance (configurable in the IDST)


22

stages before setting up

Region of Interest


presented with a map (similar to a Google Map), which would allow him/her to

They would be directed to drag and zoom the map

map, clicking zoom buttons, etc.).

The map would probably be initialised to show a map of Europe in the first instance (configurable in the IDST)

INFRARISK

Deliverable D7.2


3.3.2.1 IDST System Definition:

Figure 19: IDST System Definition:

Figure 19 shows the view once the user has located an approximate region of interest on the map. In

this example, the user then is directed to drag a rectangle (using the mouse) to define this region.

They may also enter coordinates for the region manually, or let the user upload the boundaries from

a GIS file.

Once the user has dragged a rectangle (shown in red in

automatically displayed in the text boxes on the right

afterwards, to fine-tune the region.

The user can then use the ‘Zoom into region’

interest.

3.3.2.2 IDST System Definition:

After the spatial boundaries have been defined, the user mu

boundaries for the case study. This could include, for example, the

assessment, e.g. number of years

be defined).

3.3.2.3 IDST System Definition: Hazard

The next step in the process is to define the hazard

supports the following hazard scenarios

2 For the initial IDST prototype, we may have a pre


IDST System Definition: Spatial Boundaries

IDST System Definition: Locating a Region of Interest (zoomed

shows the view once the user has located an approximate region of interest on the map. In

ser then is directed to drag a rectangle (using the mouse) to define this region.

dinates for the region manually, or let the user upload the boundaries from

Once the user has dragged a rectangle (shown in red in Figure 19), the coordinates for this are

automatically displayed in the text boxes on the right-hand panel. These may be adjusted manually

region.2

then use the ‘Zoom into region’ option to expand the map to fully show the region of

ystem Definition: Temporal Boundaries

After the spatial boundaries have been defined, the user must then enter certain required temp

oundaries for the case study. This could include, for example, the return time period for the risk

t, e.g. number of years. Other temporal boundary parameters might be entered

IDST System Definition: Hazard Scenarios

e next step in the process is to define the hazard events. The current IDST implementation

scenarios and network elements:

For the initial IDST prototype, we may have a pre-defined region of interest, which could be selected perhaps from a drop


23

Locating a Region of Interest (zoomed in view)

shows the view once the user has located an approximate region of interest on the map. In

ser then is directed to drag a rectangle (using the mouse) to define this region.

dinates for the region manually, or let the user upload the boundaries from

), the coordinates for this are

hand panel. These may be adjusted manually

option to expand the map to fully show the region of

st then enter certain required temporal

time period for the risk

. Other temporal boundary parameters might be entered here (to

The current IDST implementation

region of interest, which could be selected perhaps from a drop-down list.

INFRARISK

Deliverable D7.2


Network element

Bridge

Tunnel

Road (sections)

Table 3

Other hazards such as floods and rainfalls will be added

case study.

Figure 20

3.3.2.4 IDST System Definition: Defining the System Elements

Once the System Boundaries have been defined, the user would choose on the “System Elements”

tab, to start defining these (as shown in


Network element Hazard scenario

Earthquake

Earthquake

Road (sections) Earthquake triggered landslides

3: Network elements associated with hazards

Other hazards such as floods and rainfalls will be added later with the implementation of the second

20: System definition, selection of hazard type

IDST System Definition: Defining the System Elements


tab, to start defining these (as shown in Figure 21).


24

with the implementation of the second


INFRARISK

Deliverable D7.2


Figure 21: IDST System Definition:

System elements are described in detail in D4.1. The user would be directed

system elements (via selections in drop

• Source event (e.g. rainfall, tectonic plate movements)

• Hazard event (e.g. flood, earthquake)

• Infrastructure event (e.g.

• Network event (e.g. traffic interruption)

• Social event (e.g. direct or indirect consequences)

The options for each system element

and made available to this page dynamically (allowing them to be modified or added to by the IDST

administrator). Initial discussions on this mock

infrastructure events would be preferred, so this page will be improved over time.

elements have been defined, the user proceeds to the Risk Identificati


IDST System Definition: Defining the System Elements

System elements are described in detail in D4.1. The user would be directed to enter the following

(via selections in drop-down lists):

Source event (e.g. rainfall, tectonic plate movements)

Hazard event (e.g. flood, earthquake)

Infrastructure event (e.g. bridge failed)

Network event (e.g. traffic interruption)

ial event (e.g. direct or indirect consequences)

The options for each system element (drop-down list) will be pre-configured in the IDST database


r). Initial discussions on this mock-up suggest that a more graphical way of selecting

would be preferred, so this page will be improved over time.

lements have been defined, the user proceeds to the Risk Identification stage.


25

Defining the System Elements

to enter the following

in the IDST database


up suggest that a more graphical way of selecting

would be preferred, so this page will be improved over time. Once the system

INFRARISK

Deliverable D7.2


3.3.3 IDST Risk Identification

Figure 22: IDST Risk Identification:

Figure 22 shows the initial view for the Risk Identification stage. Here, the basic system elements (as

defined in the previous stage) are automatically linked into a basic scenario (initially labelled

“Scenario 1”).

Clicking on each of the system elements in this view will pop up a panel allowin

or edited (i.e. to enter associated parameters).

3.3.4 Gathering Data for Network Elements

Once the system definition is complete, the IDST will start

in order to estimate the probability of occurrence of the

infrastructure elements for the selected

• Structural data for all elemen

the case study spatial boundaries.

• Generate hazard events, e.g. PGA values, for the case study defined spatial and temporal

boundaries.

• Estimate fragility curves


IDST Risk Identification

IDST Risk Identification: Initial View for Scenario 1

shows the initial view for the Risk Identification stage. Here, the basic system elements (as


Clicking on each of the system elements in this view will pop up a panel allowing details to be view

i.e. to enter associated parameters).

Gathering Data for Network Elements

Once the system definition is complete, the IDST will start gathering baseline data for

probability of occurrence of the damage states of the network

selected hazard type. This may include the following:

Structural data for all elements of the selected network, i.e. bridges, tunnels, roads

the case study spatial boundaries.

Generate hazard events, e.g. PGA values, for the case study defined spatial and temporal

for each network element.


26

Initial View for Scenario 1

shows the initial view for the Risk Identification stage. Here, the basic system elements (as


g details to be viewed

baseline data for the case study,

of the network

clude the following:

tunnels, roads within

Generate hazard events, e.g. PGA values, for the case study defined spatial and temporal

INFRARISK



4 Road Case Study Risk Analysis in IDST

The first Case Study to be examined in the INFRARISK project comprises a road network in Northern

Italy. The region examined measures approximately 990km2 and is location in the vicinity of the city

of Bologna in Northern Italy,Figure 23. For this road network, earthquakes and earthquake-triggered

landslides are considered. This section will describe the development of fragility curves for bridges,

tunnels and road sections due to earthquake and earthquake-triggered landslide hazards.

Figure 23: Road network for the Italian case study

Initial structural data for network elements for this case study include bridges, tunnels and roadways

sections from the Bologna region. The following sections describe the risk analysis on those

elements in the IDST as part of the identified case studies.

4.1 Earthquake Hazard Damage State Estimation

The IDST will estimate the probability of occurrence of the damage states of transport network

elements (bridge and tunnel) due to an earthquake hazard event. During this step fragility curves are

assigned to bridges, tunnels and road sections, in order to estimate the probability of having a

defined damage state of a network element for a given hazard event. Earthquake fragility curves for

bridges, tunnels and road sections calculation is based on structural data of those elements using

reference fragility models.

Where multiple fragility curves may be assigned to a specific structural element, median fragility

curves will be generated with confidence bounds. These bounds are based on probability densities

that correspond to a range of preset percentiles. Fragility curves are then used to calculate damage

states, as described in Error! Reference source not found., for each network element.

INFRARISK



Damage State Description

0 DS0 No damage

1 DS1 Slight / minor damage

2 DS2 Moderate damage

3 DS3 Extensive / major / sever damage

4 DS4 Complete damage / collapse / failure

Table 4: Damage states for bridges, tunnels, and road sections

The probability of occurrence of the element damage states is based on the process described in

D4.3 (D'Ayala & Gehl, 2015). The damage state (DS) for any network element is based on their

fragility parameters median (a_Di) and dispersion (b_Di). For a given hazard intensity IM (PGA value

at the element location), the DS is defined as the probability of reaching or exceeding damage state

Di:

( )

−Φ=≥

Dib

DiaIMIMDidsP

_

_lnln| (1)

where φ represents the standard normal cumulative distribution function. In the present case, the

peak ground acceleration (PGA) expressed in g [9.81 m/s2] is used as the IM.

Figure 24 illustrates the generated fragility curves for a specific bridge within the IDST.

INFRARISK

Deliverable D7.2


Figure 24

The list of network element damage states then can be used to create the damage

will become the basic input to analyse and evaluate the risk

will require the simulation of traffic using for example

where the results can be visualized as a heatmap. Such analysis will evaluate

consequences on estimate repair times, cost, and functional losses

4.2 Landslide Hazard Damage State Estimation

In addition to earthquakes and floods, the INFRARISK project considers landslide hazards. Landslides

may be triggered by earthquakes or rainfall, as outlined in

A value of failure surface depth (t) in the direction normal to the slope surface equal to 2.4m was

assumed (Jibson, Harp, & Michael, 2000)

the failure surface depth (m) equal to

et al., 2014). Landslide yield acceleration values (k

Equations 1 and 2 for a 10m x 10m resolution grid, as illustrated in


24: Bridge structural data and fragility curves

damage states then can be used to create the damage

will become the basic input to analyse and evaluate the risk for the selected hazard

will require the simulation of traffic using for example Network EXplorer for Traffic Ana

visualized as a heatmap. Such analysis will evaluate

consequences on estimate repair times, cost, and functional losses on the infrastructure

Damage State Estimation

to earthquakes and floods, the INFRARISK project considers landslide hazards. Landslides

may be triggered by earthquakes or rainfall, as outlined in (D'Ayala, et al., 2014).

failure surface depth (t) in the direction normal to the slope surface equal to 2.4m was

(Jibson, Harp, & Michael, 2000) (Saygili & Rathje, 2009) and a value of saturation ratio o

the failure surface depth (m) equal to a pre-set number. The number of 0.2 was assumed

. Landslide yield acceleration values (ky) will be subsequently calculated according to

for a 10m x 10m resolution grid, as illustrated in Figure 25.


29

damage states then can be used to create the damaged network that

hazard. Such analysis

Network EXplorer for Traffic Analysis (NEXTA)

visualized as a heatmap. Such analysis will evaluate direct and indirect

on the infrastructure.

to earthquakes and floods, the INFRARISK project considers landslide hazards. Landslides

.

failure surface depth (t) in the direction normal to the slope surface equal to 2.4m was

and a value of saturation ratio of

0.2 was assumed (D'Ayala,

subsequently calculated according to

INFRARISK

Deliverable D7.2


Figure 25: ky values for Italian road network case study (10m x 10m grid resolution)

The road network for this region was subsequently examined at 10m sections and earthquake

triggered landslide fragility curves were assigned to each. Information regarding the road net

was obtained from http://download.geofabrik.de/europe/italy.html

regarding the type of roadways (e.g. major or urban).

An example calculation for a single road s

value equal to 0.33. Based on the fragility curves outlined in

2004) with the following equation:

ln�� 0.22 2.83 ln��0.244�ln�� 0.278��

The resulting fragility curves given in terms of PGA for the selected road section are illustrated in


values for Italian road network case study (10m x 10m grid resolution)

The road network for this region was subsequently examined at 10m sections and earthquake

triggered landslide fragility curves were assigned to each. Information regarding the road net

http://download.geofabrik.de/europe/italy.html, which provided information

regarding the type of roadways (e.g. major or urban).

An example calculation for a single road section is presented herein for an urban road, with a ky

value equal to 0.33. Based on the fragility curves outlined in (National Institute of Building Sciences,

with the following equation:

� �� 0.333�ln�� 0.566 ln�� ln��

� 7� (3)

he resulting fragility curves given in terms of PGA for the selected road section are illustrated in


30

values for Italian road network case study (10m x 10m grid resolution)

The road network for this region was subsequently examined at 10m sections and earthquake-

triggered landslide fragility curves were assigned to each. Information regarding the road network

, which provided information

ection is presented herein for an urban road, with a ky

(National Institute of Building Sciences,

� �3.04 ln��

he resulting fragility curves given in terms of PGA for the selected road section are illustrated in

INFRARISK



Figure 26.

Figure 26: Earthquake-triggered landslide fragility curves for example road section (road type =

urban, ky = 0.2) in Italian case study road network

4.2.1 Implementation to IDST

A similar approach for bridges, tunnels and road sections will be applied for the landslide hazard on

road sections built on slopes. Specifically, the key points are to predict road damage state estimation

of the yield acceleration (Ky), on road sections, as a function of PGA values.

Landslide yield acceleration (Ky) values which have been calculated for the region of interest in

Northern Italy will be implemented in the IDST. The landslide and road section current data

modelling in the IDST system are presented in Figure 27. The IDST Ky database provides data road

INFRARISK



sections with 10m spatial resolution. Roads are also classified as urban or major based on the

number of lanes they have, e.g. 4 lines for major roads, and 2 lines for urban roads.

Figure 27: Landslide and road section data model in the IDST

Road sections within the IDST case study will be identified and selected. The IDST will subsequently

automatically calculate fragility curves for each of the 10m road sections based on equation 2. The

fragility curves are then combined with PGA data in order to calculate the Damage State for each

road section.

The generated damage states for each of the elements in the region of study are then available for

further processing and the resulting direct (and indirect) functional losses, socio-economic costs and

repair times required prior to their restoration.

In order to reach scalability in the processing of large number of infrastructure objects that are

exposed to cascading natural hazards, importance statistical sampling of the damage states can be

exercised to compute the overall impact. Such functionality in the IDST can be potentially

implemented should the statistical importance sampling algorithms become available.

INFRARISK



4.3 Estimation of Repair Times, Costs and Functional Losses

The estimation of functional losses, repair times and consequences, will be based on the network

elements damage states (DSi) calculated earlier. The IDST will consider the following parameters for

the study of the impact of natural hazards on critical infrastructure following knowledge on their

damage states:

• Functional capacity loss

• Functional capacity loss during restoration

• Repair time

• Repair consequences

Values for these parameters are illustrated in the table below. The functional capacity loss during

restoration was provisionally assumed to be 100% for the ‘Moderate’ and ‘Extensive/Complete’

damage categories (INFRARISK Guideline for case study I, 2015):

For restoration costs, values for bridges, tunnels and road sections were estimated for each object in

each damage state. The functional capacity loss, functional capacity loss during restoration and the

base restoration time per object can be estimated per objects. This is illustrated in Table 5 below.

Functional

Capacity Loss

Functional Capacity Loss

during Restoration

Restoration

Time

(% Lane Closure) (% Lane Closure) (Days)

Pavements (All)

No Damage 0 0 0

Slight/Minor 0.1 0.1 0.9

Moderate 0.75 1 2.2

Extensive/Complete 0.9 1 21

Bridges (All)

No Damage 0 0 0


Moderate 0.7 1 2.5

Extensive/Major/Severe 0.98 1 75

Complete/Collapse/Failure 1 1 230

Tunnels (All)

No Damage 0 0 0


INFRARISK



Moderate 0.75 1 2.4

Extensive/Major/Severe 0.95 1 45

Complete/Collapse/Failure 1 1 210

Table 5: Illustrative values of functional capacity loss, restoration times (FEMA, 2003)

4.4 Restoration Model

Quantitative models of the post-earthquake restoration process can be employed to evaluate the

total economic loss caused by a natural hazard such as an earthquake (Cagnan & Davidson, 2004).

They involve the identification of a restoration sequence (e.g. the order in which the elements are

restored). For example, the restoration of infrastructure elements may be performed in series, in

parallel, or a combination of both, depending on available restoration resources.

A simple restoration model will initially be implemented as a functional module in the IDST. It will

specifically rank restoration works according to user-defined criteria (i.e. the infrastructure element

with the greatest number of closed lanes).It will also be made user-interactive while it provides

updated functionality states of the network following one (or multiple) hazard event(s).

Specifically, for each object, in the area affected by a hazardous event, the IDST will relate the

assigned damage states (DSi) to corresponding values of Functional Capacity Loss (Initially),

Functional Capacity Loss (During restoration), Restoration Time and Restoration Cost. Nevertheless,

the user will prioritize the restoration of objects based on ranking criteria options, e.g. type of

Functional Capacity Loss, Restoration Time and Restoration Cost.

4.4.1 Simulated Damage States over Restoration Period

The restoration model enables updated functionality states of the network to be determined at

discrete time steps following the hazard event(s). Since various damage states of the network are

sampled due to the uncertainty associated with GM fields and the various probabilities associated

with individual damage states, a unique functionality state of the network will be obtained for each

sample.

4.4.2 Implementation in the IDST

The IDST will allow the user to interact with various restoration scenario simulations. For example,

the IDST will allow the prioritisation of the restoration process and the control of the simulations,

the number of work crews available, lag times, etc. Currently, the restoration process is simulated by

an R-code which will be installed and fully tested under the IDST environment. This code will

subsequently be updated with more advanced restoration factors.

4.5 Estimate Direct Consequences

Direct consequences are accrued as restoration works and completed for individual network

elements following the hazard events. More specifically, the direct costs associated with the repair

of the network are not incurred all at once, but rather over time according to the restoration model.

Exemplar tables from literature about indicative costs associated to critical infrastructure repair may

INFRARISK



be made accessible in the IDST. Nevertheless, these can only be considered as solely indicative

information which should not be considered as final calculations.

4.6 Estimated Indirect Consequences Functionality

The IDST system will also adopt, whenever possible, existing software to evaluate indirect

consequences of natural hazards on infrastructure. These may include the effect on road traffic

within a large region of interest that is affected by the natural hazard, while its critical elements of

road sections are being gradually restored. The implicated traffic delays, which are encountered

throughout the network road sections will be processed by a dedicated software that computes road

network performances.

4.6.1 NEXTA Implementation in the IDST

The identified list of Damage State network elements will be used as input to NEXTA (see Appendix I)

in order to calculate the indirect consequences of a natural hazard and damage to road network

infrastructure. The damage state list will be formatted accordingly for NEXTA, e.g. in CSV format,

that can be used for subsequent NEXTA tool simulations.

The IDST will not integrate NEXTA into the PWE directly, but it will connect to either of the following

options:

• Indirectly use NEXTA as a service loosely coupled. In this option NEXTA or DTALite will run as

a service and the IDST will submit case study data in a batch mode to run the simulation.

Results from the simulation run will be returned and visualized in IDST.

• Assist IDST users to run NEXTA locally at their end. In this case the IDST will prepare for the

user all the necessary input data. The IDST user then will be assisted to download that case

study input data and run the simulation locally. Results from the simulation process then will

be uploaded to the IDST server for further processing and visualization.

The above options will be tested in the project and only the most performing option will be adopted.

INFRARISK



5 CONCLUSION

This document has outlined the IDST system specification version 2.0, which will facilitate the

development of a more advanced version of the IDST. The IDST system v2.0 has been specified

based on consultation of the developers with other consortium partners, domain knowledge experts

and end-users. The system is a decision-support tool which will enable users to set up cascading risk

scenarios with low probabilities of occurrence and high impact on Critical Infrastructure (CI) in

Europe.

The IDST integrates various data, information and outputs from INFRARISK databases and modelling

tools, which are being developed in Work-Packages 2, 3, 5 and, 6. The challenge is to integrate these

modules. Ultimately, the IDST will capture the risk of natural hazards and their effects on CIs. The

IDST system also maintains the overarching risk assessment developed in WP4 (Adey, et al. 2014).

This provides a common platform and process workflow engine for crisis management experts to

perform their risk assessments using the IDST. This will enable them achieve integrated strategies for

encountering rare natural hazards with cascading risks and impact on European CIs. The

specifications within this current document will guide, the development of the advanced version of

the IDST software v 2.0.

INFRARISK



6 REFERENCES

A world-class geographic web framework. (n.d.). Retrieved from GeoDjango: http://geodjango.org/

B.T., A., J., H., M., H., & I., I. (2014). Preliminary Model, Methodology and Information Exchange.

INFRARISK D4.1.

Balsamiq Studios. (n.d.). Balsamiq. Retrieved from Balsamiq: https://balsamiq.com/

Bootstrap. (n.d.). Retrieved from Bootstrap: http://getbootstrap.com/

Bray, J. D., & Travasarou, F. (2007). Simplified procedure for estimating earthquake-induced

deviatoric slope displacements. Journal of Geotechnical and Geoenvironmental Engineering 133 4 ,

381-392.

Bryan Adey, J. H. (2014). Novel Indicators for Identifying Critical INFRAstructure at RISK from Natural

Hazards. INFRARISK EU project.

Cagnan, Z., & Davidson, R. (2004). Post-earthquake restoration modeling of electric power systems.

13th World Conference on Earthquake Engineering. Vancouver.

Crowley, H., Colombi, M., Silva, S., Monteiro, R., Ozcebe, S., Fardis, M., et al. (2011). Fragility

functions for roadway bridges, SYNER-G D3.6 Report. Italy: University of Pavia.

D., D., & P., G. (2015). Infrarisk Deliverable D3.2 Fragility Functions Matrix. European Commission.

D’Ayala, D. G.-M. (2015). Fragility Functions Matrix. INFRARISK Technical Report D3.2.

D'Ayala, D., Gehl, P., Garcia-Fernandez, M., Jimenez, M., Ni Choine, M., Tucker, M., et al. (2014).

INFARISK Deliverable D3.1 Hazard Distribution Matrix. European Commission.

D'Ayala, D., Meslem, A., Vamvatsikos, D., Porter, K., Rossetto, T., Crowley, H., et al. (2014).

Guidelines for Analytical Vulnerability Assessment of low/mid-rise Buildings, Vulnerability Global

Component project.

Django Web Framework. (n.d.). Retrieved from Django Web Framework:

https://www.djangoproject.com/

FEMA. (2003). Multi-hazard Loss Estimation Methodology Earthquake Model, HAZUS MR4 Technical

Manual. Washington DC: Federal Emergency Management Agency .

Jibson, R. W., Harp, E. L., & Michael, J. A. (2000). A method for producing digital probabilistic seismic

landslide hazard maps. Engineering Geology , 58, 271-289.

jQuery Foundation. (n.d.). jQuery. Retrieved from jQuery: http://jquery.com/

National Institute of Building Sciences. (2004). HAZUS-MHL User's Manual and Technical Manuals.

Washington, D. C.: Report prepared for the Federal Emergency Management Agency.

Newmark, N. M. (1965). Effects of earthquakes on dams and embankments. Geotechnique 15 , 271-

289.

Ni Choine, M., & Martinovic, K. (2014). Critical Infrastructure Case Studies INFRARISK D8.1 Report.

Dublin, Ireland: RODIS.

Object Relational Mapping. (n.d.). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Object-

relational_mapping

Pitilakis, K., Fotopoulou, S., Argyroudis, S., Pitilakis, D., Senetakis, K., Treulopoulos, K., et al. (2010).

SAFELAND Deliverable 2.5 Physical vulnerability of elements at risk to landslides: Methodology for

evaluation, fragility curves and damage states for buildings and lifelines. European Commission.

INFRARISK



PostGIS -- Spatial and Geographic Objects for PostgreSQL. (n.d.). Retrieved from PostGIS:

http://postgis.net/

Python Programming Language. (n.d.). Retrieved from Python Programming Language:

https://www.python.org

Saygili, G., & Rathje, E. M. (2009). Probabilistcally based seismic landslide hazard maps: an

application in Southern California. Engineering Geology , 109 (3-4), 183-194.

Wikipedia. (n.d.). Geographic Information System. Retrieved from Wikipedia:

http://en.wikipedia.org/wiki/Geographic_information_system

Wikipedia Model View Controller. (n.d.). Model View Controller. Retrieved from Wikipedia:

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Y., S. (1985). Urban transportation network, Equilibrium analysis with mathematical programming

mehtods. Prentice Hall.

INFRARISK



APPENDIX A NEXTA Traffic Assignment Software

Network Explorer for Traffic Analysis (NEXTA) is an open-source software designed to simulate and

assess the performance of a road network given a range of traffic scenarios varying across space and

time. Given origin-destination (OD) data, NEXTA assigns traffic to the routes which allow journeys to

be completed in the least amount of time.

There are four main phases during modelling, reflecting the four steps in classic urban transpiration

systems modelling (Sheffi, 1985). These are:

• Identifying shortest paths for all OD pairs in the network.

• Trip generation based on OD data, which determines the number of vehicles entering the

network over a giver time period.

• Traffic assignment, typically based on minimizing journey times across the network. This can

be amended to reflect road pricing systems, such as toll roads.

• Traffic flow models can reflect changes to the network caused by controls such as signaling

and changes to link capacity.

There are a number of algorithms which can be used to represent how traffic behaves on a network.

Traffic assignment in NEXTA uses the open-source dynamic traffic assignment tool DTALite (Zhou &

Taylor, 2014) to implement Newell’s kinematic wave model (Newell, 1993). It is possible to import

data into NEXTA using GIS shapefiles, Excel spreadsheets or by editing the CSV files that are

automatically created when you begin a new project. Data imported into the GUI is shown in Figure

28.

Figure 28: Example of the Italian Road Network imported into NEXTA

When the model is running the DTALite window opens and shows progress (Figure 29). In the Italian

case study, over 800000 vehicles are simulated as entering the network over a one hour period. The

model takes between 15-20 minutes to run on a 12GB RAM, 2 processor desktop computer. The

INFRARISK



results are saved as a series of CSV files. As we are particularly interested in travel time, once the

model has run, the model will save a file named output_ODMOE.csv which shows travel time

between OD pairs.

Figure 29: Example output of NEXTA showing travel time for OD pairs

It is also possible to visualize other metrics of interest such as link density (Figure 29) of the

percentage of maximum speed limit (Figure 31) for any time after the first vehicle has entered the

network.

INFRARISK



Figure 30: Link density showing the amount of traffic on each road in the network

INFRARISK



Figure 31: Percentage of speed limit

To represent damage to parts of the network, it is possible to alter the capacity of each link (e.g. a

link capacity of zero could represent total damage/that the road is unusable). When the capacities

have been changed and the model has been run again, it is possible to compare travel times (and

other metrics) between the damaged and undamaged networks. For example, Figure 32 shows the

link density (meaning the amount of traffic on certain links has increased due to a reduction in

capacity on other links) has increased due to a damage scenario involving roads in the Bologna area.

INFRARISK



Figure 32: Link density given a damage scenario in Bologna

deliverable d7.2 idst system specification v2 · python a general purpose programming language ram...

Documents