Deliverable D7.1 IDST System Specification v1 › sites › default › files › docs › INFRARISK...Rev01 08/09/2014 Draft structure/TOC Ken Meacham and Zoheir Sabeur (IT Innovation)

© 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.1

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 Ken Meacham and Zoheir Sabeur/IT Innovation

WP 7

Submission Date 15th December 2014

Primary Reviewer Bryan Adey/ETHZ

Dissemination Level PU

IDST System Specification v1.0

INFRARISK Deliverable D7.1 IDST System Specification v1.0

© The INFRARISK Consortium i

Project Information

Project Duration: 1/10/2013 ‐ 30/09/2016

Project Coordinator: Professor Eugene O' Brien Roughan & O’ Donovan Limited [email protected]

Work Programme: 2013 Cooperation Theme 6: Environment (Including Climate Change).

Call Topic: Env.2013.6.4‐4 Towards Stress Testing of Critical Infrastructure Against Natural Hazards‐FP7‐ENV‐2013‐two stage.

Project Website: www.infrarisk‐fp7.eu

Partners:

Roughan & O’ Donovan Limited, Ireland

Eidgenössische Technische Hochschule Zürich, Switzerland.

Dragados SA, Spain.

Gavin and Doherty Geosolutions Ltd., Ireland.

Probabilistic Solutions Consult and Training BV, Netherlands.

Agencia Estatal Consejo Superior de Investigaciones Científicas,

Spain.

University College London, United Kingdom.

PSJ, Netherlands.

Stiftelsen SINTEF, Norway.

Ritchey Consulting AB, Sweden.

University of Southampton IT Innovation Centre, United Kingdom.


© The INFRARISK Consortium iii

Document Information

Version Date Description Primary Author Rev01 08/09/2014 Draft structure/TOC Ken Meacham and Zoheir

Sabeur (IT Innovation)

Rev02 29/09/2014 Added section on Critical Infrastructure Mairéad Ní Choine (ROD)

Rev03 29/09/2014 Added section on KB‐MGIF (WP2) Titi Roman (SINTEF)

Rev04 30/09/2014 Added sections on IDST design, PWE and IDST applications, IDST GUI

Ken Meacham (IT Innovation)

Rev05 06/10/2014 Added sections on SRA and Integrated Spatio‐Temporal Database

Tao Cheng, Dina D’Ayala, Francesca Medda, Pierre Gehl and Khaled Taalab (UCL)

Rev06 07/10/2014 Corrections to document, references Ken Meacham (IT Innovation)

Rev07 21/10/2014 Introductions and conclusions Zoheir Sabeur and Ken Meacham (IT Innovation)

Rev08 22/10/2014 Version for internal review Zoheir Sabeur and Ken Meacham (IT Innovation)

Rev09 25/11/2014 Further improvements after review Ken Meacham and Zoheir Sabeur (IT Innovation)

