sifra documentation

SIFRA DocumentationRelease 0.1.1

Maruf Rahman

Jul 10, 2017

Contents

1 Features 3

2 Contents 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Model Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Installation and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Component Fragility Attribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 License 23

Bibliography 25

i

SIFRA Documentation, Release 0.1.1

https://github.com/GeoscienceAustralia/sifra Release: 0.1.1

SIFRA is a System for Infrastructure Facility Resilience Analysis. It comprises a method and software toolsthat provide a framework for simulating the fragility of infrastructure facilities to natural hazards, based on as-sessment of the fragilities and configuration of components that comprise the facility. Currently the system isdesigned to work with earthquake hazards only. However, in the development of the methodology and classes,there is a strong emphasis on making the hazard attribution process and infrastructure models flexible to allow forexpansion to other hazards and new infrastructure sectors.

SIFRA was developed in Geoscience Australia (GA) in support of the agency’s vision to contribute to enhancingthe resilience of communities in Australia and its region.

Contents 1

https://github.com/GeoscienceAustralia/sifra

http://www.ga.gov.au/


2 Contents

CHAPTER 1

Features

• Written in Python:

It is written in Python, and there is no dependency on proprietary tools. It should run on OS X, Windows,and Linux platforms.

• Flexible Facility Model:

Facility data model is based on graph theory, allowing the user to develop arbitrarily complex custom facilitymodels for simulation.

• Extensible Component Library:

User can define new instances of component_type (the building blocks of a facility) and link it to existingor custom fragility algorithms.

• Component Criticality Analysis:

Scenario Analysis tools allow users to identify the cost of restoration for chosen scenarios, expected restora-tion times, and which component upgrades can most benefit the system.

• Restoration Prognosis:

User can experiment with different levels of hazards and post-disaster resource allocation to gauge restora-tion times for facility operations.

3


4 Chapter 1. Features

CHAPTER 2

Contents

2.1 Introduction

Critical infrastructure facilities typically comprise a number of interconnected components that work in concertto deliver a service. In the context of natural hazard vulnerability, the components have differing susceptibilities,require different resource levels and time to repair, and have a range of criticalities to the overall service delivery.The vulnerability of the facility, then, is a complex convolution of all these components and factors.

SIFRA stands for System for Infrastructure Facility Resilience Analysis. It comprises a method and softwaretools that provide a framework for simulating the fragility of infrastructure facilities to natural hazards, based onassessment of the fragilities and configuration of components that comprises the facility. Currently the system isdesigned to work with earthquake hazards only. SIFRA enables the vulnerabilities of each element to be integratedinto an assessment of the implications of severe hazard exposure to facility damage, service disruption and cost.

SIFRA is used to model the vulnerability of high-value infrastructure facilities to natural hazards. Earthquakeground motion is the present focus and many uncertainties are captured through a Monte Carlo sampling process.The tool not only enables current facility vulnerability to be quantified, but also enables the most vulnerablecomponents to be identified in terms of repair cost, time to recovery, and service disruption implications. Theoutcomes also support benefit versus cost studies of retrofit options. Ultimately, it provides information thatsupports asset managers in regards to the most cost-effective utilisation of limited retrofit resources. Vulnerabilityof a facility is modelled by assigning fragilities to the individual components that make up a facility. The programaccounts for variability in component fragilities by sampling probability distributions for the each fragility curvemedian and beta values. Once values have been selected for each curve it checks that fragility curves do notoverlap and if they do, re-samples the median and beta probability distributions until non-overlapping fragilitycurves are produced.

Damage scales for several assets, and method for estimating recovery times have been taken from HAZUS [5].Repair cost (and hence damage index) and recovery times for each component are customised for each asset type,based on consultation with assets operators. The threshold values of spectral acceleration for each of four damagestates are sampled by randomly sampling the fragility curves described above.

Hazard modelling is done externally using other applications, and provided to this tool as an input.

Currently only peak ground acceleration can be accepted by the system, but this is to be expanded in the nearfuture.

5


2.2 Model Concepts

SIFRA provides a modelling framework and software tools for assessing impact of natural hazards on infrastruc-ture systems. Infrastructure systems, within this framework, refer to facilities and networks that provide essentialutility services for communities, regions and/or a country. This will include electricity generation and transmis-sion, water and wastewater treatment and reticulation, and transport networks. It excludes standalone high-valuebuildings and manufacturing plants. The SIFRA project also deliberately eschews an exclusive focus on “critical”infrastructure, as that invites unnecessary debates on criteria of criticality and jurisdiction for that class of assets.

2.2.1 The ‘System’ Model and Related Vocabulary

The central idea in the SIFRA modelling construct is this: All lifeline infrastructure ‘systems’ within the modellingframework are conceptualised as a network of interconnected nodes.

The ‘nodes’ or vertices and connecting edges have different meaning based on the level of abstraction, which isclarified in following subsections.

This modelling approach affords a very high degree of flexibility and scalability, making it possible accommodatediverse sectors and assets of varying scales and complexities.

Furthermore, it allows the user to: (a) model the effect of impaired or destroyed components on the operationalcapacity of the overall system; (b) use graph theory to assess the graduated capacity degradation, and restoration,through modelling flow through the network; and (c) detect prioritised ‘paths’, or sets of components, withinnetwork that need to be repaired or restored in order to restore the flow through the network which represents theproductive capacity of the system.

