d4_1_sesame decision support system specification

8/18/2019 D4_1_SESAME Decision Support System Specification

1/59

1

Project number

261696

Project acronym

SESAME

Project title

Securing the European Electricity Supply Against Malicious and accidental thrEats

Deliverable Number

D4.i

System Specification of Decision Support System

Version: 0.7

Date: 2012-12-18

Submission Date: 31-12-2012

TUD, Polito, INDRA and TrEl

Dissemination Level

PU Public √

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential , only for members of the consortium (including the Commission Services)


2/59

2

Deliverable number: D4.i

Deliverable title: System Specification of Decision Support System

Work package: WP4: System Specification of Decision Support System

Lead contractor: TUD

Quality Assurance Status of deliverable

Action By Date

Internal review Enrico Pons, Polito 20/12/2012

Verified (WP Leader) Zofia Luszo, TUD 20/12/2012

Approved (Coordinator) Giovanni Griva, Polito 21/12/2012

Submitted Author(s)

Name Organisation

Wolter PIETERS TUD

Zofia LUKSZO TUD

Ettore BOMPARD PoliTo

Tao HUANG PoliTo

Abouzar Estebsari PoliTo

Javier PASCUAL Indra

Lola LUCENA Indra

Juan PRIETO Indra

Guillermo HIGUERAS Indra

Ana FUENTES Indra

Simona Louise VORONCA Transelectrica

Mihai CREMENESCU Transelectrica

Tania Ecatarina ROMAN Transelectrica


3/59

3

Abstract

This report is the first and only deliverable of the fourth (of nine) work packages of the SESAME project.

It covers both tasks of the work package, namely:

4.1 Physical Network Modelling

4.2 System Specification of DSS

Reported results will be used in work package 5 (Assembling of Decision Support System – Software

Implementation).


4/59

4

Management summary

This document provides the system specification of the SESAME decision support system (DSS). The

DSS calculates the risk associated with different threats to transmission networks, and enables

insight into the cost-effectiveness of countermeasures.

The DSS consists of the following layers:

Event selection

Frequency assessment

Impact assessment

Countermeasure evaluation Map generation

In the event selection layer, the user defines the network model and selects the variables of interest

(threats, loss events, countermeasures). In the frequency assessment layer, threat and network data

are combined to calculate the frequencies of loss events, i.e. combinations of triggering events in the

different components. In the impact assessment layer, a sequence of network states is calculated for

cascading failures after each loss event, and the damage due to power loss in these sequences is

assessed. In the risk evaluation layer, threats and countermeasures are ranked according to induced

risk and prevented risk, respectively. Finally, in the map generation layer, the results are shown on a

map of the network.

The assessment of loss event frequencies is based on the frequencies of the applicable threats, and

estimations of the likelihood of these threats causing the loss event (vulnerability). There is currently

no automatic way to calculate loss event frequencies for loss events affecting multiple components,

as this is dependent on many variables such as the area affected by a threat, the distribution of the

center of the threat events over locations, and the relation between the distance from the center

and the threat magnitude. Also, it is infeasible to run the complex impact assessment calculations for

large numbers of possible loss events, when each combination of triggering events would have to be

tested. Therefore, the DSS calculations will be based on user-selected exemplary loss events, and

their vulnerability to selected threats.

This document specifies the modules needed for each of the layers, their in- and outputs, algorithm

descriptions, and optimization possibilities. The document provides a reference architecture, but not

a fully implemented system.


5/59

5

ContentsManagement summary ........................................................................................................................... 4

1 Introduction ..................................................................................................................................... 8

2 Conceptual framework .................................................................................................................... 9

2.1 Risk taxonomy ......................................................................................................................... 9

2.2 Definitions ............................................................................................................................. 10

3 Requirements analysis ................................................................................................................... 12

3.1 Goal ....................................................................................................................................... 12

3.2 Users ...................................................................................................................................... 12

3.3 Scenarios (WP6/7) ................................................................................................................. 12

3.4 Functionality .......................................................................................................................... 12

3.5 Use cases ............................................................................................................................... 14

3.6 Detailed functions ................................................................................................................. 14

3.6.1 Event selection .............................................................................................................. 14

3.6.2 Frequency assessment .................................................................................................. 16

3.6.3 Impact assessment ........................................................................................................ 18

3.6.4 Risk evaluation ............................................................................................................... 20

3.6.5 Map generation ............................................................................................................. 21

3.7 Non-functional requirements ................................................................................................ 21

3.7.1 Speed ............................................................................................................................. 21

3.7.2 Security .......................................................................................................................... 21

4 Reference architecture .................................................................................................................. 22

4.1 High-level architecture .......................................................................................................... 22

4.1.1 The central DSS system ................................................................................................. 22

4.1.2 External modules ........................................................................................................... 23

4.2 Databank definitions ............................................................................................................. 23

4.2.1 Network ......................................................................................................................... 23

4.2.2 Load curve ..................................................................................................................... 23

4.2.3 Threat type .................................................................................................................... 24

4.2.4 Threat event .................................................................................................................. 24

4.2.5 Loss type ........................................................................................................................ 25

4.2.6 Loss event ...................................................................................................................... 25

4.2.7 Triggering event ............................................................................................................. 25

4.2.8 Vulnerability .................................................................................................................. 26


6/59

6

4.2.9 Countermeasure ............................................................................................................ 26

4.2.10 Network impact ............................................................................................................. 26

4.2.11 Damage .......................................................................................................................... 27

4.3 Interfaces ............................................................................................................................... 27

4.3.1 Interfaces between modules ......................................................................................... 27

4.3.2 User interface ................................................................................................................ 28

4.4 Modules and algorithms ........................................................................................................ 28

4.4.1 Threat selection ............................................................................................................. 28

4.4.2 Loss event selection ...................................................................................................... 29

4.4.3 Countermeasure selection ............................................................................................ 31

4.4.4 Vulnerability assessment ............................................................................................... 31

4.4.5 Threat event frequency assessment ............................................................................. 31

4.4.6 Loss event frequency assessment ................................................................................. 32

4.4.7 Network variants generation......................................................................................... 32

4.4.8 Network evolution ......................................................................................................... 33

4.4.9 Network impact assessment ......................................................................................... 35

4.4.10 Damage assessment ...................................................................................................... 36

4.4.11 Risk assessment ............................................................................................................. 36

4.4.12 Threat ranking ............................................................................................................... 36

4.4.13 Countermeasure ranking ............................................................................................... 36

4.4.14 Map generation ............................................................................................................. 37

4.5 Optimization strategies ......................................................................................................... 37

4.6 Interdependencies ................................................................................................................. 37

5 Prototype choices .......................................................................................................................... 38

5.1 Prototype threats .................................................................................................................. 38

5.2 Prototype functionality ......................................................................................................... 38

6 Conclusions and recommendations .............................................................................................. 39

Appendix A: Network data .................................................................................................................... 40

Appendix B: Triggering event data ........................................................................................................ 49

Appendix C: Countermeasure data ....................................................................................................... 53


7/59

7


8/59

8

1 Introduction

Within the SESAME project, decision support is developed for security investment in electricity

transmission grids. Measures can be taken against natural, accidental, as well as malicious threats.

For example, blackouts may occur due to ice storms, spontaneous component failure, or cyber

attacks, and these may be prevented by additional power lines, more reliable components, improved

automatic responses, or improved information security.

The current document is the deliverable of Work Package 4, which concerns the system specification

of the SESAME decision support system (DSS). The DSS calculates the risk associated with different

threats to transmission networks, and provides insight into the cost-effectiveness of

countermeasures.

This document builds upon the following deliverables:

D1.iii Risk assessment calculation kernel

D1.iv Incident-response system

D2.i Impact assessment simulation tool (due April 2012)

