Definition of use cases for WP7. Deliverable D1.4 of the iTesla Project

(1)

iTesla

Innovative Tools for Electrical System Security within Large Area

Grant agreement number 283012 Funding scheme Collaborative projects

Start date 01.01.2012 Duration 48 months

Call identifier FP7-ENERGY-2011-1

Deliverable D1.4

Definition of use cases for WP 7

Dissemination level

PU Public. X

TSO Restricted to consortium members and TSO members of ENTSO-E (including the Commission Services).

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

(2)

1/ 31

Task: 1.3

Deliverable: D1.4 Responsible Partner: Statnett

Author(s) Approval

Name Visa Name Date

[Statnett] [RTE] [INESC Porto] [KU Leuven] [KTH] [Imperial College] [RSE] [DTU] [AIA] [IPTO] [REN] [ELIA] [TRACTEBEL] [CORESO] Executive Board DIFFUSION LIST

For action For information

All partners

DOCUMENT HISTORY

Index Date Author(s) Main modifications

(3)

2/ 31

Table of content

1. GENERAL PURPOSE OF THE DELIVERABLE ... 3

1.1. GENERAL PURPOSE OF THE USE CASES... 3

1.2. DATA REQUIREMENTS AND THE VALIDATION PROCESS ... 4

2. DEFINITION OF CONTROL ZONES ... 5

3. DEFINITION OF TECHNICAL COMPLEXITIES ... 6

3.1. OVERVIEW OF THE ITESLA TOOLBOX ... 6

3.2. PRINCIPLE OF THE STATIC ONLINE SECURITY ASSESSMENT (TC 1) ... 7

3.2.1. Overall principle of the online security assessment (TC 1 and TC 4) ... 7

3.2.2. Principle of the static online security assessment (TC 1) ... 8

3.2.3. Validation of the TC 1 and dependency with the other TCs ... 8

3.2.4. Data requirements for TC 1 validation process ... 9

3.3. PRINCIPLE OF THE OFF-LINE VALIDATION OF DYNAMIC MODELS (TC 2) ... 10

3.3.1. Contents of the TC 2 process ... 10

3.3.2. Data requirements for validation of the updated models in output of the TC 2 process ... 11

3.4. PRINCIPLE OF THE OFF-LINE DEFINITION OF SCREENING RULES (TC 3) ... 11

3.4.1. Specification of the TC3 Validation Process ... 12

3.4.2. Data Requirements for TC 3 Validation Process ... 12

3.5. PRINCIPLE OF THE DYNAMIC ONLINE SECURITY ASSESSMENT (TC 4) ... 13

3.5.1. Data requirements for the TC 4 validation process ... 14

3.6. PRINCIPLE OF THE DEFENSE PLANS AND RESTORATION (TC 5) ... 14

3.6.1. Data requirements for TC 5 assessment and benchmarking ... 15

4. SHORT DESCRIPTION OF USE CASES FOR VALIDATION ... 16

4.1. TECHNICAL COMPLEXITY 1 – STATIC ONLINE SECURITY ASSESSMENT ... 16

4.1.1. Cases for CZ 1: Pan-European level ... 16

4.1.2. Cases for CZ 2: National level ... 17

4.2. TECHNICAL COMPLEXITY 2 – OFFLINE VALIDATION OF DYNAMIC MODELS ... 21

4.2.3. Cases for CZ 3: Subset of National level ... 22

4.3. TECHNICAL COMPLEXITY 3 – OFFLINE DEFINITION OF SCREENING RULES ... 23

4.4. TECHNICAL COMPLEXITY 4 – DYNAMIC ONLINE SECURITY ASSESSMENT ... 25

4.5. TECHNICAL COMPLEXITY 5 – DEFENCE PLANS AND RESTORATION ... 26

(4)

3/ 31

1. G

ENERAL PURPOSE OF THE DELIVERABLE

This deliverable presents use cases to be utilized in testing and validating the iTesla toolbox performance. This validation will be performed in Work Package 7 (WP 7) of the iTesla project, to begin when the toolbox is developed. In order to progressively validate the developed toolbox the use cases for validation cover different control zones (CZ) and technical complexities (TC). This deliverable describes the control zones and technical complexities, and presents some suggested use cases from the TSO participants of the project. The use cases that are briefly presented in this deliverable are not to be used in the development work of the toolbox. Different cases will be used during the development phase of the different modules; these cases will be defined internally in the corresponding WPs.

The validation process methodology will be described further in deliverable D7.1. It is important that TSO data confidentiality issues are handled carefully during the validation process. In order to avoid confidentiality issues, it is planned that each TSO can validate its own cases internally, and share the results with the project. The data collection for the use cases will be performed as part of WP 2.6 and the specific WP 7 tasks.

1.1. General purpose of the use cases

The scope of defining use cases is to provide real historical cases where the current tools used by the TSOs did not manage to carry out their expected task (e.g. determining and highlighting a potentially insecure operating condition) for a particular operating situation. In other words, the use cases are situations where the current tools were at or beyond their limits to operate the electrical system in a coordinated and stable mode. These cases can then be used to show where the iTesla toolbox may have helped the TSOs, thus underlining the added value of the iTesla toolbox. In WP 7 the cases will be used to validate that the developed iTesla toolbox actually provides the necessary information to operate the power system according to a secure operating state.

A situation of interest needs to reflect very specific events to be handled by the operator, such as:  frequency related events

 voltage stability related events

 transient stability related events and small signal stability related events, such as inter-area oscillations

 stressed operating situations leading to congestions

 situations requesting coordinated actions from several TSOs

 situations where defence plans were activated, or system restoration was required

Therefore, TSOs must document events leading to frequency deviations, load loss, loss of generation units, power oscillations and voltage collapse. This includes data such as PMU measurements, a detailed chronology of the events and any related information. For example, in order to reconstruct a scenario with a high level of detail, information about meteorology, conditions (staged test, disturbances etc.) as well as information of topology changes (with associated adequate points of time) might be necessary.

To validate the power system as whole, factors involved in the development of the scenario need to be known with great precision. This includes knowledge of corrective or emergency actions to be performed by operators, and the occurrence of external faults. This is necessary to correlate the measurements (time-series) with the event so that it can be replicated by simulation. In addition, information of external

(5)

4/ 31 factors, such as lightning strikes or other meteorological activity, might help to better correlate observable phenomena in the time-series available from the different measurements collected.

1.2. Data requirements and the validation process