Rev10 15/12/2014 Final refinement Ken Meacham and Zoheir Sabeur (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.


© The INFRARISK Consortium v

Executive Summary

This document (D7.1) is delivered under the INFRARISK WP7 work activities in order to specify the

design of the first version of the INFRARISK Decision Support Tool (IDST) software. The IDST

architecture is modular in design and reflects upon the user requirements, which have been

gathered through consultations with risk evaluation and modelling experts within the consortium

(and the project advisory board) during this first phase of the project. These have led to concrete

specifications of the IDST functionality which entail the integrated process of defining multiple

cascading risks, their geospatial coverage and impact on the so‐called defined natural system and

critical infrastructure of interest. Mock designs of the IDST GUI are presented to provide a feel of its

functionality and to guide how the first version of the software will be developed up to M18.

Also, some important terminologies concerning the integrated risk assessment process that have

been defined in WP4 are listed in a glossary table together with those related to modular software

design approaches in WP7.


© The INFRARISK Consortium vii

Table of Contents

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

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

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

2.1 High level design and architecture .......................................................................................... 3

2.2 IDST portal component ............................................................................................................ 4

2.3 PWE (Process Workflow Engine) ............................................................................................. 5

2.4 GIS database ............................................................................................................................ 5

2.4.1 Infrastructure Components ........................................................................................... 5

2.4.2 Hazard Maps ................................................................................................................. 6

3 Implementation .............................................................................................................................. 7

4 IDST Graphical User Interface ...................................................................................................... 10

4.1 IDST GUI design process ........................................................................................................ 10

4.2 IDST GUI mockups ................................................................................................................. 11

4.2.1 IDST Welcome Page .................................................................................................... 12

4.2.2 IDST Sign‐in Page ......................................................................................................... 13

4.2.3 IDST Dashboard – Initial View ..................................................................................... 14

4.2.4 IDST: New Case Study – General Settings ................................................................... 15

4.2.5 IDST System Definition: Locating a Region of Interest ................................................ 16

4.2.6 IDST System Definition: Locating a Region of Interest (zoomed view) ....................... 17

4.2.7 IDST System Definition: Defining a Region of Interest (Spatial Boundary) ................. 18

4.2.8 IDST System Definition: Region of Interest (zoomed in) and Temporal Boundaries .. 19

4.2.9 IDST System Definition: Defining the System Elements .............................................. 20

4.2.10 IDST Risk Identification: Initial View for Scenario 1 .................................................. 21

4.2.11 IDST Risk Identification: Editing a Source Event ....................................................... 22

4.2.12 IDST Risk Identification: Edited Source Event ........................................................... 23

4.2.13 IDST Risk Identification: Defining a New Source Event ............................................ 24

4.2.14 IDST Risk Identification: Editing a Hazard Event ....................................................... 25

4.2.15 IDST Risk Identification: Edited Hazard Event .......................................................... 26

4.2.16 IDST Risk Identification: Adding a New Hazard Event .............................................. 27

4.2.17 IDST Risk Identification: New Hazard Event Added .................................................. 28

4.2.18 IDST Risk Identification: Adding a New Infrastructure Event ................................... 29

4.2.19 IDST Risk Identification: New Infrastructure Event Added ....................................... 30


© The INFRARISK Consortium viii

4.2.20 IDST Risk Analysis ...................................................................................................... 31

5 CONCLUSION ................................................................................................................................. 32

5.1 IDST Future Development ..................................................................................................... 32

6 REFERENCES .................................................................................................................................. 33


© The INFRARISK Consortium ix

Glossary

Table 1, below, provides the terminology and abbreviations that are used in this document. These

also include certain terms defined in D4.1 (Adey et al, 2014), thus achieving consistency throughout

the project development.

Table 1 Glossary

Term Definition

AJAX Asynchronous JavaScript and XML. A method to create dynamic content on the client side via asynchronous calls for data to the server

API Application Programming InterfaceCI Critical Infrastructure database A collection of data, their related data structures (schema), and relationships. There may be

one of more data structure required to encapsulate all the data. DBV2 Former name for the ISTD (referred to in WP7)DEM Digital Elevation Model DoW Description of Work (for the project)GEM Global Earthquake Model GIS Geographic Information SystemGUI Graphical User Interface HTML Hypertext Markup LanguageHTTP(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 ISTD Integrated Spatio‐Temporal DatabaseJSON JavaScript Object NotationKB‐MGIF Knowledge Base of Major Global Infrastructure FailuresLOD Linked Open Data Mock‐up Sometimes known as a “wireframe”. A visualisation/model of a UI or web page. NetCDF Network Common Data FormORM Object‐Relational MapperORMF Overarching Risk Management Frameworkrequirement 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 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 URL Uniform Resource Locatoruse 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.


© The INFRARISK Consortium 1

1 INTRODUCTION

The purpose of the INFRARISK Decision Support Tool (IDST) is to allow infrastructure owners and

managers to assess the risks associated with a particular infrastructure network subject to natural

hazards such as earthquakes, landslides and flooding. The IDST will provide access to generated

databases and scenario simulations results for the two case study regions (Italy & Croatia) in order to

demonstrate how the methodology works. However, the user will also have the option to apply the

methodology to any network of interest provided the necessary data is uploaded to the IDST. The

development of the IDST requires the deployment of phase driven software development tasks using

an agile approach. Firstly, a consultation with the domain knowledge experts and end users within

(and outside) the consortium partnership is exercised to capture the functional requirements of the

first version of the IDST software system. Secondly, while these functionality requirements for

decision‐support are taken on board, together with: 1) The quantification of risks of natural hazards

on Critical Infrastructure (CI) and; 2) Their integration under an overarching methodology which is