As deliverable D2.i is not available yet, only the interface with this tool has been defined. This

decision support system specification will be used in the Work Package Assembling of Decision

Support System – Software Implementation (WP5).

This document does not provide an overview of threats that can or should be considered. For such an

overview, we refer to deliverable D1.1 and D1.2. The user should be able to select these threats in

the event selection layer.

This document is structured as follows. In chapter 2, the general framework and definitions of terms

are provided. In chapter 3, the requirements for the decision support system are described. In

chapter 4, a reference architecture is provided in terms of modules, databases, and their

interactions. High-level descriptions of algorithms and mathematical relations are defined. In chapter

5, specific choices for the prototype version to be implemented within the SESAME project are

highlighted. Conclusions and recommendations are discussed in chapter 6.


9/59

9

2 Conceptual framework

2.1 Risk taxonomy

As a standard for the DSS calculations, the Risk Taxonomy of The Open Group was chosen. This

standard distinguishes between threat events, loss events, and probable loss magnitudes. For

example, a storm (threat event) may cause a power line breakdown (loss event), which may cause a

blackout with economic damage (probable loss magnitude).

In transmission grids, a loss event is considered to consist of a combination of simultaneous

triggering events, for example the breakdown of one or more components. The frequency with which

such an event is expected to happen is calculated from the frequency of the associated threat, and

the likelihood of such a threat event leading to the loss event (called vulnerability). A specific method

for calculating vulnerability has been suggested,1 but this method is considered external to the DSS.

For the automatic assessment of the vulnerability of sets of components to the same threat, no

models are readily available. Such a model could be developed in the future as an extension to the

DSS. Currently, the user will need to estimate the likelihood of such simultaneous failures. The same

holds for special treatment of the frequency of malicious threats. Currently, these are treated in the

same way as natural threats, with estimated frequencies. Using scientific results from the SESAME

project, it should become possible to take attacker strategies into account in the future.

The probable loss magnitude is assessed by calculating a sequence of network states after a loss

event, in the original network as well as when countermeasures are in place. The network states are

used to calculate the amount of unserved energy in substations. Based on the unserved energy and

economic information about the affected region, the economic damage can be estimated.

The induced risk associated with a threat event or loss event is its frequency times the probable loss

magnitude, or expected damage, associated with the event. This yields the damage expected due to

this particular threat or loss event per unit of time (year). The risk associated with events can be

calculated both with and without countermeasures. This gives rise to the notion of prevented risk

associated with a countermeasure. Cost-effectiveness represents the prevented risk minus the costs

of the countermeasure(s). Both threats and countermeasures can be ranked according to the risk

they induce/prevent.

The central conceptual framework for the decision support system is thus based on a separation of

concerns between the following:

1. External events (threat events), and their associated magnitudes and frequencies;

2. Internal system events (loss events composed of one or more triggering events) caused by

external events;

3. Cascading failures in the system due to triggering events, and the resulting system states,

and unserved energy;

4. Damage caused by the unserved energy;

1 Wolter Pieters, Sanne H.G. van der Ven, and Christian W. Probst. 2012. A move in the security measurement

stalemate: elo-style ratings to quantify vulnerability. In Proceedings of the 2012 workshop on New security