A general check for data availability has been made for each of the use cases presented. However, the different steps of the validation process will better indicate the quality of the data provided and determine if the data available is sufficient for a successful validation process using the iTesla toolbox. For example, available dynamic data quality will have a significant impact on the quality of results of TC 3 and TC 4 that may affect the full validation process (in particular TC 3).

Interesting events may occur before the start of the validation process which itself won‟t begin until later in the project period. Depending on their level of interest, these events might be of higher priority than those presented below. Additional development in specific work packages may also create the need for other use cases than those presented in this deliverable. At this stage, some toolbox modules are very early in the development process and some modules have not yet started. These factors may also create the need for new use cases which are not identified in this deliverable. Data availability and confidentiality issues may also affect which use cases are actually used for validation. In addition the validation procedures that will be proposed in WP 7 may require additional cases for validation.

(6)

5/ 31

2. D

EFINITION OF CONTROL ZONES

Three control zones related to geographical or organizational area will be considered. This allows for progressive testing of the iTesla toolbox performance at various levels with increasingly large power systems from a national level up to the pan-European level.

Control Zone 1 (CZ 1) – Pan-European level

As an alternative to the pan-European level, an attempt may be made at a regional level encompassing several countries and corresponding TSOs. The clear need here is to increase coordination among TSOs and to harmonize operating procedures. Especially for dynamic security assessment, collecting data from real life cases from a large area has proven to be difficult.

A common use case with the Umbrella-project proposed by iTesla will be part of CZ 1. This case is presented in Chapter 4.1.1.

Control Zone 2 (CZ 2) – National level

For the national level it is of interest to look closer at different types of power systems, e.g. geographical areas with a meshed grid, like in central Europe, less meshed areas with large power flows over long distances, like in the Nordic region and also areas with a significant penetration of renewable generation sources.

Control Zone 3 (CZ 3) – Sub-set of national level

This control zone is only applied for the Offline validation of dynamic models – TC 2. This will validate components and aggregated components in the grid.

(7)

6/ 31

3. D

EFINITION OF

T

ECHNICAL COMPLEXITIES

Five incremental levels of technical complexity will be covered; these are related to the different work packages of the iTesla project, and address different parts of the iTesla toolbox (TC 1, TC 2, TC 3 and TC 4) or methodology aspects (TC 5). The five technical complexities that will be addressed are:

TC 1 – Static online security assessment (related to the work developed in WP 5) involving

uncertainties and different time horizons (from D-2 to real time) with corrective and preventive actions. This is mainly a filtering process where minor contingencies will not require any specific action. Remaining contingencies will be studied more precisely.

TC 2 – Offline validation of dynamic models (related to the work developed in WP 3) including

validation of new primary components (like the planned France-Spain DC link and aggregated models of Wind farms), and the validation of dynamic models based on recorded events using time synchronized measurements from PMUs. As output, more accurate dynamic models will be made available to improve the quality of the time domain simulations used in TC 3 and TC 4.

TC 3 – Offline definition of screening rules (related to the work developed in WP 4) able to capture

some dynamic behaviours of the power system based on a large number of time domain simulations. The offline screening rules will be used in the online process covered by TC 1 to speed up the online contingency analysis by minimizing the number of online time domain simulations.

TC 4 – Dynamic online security assessment (related to the work developed in WP 5) taking into

account uncertainties, preventive/corrective actions for contingencies that could not be considered as safe in the static online security assessment, TC 1.

TC 5 – Defence plans and restoration (related to the work developed in WP 6) including synchronized

measurements from PMUs and the integration of renewable energy sources in the process. Dedicated test cases will be defined to benchmark the methodologies for defence and restoration plans proposed by WP6.

3.1. Overview of the iTesla toolbox

Figure 1 below gives an overview of the iTesla toolbox, showing the main connections between the online platform (TC 1 ad TC 4) and the offline platform (TC 3). TC 5 (WP6), in a yellow box in the figure, focuses more on methodology issues and TC 2 (WP 3), also in a yellow box in the figure, aims to validate dynamic models used in modules requiring time domain simulation (TC 3 and TC 4). The figure also shows the data management layer that includes data mining functionalities required by both offline and online analysis.

(8)

7/ 31 Figure 1: Global overview of the iTesla toolbox, showing the online and offline platform

The following subsections elaborate on the principle behind each of the technical complexities, and what is the required input and data for each of them in order to perform the validation in WP 7. More details on the development work of each toolbox module can be found in the deliverables from the specific WPs.

3.2. Principle of the Static online security assessment (TC 1)

3.2.1. Overall principle of the online security assessment (TC 1 and TC 4)

Online security assessment in its entirety (both the static (TC 1) and dynamic (TC 4) parts) provides advice to the operators (but is not meant to override their decision) on:

Diagnosis: Faults or disturbances that may or may not lead to operational constraints

Advice: Actions required by the operators (corrective (post-contingency) and/or preventive (pre-contingency)) to avoid or limit the impact of problems in case of faults or severe disturbances

We divide the online security assessment into two parts, each one related to a technical complexity: First, the static security assessment, TC 1, uses methods based on static computations such as Worst Case Approach (WCA), Fuzzy Power Flow (FPF) and “Monte-Carlo like approach” (MCLA). This is mainly done to filter contingencies in a conservative way, and to keep only the ones that need further investigations for the second step.

The second step is the dynamic security assessment, TC 4, which runs dynamic simulations for contingencies that could not be filtered with the “static online security assessment process”. This

(9)

8/ 31 step has higher technical complexity and is handled in another section of this document (see TC 4 description).

3.2.2. Principle of the static online security assessment (TC 1)

The three modules of the static part, TC 1, are briefly presented below and have different data requirements that are presented in Table 1 in sub-chapter 3.2.4.

The Worst Case Approach (WCA) is a conservative approach used to filter contingencies using a DC approximation optimization that takes uncertainties into consideration. DC approximation (uncertainties include only the active components) is requested here in order to have a linear optimization problem guaranteeing that a solution can be found. At the end of the process, contingencies are sorted into different clusters according to their severity. Contingencies considered as safe in the WCA will be shown as safe to the operator.

The Fuzzy Power Flow (FPF) may be tested to provide a second filtering step. The network is the same as for the WCA, but the uncertainties include their reactive component. As output, the FPF gives intervals of trust for each variable. These intervals can be compared with offline criteria for each contingency.