derived from WP4, there will be a need to make the various project databases and natural processes

modelling results accessible to expert (and non‐expert) users of the IDST system. Last but not least, a

good capture of the system Graphical User Interface specification will be important to adopt. Under

this development perspective, two versions of the IDST system design and development will be

pursued in the project. The first version of the IDST system design specification (version 1.0) is

described in this document. A more advanced version of this document will be achieved in order to

reflect the improved and extended design specification of the IDST (version 2.0), by M24.

2 IDST Software Design

The IDST is the main software output for the INFRARISK project, and will therefore integrate all the

major tools, databases and user interfaces from various work packages into one combined system.

This will be 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 v1.0, the common browsers will be targeted (e.g. Internet Explorer, Firefox), running at least on

a Windows or Linux laptop, however the design of the graphical user interface (GUI) will take into

account multiple platforms from the start, by exploiting the latest platform independent UI toolkits.

The IDST software system will be deployed on a central server, with secure, remote access available

for all project partners and other selected stakeholders. Access will therefore be via HTTPS and, for

the main IDST pages, the user will be required to be logged in with their user account (the initial

welcome page will be available to all users, hence providing some background information about the

project and the IDST, then 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 different forms, e.g.

1. Database (local or remote) 2. Flat files (e.g. shape files) 3. Software module (e.g. Python code or MATLAB library) 4. Application (e.g. a command line executable) 5. Remote web service 6. Client‐side tool (e.g. JavaScript tool)



Early IDST prototypes may incorporate these contributions in a fairly raw form (e.g. using flat files),

whilst in later versions these will be more consistently integrated (e.g. as a database). The aim is to

integrate components in a consistent way, e.g. using common APIs, etc.

The main IDST system will use a framework that allows multiple components to be incorporated

easily, and that also integrates graphical interface (UI) features of these modules. This will be

described in more detail in the following section.

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

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

The components will be executed (after providing them with their required inputs), then results

returned either for direct display to the user, or as input to a subsequent module in a workflow.

Certain components might 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.

Other partner contributions will be made available as results in a pre‐populated database, for

example simulations that may take considerable time (e.g. more than a minute) to perform. It would

not be appropriate for the user experience to run these simulations dynamically, as a result of a user

request which might be requiring a fast response. 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.

The IDST system potentially needs to support a large number of concurrent users, so databases need

to be scalable and be able to handle a mix of structured and unstructured data. Additionally, the

plan is to open up the data so that authenticated (authorized) users can extract information for their

own application. Thus the chosen technologies will need to be able to support these numerous

requirements.

The INFRARISK DoW describes two major releases of the IDST; v1.0 is due by M18, whilst the final

version (v2.0) is due by M36. However, to help to focus the project and help to drive the user

requirements process, the plan is to release more frequent prototypes, i.e. using a “semi‐agile”

approach, whereby new features can be included relatively quickly and tried out by project partners.

This approach has been used successfully in other projects. It helps both to focus users on the

required product and to avoid too much wasted effort, developing functionality that they do not

want.

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 users often don’t have a complete

grasp of this, and therefore benefit from seeing something roughly working at an early stage, in

order to inspire ideas. As we will see in this document, some ideas are quite well developed already,

whilst others are in still their infancy (e.g. as partners learn each other’s domains, or as certain

project tasks are yet to start).

The following section introduces the high level design and architecture of the IDST v1.0.



2.1 High level design and architecture

Figure 1 shows 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:

1. Presentation Layer 2. Data Processing Layer 3. Data Storage Layer

The Presentation Layer is responsible for the creation of all 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), and 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 3.

The following sections describe in further detail the individual IDST modules and databases, as

outlined in Figure 1.



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

UsersUI data (e.g. for dropdown menus)UI config

GIS layers

InfrastructureHazard mapsSimulation resultsAnalysis 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 portal. 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 will store data related to the general operation of the portal, such as:

User accounts (including roles, etc.)

Session information (if required)

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.

User registration, login

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



2.3 PWE (Process Workflow Engine)

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

is essentially the realization of the Overarching Risk Management Framework (ORMF), as

conceptualized in WP4, within the IDST system. This risk assessment process is fully described in

D4.1 (Adey et al, 2014); the general steps would normally include:

1. Problem Identification 2. System Definition 3. Risk Identification 4. Risk Analysis 5. Risk Evaluation 6. Risk Treatment