Hierarchy of Elements within a As-Built Infrastructure System

The elements in an infrastructure (or lifeline) system are conceptualised as being structured in a three-level hier-archy:

Level 1 [Infrastructure Network] This is the top level of interconnected infrastructure systems where infras-tructure facilities are connected to form a network or networks.

Level 2 [Infrastructure Facility] The concept of facilities used in this framework map closely to the typologyof macro-components as defined in the Synerg-G program [6][7], and align with the definition systems asdefined in [8].

Level 3 [Infrastructure Microcomponent] This concept of components map closely to the typology of micro-components as defined in the Synerg-G program [6][7], and align with the definition of subsystems asdefined in [8].

This applies to discussions on a complete that is responsible for delivering some service. This also applies toclassification of assets, and how information about those assets they are stored and referenced in a database.

Hierarchy and Terminology for a Model of an Infrastructure System

In the context of a specific infrastructure model developed for hazard impact assessment, the following terms andideas apply (and are implemented in the simulation code).

The System Model This defines a logical set of assets that is an abstraction of a real equivalent asset. The usageof the term system in this context is closer to its application in System Engineering, rather than from an ITor software engineering perspective. The System Model defines the boundary of the collection of elementsunder investigation. It is the collection of nodes and connecting edges that collectively provides a serviceor generates a type of product. This term can be used to refer to a network or a facility. The context of thesimulation will disambiguate its meaning.

Component It is the high-level element within the network (or graph) that represents the System Model. A col-lection of interconnected components with specific attributes and roles comprise the System in the contextof the simulation model.

6 Chapter 2. Contents


If the subject of investigation is a Network then in the context that specific exercise: the System Model is aLevel 1 element, i.e. an Infrastructure Network, and the Components are Level 2 elements, i.e. Infras-tructure Facilities

If the subject of investigation is a Facility then in the context that specific exercise: the System Model is aLevel 2 element, i.e. an Infrastructure Facility, and the Components are Level 3 elements, i.e. anInfrastructure Microcomponents

Classification of Nodes within a Model of an Infrastructure System

For a specific impact assessment project, the Components within the System Model are represented as nodes.Based on their role within the system, these nodes (or components or vertices) are classified in four categories:

1. Supply nodes: These nodes represent the entry points into the system for required inputs or commodities.As for example, coal and water can be the required ‘commodities’ into a thermal power station. In the caseof the substation, required input is electricity from power stations or other substations.

2. Output nodes: These nodes represent the exit points for the output of the system. For example, in the caseof the power station, the output nodes act as dummy loads - representing the energy consumers - connectedto each of the step-up transformers. The sum of flow through the network measured at the output nodesrepresented the effective production (or operational) capacity of the facility.

3. Dependency nodes: These nodes represent the components that do not directly participate in the productionprocess of the system, or in the handling of system inputs, but are critical for system operations in someother capacity, e.g. system management or monitoring. The control building of a substation is an exampleof this.

4. Transhipment nodes: These are nodes that transform, transport, or store system inputs to give effect toprocesses that produces the outputs required of the system. Majority of the nodes within a system fall intothis category.

The component configuration and redundancies are captured as edges connecting the nodes. Constraints on flowthrough specific paths, or sets of nodes, can be represented as capacities of edges connecting those nodes. Figure2.1 illustrates this concept for a thermal power station.

Fig. 2.1: Schematic representation of a coal-fired power station

The ‘edges’, or inter-nodal connections, represent a link or a process for maintaining ‘flow’ of goods or serviceswithin the system, and thus their directionality is important. For the power station, the edges are unidirectional,since the inputs flow in one direction starting from the entry point into the system and are progressively trans-formed through the system to generate energy – the end product. However, a substation is an electrical networkwhere electricity – the system ‘commodity’ – can flow in either direction through an edge (electrical conductor) asdictated by load demands and system constraints. Therefore, most of the edges in the substation are bidirectional,unless specifically constrained.

2.2. Model Concepts 7


Connection paths and ‘production capacities’ along those paths within a system are calculated as the maximumflow through those paths. The igraph Python package was used as the network modelling platform to calculategraph metrics for a post-hazard damaged system model.

2.2.2 System Loss Modelling

For a given value of level of ground shaking, a set of random samples is generated, and the damage state of eachcomponent is calculated for each random sample based on the fragility function of the given component. Giventhe assessed damage state of all the system components, the system functionality is assessed and system outputlevel calculated. This process is run through a Monte Carlo process for the set of random samples to assess thesystem response at the selected ground shaking intensity. To obtain a characterisation of the system and developfragility algorithms for the system (e.g. the power station) the process is repeated for a range of PGA values. ThisProcess is shown in Figure 2.2.

Fig. 2.2: Schematic of process linking component damage assessment to loss projection

Four discrete sequential damage states are used for assessing system fragility, similar to those used in HAZUS(FEMA 2003): DS1 Slight, DS2 Moderate, DS3 Extensive, DS4 Complete. The damage scale used for a powerstation is based on ranges of economic loss as a percentage of total system value.

The probability of a component exceeding damage state 𝑑𝑠 is calculated using the log-normal cumulative distri-bution function (CDF) as shown in equation below, for a PGA value of 𝑥 g:

𝑃 [𝐷𝑠 | 𝑃𝐺𝐴 = 𝑥] = Φ