The Monte-Carlo Like Approach (MCLA) is added for contingencies that could not be filtered by the two previous steps. As input to this module, we have one base case with the non-filtered contingencies plus trust intervals modelling the uncertainties of some state variables of this base case. Given these base case uncertainties, we can derive several cases similarly to a Monte-Carlo sampling process in order to cover the trust intervals as well as possible.

Then on each of these cases derived from this sampling process, a load flow is performed. The results are compared with the rich offline criteria (obtained from TC 3 process) which are supposed to be less conservative and expressed based on the pre-contingency state.

3.2.3. Validation of the TC 1 and dependency with the other TCs

In practice, we have two possible options to realize the process of validation using a TC 1 case: Option 1: Validation with arbitrary offline rules:

Some defined TC 1 cases will not necessarily have complementary data to run a TC 3 process (generation of offline security rules), since it requires massive use of dynamic simulations which implies availability of both dynamic data and corresponding historical data for data mining.

Therefore, offline rules have to be arbitrarily fixed. However, the first option is only capable to validate the mechanism of filtering, but the results of the filtering process may not be realistic (quality of filtering will not be validated in step 1). It is recommended in option 1 to use pessimistic arbitrary offline rules to have a low power of filtering and to have a large number of contingencies assessed in the different tasks of the TC 1 (WCA, FPF and MCLA).

Option 2: Validation using offline rules resulting from a TC 3 process:

Here the validation is expected to go beyond that of the previous option. This means running a complete TC 3 process (see chapter 3.4) to extract realistic offline rules to be tested online. This allows a qualitative

(10)

9/ 31 validation of the filtering process and gives a good evaluation of the power of filtering of the static online analysis.

3.2.4. Data requirements for TC 1 validation process

Table 1 presents, for each step, the required data to run a TC 1 validation process. Table 1: Data requirements for TC 1 validation cases

TC 1 data needs

Step 1: (TC 1 only) Step 2: (TC 1 following a TC 3 process)

Uncertainties

Arbitrary uncertainties

will be chosen as input as historical data has not been mined

Intervals of injection with correlation (this is deduced from iTesla‟s data mining of similar situations):

For the WCA: they must be expressed in the DC approximation since a DC optimization is made (mainly stochastic active power injection)

For the FPF, uncertainties must be expressed for AC load flow variables (mainly stochastic active and reactive power injection)

Contingencies Simplified DC version for the WCA + AC static version

Risk/offline criteria

Arbitrary fixed in TC 1 validation process since no screening rules have been computed in the TC 3 process

Offline criteria per contingencies (simplified DC version for WCA) (deduced from TC 3)

Actions Preventive and curative actions (simplified DC version for WCA) (list and description of relevant actions usable in the context of the associated base case)

Grid Forecasts (DACF, D2CF, IDCF files) and snapshots of the studied grid at the given date of the TC 1 case Contingency list Actions (DC) TC 3 Offline Criteria (DC) Uncertainties (DC) Base case WCA fil te rin g p ro ce ss FPF fil te rin g p ro ce ss MCLA fi lter in g p ro ce ss Contingencies not filtered by WCA TC 3 Offline Criteria (AC) Uncertainties (AC) Contingencies not filtered by FPF Remaining contingencies not filtered by TC 1

(11)

10/ 31

3.3. Principle of the Off-line validation of dynamic models (TC 2)

The off-line validation process provides accurate device models for phasor time domain simulations. In addition, it can provide a measure of the quality of system level models and offer recommendations to the correction of these models. This is done by improving existing models through comparison of phasor time domain simulation output with reference data. The reference data must be higher bandwidth signals: measurements (such as PMUs or Digital fault recorders (DFR) time-stamped and synchronized records) or, if not available, higher bandwidth simulation results (such as EMTP).

The process of validation is synthesized in Figure 3.

(1) Prior Knowledge (Experience) Parameter Tuning Choice of Model Structure (2) Criterion fit: - fitting the data?

- purpose of the model? (3)

OK! Model meets the performance criteria/ indicator. Not OK! Revise from (1), (2), or (3) Experiment Design (Staged Tests) Data (System Measured Response)

Assumed Model Structure(s)

(Model of the System During

the Test) Simulate the Model

(System Simulated Response)

Chosen Criterion of Fit

(Performance Indicator)

Validate the Model

(Model of the System During the Test)

?

Figure 3: Main scheme of the WP3 process of validation of dynamic models

The output of this process are the updated values of the parameters model and/or recommendations if the provided device model is not accurate enough for a type of studied dynamic phenomenon used in the validation process.

In particular, the WP 3 validation process provides models of aggregated renewable generation and a model of the new VSC link between France and Spain. In addition, it provides a methodology to validate and correct system level models.

3.3.1. Contents of the TC 2 process

The TC 2 process uses the improved models from the WP 3 validation process. This validation process uses a different scenario (different date and different event) than those used during the development of the WP3‟s validation tool. Phasor time domain simulations will be run using the improved models and compared to corresponding reference data.

In the particular case of the France-Spain VSC line, the reference data will still be produced on the same EMTP equivalent grid but from a different scenario.

(12)

11/ 31

3.3.2. Data requirements for validation of the updated models in output of the TC 2

process

Table 2: Data requirements for TC 2 validation cases

TC 2 data needs Description

Grid Input data to run phasor time domain simulation for a given date (static data, starting point and associated dynamic data)

Validated device Updates of the device model from WP3 validation process (parameters updates or model structure updates)

Reference data Measurements (such as PMUs or Digital fault recorders (DFR) time-stamped and synchronized records) or synthesized reference data (EMTP simulation results)

Scenario Description of the sequence of events to be simulated during the phasor time domain simulation of the TC 2 process consistent with the reference data

3.4. Principle of the Off-line Definition of screening rules (TC 3)

The off-line definition of screening rules process (TC 3) uses machine learning techniques to build power system stability predictors based on time domain simulation results of a large set of sampled system base cases. The following steps are used to build these rules:

A large range of anticipated network states is generated (iTesla WP 4.1 task) using network models and stochastic load/generation parameters from data mining analysis.

The starting points for the impact analysis are created (WP 4.2).

The security of the power system is then assessed in a set of network contingencies by using high-fidelity time domain simulations (WP 4.3 and WP 4.4). The database of network states and contingencies is analysed to generate predefined security screening rules to be used by TC 1 (construct a decision tree on variables of the system to be used as criteria for online analysis). The final rules produced in this work package avoid the online assessment from checking the security of the power system in states which are labelled as „secure‟ by WP 4. The criteria produced by the offline platform will be forwarded to the online platform (TC 1).