As described in D4.1, the user (i.e. the infrastructure manager) has generally already undertaken the

first step, “Problem Identification”, before coming to use 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 process (“System Definition”, “Risk Identification” and

“Risk Analysis”). At present, the final steps, “Risk Evaluation” and “Risk Treatment”, are considered

out of scope for the IDST, as explained in D4.1. (N.B. “Risk Treatment” ‐ i.e. mitigation strategies ‐ are

not considered in the project).

The PWE database will store data related to the ORMF, such as:

Case study configuration and associated data, including o System definition (spatial and temporal boundaries, system elements, etc.) o Risk identification (i.e. scenario set‐up, e.g. event intensities)

Case study results including o Risk analysis (e.g. probability calculation results) o Simulation results

The PWE will perform the overall risk analysis, storing results in its database.

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.

2.4 GIS database

The IDST will need to store and use various types of GIS data, including:

Infrastructure

Hazard maps

Simulation results

Analysis results

These are described further in the following sections, where details are currently available.

2.4.1 Infrastructure Components

The tools and methodologies developed as part of the INFRARISK project will be tested on two

European critical infrastructure case studies. The first case study is a road network in Italy and the



second case study is a rail network in Croatia, as described in the preliminary Case Study Simulation

report, Deliverable 8.1 (Ni Choine & Martinovic, 2014).

In order to carry out these methodologies, information is required on the infrastructure in the case

study regions. This information will be provided to the IDST in the form of GIS Shape files, and

imported into the IDST’s GIS database. Initially, these Shape files will be imported manually,

however we plan to provide an option for the user to upload a new Shape file (either to update the

infrastructure for an existing case study, or to define a new region / case study).

GIS Shape files containing the following information will therefore be required:

1) Roads 2) Rail Lines 3) Bridges 4) Tunnels 5) Embankments 6) Intersections

Figure 2 shows an example of a shape file of the Italian road network.

2.4.2 Hazard Maps

Information will also be required on the hazards in the case study regions in order to carry out the

risk assessment methodology. The hazards considered will be as follows;

1) Seismic 2) Landslide 3) Flooding

These hazard maps will take the form of GIS shape files and will be input by the user. For the case

study region there will be an option to use the prepopulated hazard maps available within the IDST.



Figure 2: GIS Shape file of the Italian road network

3 Implementation

The IDST system will be built using the Django1 web framework. Django is a popular open source

web application framework, written in the Python2 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 scale and has been used in some very high performance web sites.

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”3. Django

provides many useful features “out of the box”, e.g. its “object‐relational mapper”, which provides a

database access layer.

Figure shows 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

1 https://www.djangoproject.com/ 2 https://www.python.org/ 3 http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller



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, etc., to be consumed by client browser

Ajax requests.

For accessing databases, Django uses an Object‐Relational Mapper (ORM)4. 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, we propose to use GeoDjango5, 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

GIS6 web application.

We propose to use PostGIS7 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).

4 http://en.wikipedia.org/wiki/Object‐relational_mapping 5 http://geodjango.org/ 6 http://en.wikipedia.org/wiki/Geographic_information_system 7 http://postgis.net/



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 3: 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, we plan to use off‐the‐shelf solutions such as Bootstrap8 for providing platform‐independent

layouts and UI widgets, along with jQuery9 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 helps the general

user experience. In addition to the base library there are numerous plugins for graphing, mapping,

and visualisation.

8 http://getbootstrap.com/ 9 http://jquery.com/



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

part of Task 7.4.

4 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 3. The design of the IDST

web pages will be described in the following sections.

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. Scenarios can then be “run” and the outcome presented using the

GUI. A number of visualisation methods will be explored. Specifically, we will examine GIS overlays