paradigms (NSPW '12). ACM, New York, NY, USA, 1-14. DOI=10.1145/2413296.2413298

http://doi.acm.org/10.1145/2413296.2413298


10/59

10

5. Countermeasures and their effect on frequency of and damage caused by triggering events.

In particular, the relation between external threat events and internal loss events is described by the

vulnerability of the associated components, i.e. the likelihood that a threat event causes a loss event.

For example, a power line will have vulnerability data associated with it for storms of different

magnitudes, and the likelihood of loss may for example be 0.2 for storms of 10 Beaufort.

2.2 Definitions

The table below provides definitions and examples for the most important terms used in the

following sections.

Table 1: Definitions for the SESAME DSS

Term Definition Example

Network An electricity transmission grid The Romanian transmission grid

Componenttype

A set of devices with identical properties, ofwhich an instance can be part of a network.

A power line with properties X andY

Component A part of a network with a distinguished

physical appearance and/or function

The power line between bus A and

bus B

Connection A possibility for interaction between

components in a network

Connection of bus 101 to branch A

Network model A digital representation of a transmission

grid, including its components, their

properties/parameters, and connections

The Romanian grid represented as

a graph

Countermeasure A change in the network model

representing an attempt to reduce risk

An additional power line between

bus A and bus B

Network variant The network model augmented with zero

or more countermeasures

A representation of the Romanian

grid with an additional power line

between A and B

Load curve A time-based sequence of load levels in all

parts of the network model

The expected loads in the

Romanian grid between 6pm and

2am on an average winter day

Threat type An external phenomenon that may causedamage to the transmission grid

Storms

Threat

magnitude

The ability of a threat to cause damage 10 Beaufort

Threat event A concrete occurrence of a threat with a

specific magnitude at a specific location

A storm of 10 Beaufort in a

province of Romania

Loss event A concrete occurrence of damage in one or

more components.

The breakdown of the power line

between bus A and bus B, and the

breakdown of generator X, on 1-1-

2012


11/59

11

Triggering event A concrete occurrence of damage in exactly

one component. A loss event may consist of

multiple triggering events.


between bus A and bus B on 1-1-

2012

Threat-loss

event

A concrete occurrence of damage in a

component due to a threat event


between bus A and bus B on 1-1-

2012 due to a storm of 10 Beaufort

Vulnerability The likelihood that a threat event causes a

specific loss event

The property of a power line with

properties X and Y to break down

in a storm of 10 Beaufort with 0.5

probability

Network impact The impact of an event on the network Power loss of 85% in buses A and B

for 10 hours

External impact

/ damage

The impact of an event on society in terms

of monetary loss

Economic losses of M€ 10 due to

10 hours of power loss

Risk Expected damage per unit of time M€ 10 per year

Prevented risk Reduction in risk by countermeasure A reduction of M€ 1 per year

Cost-

effectiveness

Reduction in risk minus countermeasure

costs

A cost-effectiveness of M€ 0.5 per

year

Applicationscenario

An example network and stakeholderlandscape used in the validation of the DSS

Analysis of threats andcountermeasures in the Romanian

transmission grid from the

perspective of the TSO


12/59

12

3 Requirements analysis

3.1 Goal

The goal of the DSS is balancing costs and benefits of security investments in transmission grids. The

goal can be decomposed as follows:

1. Determine the effects of threats on transmission grids;

2. Identify and rank possible (sets of) countermeasures;

3. Justify security investments.

3.2 Users

The primary users are:

1. TSOs (and ENTSO-E at European level), for system development and long-term investment

planning;

2. Regulators, for assessment and verification of incentives and investments.

Secondary use is foreseen by policy makers. Also, transmission system operators (TSOs) may use the

system to suggest possible measures to be taken by electricity producers.

3.3 Scenarios (WP6/7)

Two application scenarios are foreseen in the project

Authority perspective: e-control Austria (WP6)

TSO perspective: Transelectrica (WP7)

3.4 FunctionalityBased on the framework outlined in the previous chapter, the DSS is envisioned to consist of the

following layers:

Event selection

Frequency assessment

Impact assessment

Risk evaluation

Map generation

In the event selection layer, the user constructs the network model and selects the events of interest(threats, countermeasures). In the frequency assessment layer, threat and vulnerability data are

combined to calculate loss event frequencies for the different components. In the impact assessment

layer, network states are calculated for each loss event, and the damage due to power loss in such

states is assessed. In the risk evaluation layer, threats and countermeasures are ranked according to

induced risk and prevented risk, respectively. Finally, in the map generation layer, the results are

shown on a map of the network.

In order to justify investments, the expected costs due to threats need to be known both with and

without the countermeasure. These will be calculated by the DSS. Also, the costs of countermeasures

(both investment and operational) need to be supplied by the user.


13/59


14/59

14

3.5 Use cases

The interaction with the user is limited in the DSS. There are six main ways for the user to interact

with the system:

Entering the input data;

Selecting the relevant events;

Requesting a simulation run;

Reading the output data;

Requesting the generation of a map;

Interacting with the map.

3.6 Detailed functions

This section specifies the functions to be performed by the DSS in more detail, in particular in terms

of their in- and outputs. For each function required inputs and outputs are defined. The functions will

correspond to system modules, which are independent parts of the system transforming particular

inputs into particular outputs.

3.6.1 Event selection

The event selection layer allows the user to select the threats, loss events, and countermeasures of

interest (Figure 3).

Figure 3: The functions of the event selection layer

3.6.1.1

Threat selectionThis function allows the user to select the threats to be considered in the analysis. Threats are

generally specified as a threat type (e.g. storm) plus a threat magnitude (e.g. 10 Beaufort). For each

threat type, the system should be able to register the corresponding magnitude units. In the typical

use case, the user will select only types, not magnitudes.

If no threat is selected, the analysis will only be based on the selected loss events. For analysis

purposes, all frequencies will then be assumed to equal 1. In that case, countermeasures can only be

ranked on prevented risk, not on cost-effectiveness.

Input:


15/59


16/59

16

Social threats

contamination Chemical andbiochemicalcontamination

Solar flares/solar winds /magneticstorms

distributionline

short circuit static frequencystability

M a l i c i o u s t h r e a t s

physicalthreats

ter roristattack

distributionline

br eak

war act undergroundcable

malfunction dynamicfrequencystabilitysabotage pole br eak

humanthreats

insiderthreats

fuse malfunction Transientfrequencystabilitycyber

threatsmalware inf ormation ,

communicationandcontrolsystems

cyberequipment

br eak

terroristshacking

cybersystem

hack

Note *: not exactly associated with angle, but related to generator rotor

3.6.1.2 Loss event selection

This function allows the user to select the loss events to be considered in the analysis.

Input:

1. List of loss events

2. Selected threats

3. User input (selection from list)

Output:

1. Selected loss events

3.6.1.3 Countermeasure selection

This function allows the user to select the countermeasures to be considered in the analysis.

Countermeasures are represented as possible modifications to the network model. Countermeasures

can only be selected if the corresponding threats are selected.

Input:

1. List of countermeasures

2. Selected threats

3. User input (selection from list)

Output:

1. Selected countermeasures

3.6.2 Frequency assessment

The frequency assessment layer deals with determining the expected number of events per year

(Figure 4). For loss events, this number is based on the expected frequency of threat events, and thelikelihood of the loss event happening when such a threat event happens (vulnerability).


17/59

17

Figure 4: The modules of the frequency assessment layer

3.6.2.1

Vulnerability assessment

This function determines how likely a threat event is to cause an associated loss event. This

likelihood will depend on the properties (strength, security) of the component. It is assumed that

these likelihoods are estimated by the user for each loss event. In future extensions of the DSS, based

on scientific results from the project, the system may assist in calculating them from records of past

events.

Input:

1. Selected threats

2. Selected loss events3. User-supplied vulnerability values

Output:

1. For each combination of selected threat and selected loss event, likelihood that threat event

causes loss event

3.6.2.2 Threat event frequency assessment

This function determines how frequently a particular threat type with a particular magnitude is

expected to occur. For natural threats, the source of this information consists of threat event

frequencies at known locations (e.g. weather stations). The frequencies are assumed to be known

per region. For each component potentially affected by the threat, the frequency at the component’s

location needs to be determined based on the region in which the component is located. For

accidental threats, location-independent estimations of frequencies (e.g. spontaneous breakdown)

are used. For malicious threats, frequencies need to be supplied per region as well, depending for

example on the political situation.

Input:

1. Selected threats

2. Selected loss events3. Regions of components affected in loss events


18/59

18

4. For natural threats, frequencies per magnitude level per region

5. For accidental threats, estimation of frequencies

6. For malicious threats, frequencies per magnitude level per region

Output:

1. For each (threat, magnitude, loss event), relevant frequency at loss event location

3.6.2.3 Loss event frequency assessment

This function calculates the expected frequency of loss events from the associated threat event

frequencies and vulnerabilities.

Input:

1. Selected threat and loss events

2. For each (threat, magnitude, loss event), relevant frequency at loss event location

3. For each combination of selected threat and selected loss event, likelihood that threat eventcauses loss event

Output:

1. Loss event frequency for each combination of threat and loss event

2. Aggregate loss frequency for each loss event (caused by different threats)

3.6.3 Impact assessment

In the impact assessment layer, the consequences of each loss event are assessed, in terms of

disturbances to the network and then in terms of economic damage (Figure 5).

Figure 5: The modules of the impact assessment layer

3.6.3.1 Network variants generation

This function generates network variants from the network model and countermeasure

implementations. The resulting variants represent the same network with the countermeasure

implemented.


19/59

19

Input:

1. Countermeasures

2. Full network specification

Output:

1. Network variants

3.6.3.2 Network evolution

This function calculates the final state of the network after cascading events/failures caused by a loss

event.

Input:

1. Network variants

2. Selected loss events

3. Load scenarios

Output:

1. Sequence of network states from loss event until restored power per loss event and per

variant

3.6.3.3 Network impact assessment

This function determines the impact on the network of the resulting sequence of states after a

triggering event. This is represented as unserved energy per state and per substation.

Input:

1. Sequence of network states per loss event and per variant

Output:

1. Unserved energy per substation for each state in the evolution sequence for each loss event

and for each variant

3.6.3.4 Damage assessment

This function calculates the expected damage to society of a loss event and associated network

impacts.

Input:

1. Unserved energy per substation for each state in the evolution sequence for each loss event

and for each variant

2. Regions where substations are located

Output:

1. Expected damage per loss event and per variant


20/59


21/59

21

3.6.4.3 Countermeasure ranking

This function ranks the countermeasures according to their performance. For the ranking, two

numbers need to be calculated: the risk prevented by a countermeasure, and the cost-effectiveness

of a countermeasure.

Input:

1. Risks (for all threat-loss events for all variants)

2. Countermeasure costs (investment and operational)

Output:

1. Prevented risk per countermeasure

2. Cost-effectiveness per countermeasure

3. Ranked countermeasures according to prevented risk

4. Ranked countermeasures according to cost-effectiveness

3.6.5 Map generation

This function shows the results of the analysis on a map

Input:

1. Full system specification

2. Ranked threats and associated risk

3. Ranked countermeasures and associated costs / prevented damage

4. Sequences of network states from loss event until restored power

5. GIS data

Output:

1. Map of threats and countermeasures

2. Visual representation of network evolution after loss event

3.7 Non-functional requirements

3.7.1 Speed

As the required calculations are extensive (simulations of risk for each combination of threat – event

– countermeasure, including simulations of resulting state), the system will likely not respondinstantaneously for larger networks. Concrete speed requirements cannot be given at this stage, but

a balance between accuracy and usability is likely to be needed based on tests with the prototype.

See also the discussion on optimization (section 4.5).

3.7.2 Security

As network data is considered sensitive, the system running the software should be a stand-alone

machine. No further security measures (e.g. encryption) are planned in the prototype.


22/59

22

4 Reference architecture

4.1 High-level architecture

The different modules communicate via an Excel file (Excel 2007 / Office Open XML (.xlsx)). Input is

read from the Excel file, and output is written into (possibly a different sheet) in the same file.

The input data will be set up in an Excel© workbook, in separate sheets. The DSS tool will be a web

application built under .NET technology and running in an Internet Information Server on Windows

2003 Server 32 bits. The system will have the ability of:

Executing Matlab© programs from Excel©.

Draw geographical information in maps.

Once the modules have finished calculations, they write the output in another sheet of the Excel©

workbook and the DSS will work with the information to show to the user a result table. Some

calculations will be implemented in the Excel sheet itself, by means of Excel formulas.

Figure 7: The high-level reference architecture

4.1.1 The central DSS system

The implementation of the DSS is foreseen based on the e-SCOPE platform, developed by partner

Indra. An installation guide for this platform is available. The central DSS system consists of those

algorithms that can be implemented directly in Excel or within e-SCOPE. It is foreseen that all

modules are implemented in the central DSS, except the network evolution (Matlab) and the map

generation (GIS tool).

User

Excel sheet withinput data from the

user and outputdata from models.

Models. Readsinput form Excel.Writes output to

Excel.


23/59

23

4.1.2 External modules

4.1.2.1 Network evolution

Contrary to other system parts, the network evolution module is written in Matlab. For each

triggering event, i.e. the loss of a component, the resulting final state of the network is determined

for each of the possible network variants.

4.1.2.2 Map generation

Based on the final contents of the Excel file after analysis, a map is generated that displays the

results, including the ranking of threats and countermeasures. The map can be implemented in any

GIS tool.

4.2 Databank definitions

This section defines all the data fields used or generated by the DSS. Entries marked with * will be

computed by the DSS. All other entries need to be supplied as input. Each table corresponds to a

sheet in Excel, with the fields being associated with columns.

4.2.1 Network

Network data includes all the network elements data (elements parameters, protection data,

restoration time and costs) and the system base (frequency, MVA base, etc). Elements of the system

include all the buses, generators, loads, transmission lines, transformers, FACTS devices, etc., which

have their own parameters and this is called as the initial network status in normal operation without

any threat. Since the network data is the base for the calculation, all of them should be supplied by

the user. As the network data consists of a large number of fields, please refer to Appendix A for

details.

4.2.1.1

Locations

Location information is needed for 2 different purposes in the DSS:

1. Linking substations to economic regions for damage assessment;

2. Displaying network components on a map.

For both purposes, it is assumed that location information is available for buses, both in terms of GPS

coordinates and in terms of region. Regions are defined according to NUTS level 2.1

Table 3: Data specification for location information

Name Data type Length / Decimals Origin

BUS_NUMBER Integer Input

Longitude Float 5 Input

Latitude Float 5 Input

Region String 4 Input

4.2.2 Load curve

In order to calculate the unserved energy due to the blackout correctly, we also need information

about the (forecasted) load. In practice the load curve is provided by 96 (or 24, in some cases) points

1 http://epp.eurostat.ec.europa.eu/portal/page/portal/nuts_nomenclature/introduction


24/59

24

with assumption that during each time interval, the demand would keep constant. The following

information would be provided by the user to specify the load variation in calculation.

Table 4: Data specification of load curve

LOAD CURVE DATAINDEX NAME MEANING DATA TYPE

1 LCTIME the time in the text format including the hour and the minute

without separation (0820 means at 20 minutes past 8, 1400

means at 2 o’clock in the afternoon)

Integer (+)

2 TOTLOAD total load according to the load curve (MW) Integer (+)

4.2.3 Threat type

A threat type represents a class of threat events, such as storms, earthquakes, cyber attacks. They

have an associated category (Natural, Accidental or Malicious), and units for representing the

magnitude of events associated with the threat type. The induced risk of a threat type is calculated

by the DSS. The field “Size” is only meant to support future extensions that take the size of a threat

event into account.

Table 5: Data specification of threat type


Threat ID ID Assigned by system

Threat name String 16 Input

Threat category {N,A,M} Input

Magnitude units String 16 Input

Size Float Input

Induced risk* Currency 2 Risk assessment

4.2.4 Threat event

A threat event is characterized by a threat type (name), a location, a threat capability, and a

frequency. The threat capability of a threat event is given according to the magnitude units specified

with the associated threat type. The frequency is given in number of instances per year (often


25/59

25

4.2.5 Loss type

A loss type is a class of loss events that share characteristics, for example generator malfunction or

power line breakdown. Loss types are only meant to aggregate risk data (frequency and induced risk)

per class of loss events.

Table 7: Data specification of loss type


Loss type ID ID Assigned by system

Loss type name String Input

Frequency* Float 6 Frequency assessment


4.2.6 Loss event

Loss events represent combinations of events caused by a threat that may lead to damage to the

system. The location of the loss event is derived from the location of the affected components

(triggering events). The frequency and induced risk are calculated by the DSS.

Table 8: Data specification of loss event


Loss event ID ID Assigned by system

Loss type ID ID Input (foreign key)

Longitude* Float 5 LEF assessment

Latitude* Float 5 LEF assessment

Region* String 4 LEF assessment

Frequency* Float 6 LEF assessment


4.2.7 Triggering event

A loss event is composed of one or more triggering events. A triggering event affects only one

component, whereas a loss event can affect more. In other words, a loss event is either one single

triggering event or a combination of several triggering events. The network evolution module getsthe triggering events data in the affected components level and updates the network accordingly. In

order to exert the triggering events to the network and to do the simulations of cascading failures,

the network evolution module gets two general matrices as the triggering events input: 1) triggering

events on buses and 2) triggering events on branches. The two matrices contain only the parameters