(13)

12/ 31 Figure 4: General scheme of generation of offline security rules

3.4.1. Specification of the TC3 Validation Process

The TC 3 validating process requires either two sets of data or a single dataset split into two parts:

1. A first set trains the algorithm in order to generate screening rules. Ideally, this data corresponds to at least one year of operation.

2. A second set of data, which needs to be completely independent from the data used to train the algorithm, is utilised to test the rules generated. This data covers at least one day of operation of the power system.

3.4.2. Data Requirements for TC 3 Validation Process

(14)

13/ 31 Table 3: Data requirements for TC 3 validation cases

3.5. Principle of the Dynamic online security assessment (TC 4)

This step is directly connected to step TC 1. The main objective of the TC 1 process is to filter contingencies considered as insignificant by using static acceptability rules derived from the TC 3 process. At the end of the TC 1 process, it is highly probable that those conservative offline rules may tag some contingencies as non-secure for the given online case that are, in fact, acceptable. Therefore, further investigation is needed to refine the filtering process with more time consuming methods such as time domain simulations used in TC 4. All contingencies considered as safe from the TC 1 point of view will not be studied here.

As input for this TC 4 step, we may have several static cases from the last TC 1 step of the static online security assessment (please refer to the TC 1 – MCLA approach). Among those static cases, some may remain flagged “non 100% safe” with regard to the TC 1 static filtering process.

On each of these “non 100% safe cases”, a dynamic simulation is performed with: the given contingency at t=0s

the security rules specific to each TSO test of preventive actions

the curative actions activated according to violations encountered during the dynamic simulation

TC 3 Required data:

Set of historical data

This set of situations will be needed to apply data mining techniques to generate the input data for the sampling process (WP 4.1).

The historical data required is: load patterns

RES injections cross border flows network topology

power plant technical data (e.g. fuel type, maximum output, etc.)

power plant cost data

unit dispatch/maintenance status

All the above are needed to identify a realistic starting point (WP 4.2) for each sample from WP 4.1.

Network and dynamic models compatible with the historical data set

This is necessary data to run dynamic simulations for the impact assessment (WP 4.3/WP 4.4)

Operational data

TC 3 also needs all TSO-specific security standards that can have an impact on system operation (e.g. reserve requirements) , possible network topologies, a list of contingencies to analyse and a list of automatic corrective actions linked to this set of contingencies

(15)

14/ 31 Synthetic results are then presented to the operators, showing the remaining contingencies that are not considered as safe. If available, the platform will present possible preventive actions to make the impact of the contingencies acceptable in terms of safety of the grid.

Of necessity, this process is done after the static online security assessment (TC 1) process. The results from the static security assessment from the same case must be available as input.

3.5.1. Data requirements for the TC 4 validation process

Dynamic data covering the same area as the static data is needed to perform the dynamic simulations

(including automatic curative actions implemented through automatons).

In addition, a set of curative and preventive actions is needed, if they are configured in the platform so that this set can be tested through the “last time to decide” approach-module, which tries to minimize the required preventive actions using iterative runs of dynamics simulations.

TSO’s security rules are required if they have been configured as input such that the dynamic simulator

takes them into account.

3.6. Principle of the Defense plans and restoration (TC 5)

Dedicated test cases are defined to benchmark methodologies for defence plans and system restoration proposed by WP 6.

This work package complements WP 5 as it handles the low probability/high impact cases that are not captured by the online security assessment performed in WP 5 (TC 1 and TC 4). Figure 6 shows the ENTSO-E definition of power system states, which illustrates that the defence plan is the ultimate

TC 1 non-filtered Contingencies list

Preventive and curative actions

Dynamic data on the TC 1 covering the area of the static base case perimeter

TSO Security Rules

TC 1 multiple base cases from the MCLA approach O nl ine dyn am ic ana lys is Contingencies leading to unacceptable grid states and recommendations to the operator in terms of preventive actions to be implemented

(16)

15/ 31 safeguard against system collapse, while the task of the system restoration is to bring the system back to a safe normal operation state in case that a blackout could not be avoided.

Figure 6:Different states of a power system [ENTSO-E technical background and recommendations for defence plans in

the continental Europe synchronous area]

The mitigation of the consequences of major disturbances is consequently dealt with in two steps:

1. Defence of the interconnected system against the disturbances aiming to avoid a major blackout, possibly by sacrificing parts of the interconnected system.

2. Secure and swift restoration of system after a blackout.

The assessment and benchmarking of defence plans focuses on the recommendations for integration of renewable generation and the impact of increased loading of tie lines. The assessment and benchmarking of system restoration focuses on the hierarchical coordinated restoration from a major blackout

3.6.1. Data requirements for TC 5 assessment and benchmarking

Table 4: Data requirements for TC 5 validation cases

TC 5 data needs Description

System model

Phasor (fundamental frequency positive sequence) model including: Static grid data

Dynamic plants data, as a minimum for governors and prime movers (possibly hidden models, type specific or generic models)

Description of defence plan

Protection levels and reaction times – frequency and voltage protection

Critical cases data

Data for cases with cascading events threatening to develop to a blackout:

Initial load flow data prior to the disturbance

Telemetry data prior to and during the disturbance – PMUs or DFRs (Digital Fault Recorders)

(17)

16/ 31

4. S

HORT DESCRIPTION OF USE CASES FOR VALIDATION

The following section briefly summarizes the provided use cases available at this stage in the project. They are divided into technical complexities and control zones, as described above.

A short summary of the suggested use cases is presented in Table 5 below. The cases are specific for each cell of the table, unless they are marked with an asterisk (*). The use cases marked with * symbolizes that the same case is used for validation in different TCs within the control zone. The use cases that are reused for different TCs are only presented once in the following sub-chapters of chapter 4.

Table 5: Summary of use cases for validation, separated in control zones and technical complexity

TC 1 TC 2 TC 3 TC 4 TC 5

CZ 1 Case A* Case A Case A*

Case B Case A* Case A CZ 2 Case A* Case B* Case C* Case D* Case E Case A Case B Case A* Case B* Case C* Case D* Case A* Case B* Case C* Case D* Case A Case B CZ 3 Case A Case B

4.1. Technical complexity 1 – Static online security assessment

4.1.1. Cases for CZ 1: Pan-European level

CZ 1 TC 1 UC A: CORESO/RTE (same case used for TC 3 and TC 4)