(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.

4.1 IDST GUI design process

The design of the IDST GUI is of paramount importance since it should be employed by multiple

types of risk managers specialising in the protection of various types of critical infrastructure. Once

ideas have been reasonably well developed within the consortium, we will consult the project

advisory board and associated stakeholder communities for further expert opinions and feedback.

To help achieve mutual understanding of requirements, a useful approach (that we are using in

INFRARISK) 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 Balsamiq10 Mockups. 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, for example.

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.

10 https://balsamiq.com/



Towards the end of the first phase of the ORMF development (i.e. the delivery of D4.1), it was then

somewhat clearer about the main functionality requirements for the IDST. We developed some

more extensive mockups, showing how a user might use the IDST to login to the system, define test

cases and scenarios for identifying and evaluating risks to infrastructure from natural hazard events.

These mockups are described in detail in the following section.

It should be noted that, whilst these mockups are likely to form the basis of the design of the IDST

v1.0, we are continuously receiving feedback about them, so they are still likely to change and

develop over time. For this reason, we expect that the resulting IDST pages will look somewhat

different to these proposals. The next step will be to develop an early prototype of the IDST system,

demonstrating some of these features as a working system.

4.2 IDST GUI mockups

The following sections show the latest 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.



4.2.1 IDST Welcome Page

Figure 4: IDST Welcome Page

Figure 4 shows the main welcome (home) page for the IDST. This page will be available to all users

(whether logged in or not), and serves to provide some background information both about the

INFRARISK project and the IDST itself. Note that this page is not a replacement for the INFRARISK

website, so there is likely to be a link to the INFRARISK project site (and also a reciprocal link from

there to this IDST welcome page).

The welcome page provides a “Sign in” button to allow a user to log in to the IDST system, and an

entry point (link) into the main IDST itself.

This page will therefore only require HTTP access, whilst the main IDST pages will be secured under

HTTPS and authenticated by a user login session. The user login pages are described in the following

sections.



4.2.2 IDST Sign‐in Page

Figure 5: IDST Sign‐in Page

Figure 5 shows an example of how the Sign In page might appear (after the user has clicked “Sign in”

on the welcome page).

The page requests the user’s INFRARISK username and password, and signs in to the system once

the “Sign in” button is clicked.

This page would also appear at any time if a user attempted to access a secure IDST page and wasn’t

logged in at the time. The login page should then redirect the user to the page they were previously

on, otherwise (if coming from the Welcome Page), the user would be redirected to the main IDST

dashboard page (see next section).

Note that, for the actual implementation, the login feature might actually appear as a modal pop‐up

instead of a separate page, if this seems more appropriate or better in appearance for the user.



4.2.3 IDST Dashboard – Initial View

Figure 6: IDST Dashboard – Initial View

Figure 6 shows the initial view of the IDST “Dashboard”, which appears after the user has logged in.

This page (along with all other secure IDST pages) will show the logged in user (e.g. “Infrastructure

Manager 1”, and provide a “Log out” button, which would log the user out of the IDST and return to

the welcome page.

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). However, after

logging in for the first time (after creating an account), this initial Dashboard view will guide the user

to 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,

for example showing a quick overview of the general state of the user’s managed infrastructure.

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‐MGIF), or access other

tools and services (to be defined).



4.2.4 IDST: New Case Study – General Settings

Figure 7 IDST: New Case Study – General Settings

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 shown in Figure 7; here the user would enter

some general details about the new case study, for example its name, then click “Next” to pass to

the System Definition phase.

The phases indicated in the view follow the convention of the ORMF stages, i.e.

System Definition

Risk Identification

Risk Analysis

Although not shown in this mockup, the user would not be able to navigate to the Risk Identification

or Risk Analysis stages before setting up the System Definition (i.e. the options would be initially

disabled).



4.2.5 IDST System Definition: Locating a Region of Interest

Figure 8: IDST System Definition: Locating a Region of Interest

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

Elements. These are shown as separate tabs in Figure 8.

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

to locate the region of interest for the case study.11 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.).

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



4.2.6 IDST System Definition: Locating a Region of Interest (zoomed view)

Figure 9: IDST System Definition: Locating a Region of Interest (zoomed view)

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

this mockup, 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.



4.2.7 IDST System Definition: Defining a Region of Interest (Spatial Boundary)

Figure 10: IDST System Definition: Defining a Region of Interest (Spatial Boundary)

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

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

afterwards, to fine‐tune the region.12

The user can then use the “Zoom into region” option to expand the map to fully show the region of

interest.

12 For the initial IDST prototype, we may have a pre‐defined region of interest, which could be selected perhaps from a drop‐down list.



4.2.8 IDST System Definition: Region of Interest (zoomed in) and Temporal Boundaries

Figure 11: IDST System Definition: Region of Interest (zoomed in) and Temporal Boundaries