which can be affected by the triggering events (Appendix B).

In the network data matrices for almost all the elements there is a column entitled restoration time

specifying after how long that element can be put in to use again. For example if a line is

disconnected at 14:20 and its restoration time is 50 minutes, the line can be connected (considering

the technical possibility) at 15:30.


26/59

26

The reference time for restoring an element is the time when it goes out of service. This can happen

due to either loss event or protections. For those elements totally destroyed by the loss event, they

cannot be put into use again; therefore their restoration time should be set to infinity.

4.2.8 Vulnerability

Vulnerability data indicates how likely a threat event is to cause an associated loss event. Based onuser-supplied vulnerability estimations, the DSS calculates the expected frequency and induced risk

of the vulnerability.

Table 9: Data specification of vulnerability


Threat event ID ID Input (foreign key)

Loss event ID ID Input (foreign key)

Vulnerability Float 6 InputFrequency* Float 6 LEF assessment


4.2.9 Countermeasure

The countermeasure along with its cost would be defined before the simulation by the users. In

general, they can be categorized into two groups, online countermeasure and investment

countermeasure. For each group, there would be several subsets of countermeasures; for example,

under online countermeasures, under frequency load shedding, under voltage load shedding, etc.,

would be provided. For some of them, if not specified by the user, the simplified ENTSO-E guidelines

would be considered defaulted. In contrast, investment countermeasure contains a wide range of

installation. For more information of the countermeasures that can be considered in the DSS and

possible development in the future, please refer to the deliverable D1.4 Incident-Response System

(IRS) of the SESAME project. As for the input of the countermeasures, one can refer to Appendix C. In

addition, a table is maintained to store for each countermeasure the cost and the prevented risk.

Table 10: Data specification of prevented risk of countermeasures


Countermeasure ID ID Input

Investment cost Currency 2 Input

Depreciation period Integer Input

Operational cost Currency 2 Input

Prevented risk* Currency 2 Countermeasure

ranking

Cost-effectiveness* Currency 2 Countermeasure

ranking

4.2.10 Network impact

The impact of a loss event on the network, depending on the countermeasure, is represented as for

each state in the network evolution and for each substation (bus), the unserved energy.


27/59

27

Table 11: Data specification of network impact


Network ID ID Input

Loss event ID ID Input


BUS_NUMBER Integer Input

Network state ID* ID Network evolution