This case will be proposed to the Umbrella-project as the common Umbrella-iTesla case, since it presents an example of coordination needs to manage day-ahead N-1 violations in an area operated by several TSOs.

Title: CORESO coordination case, February 8-12, 2012 (Suggested as Umbrella-iTesla common use case) TC and CZ

addressed:

TC 1: Static online security assessment – CZ 1 - Use Case A TC 3: Offline definition of screening rules – CZ 1 - Use Case A TC 4: Dynamic online security assessment – CZ 1 - Use Case A

General description:

Use case on Pan-European level handled by CORESO in the week of February 8-12, 2012. Situation stressed all day long, especially during peak load intervals. This was the most stressed week of winter 2012, with a particularly high load demand due to low temperatures.

The problem was identified in D-1. Commercial exchanges were at their maximum at some borders in the north to south direction with several N-1 violations at ELIA, RTE and Amprion. High loop flows identified from north to south. Day-ahead studies‟ conclusions: CORESO informed Amprion that coordination and internal re-dispatching were necessary to cope with the identified constraints. Amprion took local measures.

In intraday, more capacity in the direction of France was sold, and in real-time the French consumption was higher than expected.

(18)

17/ 31 D2CF dataset from 06/02 for 08/02.

This is an ex-post analysis. It has to be mentioned that for the NTC verification almost all Flags were green.

Events on the following day:

Zandvliet PST forced outage (Buchholz alarm) on Friday 10/02/2012 Consequence: more flows through Germany

On the 13/02 during the night:

o D-2 capacity calculation: Amprion RT operator requests capacity reduction for Monday (to ELIA RT operator) after the sending of the green flag by SSC

o Calculations done by Coreso some overloads but it did not request capacity reduction

Why is this a use case for iTesla:

This is the most stressed week of winter 2012 with a particularly high load demand due to low temperatures.

High loop flows could not be solved by a TSO on its own, coordinated actions were needed at a European level.

How can the iTesla toolbox address this use case:

iTesla could provide added value on the two following topics:

Propose more coordinated preventive actions at a European level to resolve constraints that cannot be handled at a national level

Give a better evaluation of the load and renewable generation uncertainties, give delta between the realized data and the real time data.

4.1.2. Cases for CZ 2: National level

CZ 2 TC 1 UC A: RTE (same case used for TC 3 and TC 4)

Title: France, February 8, 2012. Stressed situation on the French grid. TC and CZ

addressed:

TC 1: Static online security assessment – CZ 2 - Use Case A TC 3: Offline definition of screening rules – CZ 2 - Use Case A TC 4: Dynamic online security assessment – CZ 2 - Use Case A

This use case concerns a highly stressed situation in the French network. On this day the French grid was subjected to a very high level of consumption, due to a period of extreme cold. This resulted in implementing very costly means of production to relieve the grid and meet demand. The event lasted for half an hour. The security analysis made in advance had not taken into account N-2 fault. N-1 rule had been respected but some of the N-2 faults tend to be more likely than some of the N-1 faults.

A number of external factors also contributed to this event:

A bad forecast of the consumption had been made in D-1 (The forecast was more optimistic than the real situation.)

An outage of a power unit for maintenance was incorrectly studied in D-1 The emergency response plans were needed to contain the event. After 10s an automatic load-shedding automaton was triggered on a low voltage criterion. In addition, costly generation was needed to meet the consumption.

The available tools were able to detect, assess and manage the event. Still, more accurate data related to power units is needed. Therefore, a revision and optimization of the way the current tools are used would be advisable.

To perform the security analysis for this event the following data is needed for each of these TC‟s:

(19)

18/ 31 TC 1: static modelling of the grid

TC 3 TC 4: Network modelling THT-HT-load tap changers and their dynamics

TC 3 and TC 4: In D-1, build lists of N-2 binding (ex: N-2 power units or N-1 double line)

TC 3: Need of historical data to build offline criteria Why is this a

use case for iTesla:

Because it reaches a consumption record in France and the situation is therefore very stressed, with the need of implementing costly means of production

iTesla could provide added value on the two following topics: How variants of this event could be treated more efficiently Improve the current implemented tools

CZ 2 TC 1 UC B: RTE (same case used for TC 3 and TC 4)

Title: France, March 5-6, 2012. Sticky snow.

TC and CZ addressed:

TC 1: Static online security assessment – CZ 2 - Use Case B TC 3: Offline definition of screening rules – CZ 2 -Use Case B TC 4: Dynamic online security assessment – CZ 2 - Use case B Possibly also:

TC 5: Defence plans and restoration

The cause of this event is a natural phenomenon, namely snow sticking to overhead lines. The sticky snow phenomenon provoked cascading events through a specific region of France.

Detailed information of the use case:

Total interrupted load: ~200 (MW) Average load restoration time: ~480 (minutes) Energy not supplied: ~250 (MWh) Severity of the incident (total duration): ~480 (minutes)

The tools needed up to one hour to determine the severity of the event and to initiate emergency plans. Consequently, a significant part of load was interrupted. There were sufficient tools available to cope with this kind of case. Still, it remains difficult to predict the chronologic sequence of events. Therefore, it is also difficult to determine the optimal methodology for containing these events.

This type of phenomena is very difficult to simulate correctly with current tools. How can the

iTesla toolbox address this use case:

iTesla could provide added value on the following topics:

Assess the adequacy of current tools for cascading events Make recommendations on cascade triggers

Based on the analysis and recommendations, variations of this case can be dealt with more efficiently in the future.

CZ 2 TC 1 UC C: REN (same case used for TC 3 and TC 4)

Title: Portugal, December 23, 2009

(20)

19/ 31 addressed: _{TC 3: Offline definition of screening rules – CZ 2 - Use Case C}

TC 4: Dynamic online security assessment – CZ 2 - Use Case C

There were two events both caused by natural phenomena; the 1st one occurred at 02:38 in the south part of Portugal (Algarve) and the 2nd event was in the north of Lisbon at 04:34. The extreme high wind conditions (> 200 km/h) damaged 27 pylons. The meteorological phenomenon that caused both events is called explosive cyclogenesis.

At Algarve, one 150 kV overhead line had 4 pylons damaged and a new 400 kV overhead line in construction lost 9 pylons. The Distribution network was affected but only a few customers experienced interruptions. North of Lisbon, one single 220 kV line lost 2 pylons, one double 220 kV line lost 6 pylons and one single 400 kV line lost 6 pylons.