(︂𝑙𝑛(𝑥) − 𝜇𝑙𝑛𝑋

𝜎𝑙𝑛𝑋

)︂= Φ

(︂𝑙𝑛(𝑥) − 𝜇𝜃

𝛽

)︂where, 𝜃 = median, and 𝛽 = logarithmic standard deviation.

For a component in damage state 𝑑𝑠𝑖, the corresponding loss is calculated as:

𝐿𝐶,𝑑𝑠𝑖 = 𝑅𝐶,𝑑𝑠𝑖 × 𝐶𝐹𝐶

where, 𝑅𝐶,𝑑𝑠𝑖 = d is the damage ratio for component C at damage state 𝑑𝑠𝑖, and 𝐶𝐹𝐶 = cost of component C asa proportional of total system cost.

2.2.3 System Restoration Model

The restoration algorithms are defined as normal functions. An approximation of mean restoration time for eachcomponent at each damage level is attributed. The structural damage level definitions associated with the dam-age states are central to establishing a common understanding to facilitate the development of the restorationparameters.


http://igraph.org/python/


The functionality 𝐹𝐶 of component C at t time units after impact of an earthquake of PGA=x is calculated as aweighted combination of the probability of the components being in each of the S sequential damage states usedin the model and the estimated recovery at time t for the components based of the restoration model:

𝐹𝐶|𝑥 =

𝑆∑︁𝑖=0

𝑃 [𝑑𝑠𝑖 | 𝑃𝐺𝐴 = 𝑥] ×𝑅𝑖[𝑡]

where, 𝑖 is the index of the damage state, {𝑖 ∈ Z | 0 ≤ 𝑖 ≤ 𝑆}. The ‘None’ damage state is 𝑖 = 0, and 𝑖 = 𝑆 isthe complete or highest modelled damage state. 𝑅𝑖[𝑡] is the likely level of restoration of functionality at time 𝑡 .Restoration level 𝑅𝑖 can take on any value in the unit interval [0,1].

The simulation of the restoration prognosis is conducted based on a set of inputs and assumptions. The requireddata inputs to this process are:

• The system configuration

• The modelled scenario - seismic intensity value

• Impact simulation results - system component losses

• Restoration priority list - the order at which output lines should be recovered

The process assumes that restoration is undertaken in stages, subject to the level of resources that can be madeavailable and the order of repairs. In regard to this, the concept of ‘Restoration Streams’ is used–the maximumnumber of components that can be worked on simultaneously. This is effectively a proxy representing the de-ployment of trained personnel and material for the repair tasks. Additional optional offsets can be factored in tocapture specific contexts:

1. Restoration Offset – this is a time allowance for assessment of damage to the system and for securing thesite to assure it is safe for commencement of repairs;

2. Testing and Commission Interval: this is a time allowance for testing conformity with operational and safetyparameters for the system, or a part thereof.

Given a set of restoration parameters and the restoration plan, the consequent restoration time is calculated asfollows:

1. Test if there is any available path between the set of required input nodes (i.e. supply nodes) and the outputnode assigned the highest priority to meet the demand at that node.

2. If no functional path is found, then identify the least expensive path(s) that needs to be restored to meetdemand at the output node. Within each path, identify the functional status of the nodes (components), andgenerate a repair list.

3. Iterate through the ordered output list, repeating steps 1 and 2 above. Update the component repair list andproduce a complete prioritised list of components to repair or replace.

4. Simulate an ordered restoration process based on the above list and user-specified resource constraints. Ifthe process is using x resource constraints, then whenever a component is restored (and the number ofunrepaired components is x), the next component is added to the active repair list, so that at any one time xrepair tasks are in progress. This process is repeated until all the paths are restored, i.e. until system outputcapacity is restored to normal levels.

In order to restore full capacity at an output node, it may be necessary to restore more than one path, i.e. connectan output node to multiple input nodes. This can be understood through some simple examples. If the facility inquestion is a thermal power station, the functioning of the generator depends on both the supply of fuel (as thesource of energy to be transformed) and water (for cooling and for steam production to drive the turbines). In caseof a substation, a certain output node may have a demand of 300MW, but it might be that there are four incominglines each bringing in bringing in 100MW of electricity from power plants. In this case, the designated outputnode must be linked to at least three of the input/supply nodes to meet its demand.

In addition to the core process of approximating restoration time, a routine for simulating component cannibali-sation within a facility or system has also been incorporated. Here we use cannibalisation to refer to an exercisewhereby an operator may move an undamaged component from a low priority or redundant line to replace a dam-aged component on a high priority line. This exercise may allow the operator to eliminate the potentially long

2.2. Model Concepts 9


procurement or transportation time for a replacement unit, and thereby expedite the restoration of the high prioritylines.

The outputs from the restoration model are:

1. a simple Gantt chart with each component needing repair,

2. restoration plot for each output line over time and the associated percentage of total system capacity reha-bilitated, and

3. total restoration time for each output line for a given restoration scheme.

2.3 Installation and Usage

2.3.1 Requirements

SIFRA is built in Python 2.7. Python hardware requirements are fairly minimal. Most modern systems based onx86 architecture should be able to run this software.

SIFRA has been tested on the following operating systems:

• OS X 10.11

• Ubuntu 14.04 (64 bit)

• Windows 10