Figure 11 shows the zoomed region of interest (after clicking “Zoom into region”). The user would

then see an opposite option, “Zoom out of region”, to see more of the surrounding area again.

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

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

assessment (in days, months, years, etc.). Other temporal boundary parameters might be entered

here (to be defined).



4.2.9 IDST System Definition: Defining the System Elements

Figure 12: IDST System Definition: Defining the System Elements

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

to start defining these (as shown in Figure 12).

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

system elements (via selections in drop‐down lists):

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

Hazard event (e.g. flood, earthquake)

Infrastructure event (e.g. Rio Torte bridge)

Network event (e.g. traffic interruption)

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

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

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

administrator). Initial discussions on this mockup suggest that a more graphical way of selecting an

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

Once the System Elements have been defined, the user proceeds to the Risk Identification stage.



4.2.10 IDST Risk Identification: Initial View for Scenario 1

Figure 13: IDST Risk Identification: Initial View for Scenario 1

Figure 13 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 allowing details to be view

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

At this initial stage, no parameter values are indicated in the view (for example the depth of the

rainfall). The following section shows the behavior when a user clicks on the “Rainfall” event.



4.2.11 IDST Risk Identification: Editing a Source Event

Figure 14: IDST Risk Identification: Editing a Source Event

After clicking the “Rainfall” event, the “Edit Source Event” panel pops up, as shown in Figure 14.

Here, the user must define the Intensity of the rainfall event, then click “Save”. Other associated

parameters may be required to be displayed here, so they can be edited (to be further discussed

with partners).



4.2.12 IDST Risk Identification: Edited Source Event

Figure 15: IDST Risk Identification: Edited Source Event

Figure 15 shows an edited source event. Here, the rainfall intensity has been set, and is displayed for

convenience in the box as “Rainfall, 100 yr”.



4.2.13 IDST Risk Identification: Defining a New Source Event

Figure 16: IDST Risk Identification: Defining a New Source Event

New source events may also be added, via the “New Source” link. On clicking this link, the “New

Source Event” panel pops up, as shown in Figure 16. This is virtually identical to the display for

editing a source event (see Figure 14). Here, a user might add another rainfall event, or perhaps a

“tectonic plate movement” event, for example, along with associated parameters for this. Clicking

“Save” would save this new source event to the IDST database, and display this below the “Rainfall,

100 yr” event.

As for every pop‐up panel, by clicking “Cancel”, any editing or creation of a new object will be

cancelled, as expected.



4.2.14 IDST Risk Identification: Editing a Hazard Event

Figure 17: IDST Risk Identification: Editing a Hazard Event

Similar to editing a source, each system element may be edited. Figure 17 shows an equivalent pop‐

up panel for editing a hazard event. The type of event (in this case “flood” would normally not be

changed, but this is possible if required). Note that the exact definition of “Intensity” will vary

between different types of hazard. For example, for a flood, this can be measured as a height (in

cm). For an earthquake, the intensity could be measured as a value on the Richter scale.

By changing the type of hazard event, the Intensity drop‐down will be automatically updated to

include the appropriate values.



4.2.15 IDST Risk Identification: Edited Hazard Event

Figure 18: IDST Risk Identification: Edited Hazard Event

Figure shows an edited hazard, “Flood > 30cm”.



4.2.16 IDST Risk Identification: Adding a New Hazard Event

Figure 19: IDST Risk Identification: Adding a New Hazard Event

As for source events, new hazard events may be added in a similar way (see Figure 19), via the “New

hazard” link. The form controls are the same as for editing a hazard. Upon clicking “Save”, this new

hazard will be stored in the IDST database, and displayed below the “Flood > 30cm” event (see

Figure 20).



4.2.17 IDST Risk Identification: New Hazard Event Added

Figure 20: IDST Risk Identification: New Hazard Event Added

Figure 20 shows a newly added hazard event, “Flood > 60cm”. The event is linked automatically to

the current source event (“Rainfall, 100 yr”). In a similar way, other flood events (with different

intensities) may be added to the tree. These are generally chosen by the infrastructure manager as

distinct events that have different consequences (e.g. a flood of >30cm might cause some

infrastructure damage, whilst a flood of >60cm might cause a bridge collapse).



4.2.18 IDST Risk Identification: Adding a New Infrastructure Event

