Final Report Summary - ITESLA (Innovative Tools for Electrical System Security within Large Areas) Executive Summary:This document is the final report of the iTesla project co-financed by the Seventh Framework Programme (FP7) of the European Union (Grant Agreement 283012).The iTesla project has developed a toolbox able to support the operation of the pan-European electricity transmission system in the coming years and has validated the different functionalities of this toolbox with datasets of various complexity and size. This toolbox has been designed to support the decision-making process from two-days ahead to real time and to take up the three main following challenges:- to provide a risk-based assessment taking into account the different sources of uncertainties, in particular, those brought by intermittent power generation,- to perform accurate security assessment taking into account the dynamics of the system using time-domain simulations,- to provide operators with relevant proposals of curative actions to keep the system in a secure state (such as generation redispatching, change in transformer tap position, topology of substations, set point values of HVDC lines or phase shift transformers (PST), change in the maintenance scheduling).In addition, the iTesla project has developed:- Methodologies and tools for validation of dynamic models of components of the pan-European system, using off-line analysis; these tools have been designed to determine model parameters using measured dynamic responses of the grid.- New concepts to build more robust defence plans and optimal restoration plans with the help of automated tools e.g. the integration of renewable energy resources (RES) and distributed energy resources (DER) and the use of time-synchronized measurements from phasor measurement units (PMUs).This report provides a summary of the main outcomes of the iTesla project but it does not enter deeply into technical and scientific details. All public project deliverables, publications and workshop materials can be downloaded from the project website: www.itesla-project.eu.Most of the iTesla outcomes are accessible to all, in particular:1. The iTesla platform is available at MPL Mozilla Public License 2.0.2. The computation modules are distributed by the iTesla partners either as open source software or as commercial products.3. The RaPId software for model validation is an open source software (under the GNU LGPL v3 license) and is available at https://github.com/SmarTS-Lab/iTesla_RaPId .4. The iTesla Power System Library of power system component models in the MODELICA language has been released open source (under the MPL 2.0) so that it can be used and enriched by TSOs and the whole power systems community. It is available at https://github.com/itesla/ipsl .Project Context and Objectives:Security issues of the pan-European electricity transmission system are likely to become more and more challenging in the coming years due to:- the growing contribution of less predictable and intermittent renewable energy sources,- the introduction of new controllable devices such as HVDC lines,- a partially controllable electricity demand,- the increasing difficulty to build new overhead transmission lines,- and the progressive construction of a single European electricity market where transnational power exchanges naturally increase.These new constraints but also new opportunities will result in more complex system operation, a grid working closer to its operational limits and therefore a need for a major revision of operational rules and procedures. In this context, it is clear that current tools for security assessment will no longer be suitable for network operators to take the right decisions and that a new generation of tools is needed. Furthermore, coordinated operation initiatives have already emerged for different regions of the pan-European transmission system (cf. CORESO and TSC for instance). These coordination initiatives will not be fully efficient without a new toolbox, allowing the different TSOs to increase coordination.The iTesla project has developed such a toolbox able to support the operation of the pan-European grid in the coming years and has validated the different functionalities of this toolbox with datasets of various complexity and size. More precisely, this toolbox has been designed to support the decision-making process from two-days ahead to real time and to take up the three main following challenges:- to provide a risk-based assessment taking into account the different sources of uncertainties, in particular, those brought by intermittent power generation,- to perform accurate security assessment taking into account the dynamics of the system using time-domain simulations,- to provide operators with relevant proposals of curative actions to keep the system in a secure state (such as generation redispatching, change in transformer tap position, topology of substations, set point values of HVDC lines or phase shift transformers (PST), change in the maintenance scheduling).This toolbox has been designed to be used by a single TSO, by a coordination centre such as Coreso or by a group of TSOs working in a coordinated way. It is flexible enough to be adapted to different operating rules and also to evolutive operating rules.In addition, the iTesla project has developed:- Methodologies and tools for validation of dynamic models of components of the pan-European system, using off-line analysis; these tools have been designed to determine model parameters using measured dynamic responses of the grid.- New concepts to build more robust defence plans and optimal restoration plans with the help of automated tools e.g. the integration of renewable energy resources (RES) and distributed energy resources (DER) and the use of time-synchronized measurements from phasor measurement units (PMUs).The iTesla project was carried out by a consortium of 21 European partners and supported in large part by EU funding in the framework of the Seventh Framework Programme (FP7).The consortium members are the following:- 6 national operators of electricity transmission systems: RTE (France), Elia (Belgium), National Grid (UK), REN (Portugal), Statnett (Norway) and IPTO (Greece),- 1 Regional coordination service centre: Coreso (Belgium),- 6 universities and research centres: Imperial College (UK), INESC Porto (Portugal), KTH (Sweden), KU Leuven (Belgium), RSE (Italy), DTU (Denmark),- 8 industrial R&D providers: AIA (Spain), Artelys (France), Bull (France), Gridquant (Spain), Pepite (Belgium), Quinary (Italy), Tractebel Engineering (Belgium), Technofi (France).The project was coordinated by RTE, the French transmission system operator (TSO). It started in January 2012 for a period of 4 years.Project Results:Overview of the main results:The outcomes of the iTesla project can be grouped into five main subsets: - The iTesla toolbox for power system security assessment, - Several tools for validation of power system dynamic models, - A library of power system models in the MODELICA language, - Recommendations and software tools for improvement of defence and restoration plans - Recommendations to ENTSO-E regarding TSO and RSCI rules for business processes and data exchange (common work with the Umbrella FP7 project). The project website (www.itesla-project.eu) presents an interactive way to navigate through the description of these main outcomes (Figure 2).Figure 2: Top-level page to navigate through the iTesla outcomesiTesla toolbox for network security assessment:The iTesla toolbox provides operators with tools to assess the security of forecast situations from two days ahead to near real time. The outputs are recommendations to the operators in terms of efficiency of curative actions when they are needed. The iTesla toolbox is able to take into account simultaneously the uncertainties affecting power injections and the dynamic behaviour of the grid. The computations are performed with two complementary workflows: the online and offline workflows (Figure 3). The offline workflow builds security rules that are based on an extensive analysis of a large number of system states that are likely to occur. The online workflow uses these “offline rules” to identify the contingencies for which corrective or preventive remedial actions are needed and for which accurate time-domain simulations must be performed online. Both workflows include different computation modules, each fulfilling a specific technical function such as load flow computation or time-domain simulation. Figure 3: iTesla online and offline platforms.The iTesla platform is the software framework that integrates and controls the different modules of the iTesla toolbox. It provides common services such as data management, data conversion, data mining, task management or graphical user interfaces. In particular, it provides a data model for static and dynamic power system data (IIDM - iTesla Internal Data Model) and several conversion services between this data model and external formats (CIM format, Eurostag, PSS/E). The IT architecture of the iTesla platform has been designed to allow an easy integration of new components, without being tied to specific software. The iTesla platform is an open source software (under the MPL 2.0 license ) and is available at https://github.com/itesla/ipst.Tools for validation of power system dynamic models:The developed RaPId tool prototype attempts to tune the model’s parameters so as to satisfy a fitness criterion (e.g. minimize the error between simulation and measurement traces) between the outputs of the simulation and the experimental measurements of the same outputs provided by the user (Figure 4). Figure 4: The RaPId tool prototype for model validation.The RaPId software is an open source software (under the GNU LGPL v3 license) and is available at https://github.com/SmarTS-Lab/iTesla_RaPId.Tools for validation of very large power system models have also been developed. By using a version of the dynamic power system simulation tool EUROSTAG® that incorporates the algorithmic advances from the PEGASE project, exploiting high performance computing (HPC), and using automated calculations and result analysis, it is possible to validate power systems as large as the European interconnected system (Figure 5). Figure 5: Validation of very large power system models.iTesla Power System Library:In the framework of the project, a MODELICA Library of power system component models has been built with all the dynamic models used by iTesla TSOs, namely Statnett (Norway), REN (Portugal), IPTO (Greece), Elia (Belgium), and RTE (France), either with PSS/E®, PSAT® or EUROSTAG®. All those models have been implemented into a MODELICA equivalent model and validated against their PSS/E®, PSAT® and EUROSTAG® reference models. This MODELICA Library of power system component models has been released open source (under the MPL 2.0 license) so that it can be used and enriched by TSOs and the whole power systems community. It is available at https://github.com/itesla/ipsl.Recommendations and software tools for improvement of defence and restoration plans:The iTesla recommendations regarding defence plans are gathered into the following document available to ENTSO-E TSOs: Deliverable D6.2 “Improvement of defence plans in European power systems - Proposed harmonization, coordination and inclusion of RES, distributed resources and PMU information”.In the framework of the iTesla project, Tractebel Engineering and AIA have coupled their respective tools FAST DTS and AGORA in a proof of concept tool. FAST DTS is a dynamic dispatcher training simulator and AGORA is a system for the automatic calculation of optimal restoration plans among other advanced energy management system (EMS) functions. This proof of concept is used to test and validate restoration plans proposed by AGORA on the real-time dynamic simulator FAST DTS (Figure 6).Recommendations to ENTSO-E regarding TSO and RSCI rules for business processes and data exchange:The iTesla/Umbrella common recommendations to ENTSO-E TSOs are gathered into a common document (deliverable D8.4) which addresses the need to meet necessary requirements for TSOs and DSOs to improve the interoperability and security in the pan-European grid system. Figure 6: AGORA/FAST DTS (Dispatcher Training Simulator) tool for validation of restoration plans.iTesla Toolbox:Presentation of the Toolbox:Needs resulting from operational experience at CORESO:In Europe, several Regional Security Coordination Initiatives (RSCIs) have been established with the aim to support TSOs in maintaining security. CORESO (partner of iTesla) was the first one to be launched. CORESO provides analyses and advice to partner TSOs, supporting the coordinated operations of the grid in the time horizons of two days ahead (D-2), one day ahead (D-1), intraday and close to real-time . CORESO can be regarded as an example of best practice of TSO coordination, performed with state of the art tools. Major steps of CORESO activities are the collection of data from partner TSOs (forecasts, snapshots), merging of the data to form a single power system model, static security assessment, preventive control action identification, in case some potential contingencies would have unacceptable consequences, and coordination of action deployment. CORESO adopts the “UCTE DEF” format , which has been used by ENTSO-E for more than 10 years as information exchange standard between Continental Europe TSOs within the DACF (Day-Ahead Congestion Forecast) process. However, UCTE DEF proved to be not compatible with Load Flow and Contingency Analysis processes required by the recent ENTSO-E Network Codes (NC). ENTSO-E has then decided to adopt IEC CIM Standard, which also has ability to get new scalable improvements to cover additional requirements. In particular, interoperability tests of CIM profile 1 (CIM14) brought for the first time the requirement to use persistent references (identifiers) on all equipments. However TSOs took a long time to implement reference persistence and adequate equipment translation to CIM model (especially for PST and HVDC lines). Even now with the CIM Common Grid Model Exchange Standard (CGMES), these requirements are hard to fulfil by all TSOs. So, in spite of ENTSOE efforts to push forward the adoption, the use in operational processes within TSOs is right now limited and the power of CIM (in particular, the persistence of identifiers) has not been fully exploited up to now. iTesla adopted CIM in order to show its potential for improved security analysis.Security assessment at CORESO is currently only static, whereas dynamic stability becomes more and more important. Even though individual TSOs perform some dynamic analyses on their own grid models, a need for security analyses with detailed dynamic models of the whole interconnected grid is deeply felt. One major obstacle is the lack of agreement on model description and data format, also because each simulator has proprietary solutions. iTesla, with the adoption of Modelica language for dynamic model exchange, proposes an approach that is fully independent of the time-domain simulation platform and permits a thorough and univocal description of the models. Security analyses performed at CORESO are deterministic. The uncertainty due to loads and variable renewable energy sources (RES) forecast errors is not accounted for, whereas a strong need to include them is perceived by the operators. Probabilistic security analyses for operations are usually not performed at TSO level either. iTesla addressed this challenging topic.At CORESO, some control action recommendations are automatically computed in the process of D-2 capacity calculation for the Central Southern Europe (CSE) area but nothing is yet available in D-2, D-1 and intraday activities for Central Western Europe (CWE) area. More evolved tools aimed to support optimal control action recommendations would greatly help, especially in view of coordinating actions among TSOs. At TSO level, some tools are available but generally with simplified models and few constraints and control variables. Moreover, discrete actions such as substation switching, i.e. the most appealing solutions for TSOs, are not usually included in the optimisation. iTesla also addressed this challenging topic. Uncertainties:In iTesla, security analyses are performed on forecasts of the operating conditions expected some minutes to some hours ahead of operation. Major sources of uncertainty of these forecasts regard power injections of loads and RES. Uncertainties in iTesla are taken into account, by defining probabilistic models of the forecast errors. The forecast error is the difference between forecast values (e.g. evaluated on D-1) and values occurred in real operation (“snapshots”), resulting from grid state estimation. Forecast error models are synthesised, based on historical data series of forecasts and snapshots. According to the specific needs of the security assessment process, two different error models are provided: - The simpler one defines a “domain of uncertainty” of the stochastic (uncertain) variables, expressed as a convex domain in the multi-dimensional space of stochastic variables. This representation is suitable for inclusion into linear optimization functions that are used in the security assessment process, however it is simplistic, therefore it is built in a conservative way (i.e. the resulting domain is larger than the “real” one). - The second model developed for forecast error accounts for (1) complex dependencies between injections and (2) dependences on the forecast values. Concerning item (1), it is well known that forecast errors may be correlated. For example, because loads and wind/PV generation depend on the weather conditions, bad forecasts of the weather imply forecast errors of the power injections that are located in the same area. Correlations and more complex, non-linear dependencies are taken into account . Concerning item (2), the forecast error of a power injection depends on the forecast value itself. Again, a big role in this dependence is played by the relationship between weather and power injections. An approach has been developed that handles thousands of stochastic variables compatibly with the online requirements of iTesla. Figure 7 shows an example stressing the importance of conditional probabilities in forecast error modelling. Figure 7: Samples of two forecast errors relevant to load active powers in the French network: Conditioned samples for two different initial states (red * and green x), and unconditioned samples (blue circles)In the next figures examples are shown regarding GUIs for forecast error visualisation and correlations between errors. Figure 8: GUIs for error visualisationDynamics:The most obvious way to carry out dynamic security analyses in an uncertain context would be resorting to Monte Carlo techniques. For each contingency of the TSO-defined contingency list (possibly consisting of thousands of contingencies), time-domain simulation of the contingency would be performed on the forecast state (“base case”) and on “sample” states, selected in the uncertainty region of the forecast. The samples would be obtained by modifying the base case according to the forecast error model. This approach, however, would not be feasible in an online approach, as time requirements are stringent. Given the computational burden of carrying out millions of ”what-if” simulations to determine the stability of the electricity system, iTesla addresses the problem by moving a substantial portion of the required analysis offline. In the offline part, a set of “security rules” is generated, to facilitate the analysis that will be carried out online. Security rules process pre-contingency system quantities and provide a security judgement of the post-contingency state. In this way, the post-contingency outcome is predicted with no need for post-contingency power flow or time domain simulation. Security rules are defined per contingency and per type of security problem. Both static and dynamic issues can be accounted for, from basic overloads to complex stability phenomena such as inter-area oscillations. Architecture:Based on the approach to tackle uncertainties and dynamic issues, the architecture of iTesla is designed consisting of two parts (Figure 9): 1. An offline workflow to synthesize complex system behavior into simple security rules, 2. An online workflow to identify security issues and help operators finding solutions.In particular: - Contingency filtering consists of several stages, aimed at discarding the large majority of secure contingencies and identifying control actions. - Detailed time-domain simulations are carried out for the remaining, few undecided cases.Figure 9: iTesla toolbox general architectureThe iTesla platform is the software framework that integrates and controls the different modules that implement the security assessment process. The platform implements a data management layer,(a) defining an internal data format (IIDM - iTesla Internal Data Model, based on CIM for network static data, and Modelica for dynamic data), and (b) providing services for accessing, handling and storing IIDM data; it provides conversion services from external formats (CIM, Eurostag, PSS/E) to IIDM and Modelica, and vice versa ; and defines the interfaces of the different modules, in terms of services, input and output.This architectural design makes the platform open, allowing the integration of different components in the platform, without being tied to specific software. The integration of a new tool inside the platform requires (1) implementing the defined interface, and possibly (2) coding new ‘adapters’ (conversion tools) from/to the IIDM format.The platform provides multiple interchangeable implementations of some key modules (load flow, time domain simulators, etc.): for instance both HELM Flow [by AIA] and HADES [by RTE] can be configured and used as load flow tool, and Eurostag [by Tractebel/RTE] or Dymola [by Dassault Systèmes] can be used to perform time domain simulations. Using Modelica for dynamic data, and the already available integration of Dymola, enhances the openness features of the platform: the iTesla platform already provides services to convert a dynamic model in Modelica format, and to execute external software in an efficient way: these services were used to integrate Dymola, but could be re-used to plug-in another simulator more easily, provided that the new simulator is able to process a model in Modelica format; not much work is expected to integrate the OpenModelica simulator, for instance.Another successful example of module integration regards IPSO from Tractebel Engineering and a Fuzzy Power Flow (FPF) from INESC. The former module optimizes remedial actions while the latter, which evaluates power flow quantities in a “fuzzy” way, was integrated to run in parallel to the online mainstream. Offline security rule generation:The offline rule generation workflow is an integral part of the iTesla architecture. Since we do not know exactly what will happen in the coming days/weeks, the rules must be suitable for a wide range of expected/plausible operating conditions. The first step is to build a large population of operating points that are anticipated to occur in the next period. Historical measurements from similar periods are used to inform a sophisticated statistical model that can generate a very large number of scenarios. The scenarios are consistent with what has been observed historically, but also capable of exploring marginal cases that have rarely occurred in the past. The second step is to analyse the impact of each possible contingency across all anticipated operating points. This is done by carrying out a time-domain simulation and investigating the impact of a particular asset failure event.In the final step, by applying a suitable machine learning algorithm, we compress the results of millions of simulations into a set of rules that can subsequently classify unseen operating points as being acceptable or unacceptable. This way, a rule is obtained for each analysed contingency, that will support the online iTesla platform by predicting in a very fast way whether a particular operating point is susceptible in the event of a failure. The offline rule generation workflow has been optimised to run on High Performance Computing (HPC) facilities i.e. computer farms with several thousands of cores. By leveraging the workflow’s inherent parallelisability, millions of simulations were carried out, allowing operators to compute rules across thousands of contingencies in the span of a few days of intense processing.Offline forecast error model synthesis:The forecast error model has been described earlier. Here we can add that, due to the high dimension of the problem and to issues in the real data under analysis (e.g. substation configuration, missing data etc.), historical data need to be pre-processed and undergo various compression steps such as clustering and Principal Component Analysis (PCA), with some functions in common with the rule generation. In order to synthesize the uncertainty models, the persistence of grid component identifier is mandatory not only across time but also between forecasts and snapshots. In this regard, the use of CIM format is very helpful, while the UCTE DEF is not adequate .Online merging:The Merging Module is in charge of reconciling data from the TSOs in order to obtain a consistent network state for the European electricity network. Data are affected by inconsistencies (e.g. measurement errors, time differences, etc.) and characterized by different reliability levels. A hierarchical merging procedure solves successive AC-OPF (Optimal Power Flows) in order to build a consistent merged network state by minimizing the deviations from the data provided by the different TSOs.Online Worst State Approach (WSA):The Worst State Approach is the first filtering stage of the online process. Its objective is to discard contingencies which are highly stable within the whole uncertainty domain, considering in a simplified way the security limits, the uncertainties of the injections, and the available control actions (Figure 10). The method addresses a very complex optimization problem (bi-level optimization with discrete variables). To solve this problem, the “DC” approximation for grid equations is adopted and all aspects of the problem are dealt with accordingly. “Security rules” for WSA account for security constraints (including stability) in terms of “DC” variables, in order to be included as constraints of the optimisation problem. The domain of uncertainty of the stochastic variables is expressed as a convex domain (cf. Uncertainty section above). Online Monte Carlo Like Approach (MCLA):A second filtering stage, named Monte Carlo-Like Approach (MCLA), makes a limited sampling of the uncertain injections around the forecast state, and checks the new sampled states against “rich” security rules (Figure 10). Unlike the rules defined for WSA, those for MCLA are defined on the whole range of AC quantities, hence they can more effectively take into account stability limits. The uncertainty model developed for MCLA based on historical data analysis is the detailed one described above, accounting for complex dependencies. MCLA is performed for each contingency classified as not secure by the previous filtering stage. For each contingency, the states that are classified as potentially insecure are passed to the next detailed analysis. Figure 10: MCLA (left) and WSA (right) approachesControl action identification:Corrective control is investigated for all the {state, contingency} couples resulting as potentially harmful from rich security rules’ judgement. The objective is to check more accurately if the situation is actually critical, and to identify post-contingency actions that eliminate the violations. Security-Constrained Optimal Power Flow (SC-OPF) techniques are involved in this step. In order to model the operating rules adopted by control room operators, a pre-defined set of corrective actions is associated to specific violations and to specific contingencies.The optimization module includes a solver dedicated to topological reconfiguration. Topology and the related corrective actions are modelled through binary variables in the nonlinear optimization problem. It is well-known that the resulting MINLP is a NP-hard problem. Thanks to an innovative method, this module is able to find necessary corrective actions to avoid current limits violation. An important element in that approach is the fact that a limited number of corrective actions are considered. Indeed, the choice has to be made between corrective actions that have been selected by the dispatchers and which are dedicated to the specific couple {contingency, violated constraints}. Results Obtained by the iTesla Toolbox:Data Set Building:In the iTesla platform, the input format for the static model of the use cases networks was the CIM 14 with ENTSO-E profile 1st edition. As for the dynamic data, the use cases that analysed the French (RTE) and Belgium (Elia) networks used the Eurostag format. For the Portuguese (REN) and Norwegian (Statnett) use cases, the original dynamic model was provided in PSS/E format, which required the development/use of an automatic converter to Modelica to perform time domain simulations.At RTE, since 2012 the production of French Day-Ahead Congestion Forecast (DACF) files is mostly automated. A wide variety of inputs are used to build the forecast data set, on top of the real time SCADA measurements, involving different data providers and tools. The forecast building process is designed from end-to-end to preserve the right level of data detail, stored in an internal format which is the single reference for the modelling. This process allows RTE to produce 24 DACF per day with persistent IDs, consistent with the IDs used in the snapshots (SN) files. All the data (DACF and SN) can be converted to many formats among which is the CIM V1 format used in the iTesla platform. The format conversion process is separated from other tasks (e.g. model reduction) to ensure robustness and coherence in the exported format as well. The dynamic database used in the platform to model the French network is the Eurostag database used at RTE on a daily basis to perform dynamic studies.At Elia, SN and DACF CIM files can be generated on demand for the purpose of iTesla validation tasks. An automatic tool was developed that is able to generate SN CIM files on a daily basis. These files are produced by the Elia EMS software and the automatic tool is used to convert them to CIM format. During this process, lower voltage grids are reduced into equivalent loads. The same automatic CIM conversion tool could not convert DACF files because of the different database and models related to the DACF format. Therefore, Elia also developed a converter to CIM format for DACF files. However, although there is persistent ID between different SN (resp. DACF), there is no persistence between SN and DACF. As for dynamic data, Elia uses Eurostag power plant and regulation models. A dictionary between names of generators of static CIM data and dynamic data is used to perform the dynamic simulations. Since the iTesla platform cannot currently handle regulations that involve coupling between generating units, some regulations have been replaced by academic ones. In addition, the dynamic behaviour of the distributed generation that is not explicitly represented in the DACF and SN is an approximation of the underlying physical reality. Belgium is in some extreme cases dependent on external countries in terms of power balance and external contribution in short circuit is significant and should not be neglected. It follows that it is necessary to study the interconnected system in order to have meaningful results. Therefore, a tool to merge data from countries surrounding Belgium is needed, however at the moment, only Belgium and France can produce CIM files. To overcome this issue and also in the attempt to define a European use case, at iTesla, a CIM/UCT merging tool was developed. This tool allowed to simulate the European power system at regional level (labelled CORESO/RTE use case), comprising CIM SN files for France (FR) and Belgium (BE) and UCT SN files for Netherlands (NL) and Germany (DE).For the Statnett use case, a synthetic model of the Norwegian grid was created - the Nordic 44 system. The original model was provided in PSS/E format and an automatic procedure was developed to prepare this model to match real data about power flows obtained from Nord Pool. The reference period for the creation of the power flow solutions was from April to July 2015. One SN for each hour was created totalling 2880 cases. The conversion of the SN from PSS/E to CIM format was performed by using the PSS/E ODMS toolbox. The automatic conversion of this network data to Modelica was validated and is running with success in the platform (using Dymola for time domain simulations).At REN, an automatic procedure was developed to obtain SN with constant ID’s. A base grid was defined and the generation/load/voltage conditions were changed according to metering values of the analysed period. The Portuguese network states were obtained in PSS/E v33 format and originated from the metering database (for generation and load data), outage database and SCADA database (for voltage profile). These files were then converted to CIM 14 format by using the PSS/E ODMS software. As a by-product, this work helped to improve the methodology for debugging the conversion of medium/large systems to Modelica and also provided the development, debugging and validation of new Modelica models.Studied Phenomena:Apart from the Portuguese use case, all the use cases defined for the global validation of the iTesla platform were able to generate Decision Tree (DT) based security rules. For the French use cases, DT’s were generated to perform security assessment of the following phenomena: a) Overload in French transmission lines following a short-circuit in a single or double line that leads to the line disconnection; b) Inter-area oscillations of a fictitious French network with modified regulations to create oscillation problems; c) Loss of synchronism in Civaux nuclear power plant, following a fault on a line next to it; d) Voltage collapse in the South-Eastern part of France (in Côte d´Azur region), following the loss of a double 400 kV line between Tavel and Realtor substations.It is necessary to remark that, while the European continental grid is known to have some inter-area oscillations (Portugal-Turkey, Denmark-Italy) that showed up a few times during operation, it was not realistic to build a use case for replicating these oscillations in the iTesla project, as the European TSOs do not share dynamic models between them and the grid data exchanged between D-2 and operation is not suitable for dynamic simulations.For the Elia use case, the DT generation focus on the transient stability of a nuclear substation, after a short-circuit located at 1% from the substation where nuclear power plants are connected. For the Statnett use case, DT’s were generated to perform the security assessment of overload in lines, following a N-1 or N-2 line outage. Overload in lines was also the security problem evaluated by the CORESO/RTE use case.To illustrate the results that can be provided by the offline platform, Figure 11 presents the DT structure and training set statistics provided by the DT generated for the N-1 Tavel Tamareau contingency (short-circuit and loss of the Tavel-Tamareau line) that may create overloads on the surrounding grid. This DT was generated with the SN of January 2013. In Figure 12, the 2D 4 colour plots describe the location of French network states in the security domain defined by the DT. The upper plot (which is labelled as “Samples”) provides the location of the states used for training (sampled states obtained with the SN of January 2013), whereas, to evaluate the generalization capabilities of the DT, the bottom plot (which is labelled “Historical”) provides the location of all the DACF of February 2013. Figure 12 also presents the overall, daily and hourly distribution of the misclassifications provided by the DT for all the DACF of February 2013 (not used for training).In all the performed tests, the iTesla platform produced datasets that allowed to improve the rule generation method. Namely, the CORESO/RTE use case showed that if a contingency does not always constrain the same element, the DT results can be improved by learning one DT for each constrained element. From the results obtained from DT performance for overloads in the French network, it was possible to conclude that, to reduce the number of missed alarms, the combined effect of three actions will be required: a) Increase the diversity of the historical data used for training; b) Give information on the network topology to the DT algorithm; c) Develop a method to assess online the validity domain of the generated DT. The voltage collapse use case was one of the good surprises among the French use cases. The computed rules showed to be an attractive option to bring voltage collapse security analysis closer to real time. The use case that evaluated oscillations of the French network allowed to show the potential of the platform to model inter-area oscillations.Figure 11: DT results for the training set [overload in French network, contingency N-1 Tavel Tamareau]Figure 12: DT results for the validation set [overload in French network, contingency N-1 Tavel Tamareau]Online Security Assessment with Uncertainty Introduction:Uncertainty handling is the essence of the on-line approach. In addition to the mainstream Monte Carlo-Like Approach (MCLA), the Worst State Approach (WSA) and the Fuzzy Power Flow (FPF) approaches were developed. Both could allow faster computations that enhance the MCLA efficiency by filtering out contingencies that will never lead to unacceptable consequences.In the global validation of the online platform, the results provided by the MCLA module were intensively tested. These were performed for all the DACF of three critical days (20, 25 and 27 of February 2013) and three contingencies of the French use case that tackles overload problems. The same contingencies and security problem were used to test the FPF approach, by comparing with results provided by the MCLA approach. Figure 13 presents some of the obtained results for the N-1 Tavel Tamareau contingency. It presents the 2D 4 colour plots of three French DACF’s (base cases defined by a blue cross) in the security domain of the DT, including the uncertainty defined by the MCLA (4 colour plots) and also including the uncertainty defined by the FPF approach (triangular shapes). The analysed DACF comprise: a) A 100% secure DACF and deep inside the “secure” domain defined by the DT (02h30 27/Feb/2013); b) A secure DACF near the security boundary defined by the DT (18h30 27/Feb/2013); c) and a 100% unsecure DACF placed very deep into the unsecure part of the space. As illustrated in Figure 13, the tests performed on the MCLA demonstrated the need to represent uncertainty, since from one apparently secure forecast network state, it is possible to obtain unsecure situations that need to be tackled in advance by the system operator. The obtained results (not presented here due to space limitations) also illustrate that an accurate classification of the MCLA states strongly depends on the quality/applicability of the used DT. Figure 13: 2D 4 colour plots of three French DACF in the security domain of the DT + uncertainty defined by the MCLA + uncertainty defined by the FPF approach [overload in French network, contingency N-1 Tavel Tamareau]The results obtained with the FPF demonstrated that this tool is able to provide correct classifications for contingencies that result in overloaded equipment. Moreover, as illustrated in Figure 13, the fuzzy uncertainty representation was proven to be complementary and an upper bound of the MCLA probabilistic representation and, therefore, can be exploited to filter out contingencies before MCLA analysis.As the MCLA, the WCA was tested on the loss of the Tavel-Tamareau line in the Southern part of France that creates overloads on the surrounding grid, for all the SN of January 2015. As the temperature was mild in January 2015, the result was that only 8 timestamp during the whole month should have been analysed in the MCLA as the others were classified as safe by the WCA whatever the plausible uncertainty, illustrating the usefulness of the approach. The WCA can also use the security rules generated by the offline workflow. The tests taking into account the rule in the WCA generated some false alarms, which was not the case when the MCLA uses the same rule. It suggests that the WCA specifically targets the extreme regions of the uncertainty domain in such a way that the rule is not anymore applicable because the corresponding states are not realistic enough. Finally, the WCA is able to take into account curative remedial actions so as to enhance its filtering capabilities. For 6 situations among the 8 found unacceptable without curative remedial action, the WCA verified automatically that the opening of a breaker allowed to reduce the flow on the constrained line whatever the uncertainty. The last 2 ones require the operator to find a preventive remedial action. In overall, the WCA showed a great filtering potential for contingencies despite some difficulties to define the uncertainty domain, especially on dynamic phenomena as it can handle security rules.Test of Curative Actions with the Control Actions Optimizer (IPSO):Tests on the IPSO module were performed to confront it to a fairly complex optimisation problem, including both discrete and continuous variables. The base case was the French 400 kV and 225 kV network, especially its South-Eastern part, where post-contingency corrective actions involving power generation mainly apply to a set of 29 hydraulic units, all located along the course of a river named as Durance.In some circumstances, the loss of the South-East 400 kV line between Tavel and Realtor is liable to generate severe overloads requiring a compound corrective action rather than an elementary one. For this test, IPSO was expected to compute an optimal corrective action, each stage of which had to belong to one of the following types: a) Topological actions on coupling devices in five substations; b) Topological actions on 225 kV breakers of three 400kV/225kV transformers; c) Actions on tap changers of two PSTs; d) Actions on the set-points of the generation units in the Durance Valley. The optimal corrective action was also expected to fulfil the following conditions: a) Remove all the overloads resulting from the contingency; b) Be compliant with the technical limits of all involved equipment.The optimising criterion refers to a notion of cost, which is defined as follows: a) zero-cost for topological actions, PST tap changes, hydraulic generator starts or stops; b) A significantly high cost for generator set-point changes.The optimization problem resulting from the test case described above is thus an Optimal Power Flow on the French network with discrete variables (topological actions) and continuous variables (generator active power set-points). The solution to be found by IPSO is highly dependent on the comparative costs which are associated to each type of elementary corrective action. Therefore, two tests have been carried out, each with a different value of the comparative cost of re-dispatching.After simulating the corresponding sets of corrective actions on RTE’s security analysis platform, the results of both IPSO optimisations turned out to be satisfactory, for the main following reasons: a) All the required optimising conditions, as described here above, were met; b) Both sets of results were qualitatively consistent with the corresponding costs of generated power redistribution, namely with a cost multiplied by ten, the number of topological or concerning PSTs increased by 60%.As a conclusion, the test results irrefutably show IPSO’s ability to compute optimal corrective actions after a contingency with subsequent overloads. More precisely, the test results illustrate the following major points: a) The optimiser can cope with rather complex actions; b) IPSO works from a qualitative description of elementary corrective actions which, at the least, are liable to relieve overloads partially. c) Taking into account an optimising criterion, IPSO can quantify and combine adequate actions in order to remove all the overloads which were caused by the contingency.iTesla Power System Library:Introduction:The iTesla Power Systems Library (iPSL) is a Modelica library containing a set of power system component models used for phasor time domain modelling and simulations. iPSL is released as an Open Source Software (OSS) with the hope that it will be used and enriched by both power system and Modelica communities. It is available on GitHub. Modelica was chosen as the modelling language due to its many advantages: - Modelica is a standardized modelling language for cyber-physical systems (i.e. it is NOT a simulation tool). As such, the Modelica language specification is clearly defined, developed and maintained by Modelica Association (see the following link). In addition, the specification is openly available, which allows any potential Modelica-compliant tool provider to implement their own compiler and provide services around the Modelica language. - Model ambiguity is addressed by Modelica through modelling requirements. Development in Modelica requires formal mathematical descriptions of models, thus eliminating the need for arbitrary interpretation of, e.g. block diagrams. - Modelica separates models from numerical solvers and Integrated Development Environments (IDEs) used for modelling and simulation. This allows greater flexibility and usage of models for purposes other than only performing dynamic simulations and analyses.iPSL’s Structure and Contents:The structure of iPSL is shown in Figure 14. The library is divided into four main packages: Figure 14 Structure of iTesla Power Systems Library (iPSL) - The Electrical package contains most of the components that comprise an actual power network such as electrical machines, transmission lines, loads, excitation systems, turbine governors, etc. These can be used to build power system network models. - The NonElectrical package is comprised by functions, blocks or models, which are used to build the aforementioned power system component models. They are transfer functions, logical operators, etc., that perform specific operations which were not available in the Modelica Standard Library (MSL). - As its name suggests, the Connectors package contains a set of specifically developed Modelica connectors to harmonize the models in this library. As an example, PwPin is the connector, which contains voltage and current quantities. - Models used for data conversion (to exchange data between the library and other Modelica libraries) can be found in the Interfaces package, and the Example package contains a number of different sample power systems showing capabilities and use of other models in the library. iPSL’s Application Examples:The library has been populated with several application examples of power system networks implemented during this project. These include typical networks used in academic literature and education such as IEEE 9 Bus, IEEE 14 Bus, Single-Machine-Infinite Bus (SMIB) and Klein-Rogers-Kundur 2-area 4-machine system. The IEEE 9 Bus system shown in Figure 15, as one of the examples, has been validated against a reference tool PSAT. Figure 15 Modelica model of IEEE 9 Bus system The application examples also include several networks developed for specific Use Cases within the iTesla Toolbox including, but not limited to, the AKD (Alta Kraft Detailed) developed to model an equivalent portion in the Northern Norwegian power system, a Seven Bus model used for testing of the iTesla toolbox and Nordic44, an equivalent model of the Nordic power system that expands on the Nordic32 model with many important changes. The Nordic44 (N44) system was one of the models developed for Statnett use cases in the project. The PSS/E model of the system, shown in Figure 16, was provided by Statnett. The equivalent model shown in Figure 17 was built in Modelica and validated against a model in PSS/E. N44 was modified in order to match the actual dispatch through the bidding zones of the Nordic grid, real market data was acquired from Nord Pool for the entirety of 2015. The market data, was used with N44 system to specify the initial operating point (i.e. power flow) for thousands of snapshots during the entirety of 2015. The Nordic44 model is also available in form of PSS/E and CIM snapshots for every hour during 2015. These snapshots can be converted to Modelica “records” which are used as power flow results during the initialization of the system. This allows users to simulate and analyse the state of the Nordic grid for the whole of 2015 using Modelica and iPSL. Figure 16 The PSS/E model of Nordic44 systemFigure 17 The Modelica model of Nordic44 systemSoftware-to-Software (Sw-to-Sw) Validation:iPSL contains a number of dynamic models used by TSOs participating in the project, namely Statnett, REN, IPTO, Elia and RTE. A large subset of these models were subjected to software-to-software validation procedure against a widely used reference tools typically found in the power systems domain, such as PSS/E, Eurostag, PSAT. The software-to-software validation procedure ensured that the dynamic behaviour of the iPSL models corresponds to the one from reference tools. Software-to-software validation is necessary not only to meet the functional requirements of the iPSL models, but also to address the enormous and unappreciated social aspects of resistance to change that are present when introducing new technologies in a conservative domain . For example, users of a specific power systems tool are skeptical about other tools different from the one that they use — this is a complex behavior that involves both the change in the human interactions that accompany the use of a specific tool, as well as a concern about the technical aspects of a new technology. To make a transition where the use of Modelica is accepted by power system practitioners, the work within WP3 of the iTesla project used different strategies to overcome the resistance of domain experts. This approach consisted in two strategies. The first strategy was to promote the use of Modelica in power systems as a medium for unambiguous model exchange, which is an Alpha strategy that supports the common goal of model exchange. The second strategy (type Omega ) was used to decrease avoidance forces: made a software-to-software validation of each power system component from trusted domain-specific power system tools where simulation results between the Modelica library in different tools are appraised against a domain-specific tool . SW-to-SW validation methodology used in the project is outlined in Figure 18. Figure 18 Software-to-Software validation procedureThe two models, reference and equivalent, are built in the reference tool and Modelica with iPSL. Power flow calculations from the reference tool are used to initialize equivalent Modelica model. Upon the execution of time-domain simulations of both models, simulation results are subjected to graphical (qualitative) and quantitative assessment. Quantitative assessment is carried out by computing the Root Mean Square Error between the reference waveform and the simulated output in Modelica, defined as:RMSE= √1/n ∑(xi-yi )2where xi is a data point from the simulation result and yi is a data point from the reference waveform at the given time of a simulation. The SW-to-SW validation has been performed for various networks and models. The simplest example is the validation of dynamic models by simulating various contingencies for different instances of the Single-Machine-Infinite-Bus (SMIB) system. Two equivalent models, in PSS/E and Modelica, are built (Figure 19). Figure 19 SMIB system in Modelica and PSS/EThese systems were used for, in this case, the SW-to-SW validation of the round-rotor generator model, GENROU, through a simulation of the system’s response due to a disturbance at the “FAULT” bus. The comparison of both simulation results is shown in Figure 20.Figure 20 Validation results for the round-rotor generator model, GENROUA more complex example is the SW-to-SW validation of the Nordic44 system against the reference model in PSS/E. In this case, the system underwent through several iterations in order to identify sources of discrepancy by simulating many different contingencies until a satisfactory match between the two tools was been obtained. Simulation results comparison for the validated model of the Nordic44 is given in Figure 21. It should be noted that, even though the differences in the results are visible, this is only due to the scaling of the y-axis. RMSE value of the two signals is 9.02 10 -5, which is below the error tolerance specified for both simulation tools; hence confirming that the SW-to-SW validation was successful. Figure 21 Validation result for Nordic44 modelFigure 22 GUI of the automatic Sw-to-Sw validation toolThe SW-to-SW validation process was performed manually for most of the duration of the iTesla project. However, during late 2015, the process was synthesized into a tool (Python scripts) that automates the validation process and generates reports for easier model assessment. A web based display to share the results of the SW-to-SW validation tool was implemented in JavaScript and HTML, and deployed in the Github platform. A snapshot of the tool is shown in Figure 22.Impact of iPSL Work within the ENTSO-E Common Grid Model Exchange Standard (CGMES):The European Network of Transmission System Operators for Electricity (ENTSO-E) has made substantial efforts to comply with Regulation EC 714/2009 given by the European Commission. This regulation states that TSOs should use a common transmission model dealing efficiently with interdependent physical loop-flows and having regard to discrepancies between physical and commercial flows. Reports from European standardization bodies recommended the use of the Common Information Model (CIM) and IEC61850, as they are the most prominent data models to exploit throughout many applications and systems. Results of the ENTSO-E’s efforts is the approval of Common Grid Model Exchange Standard (CGMES) that is based on CIM. Conformity of the tools to CGMES have been carried out through Interoperability (IOP) tests. However, to fully comply with the Regulation, it will be necessary to exchange dynamic data, in addition to steady-state data. CIM and CGMES currently support only exchange of parameters of pictorial block diagrams. This approach cannot guarantee unambiguous model exchange and repeatability of simulations among tools used in power system domain due to several limitations: - Dynamic models are not consistent across platforms due to modelling philosophy, assumptions and associated simplifications made during implementations, - Conventional “black boxes” and/or block diagrams force users to share only parameters of models with predetermined structure, - Mathematical equations of the models are not exchanged, - Actual implementation of block diagrams is left for open interpretation.Figure 23 ENTSO-E's call for IOP Test including the use of Modelica modelsAll of the limitations listed above can be mitigated through the use of Modelica due to all of its advantages listed in the beginning of Section 0. This approach has been recognized by ENTSO-E, and as evidence, in July 2016 the sixth ENTSO-E IOP test will be conducted (see Figure 23), with one of the goals of this IOP test being to demonstrate exchange of dynamic models following the implementation effort performed by a group of vendors. The use of models expressed in Modelica code will also be validated.Resources:The following video provides an overview of the iPSL and the use of different Modelica-compliant tools for an Application Example from the library: iPSL Overview Video – https://www.youtube.com/watch?v=nKOCulNiy3oThe following link provides all of the material developed by KTH to carry out a hands-on-tutorial on using the iPSL for power system modelling and simulation. The tutorial shows how to build from scratch a simple model using the iPSL, the OSS OpenModelica and the OSS PSAT: iPSL Tutorial on Github - https://github.com/itesla/ipsl/releases/tag/Tuto_ModProd_2016 Validation of dynamic models:The ability of the iTesla platform to perform both on-line and off-line dynamic security assessment is inherently affected by the quality of the models used. Validating models helps in having a model with good sanity and reasonable accuracy, which approximates the simulated response as close as possible to the measured response of the system. Such models increase the capability to reproduce the actual behaviour of the system and capability of having better predictions.RaPId: A general framework for power system model validation and calibration:The Rapid Parameter Identification (RaPId) toolbox is a general framework for system identification. Any model, made available through a Functional Mock-up Unit (FMU) to the MATLAB/Simulink environment, is characterized by a number of parameters whose values can be independently varied. RaPId attempts to tune the parameters of a given model so as to satisfy a user defined fitness function. RaPId has been released as Open Source Software (OSS) and it is available on GitHub. The Functional Mock-up Interface is a tool independent standard supporting both model exchange and co-simulation of dynamic models using a combination of xml files and C code, originating from the MODELISAR ITEA2 European project, driven by the needs of (primarily) the automotive industry. A Functional Mock-up Unit is a model which has been compiled using the FMI Standard Definition. A functional overview of estimation process performed by RaPId is shown in Figure 24. Figure 24 Functional overview of RaPId 1. The parameter identification/estimation process begins by providing output and, optionally, input measurements to RaPId. 2. At initialization, a user-defined number of pre-configured model parameters is set to the starting value. 3. The model is simulated with the parameter values calculated or pre-set by RaPId. 4. The outputs of the simulated models are stored and compared to user-provided output measurements. 4. A fitness factor is computed to judge how closely the simulated data matches the output data. Based on the fitness factor the new set of parameter values is calculated and the estimation procedures continues again from (3). The estimation procedure is completed when the maximum number of iterations is reached or the fitness function is satisfied. In addition to performing time domain simulations of the model to estimate its parameters, RaPId can be enhanced to include a different workflow. For example, an alternative workflow would be to perform small signal analysis to extract the eigenvalues of a model under different parameter values, and compare them with reference eigenvalues computed from measurements. To illustrate this, the workflow in the case of small signal model calibration is shown in Figure 25. Figure 25 RaPId workflow for a small signal calibrationAfter the model is initialized with a pre-defined set of parameters, it can be linearized . After the model is linearized, modes of the system are extracted and compared to the reference mode provided by user. A fitness factor (performance indicator) is then calculated as an Euclidean distance between the extracted pole and reference pole.Figure 26 Main window of RaPId Graphical User Interface (GUI)RaPId was developed in MATLAB/Simulink. MATLAB code can serve as a wrapper which provides interaction with other programs that may not be written in MATLAB. Optimization process can be set up via Graphical User Interface (GUI) such as the one shown in Figure 26 or MATLAB scripts. RaPId was developed with a completely modular, open and extensible architecture. Therefore, advanced users can change or add identification and optimization methods, specific objective functions or solvers used for the simulation of models being validated. Currently, a number of optimization algorithms are natively implemented in RaPId, among which are Particle Swarm Algorithm (PSO), Genetic Algorithm (GA), Conjugate Gradient Algorithm and a Naïve method (line search). In addition, RaPId is pre-configured to support all the algorithms available in the MATLAB Optimization Toolbox, the MATLAB Global Optimization Toolbox, and in addition it can be linked to the proprietary Knitro software.Because RaPId is a general framework for system identification, it can perform parameter estimation at different levels in power systems domain as shown in Figure 27.Model identification and validation can be performed on the level of a power system component (e.g. generator parameter estimation), on the level of a cluster of components (e.g. estimation of the parameters of an equivalent generator model to represent a plant) or on a global system level (e.g. estimation based on inter-area oscillations, as explained above). Several use cases of RaPId are available which demonstrate different levels of validation. Figure 27 RaPId Validation levelsExcitation System Parameter Identification:To illustrate the validation procedure at the component level, parameters of the excitation system of the Mostar generator have been estimated with measurements acquired at the low voltage terminals of the machine. During the commissioning test of excitation system, successive 5% step increase and decrease of voltage reference has been introduced in the AVR. Based on the steady-states observed in the measurements, simple Single-Machine Infinite Bus (SMIB) system has been built as shown in Figure 28. Within a generator model, the exciter model was developed according to the manufacturer’s specifications.Figure 28 SMIB system for excitation system identificationFigure 29 shows the results of the estimation process which closely match the measurement data. This example showed how RaPId enables estimation of parameters even with the limited information (unknown exciter parameters and governor model and unknown plant or system configuration).Figure 29 Results of the estimation of excitation system parametersParameter Estimation of Aggregated Model of Generators:Modelica equivalent of the northern part of Norwegian grid surrounding Alta power station (AKD) is shown in Figure 30. Alongside, the two aggregated generators are marked whose aggregated parameters are estimated by using RaPId. Figure 30 AKD power system modelsThe aggregated generator contains models of machine, exciter and turbine governor. All of the parameters of these models are estimated by exciting the dynamics of the AKA system in form of line opening and step increase of the load. Successive estimation processes were performed separately for each of the models contained within the generating unit. The example of simulation results with estimated parameters for the model of machine and governor is shown in Figure 31. Figure 31 Estimation results for AKD systemSmall Signal Model Calibration of N44:Nordic44 model, shown in Section 0, has been used to demonstrate small signal model calibration at the system level. Estimation process has been carried for a parameter of generator inertia whose value has been changed from the true value of 3.556 to 4.556. The method combines the time-domain and the linearization workflows in RaPId. For the time-domain simulation workflow, the dynamics of the N44 system have been excited by opening the line adjacent to the bus where the generator inertia has been estimated. Estimation results are shown in Figure 32. The generator inertia has been estimated to be 3.5546 after 70 iterations. Also, it is shown that the mode used during the calibration, has been moved from the position with incorrect starting value of inertia, to a close proximity of the reference mode, when the estimation process was completed. Figure 32 Estimation results of small signal model calibrationResources:The following video provides an overview on RaPId, how to utilize it to set up a model validation example, and its application for validating the excitation system of the Mostar generator: iTesla RaPId – An Overview and Demo - https://www.youtube.com/watch?v=XAXZO9mAXVUSeveral demonstration videos have been developed to show the use of RaPId for different identification problems, they can be found in the links below.Demonstration Videos: Small Signal Calibration - https://www.youtube.com/watch?v=5s34tjT9Cwk Excitation System Identification - https://www.youtube.com/watch?v=X8X89l1HBjo GUI Demo - https://www.youtube.com/watch?v=e7OkVEtcz6A Scripting Demo - https://www.youtube.com/watch?v=4qrPASIWdiYThe following link provides all of the material developed by KTH to carry out a hands-on-tutorial on using RaPId. The tutorial shows how to set up different system identification experiments, with both synthetic (simulated) and actual measurements: RaPId Tutorial - https://github.com/SmarTS-Lab/iTesla_RaPId/releases/tag/Tuto_ModProd_2016 Tools for Validation of Very Large Power System Models:Three tools for validation of very large power system models have also been developed. The objective of the data verification tool is to perform a basic validation of all the synchronous generators in a particular system. The objective of the Parameter Optimization Tool is to determine the model parameters based on a given performance indicator. The performance indicator used is a measure of how well the simulation matches a measurement. The objective of the Sensitivity Calculation Tool is to reduce as much as possible the search space by selecting only the most relevant variables for tuning. By using a version of the dynamic power system simulation tool EUROSTAG® that incorporates the algorithmic advances from the PEGASE project, exploiting high performance computing (HPC), and using automated calculations and result analysis, it is possible to validate power systems as large as the European interconnected system.Figure 33: Validation of very large power system models.Recommendations regarding defence and restoration plans:Definitions and relation to iTesla toolbox:The iTesla project has supplemented the development of the iTesla toolbox with research activities about defence of power systems against blackouts in cases where the online security assessment fails e.g. due to cascading, and how the power systems are safely and swiftly restored if the defence plan also fails to prevent a blackout. In this sense, defence plans and restoration procedures provide the safety nets aiming at reducing the impact of low probability events with a high impact. There are diverse definitions on defence plans and restoration procedures. The definition applied in the iTesla project is based on the ENTSO-E system states definition shown in Figure 34, but also CIGRE definitions and NERC definitions have been considered.Figure 34: System states as per ENTSO-E definitionFigure 35 illustrates how the R&D activities in iTesla on defence plans and restoration procedures complement the work done in the iTesla toolbox. They complement the online security assessment performed by the iTesla toolbox by handling the low probability and high impact cases which move the network to Emergency and Blackout states. Figure 35: Defence plans and restoration procedures supplementing the iTesla toolboxComparing the iTesla scope in Figure 35 to the ENTSO-E definition in Figure 34, it is seen that the iTesla scope explicitly includes the two elements of the defence plan (special protection against emergency state and system protection against blackout) as well as Restoration from the Emergency state in addition to the Restoration from Blackout.Defence plans:The R&D on defence plans is reported in deliverable D6.2. The work has focused on: - Coordination and harmonisation, - Power flow control, - Use of PMU information, - Handling of renewables, - Handling of distributed energy sources.Coordination and harmonisation:A methodology is proposed to analyse and identify weak-points in the operating procedures used in existing defence plans. Focusing on voltage stability, the following metrics are defined to identify weak-points in the operational procedures used in defence plans: - Number of activated automatic control units, - Relative quantity of activated resources, - Quantity of used reactive power, - Number of activated automatic controls in generators and transformers. Another part of the work focus on the analysis of several combinations of the different Under Frequency Load Shedding (UFLS) settings used by the TSOs. The analysis has been performed on a test system. The main conclusions are: - Using the same approach in the different zones gives better results: burden is spread more equally. - Currently implemented under frequency load shedding schemes are adequate, but do not always spread the UFLS equally over the zones.Power flow control:The focus of the research on using power flow control has been on how embedded HVDC links can contribute during emergency situations. This work has shown that coordinating the control actions can provide additional advantages compared to only bilateral coordination between two TSOs. It has been shown on a test system, that more support can be delivered to the area in emergency and that the system is able to cope with larger events before load needs to be disconnected. Furthermore, two different types of coordinated optimization have been considered. Firstly, the minimal DC set point change optimization which provides the minimal change of DC link set points that is needed to mitigate the overload. This to limit the sudden power flow changes in the system. Secondly, the optimal AC relieve methodology which provides information about how much the DC links can contribute in mitigating the overload and the direction of the power flow through the DC links which results in a reduction of the power system overloads. Subsequently these optimizations have been extended to also include phase shifting transformers.Once a cascading outage takes place, the meshed system is weakened and more vulnerable to inter area oscillations. Simulations have verified the possibility to use a fast change in active set points of the HVDC links to stabilize inter-area oscillations. Once an event takes place and the excitation of the inter-area oscillation has been ascertained, a pre-event active power set point combination needs to be implemented to aid in stabilizing the oscillation. In the shown example changing the set points as a corrective control action succeeds in damping the oscillations and brings the system back to a stable operating point.In Figure 36 an overview is given of the movement of the critical eigenvalue due to the different events and set point changes in a Nordic 32 system test case. The figure illustrates that using power flow control prevents a critical eigenvalue to move into the right half (unstable) complex plane.Figure 36: The initial and final eigenvalue locations with and without coordinated HVDC power flow control in a Nordic 32 system test case.Use of PMU information:Utilizing the approach proposed in this work, an impending long-term system collapse can be determined directly from synchrophasor data, in which errors and unnecessary features embedded in measurements can be properly treated. A linear regression method for computing sensitivities was adopted to detect voltage instability, using a rolling window of PMU measurements. It has been shown that this methodology is simple and it can be effectively applied when both process and measurement noise are present. Moreover, activations of system components that capture voltage instability phenomena (i.e. OEL and OLTC) can be detected efficiently. There are two main advantages offered by this method: network topology and dynamic models are not required. The ultimate goal of determining sensitivities is not only to use them for wide-area monitoring but also to enable preventive actions and to facilitate cooperation with other controllable devices arming protection systems e.g. tripping loads. Such coordination could use these “defence signals” to activate a number of devices for preventing system collapse caused by voltage instability. A prototype tool with the purpose of automatic out-of-step relay tuning has been developed. The goal of the tool is to find the set of relay parameters that minimizes the number of unwanted tripping events and tripping failures. Doing this by hand is very time-consuming and leads to sub-optimal results. Additionally, it can only be performed for simple cases with a low number of relays. The prototype developed was first validated on the NORDIC system with one relay and subsequently in a more complex network where several relays had to be tuned simultaneously. Handling of renewables:The first part of this work has analysed how the increasing uncertainties due to increased penetration of wind power in the European power systems in 2020 and 2030 will affect the need for reserves. It should be kept in mind that these studies only considered imbalance caused by wind power forecasts. Therefore, the imbalances caused by other sources like load, other variable generations like solar PV, contingencies etc. should be added to these imbalances in the future for a complete system study. Based on the obtained results, following conclusions and recommendations have been made: - Simulations show that the use of frequency containment and frequency restoration reserve with expected wind power development in 2030 is expected to be much higher than in 2020 and today although improvements in wind power forecasts are not considered. - Increased volumes of frequency restoration reserves (FRR) will significantly reduce the probability of imbalances beyond the reference incidence (loss of 3GW generation). - Faster frequency restoration reserves will cause only minor reductions of the probability of imbalances beyond the reference incidence.The second part regarding renewables is using wind power control to mitigate over-frequencies, e.g. in cases like the 4th November 2006. Figure 37 shows simulated frequencies in a synthetic case using the detailed dynamic PEGASE model of the Continental European system in a case where Denmark and Germany are separated from the remaining system resulting in 9.4 GW excess (wind) generation. The figure shows the frequency when the wind power is disconnected as it was in the 4th November case and when over-frequency (emergency) control of the wind power is applied. Figure 37: Impact of overfrequency control of wind power plants.Handling of distributed energy resources:The first part of this work is focusing on thermostatically controlled loads (TCLs) to support frequency stability in defence plans. TCLs such as refrigerators and electric space heaters use temperature hysteresis controllers that are insensitive to small temperature fluctuations. This results in the ability to modulate the power absorbed, which may be used for providing a number of ancillary services over different timescales (e.g. primary frequency control, balancing services and energy arbitrage). In particular, the proposed ENTSO-E Demand Connection Code specifies a compulsory frequency control service for such appliances, which is to be implemented as a proportional shift of the set point temperature in accordance with frequency deviations. One of the conclusion of the iTesla work is that this ENTSO-E specification should be reviewed since it results in unpredictable outcomes that vary with implementations.This research explores the range of frequency response contributions that can be delivered by smart thermal appliances, and how they affect power system’s frequency performance. Two different implementations, namely the frequency linear controller and the pre-programmed controller, are introduced and analysed. The alternate strategy, the pre-programmed controller, has the benefit of providing both substantial support and flexibility allowing system operators (or demand response aggregators) to design complex responses in accordance with the technical and commercial requirements. Moreover, this implementation enlarges the range of applications of TCLs beyond frequency-only services, allowing also delivery of longer-term services such as energy arbitrage (by using the same pre-programmed control framework).The second part regarding distributed energy resources has analysed the impact of distributed renewable generation on UFLS in the distribution network. Due to the connection of an increased capacity of distributed generation, the load behaviour of distribution network feeders has changed significantly compared to the situation where the present load shedding schemes were developed. Thus, instead of only disconnecting load, both load and local generation are now being disconnected by load shedding. This issue is particularly problematic if there is more generation than load on a specific feeder, and therefore the disconnection of this feeder further worsens the power balance during an under frequency situation. This leads to less adequate UFLS schemes resulting in larger frequency nadir and a higher than necessary consumer impact. For residential areas with high penetration of photovoltaic panels, this is an issue, as they are usually considered as low priority and as such are the first to be disconnected.To overcome these issues, it is recommended to take the distributed generation into account during UFLS scheme design in future European power systems with increased penetration of renewable generation in the distribution system. For this purpose, several feeder ranking methods have been proposed and studied taking distributed generation into account. Each of the presented methodologies uses decentral activation of the relays, but different degrees of information to determine the feeder ranking. Furthermore, these ranking methodologies have been designed keeping in mind the practical implementation. The lowest level of improvement can be provided using directional relays, which take the power flow direction on the feeder into account and as such avoid generation disconnection. The highest level of improvement can be achieved by combining both load measurements and generation estimations, and updating relays settings several times intraday. However this methodology also implies new relays and communication infrastructure. The different feeder ranking methodologies have been implemented on data of a Belgian DSO (two feeder case) and the French DSO (1200 feeder case). Finally it can be concluded that in the current ENTSOE grid codes this issue has been largely overlooked, certainly with the EU perspectives on integration of distributed generation in mind.Restoration:The R&D on restoration after a blackout is reported in deliverable D6.3. The work has focused on - Hierarchical coordinated restoration, - Use of renewables.Hierarchical coordinated restoration:A methodology that could help TSOs in the preparation and evaluation of restoration plans in a coordinated context has been proposed. In addition, softwares from AIA (AGORA) and Tractebel (FAST DTS) have been integrated in a tool for automatic computation, simulation and validation of restoration (see Figure 6). The methodology has been applied inside the project to a synthetic network of France and Belgium for incidents affecting both countries and to a real time network of Belgium for a complete country blackout.The proposed methodology includes guidelines for the preparation and validation of restoration plans at TSO and regional level. For blackout scenarios affecting more than one TSO, at least two complete restoration plans should be prepared: - A Coordinated solution. A single, global coordinated plan that will be prepared assuming that any action from any Control Area can be considered at a given stage in the restoration process. - A Separate solution. A plan that is the result of merging different, separate and individual plans for each TSO involved in the blackout. The plan for each TSO will contain only resources from his own Control Area. The merging of the independent plans can be made taking into account different criteria and a minimum amount of coordination. The restoration plans can be automatically computed using AGORA taking into account different strategies: the grid can be recovered from existing parts of the network that remain energised after the incident (top-down approach) or from generating units that can be started without any external source of energy (bottom-up approach) or a combination of both approaches.Given different restoration plans for the same disturbance, a comparison between them can be made based on different performance and reliability metrics that have been analysed and formalised in the proposed methodology: speed of load recovery, time to recover critical loads, frequency variations, amount of active and reactive reserves during the process, distance to operational limits, dynamic stability indicators, etc. As an example, Figure 38 illustrates how much load has been recovered by coordinated and separate plans along the time for an incident involving many TSOs. It can be seen that load is recovered faster in the coordinated plan. Figure 38: Load recovery along the time for two example plans.Main conclusions were the advantage of coordination for restoration actions between regions rather than isolated regional restoration, and the adequacy of the integration AGORA/FAST DTS to include dynamic assessment of actions of a given restoration plan (testing the offline simulation mode allowing to forecast a reasonable feasibility to proceed to execute in real-time in the future). Use of renewables to support power system restoration:This task aimed at evaluating the benefit of including renewable based energy sources, namely large wind parks, in the process of power system restoration (PSR), bearing in mind an increase of load pick up and reduction of reposition time. This was made through an adequate modelling of these renewable resources and its inclusion in the PSR process, namely analysis aiming at identifying the way to operate conventional power system units in the upstream transmission level, that are now combined with large wind farms, connected both in HVAC and HVDC systems. Considering the advanced features (reactive power / voltage control and primary frequency regulation capabilities) that power energy converters installed in large wind farms provide, it is possible to exploit the wind power plants to support the restoration process.For comparison, the restoration is simulated and compared in 2 different cases: a) The power system includes only conventional generation units. b) The system includes one large HVDC connected wind power plant.The base methodology is to energize the same path in both situations, assess frequency and voltage variations during the process, trying to maximize the amount of restored load for the same time.The restoration process that takes the shortest time to be completed in the established conditions is case b). However, it must be stressed that the power restoration procedure time does not differ significantly in both cases. The main reason behind this result has to do with the initialization of the wind parks and the minimum time between power increments in the cases where wind generation is integrated in the system. This requires an extra time that could be used to restore loads in a shorter time. However, after these systems are integrated in the network, it is possible to feed more power, which ends up compensating for the total time spent. Another relevant conclusion is the higher control of frequency variation, as the ramping of the wind parks guarantees a smother power connection and a higher voltage control.Overall recommendations towards Entso-e TSOs:Over the past four years the iTesla and UMBRELLA projects have developed toolboxes in order to ensure secure grid operation also in future electricity networks with high penetration of intermittent RES. Based on this work, a common deliverable has been published which includes a set of recommendations to European Network of Transmission System Operators for Electricity (ENTSO-E) regarding TSO & RSCI rules for business processes and data exchange.Exchange of static data in CGMES format:In ENTSO-E Regional Continental Europe (RG CE) the data format UCTE DEF is currently in operation for several processes (DACF, IDCF, D2CF) which are performed by all RG CE TSOs. For the upcoming challenges this format is not suited anymore. For example, limitations like the node-branch-based topology model with identifiers which are not unique and persistent between different datasets prevent the functionalities developed by iTesla or UMBRELLA from running at their full potential. After investigation by ENTSO-E the CIM/XML based Common Grid Model Exchange Standard (CGMES) format was selected as future format for data exchange.Recommendation 1:European TSOs should exchange static data of their respective system in Common Grid Model Exchange Standard (CGMES) format as soon as possible. Identifiers of network elements should be unique and persistent across the datasets in order to be able to perform an advance security assessment.Enhanced data format and network modelling:Today most of the tools used by the TSOs to generate CGMES files have only a bus-branch description of the grid, aggregating generation units, loads and using varying identifiers from one dataset to another one, even if a more detailed description is available within the concerned TSOs. This is unacceptable since a proper mapping of static and dynamic data is required to run accurate (dynamic) simulations. If this requirement is not taken into account, the added value of CGMES format with regard to UCTE format is useless. This requirement is also needed for data mining of historical data, which is needed in order to parameterize system use cases regarding load, RES and risk/reliability data properly. The TSOs should model the topology in a breaker-oriented way in order to assign equipment and loads properly. Recommendation 2:When exchanging data using the CGMES format, European TSOs should use persistent identifiers for equipment in order to be able to match them with additional data automatically (e.g. dynamic and economic data). The incorporation of the additional information, like redispatch potential, should be considered in the further development of CGMES. Aggregation of injections (loads and generation units, also RES) should be avoided, whenever possible, and forbidden for large generation units.Furthermore a common understanding and as far as possible a harmonization regarding the detail of grid modelling should be sought by the TSOs.Exchange of remedial actions:In order to be exhaustive, tools for assessing the security of power system situations should simulate not only the impact of the contingencies selected by the operator but also the efficiency of remedial actions adopted in case of violations caused by these contingencies. It is not necessary to warn the operator when corrective remedial actions (identified in advance by the operator and/or obtained from an optimization module) have been proven to be efficient to keep the system in a secure state. Nevertheless the operator has to be made aware of the situation and in case of an effect on a neighbouring TSO-grid these corrective remedial actions have to be agreed upon. When corrective remedial actions are not sufficient to alleviate all the constraints, the operator needs to know which preventive remedial actions must be put in place and at what time.Therefore exist a need to have a common understanding of modelling of contingencies and of preventive and corrective remedial actions among European TSOs and a common exchange format. Especially with respect to an automatic security constrained optimization, a clear unambiguous modelling of the different kind of remedial actions is needed.Recommendation 3:In addition to static data of their respective system, European TSOs should exchange a list of contingencies to be simulated or the methodology to determine the contingencies as well as a catalogue of relevant remedial actions. Moreover a harmonization of the merit order of remedial actions is needed to be able to get common proposals of remedial actions from the new tools developed by iTesla and UMBRELLA. The exchange format needs to be consistent with the description of the system (use of CGMES with unique and persistent identifiers).Exchange of dynamic data in the future transmission system operation:Today most of the TSOs take into account dynamic phenomena in their security assessment in one way or another, but very rarely in a systematic way, from two days ahead to real time using all available files (D2CF, DACF, IDCF and snapshot files ) updated regularly. The need to take into account dynamic phenomena in a more systematic way in operation was fully confirmed by a survey made among the iTesla TSOs at the beginning of the project (see public iTesla deliverable D1.1 “Formulation of the overall problem encountered by TSOs”).Therefore the next generation of tools that will be made available to operators in the coming years to assess the security of power system situations over a time span from two days ahead to real time will include functionalities for accurate time domain simulations, potentially from a local geographical perimeter up to the pan-European one. These models will simulate the dynamic behaviour of generators, control systems, protections and all other components with fast dynamic behaviours. They will detect every possible dangerous dynamic phenomenon that could occur in case of contingency N-1/N-k or in case a remedial action is put in place by the operator to alleviate a constraint.Recommendation 4:European TSOs should exchange dynamic data of their respective system to be able to run time domain simulations on all or parts of the European system in the framework of systematic security assessment of system situations from D-2 to close to real timeFormat of exchange of dynamic data among European TSOs:Static data is something well-known and a common understanding of the static models of devices such as generators, lines, transformers and loads has been easily reached by all TSOs even with use of different simulation tools. On the other hand, a common understanding of devices with complex dynamic behaviours is much more difficult (even for standard dynamic models) and sometimes nearly impossible. To overcome this difficulty, two solutions are proposed, a short-term one and a long term one. The short-term solution relies on the exchange of: - Data in CGMES format as already explained in the Recommendation 1. - Dynamic models in native formats, i.e. in the original dynamic formats used by TSOs for their own dynamic studies (for instance in PSS/E® or EUROSTAG® format). - A table of association to map the CIM ID of any static component (for example the ID of a generator) with a dynamic model (for example the dynamic model of a synchronous machine). This association should also include the values of associated parameters.Recommendation 5:In the short term, European TSOs should exchange dynamic data using standard or “user defined” models in the format they use for their internal dynamic studies.In the framework of the iTesla project, a Power System MODELICA Library has been built with several (or all in some cases) dynamic models used by iTesla TSOs whose reference software implementation is either in PSS/E® or EUROSTAG®. All those models have been translated into a MODELICA equivalent, validated against their reference software and put in the library. Note that the translation from proprietary models to MODELICA is possible with no loss of information even for user defined models, but the other direction is not possible since MODELICA offers a more general way to define a system with differential-algebraic equations.The long-term solution proposed by the iTesla project relies on the exchange of CGMES files (which include static and dynamic data) and on links between these files and the MODELICA library. Then it is possible to associate the CIM ID of any dynamic model to which it is referred in a CGMES file (standard model or “user defined” model) with one model of the MODELICA library.This solution will encourage vendors to develop tools compliant with the MODELICA language. This would have the following main advantages: - A common, standardized and open equation-based modelling language and parameter exchange data format with a common understanding of the models in it, - The creation of a truly free market place for modelling and simulation tool vendors, which would encourage solutions that focus on accuracy and performance using the exact same data in input (thereby decoupling of modelling and solving), - A compliance with what has already been done for static data exchange among European TSOs (CIM static), - Flexibility to define new models without the need to update the version of the exchange format (new equations are put in the library, references are still stored in the CIM dynamic file).Recommendation 6 (iTesla):European TSOs should exchange CGMES files of their respective system and it is proposed to encourage the power system community to use the open source iTesla Power System MODELICA library to be able to run time domain simulations on all or parts of the European system using MODELICA language compliant simulation engineRisk management and reliability criteria:Currently, there is no explicit calculation of risk in operational planning or real-time operation. Since the N-1 criterion considers the risk of outages only implicitly (i.e. no differentiation between the probability of different outages or the severity of the resulting operating conditions), costly measures are implemented to resolve N-1 violations with low risk, e.g. where the amount of customers hit by a failure would be marginal, the probability of the initial failure is negligible or the N-1 violation would cause no further cascading. On the other hand, which is the worst case from the perspective of a TSO, an N-1 secure state might not be sufficiently safe due to the possibility, that more than one single network element trips. Although this is a rare event with low probability, the severity of such an event might be high, leading to a significant risk. Furthermore, even though the forecasted system state was N-1 secure, uncertainty due to intra-day energy trades and forecast errors regarding power injections from RES power plants might lead to frequent violations of the N-1 criterion in real-time operation.Recommendation 7:European TSOs should be encouraged to develop and include common risk-based criteria for security assessment in their operational planning process and real-time operation. In particular, these criteria should include data related to reliability and/or failure rates of equipment, estimates of the (cost of) energy not served, as well as more comprehensive forecasts to describe uncertainties from RES, load and intra-day trading.Defence and restoration plans:Whether based on the N-1 criterion or on alternative probabilistic security criteria, there will inevitably be a risk of exceptional contingencies and related system responses, e.g. due to cascading events which are not considered by the online security assessment, and even though the probability of such occurrences is very low, the impact may be very severe deterioration of the system to a more critical state (emergency state or even a black-out).Recommendation 8:European TSOs are encouraged to continue the ongoing work towards harmonization of defence plans and restoration procedures, and consider to integrate solutions for coordinated power flow control of embedded HVDCs to dampen inter-area oscillations, over-frequency control of renewable generation and frequency control of consumption to defend the frequency stability, and use of PMU information for early detection of voltage instability and use tools for automated tuning of out-of-step relays. There is also a need to consider the impact of the steadily increasing amount of distributed generation on the existing load shedding schemes. Finally, the TSOs should consider using automatically computed coordinated restoration plans taking into account dynamics and further investigate possibilities of using AC and DC connected controllable wind power plant to speed up restoration.Amendment of operational security processes & tools:As stated in the previous chapters there is an increasing complexity in transmission system operation induced by the increasing amount of RES and cross-border trading. Therefore the future security assessment tools developed by iTesla and UMBRELLA will support operational planers in a coordinated way by finding a common optimal solution for different congestions and different combinations of uncertainties taking time dependent conditions into account. Practical tests in the toolbox prototypes and operational experience show, that it is essential to determine, evaluate and implement remedial actions in a coordinated way. The iterations caused by shifting of congestions from one TSO to another TSO due to the implementation of remedial actions with different priorities need to be avoided. The Network Codes, especially the NC OS, drafted by the ENTSO-E and enacted by the European Commission were an important step along the path of the harmonization of legal/regulatory frameworks within the European electricity system. But in order to achieve the best possible solutions in terms of a European optimum a further harmonization and clarification is needed, which is not addressed in this level of detail by the network codes.Recommendation 9:The experience of the TSOs shows that for the successful daily operation the European TSOs should further develop and harmonize their processes regarding operational planning and real-time operation, incorporating the preferable functionalities from the research projects. Support from legal and regulatory side is needed in order to achieve the best possible solutions in terms of a European optimum. The most promising approach in order to achieve this is a strong cooperation among the national regulations authorities.Potential Impact:Main dissemination activities:Different dissemination measures were undertaken to ensure the adoption and diffusion of the iTesla concepts and tools by TSOs, the research community, equipment manufacturers, the open source community and regulators:- Building an online project website www.itesla-project.eu;- Publication of scientific papers; - Publications and contributions to conferences in Europe and worldwide; - Organization of targeted workshops/events towards each audience;- Communicating the open source release of the iTesla Platform.The main dissemination events organized by the iTesla consortium between 2012 and early 2016 are the following:- Three workshops towards the TSO community (26th June 2013 in Nice, 22nd of August 2014 in Paris (before the CIGRE Paris 2014) with a specific dissemination session, held in parallel, dedicated to academic researchers and software developers on 4-5th of November 2015 in Brussels);- Three joint workshops with UMBRELLA (21st June 2012, 14th of January 2014 and 26th of January 2016 in Brussels);- Two meetings with regulators (30th of June 2014 in Ljubljana at ACER headquarters, 17th March 2016 in Brussels);- The GARPUR – iTesla meeting, 25 January 2016 in Brussels;- The PowerTech 2015 conference, 29 June – 2 July 2015 in Eindhoven: a joint session was held by the three FP7 projects iTesla, Umbrella and Garpur, on the 30th of June 2015;- The work carried out in Modelica was disseminated in several conferences and events attended by the Modelica open source community, e.g. the MODPROD workshop 2014 and 2016 on Model-Based Product Development, the International Modelica Conference 2014, the 56th Conference on Simulation and Modeling in October 2015, the iTesla Workshop at the University College of Southeast Norway, campus Porsgrunn on March 29 2016: “iTesla Result Dissemination Workshop: OSS Tools for Power System Modeling and Simulation @ HSN”.The adoption of the CIM by TSOs being also critical for the widespread of the iTesla concepts, some of the iTesla partners participated in: - The 2014 meeting of the CIM users group dealing with “EU Network Codes: Meeting the Transmission and Distribution Challenge Using the CIM".The iTesla partners are planning to organise two other important events taking place after the completion of the project:- The CIGRE Session 2016, August 21-26, 2016 in Paris (Palais des Congrès) where iTesla is planning to organise a joint side event with GARPUR to be held on the 25th of August 2016;- The 19th Power Systems Computation Conference (PSCC 2016) taking place from June 20th to 24th 2016 in Genova, Italy, where iTesla is also planning to organise a side event.Potential impacts:The different measures undertaken by the consortium allowed achieving the following results by February 2016:Website:8986 single visitors on the project website over 4 years, over one third of these users came back at least once.Papers and conferences:34 peer-reviewed papers and 27 different posters in mostly European and International conferences and journals.Project events:212 non-iTesla participants joined the iTesla dissemination workshops.17 different TSOs represented including 3 non-European TSOs, in addition to the 6 TSOs of the iTesla consortium and CORESO.Articles in scientific journalsThree scientific journal articles published and seven others will be published during 2016.Regulators :CIM users Community 1 meeting at ACER headquarters.4 national regulators involved, beyond the headquarters’ team.1 joint meeting with Garpur on 17th March 2016 with national regulators and ministries.Open Source Community:3 events focused on OS Modelica language and libraries to share experience on Modelica applied to power systems.1 workshop in Porsgrunn, Norway with a group of experts on Modelica : discussion of possible use of the iTesla tool.1 paper focused on Modelica implementation and software-to-software validation of power system component models commonly used by Nordic TSOs for dynamic simulations.CIM uses community:1 meeting with CIM users and RTE to share experiences on data management in the project.1 paper presented at the IEEE General Meeting in July 2015.Societal impacts:The use of the iTesla toolbox will contribute to the overall European objectives in the energy sector:- It will help maximizing the share of renewable electricity production;- Consequently it will help minimizing the share of fossil fuel power plants, thus reducing CO2 emissions;- It will help optimising the use of grid assets thus limiting the need to extend the network, e.g. build new overhead transmission lines which raises many public acceptance issues.Impacts on TSO community:Three workshops towards the TSO community took place, with both an informative and consultative objective. These workshops gathered representatives of 17 different TSOs (including 3 non-European TSOs from Brazil, Israel and New Zealand), in addition to the 6 TSOs of the iTesla consortium and the CORESO coordination center. These events allowed the non-iTesla TSOs to interact with the project developers and give their operational feedback on the design choices and the use cases proposed for validation. Valuable feedbacks on the iTesla toolbox architecture and components were generated. At the end of the project, after an industrialization phase, the iTesla concepts are expected to be used by several TSOs in the operation of their respective grids from two days ahead to real time. They are also expected to be used by Coreso at the European level for coordination purposes. Indeed, the iTesla concepts are able to bring increased coordination support to the daily operation of the pan-European electricity transmission network (beyond what is already done on a daily basis at Coreso).Today, the lack of knowledge about uncertainties affecting some system variables and about possible violations of dynamic limitations leads TSOs:- either to operate with higher (and costly) security margins than needed,- or to operate within system states that are very critical, but not known by operators. iTesla can help any TSO take the right decisions and in particular benefit from the project’s results in terms of availability and efficiency of curative actions needed to keep the system in a secure state.Impacts on OS Community:Three major outputs of the iTesla project have been released open source:- The iTesla platform (MPL 2.0);- The RaPId software (GNU LGPL v3);- The iTesla Power System Library of power system component models in the MODELICA language (MPL 2.0).These open source software will be used to disseminate the concepts developed by the iTesla project in the power system community, and possibly beyond.Impacts on CIM users:The adoption of the CIM format by TSOs was identified as a critical success factor for the widespread of iTesla concepts. Therefore, RTE participated in the 2014 meeting of the CIM users group dealing with “EU Network Codes: Meeting the Transmission and Distribution Challenge Using the CIM" to share their experiences on data management in the iTesla Project. The iTesla consortium made a set of recommendations concerning the use of the CIM format towards ENTSO-E TSOs. The iTesla proposition is currently being assessed by the CIM ENTSO-E working groups (see section 0 of this document for more details).Impacts on Regulators:The coordination and dissemination partners of iTesla, GARPUR and UMBRELLA joined forces to disseminate towards the regulators. The first meeting allowed regulators to get an overview of some research activities jointly performed by TSOs and academia in relation with the security assessment of power transmission systems, and to be aware of the potential impacts of these activities on European Network Codes. During the second meeting, the iTesla experts presented and debated with energy regulators and ministries the most recent achievements and plans for future developments (especially the possible consequences in terms of grid codes).List of Websites:• Website address: http://www.itesla-project.eu/ • Coordinator contact:Christian LemaîtreR&D expertRTE9, rue de la porte de Buc, 78005 Versailles, Francechristian.lemaitre@rte-france.com Related documents final1-itesla-d9-2-final-report-v5.pdf