The code should work on most other versions of these operating systems, though the environment setup processwill likely have some differences. Windows systems that are not based on the NT-platform are not supported. Thisrestriction is due to the fact that from version 2.6 onwards Python has not supported non-NT Windows platforms.

You will need to install Graphviz, which is used by networkx and pygraphviz packages to draw the system diagram.Please visit: http://www.graphviz.org/ and download the appropriate version for your operating system. Followthe posted download instructions carefully. After installation you may need to update the PATH variable with thelocation of the Graphviz binaries.

For windows systems you will need to install Microsoft Visual C++ Compiler for Python 2.7: http://aka.ms/vcpython27

2.3.2 Setting Up a Development Environment

We recommend using conda for managing virtual environments and packages required for running sifra.

For the sake of simplicity, we recommend using Anaconda. It is a free Python distribution, and comes with theconda tool which is both a package manager and environment manager. Instructions for installing Anacondaare here.

Some packages we need are not hosted in the main conda package repository. In such cases we will host themin our own user channel. We suggest adding the following channels to the default:

conda config --add channels https://conda.anaconda.org/anacondaconda config --add channels https://conda.anaconda.org/marufr

Run the following command to confirm the additional channels have been added:

conda config –get channels

For OS X and Linux-64 systems: It should be possible to set up a full run environment solely through the *.ymlenvironment specification file. For OS X run the following commands:

conda env create -f environment_osx.ymlsource activate sifra_env


http://www.graphviz.org/

http://aka.ms/vcpython27

http://aka.ms/vcpython27

http://docs.continuum.io/anaconda/install


For Linux-64 systems, the commands are identical, you will just need to use the environment specification file forLinux.

For Windows systems, a similar process needs to be followed, with some exceptions. First run:

conda env create -f environment_win64.ymlactivate sifra_env

This will install most requirements except for igraph and pygraphviz. Compiling these packages underwindows can be very challenging. The simplest and most reliable option is to download the the appropriate binarydistribution in the form of wheels from Christoph Gohlke’s unofficial page of Windows binaries.

Download the appropriate wheels (*.whl files) of the following packages for your Windows platform (32 or 64bit):

• python-igraph

• pygraphviz.

Install the downloaded wheels (*.whl files) with pip:

pip install <pkg_name>.whl

2.3.3 Running the Core SIFRA Code

For the purposes of discussion, it is assumed that the name of the configuration file is config_x.conf, and itis located in the directory /Users/user_x/sifra/simulation_setup/.

The software can be run from the command line using these simple steps:

1. Open a command terminal

2. Change to the directory that has the sifra code. If the code is in the directorty /Users/user_x/sifra, then run:

cd ~/sifra/

3. Run the primary fragility characterisation module from the command line:

python -m sifra simulation_setup/config_x.conf

The post-processing tools are run as simple python scripts. It should be noted, that the post-processing toolsdepend on the outputs produced by a full simulation run that characterises the system fragility. Therefore, theafull run of the SIFRA needs to be conducted on the system model of interest prior to running the tools for modelfitting and scenario and restoration analysis tools. They are simply run as:

cd ~/sifra/sifra/python fit_model.py ../simulation_setup/config_x.confpython scenario_loss_analysis.py ../simulation_setup/config_x.conf

2.3.4 Running Code Tests

To run tests use either nose or unittest. Example (from the first level ‘sifra’ directory):

cd sifra # and not cd sifra/sifrapython -m unittest discover tests

or, simply run:

nosetest

2.3. Installation and Usage 11

http://www.lfd.uci.edu/~gohlke/pythonlibs/

http://www.lfd.uci.edu/~gohlke/pythonlibs/#python-igraph

http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygraphviz


2.4 Simulation Setup

Setting a simulation requires populating two different sets of inputs:

• Scenario configuration

• Facility system configuration

These two sets of input data are contained in two separate files. These files, their parameters, data layout, andsample input data are presented in the remainder of this Section. In the course of the discussion it should be usefulto the keep the directory structure of the code in mind:

.LICENSE <-- License file: Apache 2README.md <-- Summary documentation

docs <-- Sphinx documentation filessource

_static_templatesextensions

models <-- Facility system models reside here<facility_type> <-- Dir for models of specified type

output <-- Simulation results are stored herescenario_X <-- Simulation project name

raw_output <-- Raw data/binary outputs for provenance &post-processing

sifra <-- The MODULES/SCRIPTSsimulation_setup <-- Scenario config filestests <-- Test scripts

2.4.1 Scenario Definition File

The simulation ‘scenario’ definition file is located in the following directory (relative to the root dir of sourcecode):

./simulation_setup/

The following table lists the parameters in the config file, their description, and representative values.

INTENSITY_MEASURE_PARAM

Description Engineering Demand Parameter

Data Type String

Example ‘PGA’

INTENSITY_MEASURE_UNIT

Description Demand Parameter Unit

Data Type String

Example ‘g’

PGA_MIN

Description Minimum value for PGA

Data Type Float

Example 0.0



PGA_MAX

Description Maximum value for PGA

Data Type Float

Example 1.5

PGA_STEP

Description Step size for incrementing PGA

Data Type Float

Example 0.01

NUM_SAMPLES

Description Iterations for Monte Carlo process

Data Type Integer

Example 500

SCENARIO_HAZARD_VALUES

Description The value(s) at which to assess facility response