Figure 21: IDST Risk Identification: Adding a New Infrastructure Event

Similarly to other types of event, Infrastructure Events may be added via the “New Infrastructure”

link. This displays a pop‐up as shown in Figure 21. An Infrastructure “Event” actually refers to a

specific piece of infrastructure being put into a particular state of repair (e.g. “no damage”,

“damage” or “collapse”). Upon clicking “Save”, this new infrastructure event will be stored in the

IDST database, and displayed below the last displayed infrastructure event.



4.2.19 IDST Risk Identification: New Infrastructure Event Added

Figure 22: IDST Risk Identification: New Infrastructure Event Added

Figure 22 shows two distinct infrastructure events, “Rio Torte, damage” and “Rio Torte, collapse”, as

caused by their preceding (different) hazard events. Further infrastructure events may be added in a

similar way.

Note that, at the time of writing, initial discussions with partners suggest that the selection of

infrastructure events could be more graphically based (in addition to the selection method shown

here). For example, the user might locate infrastructure elements instead on a pop‐up map. These

ideas will be discussed and developed further in the coming months. However, for the IDST v1.0, the

functionality displayed here will at least be available.



4.2.20 IDST Risk Analysis

Figure 23: IDST Risk Analysis

Once the user has set up their scenarios, within the “Risk Identification” stage, they would click on

“Risk Analysis”, in order to perform this stage of the ORMF process (see Figure 23). At the time of

writing, the exact form of this functionality and display for the user is at the early discussion stage,

and will be further developed in the next few months, as the first prototype is coming together.



5 CONCLUSION

The current document, which focuses on the IDST system specification, shall lead to the

development of the first version of the IDST software in INFRARISK. Following several consultations

with the partners, domain knowledge experts and end users, the INFRARISK WP7 work has led to the

overall design of the IDST system. The system is a decision‐support tool which will enable a user 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 and outputs from INFRARISK

databases and modelling tools, which are being developed in various project Work‐Packages (WP2,

3, 5, 6). The integration of such modules is the main challenge, while the end result shall be of

paramount importance for capturing the cascading effects of natural hazards with multiple risks on

CIs. The IDST system also captures the overarching multiple risk harmonization approach developed

in WP4 to provide a common platform for crisis management experts to achieve sound strategies for

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

5.1 IDST Future Development

The post specification phase of this current work will involve, imminently, the development of the

first version of the IDST software, based on the specifications within this current document.

However, further comments from the end‐users on the IDST mock‐up designs will be discussed

within WP7 and factored into software designs in an agile way. The early prototype version of the

IDST (version 1.0) will be consequently developed (by M18). Furthermore, new consultations with

domain experts and end‐users will resume for the advanced software design of IDST version 2.0 (to

be documented in D7.2 by M24). In this sense, the current document represents an evolving

specification document of the IDST until it is finalized at the end of year 2 in the project (M24).



6 REFERENCES

Adey, B.T., Hackl, J., Heitzler, M., Iosifescu, I. (2014). INFRARISK D4.1: Preliminary Model, Methodology and Information Exchange.

Argyroudis, S., Kaynia, A. M. (2014). Fragility Functions of Highway and Railway Infrastructure, In: SYNER‐G ‐ Typology Definition and Fragility Functions for Physical Elements at Seismic Risk (Pitilakis, K., Crowley, H., Kaynia, A., eds), Springer Netherlands.

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.

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

R Development Core Team (2006). R: A Language and Environment for Statistical Computing. R Foundation for Statistical Computing, Vienna.

Silva, V., Crowley, H., Colombi, M. (2014). Fragility Function Manager Tool, In: SYNER‐G ‐ Typology Definition and Fragility Functions for Physical Elements at Seismic Risk (Pitilakis, K., Crowley, H., Kaynia, A. M., eds), Springer Netherlands.

SYNER‐G (2009‐2013). Systemic Seismic Vulnerability and Risk Analysis for Buildings, Lifeline Networks and Infrastructures Safety Gain, FP7 Project coordinated by K. Pitilakis, Aristotle University of Thessaloniki.

Documents

Deliverable D7.1 IDST System Specification v1 › sites › default › files › docs › INFRARISK...Rev01 08/09/2014 Draft structure/TOC Ken Meacham and Zoheir Sabeur (IT Innovation)