Unserved energy* float 0 Network impact

assessment

4.2.11 Damage

Finally, for each loss event and each countermeasure, the expected damage caused (probable loss

magnitude) is registered.

Table 12: Data specification of damage


Network ID ID Input

Loss event ID ID Input


Damage* currency 2 Damage assessment

Induced risk* currency 2 Risk assessment

4.3 Interfaces

4.3.1 Interfaces between modules

The different modules communicate via an Excel file (Excel 2007 / Office Open XML (.xlsx)). Input is

read from the Excel file, and output is written into (possibly a different sheet) in the same file.

Two stand-alone modules are foreseen: the network evolution module and the damage assessment

module.

4.3.1.1

Interface with network evolution moduleThe network evolution module is developed in Matlab and provides the following functionality:

Network variants generation

Network evolution

Network impact assessment

The module will be called by a wrapper that will call the module for each loss event. The module

itself will provide iteration over all countermeasures (network variants).

Like other modules, this module will read and write from/to an Excel file. The DSS provides to the

network evolution module:


28/59

28

1. The network model;

2. The countermeasures to be evaluated;

3. One selected loss event;

4. The load curves.

The network evolution module provides to the DSS:

1. The sequence of states of the network after the loss event until restoration of power, for

each countermeasure (including none). One state is generated per 15 minutes of simulated

time;

2. The impact associated with each state, in terms of unserved energy per substation.

4.3.1.2 Interface with damage assessment module

The damage assessment module (Deliverable 2.i) will supply a monetary damage value (in Euros) for

each loss event. The input to the module consists of the unserved energy per substation per system

state after a loss event. Based on the location (region) of the substations, and the total amount ofunserved energy, the damage value is calculated.

4.3.2 User interface

The user interface consists of Excel input and a map interface.

4.3.2.1 Input interface

All user inputs discussed in the functional requirements can be provided by the user in the input

Excel file. This includes selection of threats, loss events, and countermeasures, by means of

checkboxes. The user can press a button to start the simulation.

4.3.2.2

Map interfaceThe system should provide an interface where the different components are shown on a map. The

map will be generated after the user presses a button. After assessment of the threats to the original

network, risk values are shown for the original network. The map interface should visually represent

the possible countermeasures. Upon clicking on one of the countermeasures, the resulting risk

values are updated. When clicking the same countermeasure again, the original values are restored.

The user can also ask for a visual representation of the development of a blackout, based on the

generated sequence of snapshots.

4.4 Modules and algorithms

This section informally describes the algorithms to be used in implementing the different modules.For formulas to be implemented in Excel, mathematical notation is used. This section also specifies

the data fields to be filled by each function.

4.4.1 Threat selection

The relevant threats can be entered and (de-)selected in the Excel file.

A sheet in the input Excel file containing threat type data

A sheet in the input Excel file containing the possible threat magnitudes for each threat

type, and frequencies per region (threat event data)

Checkboxes occurring with the threats in the threat types sheet. Threats of which thecheckboxes have been checked are considered selected.


29/59

29

4.4.2 Loss event selection

The relevant loss events can be entered and (de-)selected in the Excel file.

A sheet in the input Excel file containing loss event data

Checkboxes occurring with the loss events in the sheet, only available when the

corresponding threats have been selected in the threat types sheet. If no threat has been

selected, all loss events are eligible for selection.

To assist the user in selecting relevant loss events, a module external to the DSS will be developed in

the project. This module uses the project’s results on topological analysis to identify components

that are most likely to cause problems upon failure. The user can then enter subsets of these

components as relevant loss events.

The structural vulnerability detection module takes the same input as the IRS and extracts

topological information and electrical engineering parameters to form a network model exclusively

used for topological analysis. An extended topological method by introducing some electricalengineering specificity into complex networks approach would be implemented in order to

effectively explore the structural property and analyze vulnerability of power systems from a

topological perspective.

Firstly, electrical engineering specificity such as line impedance, line flow limit is introduced into

degree metrics of traditional graph theory to examine the connectivity of each bus in power grids. In

the meantime, in order to distinguish the centrality of buses, entropy degree is proposed to check

the connectivity of bus more comprehensively. It is showed that the proposed metrics incorporating

electrical features are more suitably analyzing the structural characteristics of power systems as a

complex system and more useful to identify the importance of buses.

Aiming at analyzing static robustness of power grids, electrical betweenness is proposed by

introducing transmission capacity and power transfer distribution factors into betweenness centrality

which is a metric to measure the importance of a vertex or an edge in network. It is confirmed that

electrical betweenness is superior to purely topological betweenness in analyzing the criticality of

components in power grids. The criticality of components (buses and lines) in a power grid can be

identified more efficiently using electrical betweenness metric.

The general goal of a power grid is the feasible and economic transmission of power from generation

buses to load buses. Therefore, in order to evaluate the performance of a power network from a

global perspective of view, net-ability in consideration of engineering features like transmission

capacity and line impedance is proposed to replace the efficiency metric in pure topological method.

Net-ability measures the ability of a power grid to perform properly its function; the possibility to

perform its function properly depends on the maximum (real or apparent) line flow limits (transfer

arbitrary amounts of power) and on the impedance of the lines (economic and technical

convenience).


30/59

30

The output would be a set of metrics (listed in the following tables) associated with the system or a

single element. By ranking them, the user would get information of the criticality of the elements in

terms of their vulnerability from structural point of view.

DEGREEINDEX NAME MEANING DATA TYPE

1 CON_DEGREE conventional degree of the node Integer (+)

2 CON_DEGREE_IND corresponding node ID of conventional degree Integer (+)

3 WEIGHTED_DEGREE weighted degree of the node Integer (+)

4 WEIGHTED_DEGREE_IND corresponding node ID of weighted degree Integer (+)

5 ENTROPY_DEGREE entropy degree of the node Float (+)

6 ENTROPY_DEGREE_IND corresponding node ID of entropy degree Integer (+)

NODE_BETWEENNESSINDEX NAME MEANING DATA TYPE

1 NODE_BETW extended betweenness of the node Float (+)

2 NODE_BETW_IND corresponding node ID Integer (+)

EDGE_BETWEENNESS

INDEX NAME MEANING DATA TYPE

1 EDGE_BETW extended betweenness of the edge Float (+)

2 EDGE_BETW_IND corresponding edge ID Integer (+)

NET-ABILITY


1 E the net-ability of the whole network, scalar data Float (+)

NODE NET-ABILITY

INDEX NAME MEANING DATA TYPE1 E_FAILURE_NODE the relative drop of the net-ability after removing

bus

Float (-)

2 E_NODE normalized E_failure_node by E Float (-)

3 E_NODE_IND corresponding bus ID Integer (+)

EDGE NET-ABILITY


1 E_FAILURE_EDGE the relative drop of the net-ability after removing branch Float (-)

2 E_EDGE normalized E_failure_edge by E Float (-)


31/59

31

3 E_EDGE_IND corresponding edge ID Integer (+)

One can refer to the Deliverable D1.3 for more technical information.

4.4.3 Countermeasure selectionThe relevant countermeasures can be entered and (de-)selected in the Excel file.

A sheet in the input Excel file containing countermeasure data, as well as the threats they

aim to protect against

Checkboxes occurring with the countermeasures in the sheet, only available when the

corresponding threats have been selected in the threat types sheet

4.4.4 Vulnerability assessment

For each combination of threat event and loss event, the user can indicate in the Excel file how likely

the threat event is to cause the loss event. For example, the user can indicate that, when a storm of

magnitude 10 occurs, there is a 0.5 probability that the power line between A and B breaks down. If

desired, the user can use vulnerability functions to calculate the vulnerability automatically in Excel

based on the threat magnitude. These are external to the DSS.