Data Type List of floats

Example [0.50, 0.55]

TIME_UNIT

Description Unit of time for restoration time calculations

Data Type String

Example ‘week’

RESTORE_PCT_CHKPOINTS

Description Number of steps to assess functionality

Data Type Integer

Example 21

RESTORE_TIME_STEP

Description Time increment for restoration period

Data Type Integer

Example 1

RESTORE_TIME_MAX

Description Maximum value for restoration period assessment

Data Type Integer

Example 300

RESTORATION_STREAMS

Description The number of simultaneous components to work on

Data Type List of integers

Example [5, 10, 20]

SYSTEM_CLASSES

Description The allowed facility system types

Data Type List of strings

2.4. Simulation Setup 13


Example [‘PowerStation’, ‘Substation’]

SYSTEM_CLASS

Description The facility system type to be modelled

Data Type String

Example ‘PowerStation’

SYSTEM_SUBCLASS

Description Sub-category of system

Data Type String

Example ‘Coal Fired’

COMMODITY_FLOW_TYPES

Description Number of input commodity types

Data Type Integer

Example 2

SYS_CONF_FILE_NAME

Description File name for system config and fragility info

Data Type String

Example ‘sys_config_ps.xlsx’

INPUT_DIR_NAME

Description File path relative to code root

Data Type String

Example ‘data/ps_coal/input’

OUTPUT_DIR_NAME

Description File path relative to code root

Data Type String

Example ‘data/ps_coal/output’

FIT_PE_DATA

Description Flag for fitting Prob of Exceedance data

Data Type Boolean

Example True

FIT_RESTORATION_DATA

Description Fit model to simulated restoration data

Data Type Boolean

Example True

SAVE_VARS_NPY

Description Switch to indicate whether to save simulated values in binary numpy format

Data Type Boolean

Example True

MULTIPROCESS

Description Switch to indicate whether to use multi-core processing. 0 → False, 1 → True



Data Type Integer

Example 1

RUN_CONTEXT

Description Switch to indicate whether to run a full simulation, or run test code. 0 → run tests,1 → normal run.

Data Type Integer

Example 1

2.4.2 Facility Definition File

The system definition files for a facility of type <facility_type_A> is located in the following directory(relative to the root dir of source code):

./models/<facility_type_A>/

The system model is defined using an MS Excel spreadsheet file. It contains five worksheets. The names of theworksheets are fixed. The function and format of these worksheets are described in the following subsections:

List of Component: component_list

The component_list has the following parameters:

component_id

Description Unique id for component in system. This is an instance of component_type

Data Type String. It is recommended to use alphanumeric characters, starting with a letter, andlogically distinct parts of the name separated by underscores

Example ‘stack_1’

component_type

Description The typology of a system component. Represents a broad category of equipment.

Data Type String. It is recommended to use alphanumeric characters, starting with a letter, andlogically distinct parts of the name separated by spaces.

Example ‘Stack’

component_class

Description The general category of equipment. A number of component types can be groupedunder this, e.g. ‘Power Transformer 100MVA 230/69’ and ‘Power Transformer 50MVA230/69’ are both under the same component_class of ‘Power Transformer’

Data Type String. It is recommended to use alphanumeric characters, starting with a letter, andlogically distinct parts of the name separated by spaces.

Example ‘Emission Management’ – stacks and ash disposal systems belong to different typolo-gies, but both contribute to the function of emission management.

cost_fraction

Description Value of the component instance a fraction of the total system cost, with the totalcost being 1.0

Data Type Float. {𝑥 ∈ R | 0 ≤ 𝑥 ≤ 1}

Example 0.03

node_type



Description This indicates the role of the node (component) within network representing thesystem. For details, see Facility System Model.

Data Type String. Must be one of four values: supply, transshipment, dependency, sink

Example ‘supply’

node_cluster

Description This is an optional parameter to assist is drawing the system diagram. It indicateshow the different component instances should be grouped together.

Data Type String

Example ‘Boiler System’

op_capacity

Description Operational capacity of the component. One (1.0) indicates full functionality, andzero (0.0) indicates complete loss of functionality. Typically at the start of the simulation allcomponents would have a value of 1.0.


Example 1.0 (default value)

Connections between Components: component_connections

origin

Description The node (component) to which the tail of a directional edge is connected.

For bidirectional connections, you will need to define two edges, e.g. A → B, and B → A.For undirected graphs the origin/destination designation is immaterial.

Data Type String. Must be one of the entries in the component_id columns in the compo-nent_list table.

Example ‘stack_1’

destination

Description The node (component) on which the head of a directional edge terminates. Forundirected graphs the origin/destination designation is immaterial.

Data Type String. Must be one of the entries in the component_id columns in the compo-nent_list table.

Example ‘turbine_condenser_1’

link_capacity

Description Capacity of the edge. It can be more than the required flow.



weight

Description This parameter can be used to prioritise an edge or a series of edges (a path) overanother edge or set of edges.

Data Type Integer

Example 1 (default value)



Configuration of Supply Nodes: supply_setup

input_node

Description The component_id of the input node.

Data Type String. Must be one of the entries in the component_id columns in the compo-nent_list table, and its node_type must be supply.

Example ‘coal_supply’

input_capacity

Description The operational capacity of the node. It can be a real value value if known, ordefault to 100%.