The left figure shows the damaged pylon in the Algarves. On the right the figure shows the damaged pylons in the north of Lisbon.

Since it was the day before Christmas, the load was low and the system was able to cope with this rare event. The main issue was the fact that too many distribution customers in the affected area had no electricity between Christmas and New Year‟s Eve and local commercial businesses were affected.

To guarantee the security of supply in the greater Lisbon area, namely for expected voltage collapse during the restoration days of the high voltage lines located in the north of Lisbon, mobilization of expensive thermal generation in the Lisbon area was necessary, instead of the cheaper hydro generation in the north of the country. The security tools installed were not able to asses and manage the event because, during the design of the tools, such an event was considered to be very unlikely. Such an event is also not included in the ENTSO-E security policy. These contingencies should be considered if probabilistic risk assessment is to be implemented. These extreme wind conditions appear not to be so rare and should thus be taken into account.

It was a situation where local extreme wind conditions were observed and some High Voltage towers and cables were seriously damaged for weeks. This led to operation of the grid based on empirical knowledge for several weeks. The iTesla toolbox could help evaluate system security and define alternative actions (if needed) to operate the network in these extreme conditions.

iTesla could provide added value on the two following topics: Consider a probabilistic approach or

Consider an “extreme contingency list” for this kind of situation.

CZ 2 TC 1 UC D: Statnett (same case used for TC 3 and TC 4)

Title: Norway, January 2013

(21)

20/ 31 addressed: _{TC 3: Offline definition of screening rules – CZ 2 - Use Case D}

TC 4: Dynamic online security assessment – CZ 2 - Use case D General

description:

Before and during the event there was cold weather, with icing of lines and a lot of wind. There were several single-phase faults, leading to loss of a line, and manual disconnection of a line. The line was reconnected later the same day.

This is a use case where the iTesla toolbox can prove the validity and performance of its static security tools.

iTesla could provide added value to:

prove the validity and performance of its static and dynamic security tools.

CZ 2 TC 1 UC E: IPTO

Title: Greece, July 24, 2007 TC and CZ

addressed:

TC 1: Static online security assessment – CZ 2 - Use Case E Possibly also (depending on data availability from neighbours):

TC 3: Offline definition of screening rules TC 4: Dynamic online security assessment

Before the incident, countries in the block (Greece, Albania and the Former Yougoslav Republic of Macedonia- FYROM) were net importers with Greece being in a high load condition (10150 MW). In addition, it should be mentioned that on July 24, the weather was extremely warm, and a lot of forest fires were taking place in the region. A study performed by the incident investigation committee has shown that the system was N-1 secure, so the tripping of any of the critical 400kV interconnection lines in the region would not result in cascading events.

On the day of the event, two 400kV lines tripped. After this double contingency, tripping of an additional 220kV line took place due to the activation of over-current protection. The result of these incidents was that the block of Greece, FYROM, Albania and the Kosovo region was fed only from one tie-line. Due to the fact that these countries were importing energy, the tie-line was overloaded and at 15:59:56 tripped due to the very high power transfer level. As a result, power systems in Greece, FYROM and Albania were islanded from the UCTE system and frequency dropped down to 48.7 Hz. The formed electrical island split further with the disconnection of FYROM and Albania. This occurred after the tripping of interconnection lines between these countries and Greece due to the activation of under-frequency protection of the lines at 49.3Hz and 48.7Hz respectively.

In the Greek power system, the activation of the 1st and 2nd stages of under-frequency load shedding, below 49 Hz and 48.8 Hz respectively, proved to be effective and a blackout was prevented.

It shows the need for common tools able to analyse and issue warnings in a regional European level.

iTesla could provide added value on the following topic: Prove the validity and performance of its security tools

(22)

21/ 31

4.2. Technical complexity 2 – Offline validation of dynamic models

4.2.1. Cases for CZ 1: Pan-European level

CZ 1 TC 2 UC A: RTE/ELIA/REN

Title: Belgium – Denmark, October 2012 TC and CZ

addressed: TC 2: Offline validation of dynamic models – CZ 1- Use Case A

This case is inherited from study cases of the European project “Twenties”.

Use case on the Pan-European level. The event took place on October 2, 2012. Similar events occurred also on other dates in October. The event in Belgium triggered modal oscillations in Denmark.

Description of the event:

A three phase fault occurred in the neighbourhood of the substation of BRUEGEL in Belgium around 7 a.m. PMU records from the substation Bruegel in Belgium are available.

A similar oscillation happened on October 22nd. This time it resulted in oscillations between Portugal and Denmark, which could be clearly viewed in the amplitude of the 0.25Hz mode.

An excited mode might be relevant for analysis to study the system response to such signal and validate the modelling of the whole system.

One of the two dates is proposed for use in the development of the associated WP 3 tasks and the other date for the TC 2 validation process.

iTesla could provide added value for the system wide validation by: analysing and studying the system response to such a signal

clarifying which external factors contributed to the oscillation and how they can get involved in managing the event.

4.2.2. Cases for CZ 2: National level

CZ 2 TC 2 UC A: Statnett

Title: Norway, January 2010. Voltage stability

TC and CZ addressed:

TC 2: Offline validation of dynamic models – CZ 2 - Use case A Possibly also:

TC 1: Static online security assessment – CZ 2 TC 3: Offline definition of screening rules – CZ 2 TC 4: Dynamic online security assessment – CZ 2 TC 5: Defence plans and restoration – CZ 2 General

description:

Loss of generation because of cold weather led to increased power transfer over a weak power transfer corridor that lead further to a near voltage instability case. The load shedding did not work as planned because there was a fault in the control equipment. The control centre rescued the situation by manual actions.

Why is this a use case for

In the case of modelling validation for voltage stability analysis, this case provides a rich data set for enhancing power system models at the regional level.

(23)

22/ 31 iTesla:

The case could also be used in TC 1, 3 and 4: This is a use case where the iTesla toolbox could prove the validity and performance of its static and dynamic security tools, specifically for near-voltage instability scenarios.

The case can be used in validating the power system models at the regional level in the case of voltage stability analysis.

As a possibility: The static and dynamic security tools, specifically for near-voltage instability scenarios, could be studied and taken in operational use. Current load shedding schemes should be reviewed to ensure their correct operation in a similar situation in the future.

CZ 2 TC 2 UC B: RTE

Title: France, synthetic data case with an EMTP model, TC and CZ