This function will not alter any data unless the user applies vulnerability functions within the input

Excel sheet.

4.4.5 Threat event frequency assessment

The expected frequency / capability distribution of the selected threats is assessed, based on the

geographical location of the network and its components. The frequencies are denoted TEF(t,m,c),

where t is the threat, m is the threat capability/magnitude, and c is the affected component (loss

event). The output is a number of events per year.

In the prototype, assessment of frequency data for component locations is external to the system,

and data need to be supplied by the user. The user is expected to enter frequency data per region. As

network components are also associated with a region, this provides a 1-to-1 mapping between

threat frequencies and potentially affected components.

Vulnerability functions are associated with threat types and loss types. The vulnerability

function specifies the relation between the threat capability and the vulnerability (likelihood of

a loss event caused by the threat event). For example, a vulnerability function may specify for

each earthquake magnitude the likelihood of breakdown of a certain type of generator. This

input is specified by the user. The vulnerability is independent of the component location; only

the threat frequencies for different classes of the threat (e.g. earthquake classes) are associated

with the location.

Vulnerability is represented as a function V(t,m,c), where t is a threat type, m is a threat

capability (magnitude), and c is a loss event. The output of the vulnerability function is a

likelihood (a real number in the interval [0..1]). The SESAME DSS will not supply vulnerability

functions.


32/59

32

This function will not alter any data unless the user applies her own calculations in the input Excel

sheet.

4.4.6 Loss event frequency assessment

Using the vulnerability information of the components V(t,m,c) and the threat frequencies of the

threats TEF(t,m,c), a loss event frequency is calculated for each loss event. The frequency is

calculated both per threat (LEF(t,c)) and cumulative (LEF(c)).

First of all, the location of the loss event is determined based on the location of the affected

components. The longitude and latitude will be the center of the affected components; the region

will be the region in which most affected components are located.

It is assumed that threats are independent, and that loss events due to different threats do not occur

simultaneously. This assumption could be lifted in future research, when dependencies between

threats and loss events are modeled.

In math:

( ) ∑() ( )

() ∑()

The loss event frequencies are again represented as numbers of events per year.

This function uses the threat event and vulnerability data, and fills the fields Longitude*, Latitude*,

Region*, and Frequency* in the loss event data.

4.4.7 Network variants generation

The system will generate different variants of the network, with different countermeasures

implemented. This function is performed in the Matlab module that takes care of the network

evolution (here called IRS). A wrapper function is foreseen that calls the Matlab module for each loss

event. The Matlab module itself will take care of evaluating the network state sequence after this

loss event for each countermeasure. The module will also calculate the unserved energy per

substation per state in the sequence.

The user needs to determine how threat frequencies for known locations are mapped to threat

frequencies for regions. Here, a suggested approach is presented, using only geographical

proximity as an indicator for comparable locations. Several algorithms are available to

interpolate the data in this case. In the simplest solution, only data from the one closest known

location are used. In a more advanced solution, multiple data points are combined.

1

Thesuggested choice is Inverse Distance Weighting with a limited set of points (n points), using

anisotropy correction. As said, these calculations are not part of the DSS.


33/59

33

Figure 8 shows the procedures of how to generate different system variants. For each loss event (a

combination of triggering events (bearing the same triggering event ID)), the upper wrapper would

call the IRS to evaluate all the considered countermeasures (with the same countermeasure ID).

4.4.8 Network evolution

A Matlab module will read the Excel file, and will calculate the final network state for one selectedloss event, for each countermeasure. This module is discussed in detail in D1.4 Incident-response

system.

Regardless of the threat ID, loss event ID and triggering event ID, the simulator considers all the

modifications provided by the loss event data (Appendix B). For instance, a generator on bus 67 was

destroyed, then this generator’s status will be set to “0” and the two concerning restoration time will

be set to infinite (or a really large number); and if at the same time, the protection systems of the

loads on the same bus do not work anymore, the user (or triggering events simulator (TES)) needs to

go to another row to set the status of the load protection relays to “1” (which means the relays

activation is blocked).1

In other words, each line only accepts the modification to a single element. Also, the user ((TES))

needs to remember that the modification to the same parameter more than once, only the last

modification would actually affect.

In some situation, when a threat happens, there may be several different possible loss events for the

user to consider. In other words, the user may be interested in simulate different consequences from

the same threat. For example a flood may destroy some generators and transmission lines which are

called “loss events 1”; meanwhile, the same flood may cause damages to some buses in the system,

called “loss event 2”. When such damages are translated technically in order to be exerted to the power system, they are called: “triggering events”. Such technical details can be easily set in

appropriate columns and then the Incident-Response System (IRS) modifies the system accordingly

(Figure 9).

1 Since the matrices are given to the simulator in MATLAB format, the blank cells must be set as “NaN”.


34/59

34

Figure 8: IRS Calling sequence from external wrapper


35/59

35

Figure 9: IRS input from triggering events side

Thus whenever the IRS is called, it will get one file including one loss event and other associated

network elements and countermeasures; then it will modify the whole system accordingly.

Obviously, each time, the IRS handles with one loss event. In other words, the number of the IRS

being called is equal to the number of loss events.

This function uses the loss event / triggering event , network , and countermeasure data, and creates

snapshots of the network after the loss events. These snapshots are then used in the network impact

assessment.

4.4.9 Network impact assessment

Based on the sequence of network snapshots S(c,N), the impact of the loss event on the network

I(c,N) is calculated. This is represented as for each state in the sequence the unserved power persubstation. This procedure is repeated for each network variant (countermeasure).

Threats, loss events and corresponding triggering events in 2 general data matrices for buses

and branches (in 2 excel sheets with the proposed format)

Organise loss events with their Ids, each of which is going to be

adopted by the IRS once at a time.

Add two Matlab matrices (bus and branch

triggering events for a single loss vent) to the

input file

IRS updates the network according to

the given file to simulate the cascading

failures and etc.

Call IRS


36/59

36

As the simulation runs, several system snapshots will be given for assessment purpose. As targeted

to minimize the un-served energy and accelerate the restoration of loss power, the IRS would give

the unserved energy during the time interval of two snapshots substation by substation.

As only total load curve is available, the (forecasted) load would vary in the same proportion as the

total load.

This function uses the network snapshots and the bus location data, and fills the network impact

data.

4.4.10 Damage assessment

The system calculates the expected damage D(c,N) of the blackout that occurs after loss event c,

based on the impact I(c,N). The procedure will be devised by WP2, and we refer to the forthcoming

deliverable D2.1 for details. This procedure receives as input the unserved energy per substation per

state after the loss event. The output is the damage represented in euros. Again, this is done for each

network variant.

This function uses the network impact data, and fills the damage data.

4.4.11 Risk assessment

The frequency and damage information is used to calculate the risk for the selected threats in

combination with all the possible network variants.

The system uses frequency and impact data to calculate the risk induced in the network by each

threat, as the product of the loss event frequency for the triggering event, and the damage caused by

the triggering event. The risk is denoted R(t,c,N) when specified per loss event and R(t,N) when

aggregated for all loss events caused by the threat. The aggregated risk for one loss event due to allthreats is denoted R(c,N).

( ) ( ) ()

( ) ∑()

( ) ∑()

Risk values are represented as euros per year.

This function uses the threat type, loss event and damage data, and fills the field Induced risk* in the

damage, loss event , vulnerability , threat event , and threat type data.

4.4.12 Threat ranking

The threats are ranked according to the associated risk R(t,N).

4.4.13 Countermeasure ranking

For each countermeasure (network variant) N’ , the difference between the risk in the system with

the countermeasure and the risk in the system without the countermeasure is calculated. The


37/59

37

difference is called the prevented risk and is denoted PR(N,N’). This difference includes all threats for

which the risk is reduced by the countermeasure.