Data Type Float. {𝑥 ∈ R | 0.0𝑥 ≤ 100.0}


capacity_fraction

Description What decimal fractional value of the input commodity enters the system throughthis input node.

Data Type Float. {𝑥 ∈ R | 0.0𝑥 ≤ 1.0}

Example 1.0

commodity_type

Description The type of commodity entering into the system through the specified input node.

Data Type String.

Example For a coal-fired power station there might be two commodities, namely coal and water.So, there will need to be at least two input nodes, one with a commodity_type of ‘coal’ andthe other with commodity_type of ‘water’.

For an electric substation the commodity_type is electricity. For a water treatment plant, itis waster water.

Configuration of Output Nodes: output_setup

output_node

Description These are the ‘sink’ nodes representing the load or the aggregate consumer of theproduct(s) of the system.

These are not real components, but a modelling construct. These nodes are not consideredin the fragility calculations.

Data Type String. Must be one of the entries in the component_id columns in the compo-nent_list table, and must be of node_type sink.

Example ‘output_1’

production_node

Description These are the real terminal nodes within the facility system model. The completed‘product’ of a system exits from this node.

Data Type String. Must be one of the entries in the component_id columns in the compo-nent_list table, and must be of node_type transshipment.

Example ‘gen_1’

output_node_capacity



Description Production capacity that the specific production node is responsible for.

The unit depends on the type of product the system produces (e.g. MW for generator plant).

Data Type Float

Example 300

capacity_fraction

Description The fraction of total production capacity of the output nodes. The sum of capacitiesof all nodes must equal 1.0.

Data Type Float {𝑥 ∈ R | 0 < 𝑥 ≤ 1}

Example 0.5

priority

Description This parameter is used to assign relative sequential priority for output/productionnodes in for the purposes of post-disaster recovery

Data Type Integer. {𝑥 ∈ Z | 1 ≤ 𝑥 ≤ 𝑛}, where n is the total number of output nodes

Example _

Component Type Damage Algorithms: comp_type_dmg_algo

component_type

Description The type of component, based on the typology definitions being used in the systemmodel.

Example: ‘Demineralisation Plant’

Data Type Alphanumeric characters. May use dashes ‘-‘ or underscores ‘_’. Avoid using spe-cial characters.

damage_state

Description The list of damage states used in defining the damage scale being modelled withinthe system.

Example: For a four-state sequential damage scale, the following damage states are used:

1. DS1 Slight

2. DS2 Moderate

3. DS3 Extensive

4. DS4 Complete

Data Type String. Fixed, pre-determined state names.

damage_function

Description The probability distribution for the damage function.

Currently only log-normal curves are used, but additional distributions can be added asrequired.

Example: ‘lognormal’

Data Type String.

mode

Description Number indicating the mode of the function. Currently can handle only unimodalor bimodal functions.

Default value is 1.



Data Type Integer [1,2]

damage_median

Description Median of the damage function. A median will need to be defined for each damagestate. It should be typically be progressively higher for more severe damage states:

𝜇𝐷𝑆1 ≤ 𝜇𝐷𝑆2 ≤ 𝜇𝐷𝑆3 ≤ 𝜇𝐷𝑆4

Data Type Float.

damage_logstd

Description Standard deviation of the damage function. It will need to be defined for eachdamage state. The value of standard deviation should be such that the curves do not overlap.

Data Type Float.

damage_ratio

Description The fractional loss of a component’s value for damage sustained at a given damagestate. This parameter links a damage state to expected direct loss of component value.

Example: Damage ratio of 0.30 for damage state “DS2 Moderate”

Data Type Float. {𝑥 ∈ R | 0.0 ≤ 𝑥}. A value of 0 indicates no loss of value, and a value of1.0 indicates complete loss. In special cases the the value of loss ratio can be greater than1.0, which indicates complete loss of component and additional cost of removal, disposal,or securing or destroyed component.

functionality

Description An unitless fractional value indicating the functional capacity of a component fora given damage state. This parameter links damage states to expected post-impact residualfunctionality of the component.

Example: A stack of a thermal power station is expected to remain fully functional (func-tionality==1), under ‘Slight’ damage state, i.e. under conditions of minor damage to struc-ture with deformation of holding down bolts and with some bracing connections.

Data Type Float. {𝑥 ∈ R | 0.0 ≤ 𝑥 ≤ 1.0}. A value of 0 indicates no loss of value, and a valueof 1.0 indicates complete loss. In special cases the the value of loss ratio can be greater than1.0, which indicates complete loss of component and additional cost of removal, disposal,or securing or destroyed component.

minimum

Description Minimum value for which the damage algorithm is applicable.

Example: The algorithms presented by Anagnos [1] for 500kV circuit breakers are onlyapplicable for PGA values of 0.15g and above, for the various noted failure modes.

Data Type Float.

sigma_1

Description The first standard deviation for a bimodal damage function.

Data Type Float, for a bimodal function. For single mode functions, use ‘NA’.

sigma_2

Description The second standard deviation for a bimodal damage function.

Data Type Float, for a bimodal function. For single mode functions, use ‘NA’.

recovery_mean

Description The mean of the recovery function. Component and system restoration time areassumed to follow the normal distribution.

Data Type Float.



recovery_std

Description The standard deviation of the recovery function. Component and system restorationtime are assumed to follow the normal distribution.