addressed: TC 2: Offline validation of dynamic models – CZ 2 - Use case B General

description:

In 2010, RTE modelled the complete 400kV French network. In 2011, this work was completed with parts of the 225kV network for cable insertion studies.

When only a small number of PMU is available as reference data for the WP3 validation of dynamic models, synthetic data resulting from high bandwidth simulation tools are used as reference data. Various scenarios can be used for EMTP simulations in both the development phase of WP3 and in TC 2 validation process.

The iTesla toolbox may help improve the modelling of phasor models of some devices based on their simulation outputs made with EMTP.

4.2.3. Cases for CZ 3: Subset of National level

This control zone is only used for technical complexity 2, offline validation of dynamic models.

CZ 3 TC 2 UC A: RTE

Title: France, Validation of the VSC line model between France and Spain TC and CZ

addressed: TC 2: Offline validation of dynamic models – CZ 3 - Use case A General

description:

An EMTP model of the VSC line and a small equivalent network around this line has been modelled in order to carry out stability studies in the area.

A phasor equivalent model of the VSC line also exists. As for the TC 2 CZ 2 RTE EMTP case, synthetic data will be generated by EMTP simulation tools and will be used to validate and improve the existing phasor equivalent model.

Since the VSC line will be in operation in 2014, PMU reference data will not be available soon. This case will be used in both development and validation phases but in different scenarios.

(24)

23/ 31

CZ 3 TC 2 UC B: REN

Title: Portugal, May 14, 2012. Fault on feeder of a wind farm TC and CZ

addressed: TC 2: Offline validation of dynamic models – CZ 3 -Use Case B

This case is related to an incident on a line that feeds several 60kV wind farms. The toolbox should deal with an aggregated model comprising characteristics of different generators that are part of these wind farms. In this case, the fault current contribution from each generator will be different for each wind farm/generator. Fault in the 60 kV line connecting several wind farms at CABRIL to REN Substation TORRÃO. The fault was cleared in 70 ms, with an automatic recloser. The fault data is available in COMTRADE format.

This case should be used to validate the dynamic aggregation model by comparing the calculated fault current to the total measured fault current. From a security point of view, this is just a question of contingency analysis (contingency of the 60kV line feed).

The available tools were sufficient to perform the security analysis, as this specific fault had been taken into account. The contingency analysis application had results considering this line feed fault. Thus, after the event, no changes were made in the current security tools.

The iTesla model toolbox should be able to simulate the aggregated model, comprising different generator characteristics, to calculate the total fault current. This case should be used to test and validate the aggregated dynamic model of different wind farm generators, by comparing the calculated values with the actual fault measurements.

iTesla could provide added value on the two following topics:

Modelling dynamic wind farms with different generator characteristics. Simulating the aggregated model, calculating the total current and

comparing the calculated values with the fault measurements.

4.3. Technical complexity 3 – Offline definition of screening rules

4.3.1. Cases for CZ 1: Pan-European level

CZ 1 TC 3 UC A: CORESO/RTE

This case is presented in Chapter 4.1.1

Title: European inter-area oscillations, October – December, 2012 TC and CZ

addressed: TC 3: Offline definition of screening rules- CZ 1 – Use Case B General

description:

In a given area and for a topology not changing too fast, the oscillation modes are the same. However, the damping of a mode depends on the current state of a grid. The modes are excited by faults.

(25)

24/ 31 situations where inter-area oscillations have been detected and to excite a maximum of poorly damped modes in order to deduce criteria in the pre-contingency state guaranteeing that there is no mode insufficiently damped that could be excited.

It is proposed to analyse situations from October to December 2012 where studies, like the one presented in the “TC 2 CZ 1 A case”, showed inter-area oscillations. How can the

The damping of the modes depends on the pre-contingency state. Offline screening rules deduced from a large number of situations might help to easily identify in online analysis poorly damped oscillation modes and their associated unacceptable situations.

4.3.2. Cases for CZ 2: National level

CZ 2 TC 3 UC C: REN

CZ 2 TC 3 UC D: Statnett

CZ 2 TC 3 UC E: ELIA (same case used for TC 4)

Title: Belgium, April 22, 2011 TC and CZ

addressed:

TC 3: Offline definition of screening rules – CZ 2 - Use Case E TC 4: Dynamic online security assessment - CZ 2 - Use Case E

On April 22, 2011, two 380 kV lines in the region of GRAMME - BRUEGEL were out of service for maintenance. Additionally, sometime before, an issue was detected with a certain type of current transformer that is installed in the ELIA 380 kV grid. After an explosion of one of these current transformers, it became apparent that, in case of ambient temperatures above 25°C, the risk of explosion of this type of current transformer increased significantly. As a result of this assessment, it was decided to replace all equipment of this type as soon as possible. Meanwhile, when temperatures above the threshold were measured, the affected transmission lines were to be taken out of service.

As of April 21st temperatures above 25°C were measured, and due to the fact that it had the defective current transformer type installed, this transmission line (parallel to one of the lines already out), needed to be taken out of service as well. As a consequence, the 380kV substation of GRAMME would only be connected to the 400kV ENTSO-E grid by one transmission line.

Before putting this topology into place, the normal security calculation processes were followed, and static assessments were carried out. These assessments revealed no issues: no N-1 overloads were detected on the loss of any equipment in the ELIA grid. However, as the operator did not feel very comfortable with this situation, he requested an additional dynamic analysis by the network expert's

(26)

25/ 31 team. A full-dynamic simulation was performed with the Eurostag tool. The results for the most critical short-circuit event showed that a 200 ms three phase short circuit event occurred on the line which would be the only one connecting the substation of GRAMME to the 400kV ENTSO-E Grid. This fault was cleared by opening the line.

Apparently this short circuit event would provoke unacceptable oscillations on the nuclear units at the site of Tihange (connected to the GRAMME busbar), leading to the loss of synchronism of all the nuclear units at this site (ca. 3000 MW), which is not acceptable.

Finally, it was decided not to open the line 380.36, and to cancel all maintenance work near the current transformers with an elevated risk of explosion.

The criticality of this use case situation was not detected by the systematic processes and assessments that were installed in the different timeframes of the operational planning and preparation process. It was only because of the System Engineers‟ (operators‟) experience that the dangerous situation could be detected, and an ad-hoc dynamic analysis was triggered. The conclusion from this analysis was that the planned grid situation could lead to unacceptable states of the grid after a short-circuit event. As a result, taking a 380kV transmission line out of service was cancelled.