( ) ∑ ( ) ∑ ()

The cost-effectiveness of a countermeasure is the difference between its cost per year (C) and the

prevented risk.

( ) ( ) ( ) Cost-effectiveness is represented in euros per year. The countermeasures can be ranked according to

(a) the prevented risk, and (b) their cost-effectiveness.

This function uses the damage data, and fills the fields Prevented risk* and Cost-effectiveness* in the

countermeasure data.

Countermeasures are then ranked according to prevented risk and/or cost-effectiveness.

4.4.14 Map generation

The user can click a button to generate a map of the network. The user can click on map items to get

more information. Threat, countermeasures, and network evolution snapshots will be selected in

Excel cells and the corresponding network status will be shown in the map component, in particular

in terms of on/off status of network elements and unserved energy. The mapping component will

allow showing different levels of detail, zoom, moving through the network and showing basic

elements properties and affected areas. The user can click on map items to get more information.

4.5 Optimization strategies

The network dynamics module, written in Matlab, has to be called for each loss event. This module

produces a sequence of network states after the event, which is a complex and time-intensive

calculation. Furthermore, this calculation has to be repeated for each countermeasure considered.

Therefore, the user is expected to select a typical loss event associated with a threat. Evaluating all

possible loss events associated with a threat would take prohibitively long. For the same reason, if a

loss event consists of multiple triggering events, all triggering events are assumed to happen

simultaneously.

4.6 Interdependencies

The implementation of the DSS is dependent on the damage assessment module (D2.i), which is

expected in April 2013.


38/59

38

5 Prototype choices

5.1 Prototype threats

For the prototype of the system, we choose to focus on the following threats:

1. Ice/snow storms (natural)2. Nuclear incidents (accidental)

3. Cyber attacks (intentional)

5.2 Prototype functionality

The following functionality is limited in the prototype:

1. All network, threat, loss and countermeasure data should be provided by the user in an Excel

file. This includes a load curve of the expected loads. The format of this file will be

determined in by the implementation, based on the data models outlined in this document.

Documentation and templates will be provided.2. Countermeasures will need to be network-specific. The prototype will not assist in mapping

generic countermeasures to concrete implementations.

3. Only discrete threat data are supported. Each threat level (e.g. earthquake magnitude) needs

to be listed as a separate threat.

4. Vulnerability functions (mapping threat capability to vulnerability) are not considered part of

the DSS. The user can still use such functions, by supplying the function in the associated

Excel cells, thereby enabling automatic calculation of the vulnerabilities for the different

threat capability levels. The vulnerability function will determine the contents of the

vulnerability cells for a particular threat type (e.g. earthquake).

5. Dependencies between threats (e.g. simultaneous volcanic eruption and earthquakes) and

between loss events (multiple loss events due to same threat) are not calculated

automatically.

6. The DSS does not support new vulnerabilities or loss events introduced by the

countermeasures.


39/59

39

6 Conclusions and recommendationsThis document provides the system specification for the SESAME decision support system. The goal

of the DSS is supporting decisions on investment in the security of transmission grids.

A risk management framework has been devised, following the Risk Taxonomy of The Open Group,

to serve as a basis for the decision support system. The ranking of threats is based on their induced

risk, and the ranking of countermeasures on their prevented risk. Interfaces have been defined

between the central system and the network simulation (Polito) and damage assessment (EI-JKU)

modules. A flowchart of the system was constructed and refined to the level of individual system

modules and algorithms. For all relevant interfaces, the data fields have been specified. Optimisation

strategies have been defined in order to limit the number of calls to computation-intensive modules.

This report represents the current state of knowledge within the SESAME project. Based on this

report, the DSS will be implemented in Work Package 5, and used in case studies in Work Packages 6

and 7. When results of these activities lead to new insights in requirements or architectures, the DSS

specification may need to be revised. This report also leaves room for future extensions to the DSS,

notably in terms of automatic calculation of parameters that are currently foreseen to be entered

manually.


40/59

40

Appendix A: Network data

When the data type is in red, the field is mandatory. When it is purple, it is optional. When is it blue,

it is not related to the calculations (e.g. a name).

SIMULATION PARAMETERS


1 MAN_INITIME Human decision initiating time (min) Integer (+)1

2 EACHPF_TIME Time interval for each PF calculation (min) Integer (+)

3 EACHOPF_TIME Time interval for each OPF calculation (min) Integer (+)

4 SIM_ENDTIME Simulation End Time (min) Integer (+)

5 LOSSDATE Date of Loss Event (YYYY/MM/DD) YYYY/MM/DD

6 LOSSTIME Time of Loss Event (the time in the text format includingthe hour and the minute without separation (0820

means at 20 minutes past 8, 1400 means at 2 o’clock in

the afternoon))

Integer (+)

SYSTEM BASE


1 BASE_MW Base MW Integer (+)

2 REF_FREQ Reference Frequency (Hz) Integer (+)

3 KRS Whole system power frequency characteristic (MW/Hz) Float (+)

GENERATOR DATA INPUT


1 BUS_NAME bus name String2

2 BUS_NUMBER bus number Integer (+)

3 ID Id number of the generator on this bus Integer (+)

4 GEN_STATUS status, (1)- in service, (0) - out of service Boolean

5 GEN_MW Pg, real power output (MW) Float (+)

6 GEN_MVAR Qg, reactive power output (MVAr) Float (+/-)

7 SET_VOLT Vg, voltage magnitude setpoint (p.u.) Float (+)8 AGC Status of AGC, (1)- in service, (0) - out of service Boolean

9 AVR Status of AVR, (1)- in service, (0) - out of service Boolean

10 BLK_STRT Flag for black start Boolean

11 MIN_MW Pmin, operational minimum real power output(MW)

Float (+)

12 MAX_MW Pmax, operational maximum real power output(MW)

Float (+)

13 MIN_MVAR Qmin, operational minimum reactive power output(MVAr)

Float (+/-)

1 Red color emphasizes that the corresponding parameter must be provided. Otherwise the simulation cannot

be run.2 Blue color shows the parameters or information which should not pass to the IRS.


41/59

41

14 MAX_MVAR Qmax, operational maximum reactive power output(MVAr)

Float (+/-)

15 REG_BAND regulated band (MW) Float (+)

16 SCH_POWER Scheduled point (MW) Float (+)

17 MBASE MBase, total MVA base of machine, defaults tobaseMVA

Float (+)

18 PC1 Pc1, lower real power output of PQ capability curve(MW)

Float (+)1

19 PC2 Pc2, upper real power output of PQ capability curve(MW)

Float (+)2

20 QC1MIN Qc1min, minimum reactive power output at Pc1(MVAr)

Float (+/-)

21 QC1MAX Qc1max, maximum reactive power output at Pc1(MVAr)

Float (+/-)

22 QC2MIN Qc2min, minimum reactive power output at Pc2(MVAr)

Float (+/-)

23 QC2MAX Qc2max, maximum reactive power output at Pc2(MVAr)

Float (+/-)

24 RAMP_AGC ramp rate for load following/AGC (MW/min) Float (+)

25 RAMP_10 ramp rate for 10 minute reserves (MW) Float (+)

26 RAMP_30 ramp rate for 30 minute reserves (MW) Float (+)

27 RAMP_Q ramp rate for reactive power (2 sec timescale)(MVAr/min)

Float (+)

28 KG drop of the generation (MW/Hz) Float (+)

29 SEC_BAND reserved power for secondary control (MW) Float (+)

30 EQUI_COEFF an equivalent index to define the P-Q capacity ofthe generator (1-1.14)

Float (+)

31 PRIORITY starting priority in case of black start in an island Integer (+)

32 OF over frequency protection limit (Hz) Float (+)