Data Type Float.

recovery_95percentile

Description Some times it is difficult to get the concept of standard deviation across to an audi-ence of infrastructure experts, and hence it is difficult to get a reliable value for it. In suchcases we can obtain a 95th percentile value for recovery time, and translate that to standarddeviation for a normal distribution using the following equation:

𝑋0.95 = 𝜇 + 𝑍0.95𝜎 (2.1)

⇒𝑋0.95 = 𝜇 + Φ−1(0.95)𝜎(2.2)

⇒𝜎 =𝑋0.95 − 𝜇

Φ−1(0.95)(2.3)

Data Type Float

fragility_source

Description Which source the fragility algorithm was adopted from, how it was adapted, or howit was developed.

Data Type Free text

Definition of Damage States: damage_state_def

This table documents the physical damage characteristics that are implied by the damage states used to model thefragility of the system components.

component_type The entries here are the same as noted under component_type in the ‘Component Type DamageAlgorithms’ table.

damage_state The entries here are the same as noted under damage_state in the ‘Component Type DamageAlgorithms’ table.

damage_state_definitions

Description The physical damage descriptors corresponding to the damage states.

Example: 230 kV Current Transformers would be said to be in Failure state if there is“porcelain cracking, or overturning.”

Data Type Free text.

2.5 Component Fragility Attribution

As earthquake induced ground shaking at a facility increases in intensity, the individual components respond andsustain progressively more damage. Fragility functions are used to define this susceptibility of components todamage by quantifying the likelihood that a level of damage will be exceeded for a given level of shaking. Thisapproach entails the definition of one or more earthquake damage states for each component and the selection ofa ground shaking measure that is highly correlated to the component damage.

Each component within a facility is strictly unique. However, for a given component it can be classed into acategory of asset referred to as a component type, in which all components have similar vulnerability. Theassignment of component type fragility algorithms for each damage state is based on asset typology and thedesign levels under consideration. The fragility algorithm defines a cumulative probability of exceedance foreach damage state that captures the variability of the vulnerability within a “component type” and the effect ofvariability in component response to ground motion on damage severity. The form of these functions can take a



range of mathematical forms. The most common form is log normal and defined by a median (𝜃) and log standarddeviation (𝛽), which is the form that SIFRA uses.

Component type fragility models need to be representative of the assets they characterise. Models can be devel-oped or sourced using the following hierarchy of approaches which is in order of increasing uncertainty:

1. Direct consultation with industry asset managers to reach agreement on component fragilities by adjustingthe most appropriate published models and drawing upon construction specifications, manufacturer’s shaketable proof testing (if available) and observed earthquake performance (if possible).

2. Selection of the most applicable model from published models in the literature.

3. Utilisation of heuristic engineering judgment in adapting damage models for other components assessed tohave similar fragility. There are many fragility models published in the literature. The literature review andmodel compilation produced by the Syner-G Project [7]. sponsored by the European Commission presentsa wide range of electricity sector component models. Its key references included works by Vanzi [12],Anagnos [1] and the HAZUS Technical Manual [5]. HAZUS includes fragility functions for a wider rangeof facility components than those presented in the Syner-G Project.

Each damage state has a description of the typical severity of physical component damage which has implicationsfor the use of the component. Hence, each damage state also has an operational level for the damaged component,a cost to repair (as a proportion of the replacement cost) and a resource requirement in terms of number oftechnicians and time. This is used to assess the utility of the facility immediately after an extreme event and toassess the restoration prognosis.

2.6 Glossary

acceleration Rate of change of velocity with time.

Acceleration Response Spectrum A graphical plot of the maximum acceleration that structures having differentcharacteristics will experience when subjected to a specific earthquake ground motion.

amplitude The maximum value of a time-varying quantity.

critical infrastructure Critical Infrastructure are “those physical facilities, supply chains, information technolo-gies and communication networks which, if destroyed, degraded or rendered unavailable for an extendedperiod, would significantly impact on the social or economic wellbeing of the nation or affect Australia’sability to conduct national defence and ensure national security.” Attorney General’s Department, Com-monwealth of Australia (2015). Critical Infrastructure Resilience Strategy: Policy Statement, pg 3. Source:http://www.tisn.gov.au/Pages/default.aspx

facility In this document facility is used as a shorthand for critical infrastructure (CI) facility. CI Facilities arephysical structures with collection of components that work as a system and act as hubs for generation,processing, transmission, distribution, storage of lifeline products and services. These are high-value assetsthat are essential for the proper functioning of the CI networks and for the provisioning of essential services.

fragility Fragility “implies easily damaged or broken, but is often used to describe the probability of a statedlevel of damage for a specific hazard, e.g. an earthquake.” Fragility measures probability.

fragility function

fragility curves Fragility function is a mathematical function that expresses the relationship between the proba-bility of occurrence of some undesirable event and some measure of environmental excitation. In our casethe the undesirable event is a facility or component reaching or exceeding some clearly defined limit state,and the environmental excitation is an earthquake of a defined intensity measure.

typology “a system used for putting things into groups according to how they are similar : the study of howthings can be divided into different types”. Source: http://www.merriam-webster.com/dictionary/typology

vulnerability Vulnerability refers to the concept of susceptibility of damage for a given entity. The entity can bea civil structure, a critical infrastructure facility, a component within such a facility, or a subset of populationwithin a defined geographical area, etc. Vulnerability measures loss.