Using the off-line screening rules, the iTesla toolbox should be capable of detecting this dangerous situation in its systematic day-to-day assessments.

Create sufficient off-line screening rules to detect such dangerous situations using systematic on-line assessments. Some way of on-line assessing the risks resulting from dynamic effects should be included in the systematic analyses carried out by the TSOs. At the moment, operator experience is the key to detect such situations as tools are not capable of performing efficient on-line dynamic security assessment.

4.4. Technical complexity 4 – Dynamic online security assessment

4.4.1. Cases for CZ 1: Pan-European level

CZ 1 TC 4 UC A: CORESO/RTE

This case is presented in chapter 4.1.1

4.4.2. Cases for CZ 2: National level

CZ 2 TC 4 UC C: REN

(27)

26/ 31

CZ 2 TC 4 UC D: Statnett

CZ 2 TC 4 UC E: ELIA

4.5. Technical complexity 5 – Defence plans and restoration

4.5.1. Cases for CZ 1: Pan-European level

CZ 1 TC 5 UC A: TRACTEBEL, synthetic case from the PEGASE project

Title: Pan-Europe, November 4, 2006. Synthetic case from the PEGASE project. TC and CZ

addressed: TC 5: Defence plans and restoration – CZ 1 - Use Case A

This scenario is inspired by the November 2006 incident, retaining the dynamical phenomena but not the exact sequence and location of faults and trajectory of frequency. It has been developed in the frame of PEGASE T6.4 to assess the speed and the simulation accuracy of the prototypes developed in the PEGASE project. The scenario is a hypothetical case, not based on historical data. The data is anonymous and the trips of the lines are pre-programmed (not triggered by relays). The dynamical model has been developed within PEGASE WP6 and is based on typical data.

The model includes full dynamics of the system, the triggering events and the wrong actions of the operators that trigger a frequency collapse, modelled as sequence of events.

Cause of the event:

Poor/incorrect operator control actions – e.g. a voltage collapse caused by poor voltage control, failure to maintain N-1 security, etc.

Miscalculation of system operating limits Switching errors

Sequence of events:

After cross-border lines opening (Austria-Hungary, Austria-Slovakia, Germany-Czech Republic, Slovenia-Croatia; Croatia, Romania, Hungary-Serbia, Ukraine-Romania) from time t=10s to t=180s, the load is decreased by 20 % in Germany for under frequency at time t=181s where fifteen generators are also tripped (~ 1900 MW) from t=250s to t=266s. These events lead to the splitting of the network in:

Under-synchronous sub-network (Albania, Bosnia and Herzegovina, Bulgaria, Greece, Croatia, Montenegro, FYROM, Romania, Serbia). Over-synchronous sub-network (Austria, Belgium, Switzerland, Czech

(28)

27/ 31 Netherlands, Poland, Portugal, Slovenia, Slovakia).

Following the cross-border lines opening between Germany and Poland, the Western system itself is split in two over-synchronous sub-networks:

Czech Republic, Hungary, Poland, Slovakia.

Austria, Belgium, Switzerland, Germany, Denmark, Spain, France, Italy, Luxemburg, Netherlands, Portugal, Slovenia.

This is a synthetic use case, which is based on an iconic event. Furthermore, it contains all the ingredients needed for validation of WP 6 on defence plans and restoration.

iTesla could provide added value on the two following topics:

Propose more coordinated defence plans at a European level to resolve constraints that cannot be handled at a national level

Check the influence of RES on defence plans by including in the test case an increasing amount of RES.

4.5.2. Cases for CZ 2: National level

CZ 2 TC 5 UC A: TRACTEBEL, synthetic case from the PEGASE project

Title: Synthetic case from the PEGASE project TC and CZ

addressed: TC 5: Defence plans and restoration – CZ 2 - Use Case A General

description:

This scenario is a loss of a cross-border line between Denmark and Germany resulting in the islanding and blackout of Denmark. This scenario is a synthetic case that has been developed in the framework of PEGASE T6.4 to assess the

(29)

28/ 31 speed and the simulation accuracy of the prototypes developed in the project. As the scenario is a hypothetical case, it is not based on historical events or real snapshots. The data are made anonymous. The dynamical model has been developed within PEGASE WP6 and is based on typical data. The protections have been tuned to obtain the events foreseen and may not be fully realistic. The root causes of this event are operator errors resulting in 3000MW of load interruption. The following errors have been implemented in this case:

Poor/incorrect operator control actions – e.g. failure to maintain N-1 security, etc.

Miscalculation of system operating limits Switching errors

Operators‟ incorrect actions for the reconstruction. Sequence of events:

One cross-border line between Germany and Denmark is opened at 5 seconds. The three remaining cross-border lines on this border trip automatically due to maximum current relays detecting overloaded branches. Consequently, Denmark is islanded and under speed relays stop the 33 machines in this sub-network: the country experiences a blackout.

This synthetic use case contains all the elements needed for validation of WP6 How can the

iTesla could provide added value on the two following topics: To validate coordinated defence plans

To analyse the influence of RES on defence plans and restoration schemes

CZ 2 TC 5 UC B: ELIA

Title: Elia use case for grid restoration, black start TC and CZ

addressed: TC 5: Defence plans and restoration – CZ 2 - Use Case B

Elia has at its disposal a Dispatcher Training Simulator modelling the Belgian grid and capable of performing full dynamic simulations. For example, a grid restoration (black start) is one of the scenarios that were developed on this simulator to test the real-time behaviour of the grid when executing the grid restoration procedures. As one of the goals of the iTesla project is to develop new and better ways/algorithms of restoring a grid after disturbances/blackout, the developed algorithms could be delivered to Elia and tested on their simulator. The test results can then be used by the iTesla partners to validate or improve the outcome of the project.

Tractebel will work together with Elia on this use case. For practical purposes, Tractebel will integrate the developed algorithms in the simulator, run them, and create the results. To avoid confidentiality issues, this integration and testing will be done internally at Elia, and the results will be shared.

The use case can be used to test the algorithms for restoration of the electricity system developed within the iTesla project on the full dynamic simulator of the Elia Grid.

(30)

29/ 31 How can the

It is generally very difficult to test methodologies for grid restoration, as it cannot be tested in real-time situations. Therefore, the use of a full dynamic simulator capable of simulating new methodologies on a realistic situation can be a useful asset for the iTesla project.

(31)

30/ 31