33 UF under frequency protection limit (Hz) Float (+)

34 OV over voltage protection limit (p.u.) Float (+)

35 UV under voltage protection limit (p.u.) Float (+)

36 OV_DELAY over voltage protection delay time (min) Integer (+)

37 UV_DELAY under voltage protection delay time (min) Integer (+)

38 FREQ_BLOCK frequency protection status, (0)- in service, (1) - outof service

Boolean

39 VOLT_BLOCK voltage protection status, (0)- in service, (1) - out ofservice

Boolean

40 HOT_STIME Hot Starting Time (min) Integer (+)

41 COLD_STIME Cold Starting Time (min) Integer (+)

42 OPER_COST operational cost (€/MW) Float (+)

43 RESERVE_COST cost of generating the reserved power (€/MW) Float (+)

44 HOTRSTR_COST restoration cost specifying how much it cost to beput into use again as hot (€)

Float (+)

45 COLDRSTR_COST restoration cost specifying how much it cost to be Float (+)

1 Purple means not necessary data; if the corresponding parameters are defined, the IRS can consider them in

the calculations. (Not provided cells must be filled by “NaN”) 2 For columns number 18 to 23 and 30 there are 4 possible situations among which one must be seen:

a) All the parameters under 18 – 23 and 30 on a row are “NaN”,

b) Parameters under 18 – 23 on a row have values and 30 is “NaN”,

c) Parameters under 18 – 23 on a row are “NaN” and 30 has value,

d) All the parameters under 18 – 23 and 30 on a row have values; in this case we consider it the same as b.


42/59

42

put into use again when it is cold (€)

BUS DATA INPUT


1 BUS_NAME Bus name String

2 BUS_NUMBER bus number (positive integer) Integer (+) 3 BUS_TYPE bus type (1 = PQ, 2 = PV, 3 = ref, 4 = isolated) Integer (+)

4 BUS_STATUS bus status, 1 in service, 0 out-of-service Boolean

5 BUS_AREA area number, (positive integer) Integer (+)

6 VM Vm, voltage magnitude (p.u.) Float (+)

7 VA Va, voltage angle (degrees) Float (+)

8 BASE_KV baseKV, base voltage (kV) Float (+)

9 VMAX maxVm, maximum voltage magnitude (p.u.) Float (+)

10 VMIN minVm, minimum voltage magnitude (p.u.) Float (+)

11 RSTR_TIME restoration time specifying after how long it can be put intouse again (min)

Integer (+)

12 RSTR_COST restoration cost specifying how much it cost to be put intouse again (€)

Float (+)

LOAD DATA INPUT


1 BUS_NAME bus name String

2 BUS_NUMBER bus number (positive integer) Integer (+)

3 STATUS load status, 1 consuming, 0 disconnected Boolean

4 PD Pd, real power demand (MW) Float (+)

5 QD Qd, reactive power demand (MVAr) Float (+)

6 GS Gs, shunt conductance (MW demanded at V = 1.0 p.u.) Float (+)

7 BS Bs, shunt susceptance (MVAr injected at V = 1.0 p.u.) Float (+)

8 INTRUPTIBLE percentage of un-prioritized load, which can be shed underemergency (%)

Integer (+)

9 SHED_MAX maximum percentage of shed load regardless ofregulations (%)

Integer (+)





14 OV_BLOCK over voltage protection relay status, (0)- in service, (1) -out of service

Boolean

15 UV_BLOCK under voltage protection relay status, (0)- in service, (1) -out of service

Boolean

16 RSTR_TIME restoration time specifying after how long it can be put intouse again (min)

Integer (+)

17 INTRPT_COST Cost of shedding interruptible loads (€/MW) Float (+)

18 SHED_COST Cost of shedding shedable loads (€/MW) Float (+)

19 RSTR_COST restoration cost specifying how much it cost to be put intouse again (€)

Float (+)


43/59

43

CAPACITOR/CONDUCTOR BANK DATA INPUT


1 BUS_NAME bus name String

2 BUS_NUMBER bus number (positive integer) Integer (+)

3 BANK_ID The ID of this bank on this bus Integer (+)4 STATUS bank status, 1 in service, 0 out-of-service Boolean

5 CPNUM_STEPS current number of steps (capacitors) Integer (+)

6 REACTIVE_STEP reactive power of each step (MVar) (capacitors) Float (+)

7 MAXNO_STEPS maximum number of steps (capacitors) Integer (+)

8 CNNUM_STEPS current number of steps (in conductors) Integer (+)

9 ACTIVE_STEP active power of each step (MW) (in conductors) Float (+)

10 MAX_STEPS maximum number of steps (in conductors) Integer (+)





15 PROT_OPERSTS protection relay status, (0)- in service, (1) - out of service Boolean

16RSTR_TIME restoration time specifying after how long it can be put

into use again (min)

Integer (+)

17RSTR_COST restoration cost specifying how much it cost to be put

into use again (€)

Float (+)

LINE DATA INPUT


1 FROM_NUMBER f, from bus number Integer (+)

2 FROM_NAME f, from bus name String

3 TO_NUMBER t, to bus number Integer (+)

4 TO_NAME t, to bus name String

5 CIRCUIT number of line circuit (positive integer) Integer (+)

6 STATUS line status, 1 - in service, 0 - out of service Boolean

7 R r, resistance (p.u.) Float (+)

8 X x, reactance (p.u.) Float (+)

9 B b, total line charging susceptance (p.u.) Float (+)

10 LIMA_MVA rateA, MVA rating A (long term rating) Float (+)

11 LIMB_MVArateB, MVA rating B (short term rating) Float (+)

12 LIMC_MVA rateC, MVA rating C (emergency rating) Float (+)

13 PROT_TIMEDELAY over current protection delay time (min) Integer (+)

14 PROT_OPERSTAT over current protection relay status, (0)- in service,(1) - out of service

Boolean

15 RSTR_TIME restoration time specifying after how long it can beput into use again (min)

Integer (+)

16 RSTR_COST restoration cost specifying how much it cost to be putinto use again (€)

Float (+)


44/59

44

DC LINE DATA INPUT


1 FROM_NUMBER f, from bus number Integer (+)

2 FROM_NAME f, from bus name String

3 TO_NUMBER t, to bus number Integer (+) 4 TO_NAME t, to bus name String

5 CIRCUIT number of line circuit (positive integer) Integer (+)

6 STATUS DC line status, 1 - in service, 0 - out of service Boolean

7 LOSS0 coefficient l0 of constant term of linear loss function(MW)

Float (+)

8 LOSS1 coefficient l1 of linear term of linear loss function(MW/MW)

(ploss = l0 + l1pf , where pf is the flow at the \from" end)

Float (+)

9 R r, resistance (p.u.) Float (+)

10 X x, reactance (p.u.) Float (+)

11 B b, total line charging susceptance (p.u.) Float (+) 12 PF real power flow at “from" bus end (MW), “from" → “to" Float (+/-)

13 PT real power flow at “to" bus end (MW), “from" → “to" Float (+/-)

14 QF reactive power injected at "from" bus end (MVAr) Float (+/-)

15 QT reactive power injected at "to" bus end (MVAr) Float (+/-)

16 VF voltage magnitude setpoint at “from" bus (p.u.) Float (+)

17 VT voltage magnitude setpoint at “to" bus (p.u.) Float (+)

18 PMIN if positive (negative), lower limit on PF (PT) Float (+/-)

19 PMAX if positive (negative), upper limit on PF (PT) Float (+/-)

20 QMINF lower limit on reactive power injection into “from" bus(MVAr)

Float (+/-)

21 QMAXF upper limit on reactive power injection into \from" bus(MVAr)

Float (+/-)

22 QMINT lower limit on reactive power injection

d4_1_sesame decision support system specification

Documents