2.6. Glossary 21

http://www.tisn.gov.au/Pages/default.aspx

http://www.merriam-webster.com/dictionary/typology


vulnerability function Vulnerability function is a mathematical function that depicts loss as a function of envi-ronmental excitation. It has several synonyms: vulnerability curves, damage functions, loss functions.


CHAPTER 3

License

Copyright 2016, Geoscience Australia

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliancewith the License. You may obtain a copy of the License at:

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed onan “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions and limitations under the License.

23

http://www.apache.org/licenses/LICENSE-2.0


24 Chapter 3. License

Bibliography

[1] T. Anagnos. Development of an electrical substation equipment performance database for evaluation of equip-ment fragilities. Technical Report, Department of Civil and Environmental Engineering, San Jose State Uni-versity, San Jose, USA, 1999. Prepared for the Pacific Gas and Electric Company and for the Pacific Earth-quake Engineering Research Center. URL: http://peer.berkeley.edu/publications/peer_reports/reports_2001/0106.pdf.

[2] S.V. Buldyrev, R. Parshani, G. Paul, H.E. Stanley, and S. Havlin. Catastrophic cascade of failures in interde-pendent networks. Nature, 464:1025–1028, April 2010. doi:10.1038/nature08932.

[3] Applied Technology Council. Atc-13 earthquake damage evaluation data for california. Technical Report,Applied Technology Council, Redwood City, CA, 1985.

[4] P. Jiang and Y.Y. Haimes. Risk management for leontief-based interdependent systems. Risk Analysis,24(5):1215–1229, October 2004. URL: http://onlinelibrary.wiley.com/doi/10.1111/j.0272-4332.2004.00520.x/full.

[5] National Institute of Building Sciences (NIBS). Multi-hazard Loss Estimation Methodology, EarthquakeModel. HAZUS MR4, Technical Manual. Federal Emergency Management Agency, Washington DC, USA,2003. URL: http://www.fema.gov/media-library-data/20130726-1716-25045-6422/hazus_mr4_earthquake_tech_manual.pdf.

[6] K. Pitilakis. D3.3 - fragility functions for electric power system elements. Technical Report, Syner-G, Eu-ropean Community, October 2010. URL: http://www.vce.at/SYNER-G/pdf/deliverables/D3.03_SYNER-G_Fragilityfunctionsforelectricpowersystemelements.pdf.

[7] K. Pitilakis, H. Crowley, and A.M. Kaynia. Syner-G: Typology Definition and Fragility Functions for PhysicalElements at Seismic Risk, chapter 6, pages 157–186. Springer, Netherlands, 2014.

[8] S.M. Rinaldi, J.P. Peerenboom, and T.K. Kelly. Identifying, understanding, and analyzing critical infrastruc-ture interdependencies. IEEE Control Systems Magazine, 0272-1780/01:11–25, 2001.

[9] P. Shi, T.D. O’Rourke, and Y. Wang. Simulation of earthquake water supply performance. In In 8th U.S.National Conference on Earthquake Engineering, number 1285. San Francisco, CA, USA, 2006.

[10] M. Shinozuka, R.Y. Tan, and T. Koike. Serviceability of water transmission systems under seismic risk.the current state of knowledge. In ASCE Specialty Conference on Lifeline Earthquake Engineering, 97–110.Oakland, CA, USA, 1981.

[11] A. Urlainis, I.M. Shohet, R. Levy, D. Ornai, and O. Vilnay. Damage in critical infrastructures due to naturaland man-made extreme events â a critical review. Procedia Engineering, 85:529–535, 2014.

[12] I. Vanzi. Seismic reliability of electric power networks: methodology and application. Structural Safety,18(4):311–327, 1996. doi:10.1016/S0167-4730(96)00024-0.

25

http://peer.berkeley.edu/publications/peer_reports/reports_2001/0106.pdf

http://peer.berkeley.edu/publications/peer_reports/reports_2001/0106.pdf

https://doi.org/10.1038/nature08932

http://onlinelibrary.wiley.com/doi/10.1111/j.0272-4332.2004.00520.x/full

http://onlinelibrary.wiley.com/doi/10.1111/j.0272-4332.2004.00520.x/full

http://www.fema.gov/media-library-data/20130726-1716-25045-6422/hazus_mr4_earthquake_tech_manual.pdf

http://www.fema.gov/media-library-data/20130726-1716-25045-6422/hazus_mr4_earthquake_tech_manual.pdf

http://www.vce.at/SYNER-G/pdf/deliverables/D3.03_SYNER-G_Fragility functions for electric power system elements.pdf

http://www.vce.at/SYNER-G/pdf/deliverables/D3.03_SYNER-G_Fragility functions for electric power system elements.pdf

https://doi.org/10.1016/S0167-4730(96)00024-0


[13] Y. Wang, A. Siu-Kui, and F. Qiang. Seismic risk assessment and mitigation of water supply systems. Earth-quake Spectra, 26(1):257–274, 2010.

26 Bibliography

Index

Aacceleration, 21Acceleration Response Spectrum, 21amplitude, 21

Ccritical infrastructure, 21

Ffacility, 21fragility, 21fragility curves, 21fragility function, 21

Ttypology, 21

Vvulnerability, 21vulnerability function, 22

27

sifra documentation

Documents