Analysis Report on CIM
Interoperability Guideline
May 2017
Contents
Chapter 1. Overview of CIM Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·2
Section 1. Overview of Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·3
1. Need of Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·3
2. Introduction to ENTSO-E Interoperability Test ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·3
Section 2. Definition of Data in Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·6
1. Definition of Interoperability CIM/XML Test Model ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·6
2. Definition of Interoperability CIM/XML Test ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·8
Chapter 2. Analysis of ENTSO-E Interoperability Test Case ·10
Section 1. Analysis of Interoperability Process ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·11
1. Interoperability Test Procedure ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·11
Section 2. Analysis of Interoperability Test Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·15
1. Analysis of Stage 1 Test for Interoperability Test Procedure ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·15
2. Analysis of Stage 2 Test for Interoperability Test Procedure ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·30
Chapter 3. Technological Considerations of ENTSO-E
Interoperability Test Model ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·38
Section 1. Framework for Interoperability Model Exchange ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·39
1. Need of Interoperability Model Exchange ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·39
2. Use Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·40
Section 2. Power System Project ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·51
1. Need of Power System Project ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·51
2. Use Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·51
3. Interoperability Test Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·52
Section 3. Power System Project ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·64
1. Need of Variation Processing in Power System ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·64
2. Generating Scenario and Processing Variation in Power System ·
·
·
·
·
·
·
·
·
·
·
·
·65
3. Generating Data Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·69
4. Use Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·75
Section 4. Installed Capacity Calculating Profile ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·87
1. Need to Calculate Installed Capacity ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·87
2. European Power Market ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·89
3. Use Case ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·91
Chapter 4. Test Case Guideline for CIM Interoperability
in Korea ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·103
Section 1. CIM-XML Syntax Compliance Factors for Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·104
1. CIM-XML Syntax Compliance Factors for Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·104
2. CIM-XML Profile Compliance Factors for Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·104
Section 2. Compliance Factors for Interpreting Power System of CIM-XML Data
for Interoperability ·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·110
1. Data Conformance Validating Factors for CIM-XML Power System ·
·
·
·
·
·110
2. Data Conformance Validating Factors Acquired by CIM-XML Power System ·113
Ch 1
Overview of CIM
Interoperability
Section 1. Overview of Interoperability
1. Need of Interoperability
In the unstandardized technological era, a range of different forms of
models were used by institutions, companies, countries, regions and elements
to express the same power system or facility into data information model.
With the emergence of smart grids and digital substations, to expand the
operation through the exchange of data information model expressing the
power system, the unified form of information model is being used as the
CIM/XML standard (61970, 61850, 61968) ruled by the IEC. The form of
CIM/XML provided by IEC only suggests the basic form and regulations, and
operators of power system and unregulated information can be expanded and
modified as needed. Also, until now, not all power system information (EMS,
SCADA,
DMS,
international
comply
(renewable)
standard
with
the
and
generator,
existing
international
IED,
etc.)
facility
standards.
have
system
Hence,
been
converted
manufacturers
there
is
still
to
do
not
room
for
generating additional information models. Likewise, with the emergence of
international standard based system, under the system operating environment
of
information
exchange
between
different
systems,
the
possibility
of
information exchange needs to be reviewed from data expressions using
CIM/XML basis.
2. Introduction to ENTSO-E Interoperability Test
Currently, the interoperability of CIM-XML is being conducted by the
ENTSO-E (European Network of Transmission System Operators for
Electricity). It consists of 34 countries and 41 power companies. The details of
member companies are as follows. ENTSO-E classifies and integrates each of
the operating structures, and it operates local synchronization and
interoperability under a major working group.
m Consists of 36 countries and 43 power companies
<Figure 1-1> ENTSO-E Members and Classification Codes
TSOs : Transmission System
m
Operators
ENTSO-E Members
Classifications
Countries/Cities
Power Companies
AT/Austria
Austrian Power Grid AG (APG)
Vorarlberger Übertragungsnetz GmbH (VUEN)
AL/Albania
Sistemit te Transmetimit (OST sh.a)
BA / Bosnia
Herzegovina
and
Nezavisni
operator sustava u Bosni i Hercegovini (NOS BiH)
BE / Belgium
Elia System Operator SA (Elia)
BG / Bulgaria
Electroenergien
CH / Switzerland
Swissgrid ag (Swissgrid)
CY / Cyprus
Cyprus
CZ / Czech
Republic
DE / Germany
Sistemen Operator EAD (ESO)
Transmission System Operator (Cyprus TSO)
ČEPSa.s. (ČEPS)
TransnetBW GmbH (TransnetBW)
ENTSO-E Members
Classifications
Countries/Cities
Power Companies
TenneT TSO GmbH (TenneT DE)
Amprion GmbH (Amprion)
50Hertz Transmission GmbH (50Hertz)
DK / Denmark
Energinet.dk (Energinet.dk)
EE / Estonia
Elering
ES / Spain
Red Eléctrica de España: S.A. (REE)
FI / Finland
Fingrid OyJ (Fingrid)
FR / France
Réseau de
GB / United
Kingdom
AS (Elerinng AS)
Transport d'Electricité (RTE)
National Grid Electricity Transmission plc (National Grid)
System Operator for Northern Ireland Ltd (SONI)
Scottish Hydro Electric Transmission plc (SHE Transmission)
Scottish Power Transmission plc (SPTransmission)
GR / Greece
Independent
Power Transmission Operator S.A. (IPTO)
HR / Croatia
HEP-Operator
HU / Hungary
MAVIRMagyarVillamosenergia (MAVIR ZRt)
-ipariÁtviteliRendszerirányító
Részvénytársaság
IE / Ireland
EirGrid
IS / Iceland
Landsnet hf (Landsnet)
IT / Italy
Terna
LT / Lithuania
Litgrid AB (Litgrid)
LU / Luxembourg
Creos
LV / Latvia
AS
ME / Montenegro
Crnogorski
elektroprenosni
elektroprenosni sistem)
MK / FYROM
Macedonian
NL / Netherlands
TenneT
NO / Norway
Statnett SF (Statnett)
PL / Poland
PSE S.A. (PSE S.A.)
PT / Portugal
Rede Eléctrica
RO / Romania
C.N.
RS / Serbia
JP Elektromreža
SE / Sweden
Svenska
SI / Slovenia
Elektro
SK / Slovak Republic
Slovenska elektrizacna prenosova sustava, a.s. (SEPS)
TR - Observer Trukey
TEİAŞ (TEİAŞ)
prijenosnog sustava d.o.o. (HOPS)
ZártkörűenMűködő
plc (EirGrid)
- Rete Elettrica Nazionale SpA (Terna)
Luxembourg S.A. (Creos Luxembourg)
Augstsprieguma tÏkls (Augstsprieguma tÏkls)
sistem
AD
(Crnogorski
Transmission System Operator AD (MEPSO)
TSO B.V. (TenneT NL)
Nacional, S.A. (REN)
Transelectrica S.A. (Transelectrica)
Srbije (EMS)
Kraftnät (SVENSKA KRAFTNäT)
Slovenija d.o.o. (ELES)
Section 2. Definition of Interoperability Data
1. Definition of Interoperability CIM/XML Test Model
CIM/XML models for testing interoperability can be classified into two
groups as follows.
A. Classification by Information Model Specifications
- CIM/XML : IEC 61970 Basic Standard Model Ver16_RevXX
- CIM/XML-Extension : IEC 61970 Ver16 Based User Extension Standard Model
B. Classification by Form
(1) Full Model
- Complete form including all the information required for expressing a model
- Base Model
(2) Partial Model
- Form of information divided from or merged with full model
- Unlike full model, it can exist in incomplete form. In other words,
while it is meaningful independently, it also includes the areas that
cannot be used independently.
- Form that can be classified into standardized information (TP, SV,
EQ) and user selection group
(3) Incremental Model
- Form of information with the factors to be reflected to the
information of the full model entered
- Updated form of information unlike the merged/replaced form of
partial model
- Can be divided or derived from full model or partial model for
modification
- Its form includes addition or deletion of power facility, change of
measurement or status and addition or extension information
C. Conversion (Division)
(1) Conversion (division) includes the conversion (division) into the
same structure and conversion into different structure as
follows.
(A) CIM/XML -> CIM/XML Conversion
- Full -> Full
: Convert from Import, Export process by applying version
: Convert from Import, Export process to IEC 61970-453 CPSM
(Common Power System Model)
- Partial -> Partial
: Convert from Import, Export process by applying version
: Convert from Import, Export process to IEC 61970-453 CPSM
(Common Power System Model)
(B) CIM/XML -> CIM/XML Division
- Full -> Partial, Incremental
: Convert from Full Model into Profile, CPSM model by selecting
Partial, Incremental Model group
- Partial -> Partial, Incremental
: Convert from Partial Model to Profile, CPSM model by selecting
Partial, Incremental Model group
D. Merger
<Figure 1-2> CIM/XML Merger
(1) Merger of model with two independent power information
- Merge A and B model information in the merger process as models
of common structure are used
- Electrically, two regions are independent from each other.
- In the merger process, mrID, rdfID and resourceID of A and B
models need to be processed.
- In the merger process, overlapping information on border needs to be
processed.
- Independent information needs to be connected.
<Figure 1-3> Electrical Independency
<Figure 1-4> Electrical Connection
<Figure 1-5> Electrical Overlapping
Two partial models derived from a single shared model have three
conditions as shown above, and three areas - independent, tie and overlapping
- need to be processed.
2. Definition of Interoperability CIM/XML Test
For interoperability test, the following items are currently managing and
recording tests under ENTSO-E.
- Basic Test : Compatibility test of import, export and re-import processes
of tested document (CIM/XML)
- Instance Test : Instance comparison test between import, re-import and
converted document of tested document (CIM/XML)
- Topology Test : Topology test of tested document
- Merger1) : Test on possibility of merger between tested documents
- Conversion2) : Test on inclusiveness of necessary information for
conversion of tested document
- Division3) : Test on inclusiveness of necessary information for division
of tested document
- Increment4) : Compatibility test on application of increment/decrement of
tested document
- Interpretation5) : Test on possibility of interpretation of tested document,
Test comparing the interpretation result between tested documents
- Scenario : Perform test by making a scenario of a series of tests
- Test Module : Perform the above tests
1) Merger : Merging two CIM models to create one CIM model
2) Conversion : Converting CIM model into PSS/E model
3) Division : Taking out a portion of CIM model to make a partial model
4) Increment/Decrement : Reflecting new incremental information to existing CIM model to
create CIM model
5) Interpretation : Performing interpretation on power system expressed in CIM model
ENTSO-E
Analysis of
Ch 2
Interoperability
Test Case
Section 1. Analysis of Interoperability Process
1. Interoperability Test Procedure
Interoperability test is performed separately by EPRI and ENTSO-E. The
following is the test procedure and items at ENTSO-E. Interoperability test is
conducted in two stages.
m In stage 1, A-H number of test evaluations are graded, and in stage 2,
the compliance to 1-32 tests is measured.
For necessary sample data, the evaluation group at ENTSO-E and each
vendor share CIM14 and CIM16 versions prepared in advance using
NMD.
<Figure 2-1> ENTSO-E NMD Based Test Model
- TSO Model : Among ENTOS-E models, the file consisting of
Equipment (EQ), Topology (TO) and State Variables (SV) as the basic
models including one measurement
- NMD : Network Modeling DataBase. Test sample of file server
Replace by offline file if file cannot be downloaded, uploaded or shared
via communication network
Each testing stage will be led by a supervisor. The verification result
of the tool is submitted by a screenshot with a marking table and
opinion.
- Stage 1 Test Sheet
- Stage 2 Test Sheet
Section 2. Analysis of Interoperability Test Case
1. Analysis of Stage 1 Test for Interoperability Test
Procedure
m
Test No A : Set off TSO review model
- Purpose : To verify that TSO review model can be set off and reenter
to verify the same result is indicated
Use Equipment (EQ), Topology (TP), and State Variables (SV) XML
files in *.zip file format
Task
-
m
Cannot set off output
Can set off output including
Verify CIMDesk / CIMSpy EE
When reentering file already
Confirm the same load flow
ENTSO-E tie information
output
set off, there is no changed value. No error.
result
m
3
Test No B: Use TSO model in NMD
- Purpose : For TSO evaluator to verify the file set off from reviewed materials
Use Equipment (EQ), Topology (TP), and State Variables (SV) XML files
in *.zip file format
Task
-
Score
0
1
2
Non-compliance in syntax validation of file submitted to NMD
Non-compliance in business validation at ENTSO-E
Compliance with warning from NMD
Compliance without warning from NMD
Score
0
1
2
3
Test No C: Download TSO model necessary at NMD
- Purpose : For TSO evaluator to verify if TSO model can be
downloaded from NMD
Task
- Can download model
- Validation in CIMDesk / CIMSpy EE and error (from NMD)
- No changed value in downloaded model input. No error. Same load flow
result confirmed.
Score
0
1
2
m
Test No D: Use TSO partial model in NMD
- Purpose : For TSO evaluator to verify the model set off from review
tool
Use only TP, SV or SV file
Task
- Can set off partial model file
- Non-compliance in syntax validation of partial model file submitted to NMD
- Non-compliance in business validation of ENTSO-E
- Compliance with warning from NMD
- Compliance without warning from NMD
m
Score
0
1
2
3
4
Test No E: Download TSO partial model needed from NMD
- Purpose : For TSO evaluator to verify if TSO partial model can be
downloaded from NMD
Task
- CIMDesk / CIMSpy EE validation of partial model and error (from NMD)
Score
0
1
- No change in downloaded model input. No error. Same load flow result
confirmed
2
- Can download partial model
m
Test No F: Download different TSO model from NMD
- Purpose : To verify the use of different TSO model in NMD to see if different
TSO model can be used
Task
- Download model
- Verify CIMDesk / CIMSpy EE and error (from NMD)
- Cannot enter different TSO model. Cannot enter
- Can enter. With error
- Can enter. Without error
- Load Flow capable. With error
- Load Flow capable. Without error
- Load Flow calculation satisfies tolerance
Score
0
1
2
3
4
5
6
m
Test No G: Use assembled model of NMD
- Purpose : To verify possibility to use assembled (merged) model of NMD
Task
- Use assembled (merged) model in NMD
- Verification of CIMDesk / CIMSpy EE and error (from NMD)
- Cannot enter different TSO model. Cannot enter
- Can enter. With error
- Can enter. Without error
- Load Flow capable. With error
- Load Flow capable. Without error
- Load Flow calculation satisfies tolerance
- Load Flow result matches the value defined in NMD
m
Score
0
1
2
3
4
5
6
7
Test No H: Verify assembled (merged) model of evaluator
- Purpose : For TSO evaluator to verify assembled (merged) model and tool
Task
- Download Socre 6 model of Test F
- No error in assembled (merged) model
- Load Flow capable. With error
- Load Flow capable. Without error
- Load Flow calculation satisfies tolerance
Score
0
1
2
3
4
■ Test Procedure and Sample of Result of European Vendor
<Figure 2-2> Test Procedure and Sample of Result of European Vendor
m
Test No A : Set off TSO review model
<Figure 2-3> Set off TSO Review Model
- Set off Italian system in CIM format
- Enter tie area (IOP Test Scenario of NMD : IOP Test Rte Terna) of
Italian system
- Submit error output of CIMDesk / CIMSpy EE
<Figure 2-4> 2_CIMDesk_Test_A.png
<Figure 2-5> CIMDesk_Test_A.png
- Load Flow Calculation : Comparison value within 5%
<Figure 2-6> Initial Input ( 1_LF_TSO_Model.jpeg)
<Figure 2-7> After Calculation ( 2_LF_Re-Imported_Model.jpge)
m
Test No B: Use TSO model in NMD
<Figure 2-8> Use TSO Model in NMD
- As a result of submitting NMD, Italian system of [IOP 2013 April Test]
was
successfully
submitted
with
partial
errors
(NMD_Succesfully_Model_Submit.jpg)
<Figure 2-9> NMD Submission Result
m
Test No C: Download TSO model necessary for NMD
<Figure 2-10> Download TSO Model Necessary for NMD
- CIMDesk / CIMSpy EE result of Test B Model (CIMDesk_validation.jpg)
<Figure 2-11> CIMDesk / CIMSpy EE Result
- Review load flow from Test B model
<Figure 2-12> 1_LF_model_submitted_to_NMD.jpeg
<Figure 2-13> 2_LF_model_imported_from_NMD.jpeg
m
Test No D: Use TSO partial model in NMD
<Figure 2-14> Use TSO Partial Model in NMD
- Submit SV partial model to NMD
<Figure 2-15> Submit_partial_succesfully_SV.jpg
<Figure 2-16> Submit_partial_successfully_2_SV.jpg
m
Test No E: Download TSO partial model necessary for NMD
<Figure 2-17> Test No E
- Submission result of SV model, a partial model of Test D to NMD
<Figure 2-18> CIMDesk_Validation.jpg
- Load flow result of the partial model of Test D used in Test C
<Figure 2-19> 1_LF_model_imported_from_NMD.jpeg
<Figure 2-20> 2_LF_Submitted_Partial_SV.jpeg
m
Test No F: Download different TSO model from NMD
<Figure 2-21> Test No F
- Download RTE model and its corresponding tie model from NMD
(Scenario: Scenario Vision 1 – 2030; Case: C1 WP2030 Vision 1).
- CIMDesk / CIMSpy EE result (CIMDesk_Validation.jpg)
<Figure 2-22> CIMDesk_Validation.jpg
- Load Flow result
<Figure 2-23> LF_RTE_Model_2030_P-Q.jpeg
- Difference in voltage indicated from calculation result
<Figure 2-24> LF_RTE_Model_2030_Voltages.jpeg
m
Test No G: Use assembled model of NMD.
<Figure 2-25> Test No G
- Assemble (merge) Terna TSO model and RTE TSO model in NMD
(Scenario: Scenario Vision 1 – 2030; Case: C1 WP2030 Vision 1).
- After assembling, review CIMDesk / CIMSpy EE
<Figure 2-26> CIMDeskValidation_Test_G.jpg
- Load Flow calculation result
<Figure 2-27> albertville.jpeg
<Figure 2-28> albertville_kV.jpeg
- Level of difference in voltage after calculating load flow
<Figure 2-29> Baggio.jpeg
<Figure 2-30> Baggio_kV.jpeg
m
Test No H: Evaluator's verification of assembled (merged) model
<Figure 2-31> Test No H
- Succeeded in Terna model and RTE model
- Power flow calculation result
<Figure 2-32> albert.jpeg
<Figure 2-33> baggio.jpeg
- Voltage difference from calculation result
albert_kV.jpeg
baggio_kV.jpeg
<Figure 2-34> Comparison of Voltage Difference from Calculation Result
2 Analysis of Stage 2 Test for Interoperability Test
Procedure
m
Test No 1: Enter Load Flow model
Purpose
Process
Outcome
m
Verify load flow model input without defect
Ÿ
Ÿ
Ÿ
Enter a single TSO model (*.xml composed of TP, EQ, SV in *.zip file)
in NM
Calculate load flow with own tool
Evaluator confirms resulting value
Ÿ
Ÿ
Ÿ
Define file name used
Check status value of data used
Attach screenshot of result of tool in outcome
Test No 2: Set off Load Flow Model
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Verify interoperability with load flow output
Output file must maintain input status
Ÿ
Use file set off from Test No 1 as input to set off each of TP, EQ
and SV in either *.xml or *.zip file
Using CIMDesk / CIMSpy EE, verify output file
Verify syntax and data integrity of file entered by evaluator and
output file
Define *.xml and *.zip file name entered
Define *.xml and *.zip output file name
Attach screenshot indicating the value of *.zip file entered from tool
in outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Test No 3: Comparison & Verification of Load Flow Result
Ÿ
Using comparison tool A (Vendor A Tool) and comparison tool B
(Vendor B Tool), compare the load flow result to verify interoperability
of target tool
Under 5% tolerance
Ÿ
Ÿ
Ÿ
Enter each of the files used in Test No.1 into tools A and B
Calculate load flow for tools A and B each
Evaluator compares results of A and B
Ÿ
Ÿ
Ÿ
Define entered file name in *.xml and *.zip
Evaluator checks calculation option and configuration value
Attach at least one calculation result for each of tools A and B in
outcome as screenshot
Ÿ
Purpose
Process
Outcome
m
Test No 4: Change and Calculate Topology, and Verify Output
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
m
Test No 5: Change and Calculate State Variables (SV) Voltage and
Verify Output
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
m
Verify that the topology (TP) of entered model can be changed
Output TP is assembled with a different model. This is to verify that it
can be used in a different tool.
Change TP of TSO model used in Test No. 1
Define topology to be changed by supervisor
Calculate load flow using changed data
Set off calculated State Variable (SV) file and TP file
Define entered *.xml and *.zip file name
Define changed and set off *.xml and *.zip file name
Define changed topology
Attach the screenshot of load flow result of changed value to
outcome
Attach the screenshot of CIMDesk / CIMSpy EE verification result of
changed model to outcome
Verify by changing the power operation, operation value of entered
model (generation amount, load amount, voltage level, etc.)
Change voltage information in file entered in Test No. 1
Define the voltage information changed by supervisor
Calculate load flow of changed value
Output State Variables (SV) file of calculated value
Verify output SV file using CIMDesk / CIMSpy EE
Define entered file name in *.xml and *.zip
Define changed and output file name in *.xml and *.zip
Define changed state variable
Attach the screenshot of load flow result of changed value to
outcome
Attach the screenshot of CIMDesk / CIMSpy EE verification result of
changed model to outcome
Test No 6: Enter Changed Topology (TP), and State Variables (SV) File
to Verify Load Flow
Purpose
Ÿ
Verify the assembly of TP and SV models and calculation result of
load flow
Ÿ
Ÿ
Enter Equipment (EQ) file used in Test No. 1
From Tool A (Vendor A Tool) and Tool B (Vendor B Tool), enter TP
and SV set off from Test No. 4 and 5.
Calculate load flow from each tool
Supervisor compares load flow calculation
Process
Ÿ
Ÿ
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Define entered EQ file names in *.xml and *.zip
Define entered TP and SV file names in *.xml and *.zip
Define entered tie value file names provided by NMD in *.xml and *.zip
Attach load flow result calculated from each tool to outcome as
screenshot
m
Test No 7: Enter State Variables (SV) file only to verify load flow
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Test No 8: Verification and comparison of calculation for fault calculation
(short-circuit) of tools
Ÿ
Purpose
Process
Outcome
m
Enter SV value changed from test No. 5 only to verify load flow
Enter EQ and TP of model used in Test No 1 of Tool A (Vendor A
Tool) and Tool B (Vendor B Tool).
Enter and combine the SV models changed in Test No. 5.
Calculate each load flow.
Define file name of entered EQ and TP in *.xml and *.zip.
Define file name of entered tie value provided by NMD in *.xml and
*.zip.
Define entered file name in *.xml and *.zip.
Attach screenshot of load flow result calculated by each tool to
outcome.
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Compare the fault calculation (short-circuit) results from comparison
tool A (Vendor A Tool) and comparison tool B (Vendor B Tool) to
verify interoperability of target tool.
Calculation result must satisfy the defined tolerance.
Enter model file needed by NMD (EQ, TP, SV).
Execute three-phase fault calculation from IEC 60909 and
unbalanced fault calculation.
Supervisor compares and verifies the calculation results.
Define entered file name in *.xml and *.zip.
Define entered tie value provided by NMD in *.xml and *.zip.
Attach the screenshot of fault calculation result calculated from each
tool to outcome.
Test No 9: Combine models of different regions and verify output
Purpose
Ÿ
Ÿ
Process
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Outcome
Ÿ
Ÿ
Combine models of different regions and verify that they can be
calculated and set off.
Classify a single system into Area 1 and Area 2, and prepare from
NMD. (Compose each by EQ, TP and SV.)
Sequentially enter files for Areas 1 and 2.
Calculate the load flow of system data entered and combined.
For Areas 1 and 2, set off EQ and TP for each and SV as a single
file.
Verify output files by CIMDesk / CIMSpy EE.
Enter output SV file again to calculate load flow.
Define file names of entered two regions in *.xml and *.zip.
Define file names for two EQ files, 2 TP files and 1 SV file set off
in *.xml.
Attach the screenshot of load flow calculation result entered and
combined in outcome.
Attach the screenshot of load flow calculation result as reentered SV
file in outcome.
m
Test No 10: Combine models of different regions and compare and verify
the output using different tools
Purpose
Process
Outcome
m
Process
Outcome
Change and set off Equipment information and verify load flow.
From test No. 5, change SV to EQ and execute the same process.
From test No. 5, change SV to EQ.
Ÿ
Ÿ
Ÿ
Enter EQ file changed from Test No. 11 in tools A and B to
compare and verify load flow.
From Test No. 6, change TP and SV into EQ and execute the same
process.
From outcome of Test No. 6, change TP and SV into EQ.
Test No 13: Combine changed EQ files to verify load flow
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Test No 12: Enter EQ file in different tools and then compare and verify
Purpose
m
Same as Test No 9. Compare and verify using tools A and B.
Same as process in test No 9 for tools A and B.
Supervisor compares the load flow calculation results.
Same as test No. 9 for tools A and B.
Test No 11: Change, calculate and verify output of Equipment (EQ) model
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Combine changed EQ file to verify load flow.
From Test No. 7, substitute with EQ file changed from SV and
conduct the same process.
From outcome of Test No. 7, change SV into EQ.
Test No 14: Compare and verify using different tools for changed EQ file
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Combine EQ files changed from areas 1 and 2 to verify load flow.
Use EQ file changed from Test No. 11.
For each of Tools A and B, apply the process in Test No. 12.
Supervisor compares and verifies load flow results for Tools A and
B.
For Tools A and B, apply the same outcome of Test No. 12.
m
Test No 15: Enter and verify the dynamic moel with standard model
only applied
Purpose
Process
Outcome
m
Ÿ
Ÿ
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Verify interoperability using DY file output.
Set off DY file entered from Test No. 15.
Supervisor reviews the output value.
Define file name of entered EQ, TP, SV and DY in *.xml and *.zip.
Define file name of output EQ, TP, SV and DY in *.xml and *.zip.
Attach screenshot of entered value to outcome.
Attach screenshot of output value to outcome.
Attach screenshot of verified result of CIMDesk / CIMSpy EE to
outcome.
Test No 17: Compare and verify the dynamic analysis result using
different tools
Ÿ
Ÿ
Purpose
Ÿ
Process
Outcome
m
Enter dynamic model to verify that transient analysis is possible.
Enter EQ, TP, SV and DY (Dynamic Data Set) prepared from NMD.
Verify that load flow can be calculated.
Execute dynamic study.
Define file names of entered EQ, TP, SV and DY in *.xml and
*.zip.
Attach screenshot of entered data to outcome.
Attach screenshot of calculated result to outcome.
Test No 16: Verify the output of dynamic model with only standard
model applied
Purpose
m
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Compare and verify dynamic calculation result using different tools.
Calculate at least 10 seconds of three-phase fault calculation and
unbalanced fault.
Compare Vref [tolerance within ±5%], Pgen, Pflow, Qgen, Qflow
and V.
For each of Tools A and B, perform process in Test No. 15.
Supervisor compares and verifies each result.
Define file name of entered EQ, TP, SV and DY in *.xml and *.zip.
Attach screenshot of calculation result for each of Tools A and B to
outcome.
Test No 18: Verify user extension DY file entry complying with standard
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
Verify entry of file with user extension information based on standard
model in DY file from Test No. 15.
From Test No. 15, change entered DY to user extension information
and then execute the same process.
Same as Test No. 15
m
Test No 19: Verify user extension DY file output complying with standard
Purpose
Process
Outcome
m
Process
Outcome
Process
Outcome
Ÿ
Ÿ
Ÿ
Verify the tool for DY file with user extension information complying with the
standard using different tools
From Test No. 17, change entered DY to user extension information
and then execute the same process.
Same as Test No. 17
Ÿ
Ÿ
Ÿ
Verify input for file with nonstandard user extension model information
for DY file in Test No. 15.
From Test No. 15, change entered DY to nonstandard user
extension model information and then execute the same process.
Same as Test No. 15
Test No 22: Verification of output of nonstandard user extension DY file
Purpose
Process
Outcome
m
Ÿ
Test No 21: Verify nonstandard user extension DY file input
Purpose
m
Ÿ
Varify output of file with user extension information based on
standard model in DY file from Test No. 16.
From Test No. 16, change entered DY to user extension information
and then execute the same process.
Same as Test No. 16
Test No 20: Compare and verify the dynamic analysis result of user
extension DY file complying with the standard using
different tools
Purpose
m
Ÿ
Ÿ
Ÿ
Ÿ
Verify output for file with nonstandard user extension model
information for DY file in Test No. 16.
From Test No. 16, change entered DY to nonstandard user
extension model information and then execute the same process.
Same as Test No. 16
Test No 23: Compare and verify the dynamic analysis result of
nonstandard user extension DY file using different tools
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
From Test No. 15, verify the input of file with nonstandard user
extension model information in DY file.
Change DY entered in Test No. 15 to nonstandard user extension
model information and then execute the same process.
Same as Test No. 15
m
Test No 24: Verify DY file input extended by unknown model information
Purpose
Process
Outcome
m
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Verify output of file with unknown model information in DY file from Test
No. 16
Change DY entered from Test No. 16 to unknown model information
and then execute the same process.
Same as Test No. 16
Test No 26: Compare and verify the dynamic analysis result of DY file
extended by unknown model information using different
tools
Purpose
Process
Outcome
m
Ÿ
Verify input of file with unknown model information in DY file from Test No.
15.
Change DY entered in Test No. 15 to unknown model information and
then execute the same process.
Same as Test No. 15
Test No 25: Verify DY file input extended by unknown model
information
Purpose
m
Ÿ
Ÿ
Ÿ
Ÿ
Verify input of file with unknown model information in DY file from Test No.
15
Change DY entered from Test No. 15 to unknown model information
and then execute the same process.
Same as Test No. 15
Test No 27: Using 'Operation' model, set off 'Planning' model
Ÿ
Purpose
Ÿ
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Set off and verify the 'planning' model to prove the tool for
managing 'operation' model from operation tool related with
EMS/SCADA
For ENTSO-E profile, create all information required related with 'operation'
and 'planning'.
Set off created information.
Verify output file in CIMDesk / CIMSpy EE.
Supervisor sets off the reviewed result.
Define all input files in *.xml and *.zip.
Define all output files in *.xml and *.zip.
Attach the screenshot for confirming input/output models and data
to outcome.
m
Test No 28: From different tools, enter 'Planning' into 'Operation' model
to compare and verify
Ÿ
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Test No 29: From different tools, enter 'Operation' into 'Planning' model
to compare and verify
Ÿ
Purpose
Process
Outcome
m
Combine the result of 'planning' file set off from EMS/SCADA
operation or related tool with 'operation' model and compare and
verify using different tools
Enter data used from Test No. 27.
Enter 'planning' file set off from Test No. 27 into tools A and B.
Calculate load flow from each of tools A and B.
Supervisor compares and verifies load flow calculation result.
Define input file in *.xml and *.zip.
Attach the screenshot for confirming load flow result calculated from
tools A and B to outcome.
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Combine the result of 'operation' file set off from EMS/SCADA
operation or related tool with 'planning' model to compare and verify
using different tools
Enter data used from Test No. 27.
Enter 'operation' file set off from Test No. 27 into tools A and B.
Calculate load flow for each of tools A and B.
Supervisor compares and verifies the load flow calculation result.
Define input file in *.xml and *.zip.
Attach the screenshot for conforming load flow result calculated
from tools A and B to outcome.
Test No 30: Verify change in ownership authority of facility information
Ÿ
Purpose
Ÿ
Ÿ
Ÿ
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
When combining data from different regions as in Test No.
change ownership (authority) to verify application.
Examples include change or modification of ownership for
information, facility and grid.
Enter basic model to Tool A.
Supervisor defines changed information and sets off change
information.
Output file is verified from CIMDesk / CIMSpy EE.
Enter output file from Tool A into Tool B (or A).
Supervisor confirms changed information.
Define *.xml and *.zip files for basic model information.
Attach the screenshot of CIMDesk / CIMSpy EE verification result
Tool A (B) to outcome.
9,
tie
of
for
m
Test No 31: File header test
Ÿ
Purpose
Process
Outcome
m
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Test No 32: Verify change in diagram data
Purpose
Ÿ
Ÿ
Ÿ
Ÿ
Process
Outcome
m
When changing header information of entered information model, review
supporting function of tool.
One or more header information can be changed from separate tool ot
prepared as a sample in advance.
Enter sample with incorrect header information.
Supervisor confirms the tool user, program supporting process,
message and error of tool with incorrect header entry.
Define input file in *.xml and *.zip.
Describe the changed [error] information record of sample file.
Attach the screenshot for conforming information occurred from tool
to outcome.
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
When changing diagram data, verify interoperability within the tool or from
different tools
Enter all information required from Tool A.
Supervisor confirms entered diagram.
Supervisor changes and defines one or more x, y coordinates of
diagram.
Set off only the changed diagram file.
Enter diagram file from Tool A (or B).
Supervisor confirms changed information.
Define input file in *.xml and *.zip.
Define output diagram file in *.xml and *.zip.
Describe changed information record from diagram.
Attach the screenshot for confirming changed diagram from Tool A
(B) to outcome.
Test No 33: Verify geographical data change
Purpose
Process
Outcome
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
When
changing
geographical
data
(GIS
information),
verify
interoperability within the tool or from different tools.
Enter all information required from Tool A.
Supervisor confirms entered GIS information.
Supervisor changes and defines one or more GIS information.
Set off only the changed GIS file.
Enter GIS file from Tool A (or B).
Supervisor confirms changed information.
Define input file in *.xml and *.zip.
Define output GIS file in *.xml and *.zip.
Describe changed GIS information record.
Attach the screenshot for confirming change GIS information from
Tool A (B) to outcome.
Ch 3
Technological
Considerations for
ENTSO-E
Interoperability Test
Model
Section 1. Framework for Interoperability
Model Exchange
1. Necessity of Interoperability Model Exchange
It is necessary to define the composition of each system model for system
model exchange between TSO or between TSO and DSO, and define how to
compose integrated system model that combines individual system models. This
is to compose an integrated system model that automates the interoperability
model exchange used for calculating system analysis. Separate from this, the
standards for system facility and system state are described in CGMES, IEC
61970-452 and IEC 61970-456 of ENTSO-E.
For system models for system planning or system operation, different
system models depending on purpose of organization were used that were
managed within system operator or from different organizations. In other
words, the bus-brnach model was mainly used from system planning, while
the node-breaker model was mainly used from system operation. CIM
combines two system models so that system planning and system operation
can share the same system model.
On the other hand, TSO or DSO performs overlapping task for composing a
model for system outside the nearby jurisdiction within its own system within
the jurisdiction. A shared system model between TSO/DSO can decrease
overlapping tasks while increasing the accuracy of system model.
2. Use Case
A. Actor
A system operator is responsible for system operation generally for national
unit or regional unit. A system operator in broadband system has responsibility
to part of the entire system in which system operators will share system models
between each other. Large customer or power generation business connected to
the system has to be able to exchange data with system operator.
<Figure 3-1> Data Exchange between Actors
TSO6) and DSO7) can share system model between each
other. TSO8) provides SCI9) the system model in jurisdiction for establishing
broadband system model.
In <Figure 3-1>,
6) TSO (Transmission System Owner)
7) DSO (Distribution System Owner)
8) TSO (Transmission System Owner)
9) SCI (Security Coordinator)
B. System Model Framework
(1) System Jurisdiction and Boundary
<Figure 3-2> is an example showing how the system is divided for 4
TSOs and 2 DSOs.
<Figure 3-2> System Model Case
Grid systems under jurisdictions by system operators TSO A, B, E and F
and DSO C and D are interconnected via connected grids and substations.
Each jurisdictions are indicated by a square in <Figure 3-1>. Each of the
connecting
lines
between
TSO have
one connection
point
each.
indicated by a red dot in <Figure 3-2> and is referred to as an x-node.
This
is
TSO A is connected to the distribution system under jurisdiction of DSO D
via a substation, and TSO B is connected to the distribution system under
jurisdiction of DSO C via another substation. DSO C and DSO D have
distributed power sources from wind power and solar power. Here, as in TSO,
the connecting point is indicated in <Figure 3-3> by an x-node.
From CIM, the connecting point is equivalent to the Connectivity Node.
The connecting points from CIM are stipulated in details in <Figure 3-3>.
<Figure 3-3> Detailed Data Diagram for Connecting Point between TSO A and
TSO B
While the cim:ConnectivityNode of connecting line is included in cim:Lines,
the cim:ConnectivityNode of substation is included in cim:Substation. cim:Lines
and cim:Substation are placed on the boundary. Connecting line
cim:ACLineSegments is included in cim:Line on the boundary, but pay
attention that it is defined within the TSO system jurisdiction and that the
jurisdiction of TSO A and TSO B refers to the boundary. Hence, the
affiliation is vague until it combines with the boundary. The two use cases
dealing with this situation are as follows.
- Boundary is implemented. (Included in system model in jurisdiction)
- Boundary is not implemented. (Importing target)
When the boundary is implemented, the TSO implements the system model
in jurisdiction and define the boundary. It defines each of the boundaries
and defines the matching boundary model in consultation with nearby TSO
and DSO. Afterward, in case a model for external system outside the
boundary is needed, it can import from nearby TSO and DSO. In this case,
the boundary model is not imported.
In case boundary is not implemented, the boundary model is also imported.
(2) System Edge
In ENTSO-E congestion forecast processes (IDCF, DACF, D2CF, etc.), the
planned value for power flow at the boundary point at the TSO performing
congestion forecast is used. This means that the power flow at the boundary
point needs to be maintained at planned value, and system edge is expressed
as an inflow of power at a specific boundary point. <Figure 3-4> shows the
system model in which TSO A performs congestion forecast. Dividing the
external system from the boundary can give more flexibility in integrating and
evaluating system models of different forms.
<Figure 3-4> Example of TSO A Substituting TSO B and TSO E by System Edge
(3) System Equivalent Model
The entire system model is composed by integrating the system models for
region, boundary and outside systems. These system models have more data
needed by SO, SCI and ENTSO-E, hence some system models needs to be
removed. When the systems are removed, they substitute by inducing
equivalent systems in the following method.
- System edge expressing as uniform power flow at boundary point
- System equivalent model by empirical method
- System equivalent model generated by system reduction program
System edge is valid in distribution systems or radial systems such as the
first congestion forecast stage where power flow is uniformly maintained at
the boundary. However, in network systems surrounded by nearby regional
systems, a simple system edge is inappropriate, and the system operator can
define the nearby systems in the following process.
- Confirm the boundary point for applying system equivalent model
- Determine how to generate system equivalent model (empirical method or
system reduction program)
- Change power facility outside the boundary to system equivalent model
Due to seasonal factors, a number of system equivalent models may be
needed at the connection point. <Figure 3-2> shows that TSO B and entire
system model for DSO D are needed in planning and operation of TSO A
system. TSO A may require the system model for wind power complex or
solar power complex under jurisdiction of DSO C, and this can be done by
modelling that power generator and load are connected to the connecting point.
In <Figure 3-5>, TSO A and TSO B are connected to 4 connecting lines
via connection points AE and CF to TSO E and TSO F. The reduced system
equivalent model for expressing TSO E and F in system equivalent model for
TSO A is shown in <Figure 3-2>.
<Figure 3-5> Example of TSO A Substituting TSO B and TSO E with System Edge
<Figure
system
3-5>
shows
equivalent
how
facilities
all
system
(yellow)
facilities
including
can
be
connection
substituted
point
EF.
by
By
substituting some facilities with equivalent systems and using actual facilities
for some facilities, the final equivalent model can be expressed as <Figure
3-5>.
In <Figure 3-6>, the TSO E and F expressed from reduced equivalent
system model of TSO A are connected, and DSO C expressed from equivalent
system model is connected.
<Figure 3-6> System Model of TSO A
In <Figure 3-6>, the equivalent system facility is shown in yellow. Here,
the substations of DSO C have been replaced by equivalent loads and
equivalent generators. Although the connecting lines between TSO A and
TSO E, and between TSO B and TSO F are maintained, the remaining
system
network
facilities
systems,
have
been
equivalent
replaced
system
by
equivalent
facilities
can
system
connect
facilities.
to
In
multiple
connecting points, and these connecting points can be reduced within the
equivalent system facility.
In examples in <Figure 3-5> and <Figure 3-6>, the connection point
between TSO E and TSO F is maintained. Likewise, it is recommended to
maintain connection point.
(4) FRM (Framework for Model Exchange)
The data model for expressing system model is referred to as FRM which
conveys the following concepts.
- Actor technology of system model (in CIM, ModelAuthority)
- Connection point technology of system model (framework connection
point technology)
- System model partial technology specified in actor and one or more
CIM profiles (framework connection point specifications)
- System model data technology to be exchanged
On the other hand, the system model connection point technology conveys
the following information.
- Relevant ModelAuthority
- System technology of jurisdiction (systems do not overlap)
TSO or DSO can have independent specific framework connection points.
Hence, there can be multiple system model connection point technologies,
requiring the system model connection point specifications. System model
connection point technology does not consider the progress in time. However, as
the system composition varies in time, the system model will change. Partial
system model is referred to as "model part". The data composing model part is
as follows.
- Data group expressing actual system elements (e.g. EQ, SSH, DL, etc.)
- Valid data point
- Data group version
C. System Model
System models are used in the application program for system interpretation
equivalent to power flow calculation. These system models are composed of
system elements defined in system framework and the system boundary needs
to be defined in advance. There are two situations for confirming system
boundary.
- System boundary for defining jurisdiction in existing system model is
defined.
- System boundary is not defined and needs to be imported.
In case system boundary has already been defined in the system model,
irrelevant of the inclusiveness of system boundary, the entire system model is
generated by combining the system models outside the jurisdiction. When
importing the system boundary, the system boundary as well as the system
model is combined.
The following description informs what system elements are included in the
entire system model integration process. The entire system model is composed
by combining all system elements collected according to the integration process.
It is recorded in the integration list what system elements are combined in
what system models. From the recorded system model information, the following
information can be confirmed.
- Combined system model element
- Time of generating integrated system model and personnel conducting
generation task
Depending on the reflection of system element classification of each system
model at the time of integration, the system elements of integrated system
model can be classified into each system model.
(1) Exchanging System Model
(A) Overview
- System model exchange stage (2 stages)
Exchange data describing the system model elements to be
exchanged
Exchange system model data for profiles such as EQ, SSH, DL,
and DY
- This technological document describes "Exchange of data describing
system model elements to be exchanged" in the stage 1.
- "Exchange of data describing system model elements to be exchanged"
is conducted in the following order.
ModelAuthorities : Official documents issued by central organs such
as ENTSO-E
Framework (system model element and boundary) : Official document
issued by ModelAuthorities or ENTSO-E
System element statement : Issued by each of ModelAuthorities
of jurisdiction of system elements
- From this, all actors can exchange information between each other,
and perform "exchange of system model data for profiles such as
EQ, SSH, DL and DY" in the stage 2.
(B) Exchange of System Operation Model
- Exchange of system operation model is conducted between system
operators, and used in SCADA/EMS. In power system of <Figure
3-4>, each TSO uses partial system model from TSO, DSO or
large system user to expand the system model to be used in the
corresponding TSO. The system measurement of area of interest in
the nearby system needs to be able to predict the state. Regions
outside the area of interest are normally processed by equivalent
system model.
- In <Figure 3-4>, for TSO A, TSO A provides EQ model from
nearby TSO B, TSO E, TSO F, DSO D and DSO C. Using this,
TSO A substitutes part of system elements by equivalent system
model and then composes the entire integrated system model.
<Figure 3-5> and <Figure 3-6> show the final form of integrated
system mode.
(C) Exchange of Day Ahead Congestion Forecast (DACF)
- Based on the system in <Figure 3-2>, TSO performs DACF and
through the integration of regional system model on the result, the
system safety coordinator re-performs integrated DACF on the
overall integrated system model.
- TSO A operates the real time operation system capable of forecasting
the status for generating SSH and SV data sets for system model in
<Figure 3-6> and calculates the power flow.
- DACF is conducted on a system model smaller than the real time
system model. DACF includes the system models under jurisdiction
of TSO. (On the boundary, power flow is fixed as planned value.)
<Figure 3-7> DACF System Model of TSO A
- The shaded area in <Figure 3-7> shows the power flow fixed as
planned value of system boundary.
- TSO A has the following options for DSO D system:
Reduce system elements less influencing TSO A (maintain major
loads and generation facilities)
Substitute major loads and major generation facilities with system
parallel elements
Maintain DSO D system boundary
After removing DSO D system boundary, integrate DSO D with equivalent
system model
- In <Figure 3-7>, the system boundary of TSO A and DSO D is
maintained while major loads and major generation facilities are
replaced from system boundary to system parallel elements. Not
removing system boundary is the most flexible solution to the situation.
By changing to equivalent system according to change in DSO system
status, the TSO A system model itself can remain uninfluenced.
- TSO A delivers the following system model elements to the system
safety coordinator. (Assume separate exchange of system boundary and
system edge EQ model elements.)
TSO A EQ model
Outage schedule for TSO A system model element
SSH data set for TSO A system model element
TSO A version of DSO D EQ model
SSH data set for DSO D system model element
SSH data set of system edge between TSO B and TSO E
- From each TSO, the system safety coordinator is provided with the EQ
model and SSH data set generated by each. The system safety
coordinator combines the system elements to compose the overall
integrated system model. <Figure 3-8> shows the overall integrated
system model.
<Figure 3-8> Overall Integrated System Model (System
Safety Coordinator)
- The system safety coordinator conducts the following:
Combine TSO system model elements
Check for noncompliance of boundary data state through comparative
analysis of power flow in boundary SSH data set of system edge
Confirm boundary power flow value for each TSO SSH data set
Section 2. Power System Project
1. Necessity of Power System Project
In this section, the test composition, test procedure, information model and
profile necessary for interoperability test when changing system facility (PSR)
are stipulated. The change in system model is reflected to change in CIM, and
the additional meta data necessary for stipulating this change is as follows.
m
m
m
Essential meta data information
- Changed time and date of system model
- Change application stages (planning, building and cancellation)
- Energization date of new facility (standard maintenance procedure for
renewed facility and removed facility)
- Energization date of new facility (standard maintenance procedure for
renewed facility and removed facility)
Recommended meta data information
- Application time and date of change
- Cancellation time and date of change
- Mutually excluded change
- Priority to substitute change
Selective meta data information
- Classification of change (prompt determination of influence from
change)
- Changing entity (primary responsible organization for model change)
2. Use Case
The use cases on change in meta data are relevant with all use cases
including system model change.
m
Entity generating changed information
- Information generated by system interpretation team (establish system
control plan, system protection plan)
- Information generated from establishment project (new and
maintenance)
- Information generated by external organization
In general, there are two or more systems handling change information in
an organization, for example, system development plan establishing tool and
EMS/DMS related system operation system. Changes in system model are
uniformly applied to these systems. CIM standard applies the change only once
to assist usage in both system planning and system operation. Data group and
selected information need to be able to exchange information between systems.
m
m
Related information
- Establish system plan
- Establish protection plan
- Market design and market planning
- Set up assets
- TSO/DSO(DNO), TSO/TSO, DSO(DNO)/DSO(DNO)
- Government, country/Europe (ENTSO-E)
- Challenging solution to research project (solutions with least influence
to information exchange)
System applying exchange of established model
- Outage management system/outage planning system (OMS/OSS)
- Market management system (MMS)
- Operation plan and operating system (EMS/DMS)
- System settlement
- Archive, measurement history
3. Interoperability Test Case
Interoperability test for power system project (PSP) is conducted to verify
the performance of managing tool.
m
m
Interoperability test items for power system project (PSP)
- Add changed items in PSP
- Change property of PSP (changed time and date, etc.)
- Change PSP state
- Separate PSP
- Create PSP
Major use cases related with PSP
- MAS connected project
- Select project schedule
- Project life cycle
A. MAS Connected Project
When establishing a new line between substations under two MAS, the
information on connection point as a test for model exchange is generated
separately and then combined afterward. As shown in <Figure 3-9>, it is
indicated as separate connections from virtual generator on the connection
point.
<Figure 3-9> New Line Modeling Connected to MAS
Actor
- System SA user UA (MAS1 update)
- System SB user UB (MAS2 update)
- System SC user UC (Combine changes in MAS1 and MAS2, Derive
changes related with each MAS)
m Changing sequence
- System SA user UA : Create connection point in system SC (Request)
- System SA user UA : Create ACLineSegment in connection point
- System SA user UA : Deliver change to system SC
- System SB user UB : Download connection point information from system SC
- System SB user UB : Create ACLineSegment in connection point
- System SB user UB : Deliver change to system SC
- System SC user UC : Combine collected changes
- System SC user UC : Provide reviewed result for power flow calculation
(Reflect to both MAS1 and MAS2, Reflect collected changes)
- System SC user UC : Separately reflect collected changes (a. Connect
generator G to MAS1 substation A, b. Connect generator G to MAS2
substation B, Derive reviewed result for each case.)
- System SC user UC : Deliver change to system SA and system SB
- System SA user UA & system SB user UB: Each reflects changes and
reviews power flow calculation
- System SA user UA & system SB user UB: Each submits power flow
calculation result to system SC
m
<Figure 3-10> System SA User UA Sequence Diagram (Create New Connected Line in
Figure 3.2-1)
<Figure 3-11> System SB User UB Sequence Diagram
(Create new connected line in Figure 3-9)
<Figure 3-12> System SC User UC Sequence Diagram
(Create new connected line in Figure 3-9)
<Figure 3-13> System SA User UA Sequence Diagram (Renew Information)
B. Select Project Schedule
When connecting a large generator G to system, it is known that
creating the system model by creating and connecting a virtual substation D
is
useful
in
system
interpretation.
However,
in
the
example
in
<Figure
3-14>, it was not determined whether to implement the connection of large
generator
via
substation
A
virtual
and
substation
substation
B)
D
from
project
P1
process
(connecting
or
from
project
P2
process
(connecting
substation A and substation C).
The project P1 process includes creation of ACLineSegmentAD, substation
D, generator G (connected to substation D) and ACLineSegmentDB while
project P2 process includes creation of ACLineSegmentAD, substation D,
generator G (connected to substation D) and ACLineSegmentDC.
Projects P1 and P2 are mutually excluded and both of the two include
creation of ACLineSegmentAD, substation D and generator G (connected to
substation D). However, project P1 creates ACLineSegmentAD prior to
energizing the generator while project P2 creates ACLineSegmentAD after
energizing the generator.
<Figure 3-14> Connection of Large Generator Via Virtual Substation D
m
Changing sequence
- System SA user UA : Import P1 and P2
- System SA user UA : Create/calculate test case including P1, export
calculation result
- System SA user UA : Create/calculate two test cases including P2,
export calculation result (1 test case does not include
ACLineSegmentAD)
- System SA user UA : Change 1 parameter of ACLineSegmentAD
(must be reflected to P1 and P2)
- System SA user UA : Create and calculate test case C1 with P1 and
test case C2 with P2
- System SA user UA : Export changes and result for test cases C1 and C2
- System SB user UB : Import P1 and P2
- System SB user UB : Import changes by system SA user UA,
calculate test cases C1 and C2
<Figure 3-15> System SA User UA Sequence Diagram (P1 in Figure 3-14)
<Figure 3-16> System SB User UB Sequence Diagram (P2 in Figure 3-14)
C. Project Life Cycle
Project life cycle manages the changes from interpretation stage to test
operation. Life cycle management begins from dividing the target project
into sub-projects with particulars of changes. The project updates between
users of different systems continue to change.
<Figure 3-17> System SA User UA Sequence Diagram (Project Life Cycle)
<Figure 3-18> System SB User UB Sequence Diagram (Project Life Cycle)
(1) Stage 1 – Early Interpretation Stage
Stage 1 deals with low standard refinement and handles multiple substitute
projects. Information exchange of substitute project is handled from another test
use case. Projects on addition of lines between substations or addition of
transformer in a substation are created. In the example in <Figure 3.2-11>, a
project is created from the changed data set by adding 150km 2-line
transmission line ACLineSegment between substations Sub A and Sub E and
adding 300MVA transformer at substation Sub E.
<Figure 3-19> Addition of New Line between Substations (ACLineSegment)
m
Stage 1 system interpretation and system operation
- Calculate power flow (Reflect addition of new line)
- Calculate fault current (balanced three phase)
- Single line diagram (Reflect addition of new line)
- Relevant simple geographic information
- Normal component system model (including dynamic model)
(2) Stage 2 – Primary Interpretation Stage
When substitute project exists although restrictively, it mainly seeks
optimal substitute project among multiple substitute project in stage 1. The
result from this stage can be used for REP (Request for Proposal) for the
project or system facility. The information exchange of substitute project will be
dealt with in another test use case. The example in <Figure 3-20> shows that
an existing substation Sub D' moves to become a substation Sub D. Here,
although the process of transition does not have to be defined in details, the
stage for temporarily required composition needs to be defined.
<Figure 3-20> Addition of New Line between Substations (ACLineSegment) Reflect
Test Model
m
Stage 2 System Interpretation and System Operation
- Calculate power flow (Reflect addition of new line)
- Calculate fault current (balanced three phase)
- Calculate fault current of phase 1 ground fault (phase 1 fault)
- Single line diagram (Reflect addition of new line)
- Relevant temporary geographical information
- Normal component/image component system model (including dynamic
model)
(3) Stage 3 – Permission Stage
Stage 3 consists of only one substitute project in general. Information for
interpreting the details of each system operation status is needed. Here, the
standard configurations are changed to the manufacturer specifications of the
actual system facility. In the example in <Figure 3-21>, after connecting
substations Sub A and Sub B, the transmission line between substations Sub B
and Sub C is removed. After substation Sub D' moves to Sub D, the task is
completed by removing the transmission line between substations Sub C and
Sub D, and then connecting each of the transmission lines designed to connect
substations Sub B and Sub E to substation D. Figure 3.2-14 shows the
sequence of this task.
<Figure 3-21> Reflect Model During Extention of Line
a
b
c
d
e
f
<Figure 3-22> Sequence of Reflecting System Model for Extension of Line
m
Stage 2 system interpretation and system operation
- Calculate power flow (Reflect addition of new line)
- Calculate fault current (balanced three phase)
- Protection plan and fault interpretation (for all fault types)
- Single line diagram (Reflect addition of new line)
- Relevant geographic information
- Normal component/image component system model (including dynamic
model)
(4) Stage 4 – Set Up Stage
The project is updated by detailed updates of individual subsidiary
project. The manufacturer technical specifications are replaced by actual
measurements. Part of the project is used in basic model. For application in
EMS model, the circuit breaker, measurements and control information are
additionally provided. Additional information on circuit breaker becomes part of
the test case. The subsidiary project including the base case or the entire
project is used for predicting the state of EMS. In this stage, outage plan,
switching plan and EMS based interpretation are not included.
(5) Stage 5 – Operation Stage
The change is reflected to the basic model. Added system facility is
controlled and operated under outage plan. The change on basic model is
processed as a new change set rather than update on basic change set. In this
stage EMS based interpretation such as outage plan and fault interpretation is
not included.
D. Study Change in PSR (Power System Resource)
Study on system development plan is performed on predefined system
model. Multiple system models will be created by reflecting the system state
with high probability of occurrence based on study data on change of PSR.
Section 3. Processing Change in Power System
1. Necessity of Processing Change in Power System
Each TSO is responsible to provide the relevant detailed system model. In
general, the power system composition changes due to the following change
factors.
m
Change factors of power system
- Change in system facility : Few times/year, new investment and
composition change
Related department : Asset management team, system planning team
Can change from modeling change (e.g. change from linear system
facility model to nonlinear model)
- Planned outage : Over 10 times/week, operation plan
Change in power system : 1 week operation scenario (Reflect planned
outage)
- Fault blackout : Hundreds/times
Change in power system : (n-1) System structure for interpreting
credible accident
- Change from operation : Over 10 times/day
Change in power system : Switch manipulation, change in
transformer tab, change in generation amount/power load, etc.
Change in system from change in system facility and outage schedule
has to be submitted by reflecting to the detailed system model of TSO prior
to actual incident. This is reflected to changed project form by change in
facility asset or part of outage schedule related time scenario.
The change from operation needs to be submitted by reflecting to the
detailed system model of TSO if cooperation of DSO or DNO is needed.
However, if this change is solely due to the current system state value
monitored by TSO operator, it cannot be specifically reflected in advance, and
it is difficult to forecast how long it will last.
The change in system from fault blackout is unknown prior to the
incident, hence these changes need to be reflected as occurring during the day.
Fault blackout composing the TSO accident scenario resumes electricity supply
at predetermined time after removal of the accident, hence fault blackout has
to perform planned recovery.
2. Creating Scenario and Processing Change Factor
of Power System
A. Creating Scenario
m
Determinations for creating scenario
- All related system facilities (at the time of creating scenario)
- Combine system model based on system model exchange framework
(Reflect change factors of power system on related field)
- Select outage schedule
- Select change in system state for study (switch state, transformer tab
location, power load, power amount, facility rating, dependent failure
prevention device, recovery process, scheduled connection power)
<Figure 3-23> Create Scenario by System State Change Data
The terms indicated in <Figure 3-23> are as follows.
- Variations : Hourly system data
- Power System Project : Changes in system facility and parameter
- Outages : System facility outage schedule
- Operational Data : System facility outage schedule
Forecasts : Climate related data
; Electricity consumption and distributed power source power amount
; Marginal value (e.g. marginal current of transmission and distribution line)
Schedules : Schedule
; Power amount and connected power (Normally determined from
power market)
; Transformer tab location and voltage (Normally established from
operation plan)
Patterns : Daily/seasonal operating pattern based on actual values
; Electricity consumption and distributed power source power amount
( Conforming vs. Non-conforming )
; Power amount
; Connected power
; Transformer tab location
; Voltage
TSO collects the system state data over one year to create scenario
reflecting the actual circumstances. The scenario created in this manner
reflects the peak load by four season and the system condition when the load
increased by certain amount.
B. Change Factor of Power System
(1) Change in Power Facility
(A) Addition, Deletion and Modification of Power Facility
- From project stage, the structure and state of TSO power system
are changed. Depending on the size and scope of project, there
may be a project with a single starting/ending date or multi-step
project with starting/ending dates by stage. The detailed changes
on system change are reflected to the file of changes in individual
system model.
- After reviewing the file of changes, compose a model that can be
recovered before the application of file of changes so that a new
individual system model with change is submitted.
- By reflecting the time varying data such as rated thermal
capacity, substation feeder alignment and system model application
time, activate after the system model application time.
<Figure 3-24> Basic Structure of System Model and Updating Process
(B) Change in Scenario
- Time varying data used for creating scenario influencing the
power flow calculation result
: Time and date, time of calculation
: Switch state
: Transformer tab location
: Thermal capacity of transformer and line
: Power amount and available capacity
: Load capacity
(2) Outage Schedule
- Test operation and de-commissioning
- Maintenance
(3) Fault Blackout
System change from fault blackout needs to be reflected to system model
submitted by TSO for actual system topology. The longer the fault lasts, fault
blackout can have the property of outage schedule based on blackout recovery
schedule of TSO.
(4) Change from Operation
Some TSOs use change in system topology for the purpose of managing
system voltage during insufficiency in power or light load. Instances of change
in system topology for voltage management opens the switch of cable line to
block transmission of reactive power in the cable line. Although this kind of
blackout is not performed as planned blackout, but can occur at specific hours
depending on system conditions. In scheduling of cable line connected via
transformer requiring cooperation of DSO/DNO, this type of blackout time can
change depending on system requirements on specific date.
C. Power Facility and Topology from Study Process
When using the node-breaker model of CIM, node-breaker model has to
have relevant information so that the bus-branch model created from topology
processing can always have the same bus name.
m
System Facility Profile
- Facility file represents a fixed physical model, and will not change even
in study environments for diverse system conditions. (When conducting
study on diverse system conditions as base case, the facility file is
read only once.)
m
m
m
Outage Schedule
- After conducting study on outage schedule for certiain period of time,
request for approval of outage schedule. Then, close to the approved
time, the multi-step switching plan on sequential switching method is
created. (Power device exceeding the requested outage schedule may be
separated from system.)
: For outage scheduling for maintenance of circuit breaker, the
system has to be separated by opening the switch near the circuit
breaker rather than opening the circuit breaker itself.
- It is important to know the system state at the target study time in
order to reflect the facility state from outage schedule from system
interpretation of study.
Test Operation
- When connecting a new power facility, review the scenario with outage
schedule. After reviewing the influence on change in system structure,
appropriately change the bus bar arrangement in substation under
operation.
- Include all new power facilities in base case from the early stage and
use the same facility model. (Prior to test operation stage, set up the
particular facility in non-energized state.)
: TOS is reflected to the facility model in advance a few days or a
few weeks before installation of new power facility. (In this case,
control the related switch to set the power facility in non-energized
state.)
Credible Accident
- Credible accident : Outage facility, failure point, circuit breaker
operation (fault clearing)
- For interpreting credible accident, use bus-branch model. It is recent
tendency to consider special protection system in interpretation of
credible accident which requires node-breaker model.
m
Expressing Bus-Branch Model in CIM
- x node expressing connection point is defined as ConnectivityNode of
EQ instance.
- Expressing single point opening of line and single point line voltage
from Bus-Branch model
: Open state (Indicated by line terminal property)
: Maintain Terminal-ConnectivityNode relationship (No change in
equipment from opening single point)
: Indicate new temporary bus from Terminal-TopologyNode relationship
by processing topology (Can indicate single point voltage)
: Indicate actual bus from ConnectivityNode-TopologyNode relationship
by processing topology (Can indicate bus allocated to single point
open line)
3. Create Data Case
m
Description of Symbols
- Variable Name : Indicate profile type as subscript
VariableNameEQ : CIM data profile instance (e.g. EQ, SSH, TP, SV, etc.)
△VariableNameEQ : CIM project, incremental model
- Function Name : Bold
U : Function factor (CIM data), Result (CIM data)
Inc : Function factor (1st: CIM project, 2nd: CIM data), Result (CIM
data)
Topology : Function factor (EQ, SSH data), Result (TP data)
PowerFlow : Function factor (EQ, SSH, TP data), Result (TP data)
Diff : Function factor (CIM data), Result (Changed data)
- { } : Used in variable names referring to similar variable name
A. Base Case
The basic data group for study is called base case. Base case means a
data group for specific time of the day. Previously generated base case can be
used if there is no change in TSO system state. The base cases to be created
by TSO consist of EQ, SSH, TP and SV.
The data exchange format should be written so that the TSO system and
connection point are maintained when the base case created by using MAS
framework is used. The following describes the relevant payload of base case.
(1) EQ
- EQ within base case
: Connecting point instance (X-ConnectivityNode)
: Edge model (Configure so that connected power flow is transmitted
to the connected line by connecting the virtual generator and virtual
load to X-node when two TSO including virtual generator
connected to X-ConnectivityNode via Terminal are connected.)
: New instance (including facility connected to connection point and
new facility)
- When TSO EQ model is updated by new construction, EQ model is
updated by outage schedule indicated by CIM project. The outage
schedule is saved in central outage facility database.
- All changes before time T have to be applied in sequence.
: TSOEQT = Inc(△TSOEQn, ... ( Inc(△TSOEQ2, Inc(△TSOEQ1 , △TSOEQnow)))
- In case TSO uses both bus-branch model and node-breaker model,
the EQ model will reflect all changes from new construction, but the
outage or switch schedule will not be influenced.
(2) SSH
- SSH data setting and system state indication
SSH connecting instance not necessary
1 SSH instance is needed for edge model including equivalent
virtual generator. (Edge model does not have data influencing
system facility state.)
SSH instance and TSO EQ model have 1:1 relationship. The
system facility state at specific time T needs to be reflected.
: State data (Switch opening/closing state, Both ends of line
energized/non-energized data, Facility connection data)
: Standard state data (Based on current state or standard scenario)
: Outage schedule reflected data (Outage data based system facility
separation flag, circuit breaker operation data)
: Recovery data (System change from execution result of outage
schedule or new construction)
: Status data of both ends of connecting line on X-node (cannot
open both ends)
- Outage schedule is ssaved in outage schedule database for common
system model as CIM SSH project.
- TSO SSH result includes energy input and voltage adjustment
executed by TSO.
: TSOSSHT = Inc(△TSOSSHn, ... (Inc(△TSOSSH2, Inc(△TSOSSH1,
△TSOSSHnow)))
(3) TP & SV
- TSO calculates the power flow to inspect the system status. When
calculating power flow, TP result (topology data) is created and then
SV result (system status data) is created.
: From topology processing, 1 TP instance is creased per interpretation
case (including TopologyNode including X-node, Define relationships
of Terminal-TopologyNode and ConnectivityNode-TopologyNode)
: Create 1 SV instant per interpretation case
(4) Base Case Data Exchange
- Payload (Assume connection and edge between two, k=1,2)
Connection Data : BoundaryEQk
Edge Data : BoundaryEQk
TSOEQT = Inc(△TSOEQn, ... ( Inc(△TSOEQ2, Inc(△TSOEQ1 , △
TSOEQnow))), Here, △TSOEQi is new established schedule at time i
TSOSSHT = Inc(△TSOSSHn, ... ( Inc(△TSOSSH2, Inc(△TSOSSH1 ,
△TSOSSHnow))), Here, △TSOSSHi is scheduled outage or recovery at time i
TSOTPT = Topology( U ( {BoundaryEQk}, TSOTPT), U (
TSOSSHT, {EdgeSSH} ))
TSOSVT = PowerFlow( U ( {BoundaryEQk}, {EdgeSSHk}, TSOEQT ),
U ( TSOSSHT, {EdgeSSH}, TSOTPT )
- Data exchanging profile instance tracks and manages the payload
expressed as a function. (For example, TSOSSHT instance does not
create one unique SSH instance.) In other words, it reviews the
given exchange data considering initial status of SSH and outage
schedule data.
B. Hourly and Seasonal Case
This refers to case for a series of time such as time or season. Hourly
case can only transmit changed part.
(1) EQ
- No change (e.g. No change for day ahead congestion forecasting)
(2) SSH
- Create new overall data every hour (Reflect energy injection change)
- Outage and recovery data may be reflected (Similar to base case)
(3) TP & SV
- Create new overall data every hour
(4) Data Exchange
- Exchange data every hour (Except EQ data)
C. Hourly and Seasonal Case Combination
Create a case for overall common system model by combining hourly and
seasonal cases submitted by TSO. The combination process is similar to that
of hourly and seasonal case creation.
(1) EQ
- Remaining EQ except EdgeEQ is reflected as is.
CASEEQT = U ( {TSOEQT}, {BoundaryEQT} )
Here,
{TSOEQT} : TSOEQ instance
{BoundaryEQT} : Connection point instance between two
(2) SSH
- To find out if the assumption on edge model is met prior to case
combination, edge SSH for each TSO needs to be reviewed. (SSH
for each edge has the same value, which means that the power flow
of connecting line is the same.)
- If edge models of the two are the same, the influence between two
is set off and can be neglected from the case combination. Hence,
TSO SSH is reflected as is.
CASESSHT = U ( {TSOSSHT} )
(3) TP
- Cases can be combined by combining the TP data of the two. Here,
X-TopologyNode has to remove duplicate data.
- In fact, perform topology processing each time to create new TP
result and then combine changed part only.
CASETPT = Topology ( CASEEQT, CASESSHT )
CASETPT = U ( {TSOTPT} ), Here, overlapping X-TopologyNode needs
to be removed when combining.
△Null = Diff ( CASETPT, CASETPT ), Here, for each bus created
from performing TP, the same mRID needs to be created.
(4) SV
- Power flow calculation result may be conducted irrelevant of the
submitted result (flat start condition)
CASESVT = PowerFlow ( CASEEQT, CASESSHT, CASETPT)
- To compare the new power flow calculation result and submitted
result, phase angle needs calibration.
: Reference bus phase angle study of new calculation result
: Calculate the difference in reference phase angles of calculation using
common system model and calculation result submitted to TSO
: Calibrate each calculation result submitted to TSO
: Compare SV result
- Although submitted calculation result may be used as the reference
phase angle, additional calibrations are necessary.
D. Partial Data Case for System Safety Coordinator
Create a case for the overall common system model by merging hourly
and seasonal cases submitted by TSO. The merging process is similar to that
of hourly and seasonal case.
(1) EQ – Partial Model Framework
- Framework necessary for combining partial model
{ DetailTSOEQT } : Identify target TSO
{ InternalBoundaryEQT } & { EdgeBoundaryEQT }: Identify all
connecting points on both sides (EdgeBoundary is a connection point
related with only 1 TSO)
EdgeEQ is needed for each edge tie
- The easiest way of creating an edge is using the same model as the
edge model submitted by TSO. However, this may unnecessarily
include detailed TSO models.
<Figure 3-25> Ties between TSO
(2) SSH, TP, SV
- SSH, TP and SV have the same process as combining hourly and
seasonal cases. (Here, to supply equivalent virtual power to tie line,
EdgeSSH for each EdgeEQ is maintained.)
(3) Complicated Reduction
- In case complicated reduction is needed in system edge, ReducedTSOEQ
model is created. In general, bulk electricity is extracted from TSO
system model to separate the system model. ReducedTSOEQ model is
composed of one or more system edges. System edge model is used in
its original form, but ReducedTSOEQ model needs to be recreated for
every TSO system model case.
4. Use Case
A. Outage Scheduling Process based on NC OPS (Network
Code on Operational Planning and Scheduling)
The starting time for NC OPS process was defined based on the
requirements and experience of other processes and evaluation processes. First,
it starts when all participants establish the feasibility plan between each other
through validity evaluation. Here, later the feasibility evaluation is set, it can
utilize more accurate data, hence rational level of trade off on the
establishment timing is necessary. However, feasibility evaluation on the
perspective of feasibility planning is necessary to be used as reference data in
generation feasibility evaluation, tasks such as calculating connecting electricity
capacity, contract between third parties and other unrelated asset plans.
Some annual outage cooperation processes are already established (e.g.
annual outage cooperation process in European continent), the proper process
starting time is already defined in system regulation. After establishing the
annual outage cooperation process, the feasibility evaluation and updating
process are conducted in order to establish the most flexible feasibility plan on
related assets. In this process, the expiry date for using feasibility state data
on related assets is set for system safety interpretation, system feasibility
evaluation and calculation of capacity of connected electricity.
The tasks to be performed from annual cooperation process, flow chart of
tasks and expiry date are indicated in <Figure 3-26>. To avoid confusion, the
cooperation process is reduced and is focusing on the flow of process.
Until early September, the closing date is set so that preliminary outage
schedule can be used for evaluating validity of power generation in European
continent and calculating long term connected capacity. Some closing dates are
set only to show the time flow of the process without reflecting the NC
requirements.
<Figure 3-26> Annual Cooperation Process (With Emphasis on Time Flow and
Data Correlation)
B. Annual Outage Cooperation Stage
The annual outage cooperation process in NC OPS 35-39 is shown in
<Figure 3-27>.
<Figure 3-27> Annual Cooperation Process (With an Emphasis on Correlation
between Stakeholder)
C. Updating Annual Availability Schedule
NC OPS 41 describes how stakeholder can change the availability cooperation
schedule.
<Figure
3-26>
and
<Figure
3-27>
show
the
process
individually
changed by outage scheduling department and TSO respectively. It is important
how to cooperate in case the established outage schedule is inappropriate.
Although not precisely defined in NC OPS, it can be accomplished by introducing
a process verified from other systems. NC OPS deals with the legal framework
for improving cooperation process.
To reflect early change requests in cooperation process, availability
schedule of other stakeholder may need to be changed. According to national
laws, contract between two parties or other consultations, the requesting party
may need to financially compensate the changing party. Hence, rather than
obliging or prohibiting any compensation, NC states that a properly consulted
availability schedule needs to be established.
<Figure 3-28> Annual Availability Schedule Updating Process by Outage
Scheduling Team or DSO
<Figure 3-29> Annual Availability Schedule Updating Process by TSO
D. Availability Data
Related data between TSO is shared between stakeholder or EU via
ENTSO-E OPDE (Operational Planning Data Environment). All TSO are
obliged to register and update data (availability schedule, data necessary for
safety interpretation and cooperation related data) in OPDE common format.
This data is accessible by all TSOs of EU. If necessary, one is permitted to
access the entire EU data and filter related data. The data used for
establishing TSO availability schedule is limited to system facility defined as
related asset by TSO. Enormous amount of data is used for interpreting safety
cooperation by OPDE.
Although currently there is no central data managing system for sharing
data related with availability schedule between TSOs, by establishing a data
management environment, TSOs can find necessary data by requesting each
other, use common methods such as common data format and common process
time management, and easily seek cooperation and collaboration between
TSOs.
In order to determine the influence of specific system facility outage on
systems under jurisdiction of other TSOs, the data of TSO requested by other
TSO varies based on the time range sought by the requesting TSO.
m
Availability Flag Stated in OPS 32(4)
- Available
- Unavailable
- Testing, Test Operating or Under Maintenance
(1) Week Ahead/Year Ahead Time Range
- All system elements of transmission system or related distribution system
Name of transmission system element and unavailable time
Name of generator and available/unavailable day (If generator is
available or restrictively available)
Name of large load and available/unavailable day
New system element (system element, generator, load) : Test operation
starting/finishing day
; Reflect to TSO system model and configure "Testing" status
(Test operating period)
; Reflect to TSO system model and configure "Unavailable" status
(Before test operation)
Elements removed from system (generator, load)
; Reflect to TSO system model and configure "unavailable" status
(for some branches, after completing de-commissioning)
- Outage data influencing transmission system topology such as
starting/finishing time of unavailable status (in hours), and service
resuming date (changing factor to available status)
(2) Day Ahead/2 Days Ahead Time Range
- 1 day/2 days power scheduling amount in market under jurisdiction of
specific RSCI (Reflect ENTSO-E OPDE and individual system model)
- TSO identifies necessary system composition (recompose system for
recovery of specific system element causing blackout)
(3) Days Ahead Time Range
- Fault Blackout : Fault blackouts are not scheduled. In specific
transmission systems, this can deteriorate system safety/system
stability. Related TSO shall consult major monitored system elements
with large influence from fault blackout. Reflect the major system
asset status in ENTSO-E OPDE and individual system model.
- Particulars of fault blackout and sustained time for change in
transmission system : Share data via ENTSO-E OPDE, and modify
individual day ahead/2 days ahead system model
- Tie between ENTSO-E OPDE data and TSO individual system model :
Not defined yet. Data aligning function for system model between TSOs
influencing each other
E. Operating Entity related with Outage Cooperation and
Data Exchange
<Figure 3-30> Data Exchange System during Outage Cooperation
<Figure 3-30> shows data exchange between TSOs under outage
cooperation. An application program was designed to enable data exchange on
the internet. User accounts use password through security token. In general,
TSOs access via firewall, but in some cases, they can access via VPN tunnel
or other secure accessing method and firewall. In the event of difficulty in
using secure accessing method due to poor telecommunication environment, the
system grants ordinary read-only access instead of secure access. However,
this is conducted by an individual TSO by changing data using application
program, hence is to be determined by TSO. <Figure 3-30> shows a
classification of 3 types of user groups: standard user, system administrator
and local TSO administrator. Here, TSO determines the authority to be
granted to each user group. Hence, the operation scheduler may have varying
authorities per TSO.
F. Business Needs
m
m
m
m
Upload outage schedule and search nearby TSO data using administrator
ERP tool of outage scheduling institute : Simulate influence of power
flow calculation by manually entering outage schedule (Outage Flag:
Accepted, Requested (Roughly planned) or Rejected)
Download nearby data and upload nearby TSO data power flow calculating
tool using administrator ERP tool of outage scheduling institute : Analyze
influence of power flow calculation (Download data for major system
elements consulted with nearby TSO)
Upload/modify and download outage schedule and upload local ERP using
administrator ERP tool of outage scheduling institute : Manual
synchronization between two systems not necessary (ultimately aiming
for automated change)
Upload outage schedule using administrator ERP of outage scheduling institute
and analyze influence in CTDS environment (synchronize modification on local
ERP if needed) : Complicated tasks such as creation of individual system
model, verification of data validity and data merging when downloading outage
data and analyzing influence (calculate power flow and credible accident)
m
m
System safety evaluation (2 stages) : Temporary investigation and detailed
investigation of outage scheduled region (cooperate and calculate power
flow/credible accident)
Outage scheduling institute user interface and power flow calculating tool
interface (with possibility to change topology)
G. Exchange Data Property
The properties related with ERP tool and interface between environments
are as follows.
m
Case Data
case ID
- case ID is an identifier individual for each case
- starts with TSO code and is a TSO-unique code with
letters or numbers
- the number of digits is not limited
project ID / name
- if multiple cases belong together, one common project ID
for these cases has to be determined by the requesting TSO
- additional to case ID
date of last change
- versioning of the case
- date and time of last change of the case information of
the requesting TSO
Status Information
- Status
m
System Element Data
Element ID
- Enter the code which is used for the unique
identification of this grid element.
- EMFIP
required
Coding Scheme
- Enter the name of the coding scheme used.
-
Long Name
- The long name for the grid element(s) has to
be provided.
- The following naming convention should be used
for new grid elements:
- Substation: Voltage level (optional), name
- Line: Voltage level (optional), Subst. 1, Subst.2,
Subst. X (in alphabetical order), name (optional)
- Transformer: Voltage levels (optional), Subst., name
- For a transition period the long name field
could also be used for UCTE coding for elements
- EMFIP
required
Element Type
-
- EMFIP
required only
for identified
Critical
Network
elements
Voltage Level [kV]
- Voltage level of the grid element
- EMFIP
required
Status
- To be marked whether element is "active" or
"inactive"
- After an element reaches its end of time it is
not simply deleted from the REF data base but
its status is changed from active to inactive.
- EMFIP
required
Notification
- Add the TSO(s) that should be notified that a
case or a change to a case for an element was
uploaded/inserted to OPDE (i.e. for creation of
the observability area).
- Only the "responsible" TSO can fill in other
TSOs to be notified. If a TSO wishes to be
added to "Notification" he has to contact the
responsible TSO by email or phone.
- EMFIP
required
LINE (internal overheadline or cable)
TIE (tieline)
DCL (DC-line)
TRA (transformer)
BUB (busbar)
CAP (capacitor)
IND (inductor)
GEN (generating unit)
LOAD (consumption unit)
SUB (substation)
PPL (powerplant-Line)
Responsible
- TSO that is responsible for reference data
maintenance and can send cases (outage
planning/availability data for this element).
- Exceptions:
- If the element type is TIE more than one TSOs
can be listed here. The following rules are
applicable:
- The TSO, that is listed first is responsible for
reference data management
- All TSOs listed under "responsible" can send
cases (outage planning/availability data for this
element).
- All TSOs listed under "responsible " must be
listed under "coordination" as well. (Important
for filtering purposes and for coordination
process via MLTOP)
- EMFIP
required
Planning Region
- Is the element part of a planning or market
region eg: DACH, CCE, CWE etc.
- EMFIP
required
Co-ordination
- Insert the ISO country code for all TSO(s) who
have to coordinate for this element (e.g.
tielines)
- TSOs that are listed in this column must not be
put to the "notification area" as they will be
notified by the "Coordination process" about
cases and changes to a existing case
- The responsible TSO(s) must be put also to this
column (for filtering purposes "show all grid
elements where I am in coordination")
- EMFIP
required
Cap Calc Relevance
- Either yes ‘Y’ or no ‘N’
- EMFIP
required
Part of Multipod
[ID of Multipod]
- Enter the element ID which is used for the
unique identification of the multipod.
-
Special relation to
another element [ID]
- Add here the element ID of the element that
has a special relationship to this element(s).
- This information is needed for interdependency
checks.
-
Remarks
- If needed any additional information can be
provided here.
- EMFIP
required
m
Unavailable Data
Case type
The case type indicates the status of the involved grid
element(s):
- OUT: outage (element is out of operation)
- 1BBO: single bus bar operation (only valid for Element type
Substation "SUB")
- xBBO: multi-bus bars operation (only valid for for Element
type Substation "SUB"); In field "Operational hint for
Substation" it can be indicated which element is connected
to which busbar
- AUX: auxiliary bus bar operation (element is IN service but
connected via Auxiliary busbar)
- SSS: special switching state (for element types Substation
"SUB", "LINE" and Transformer "TRA"); Elements are in
service but in a special switching state
- AR: protection function „Automatic reclosing“ is switched off
- BBprot: protection function „Busbar protection“ is switched off
- ON: line in operation if off is the default state of the element
- NEW: new element which is not yet in operation
- EOL: End of lifetime, element is available but cannot be
used anymore
- ITS: interim solution: element is available only for a limited
period of time
- EMFIP
required
Alternating
- If two elements are used alternatingly, both elements
belong to the same case ID and an "X" is required in this
column.
- EMFIP
required
m
Outage Time
Start date
- start date of the unavailability
- date format DD.MM.YYYY
- EMFIP
required
Start time
- start time of the unavailability
- time format hh:mm [CET/CEST]
- EMFIP
required
End date
- end date of the unavailability
- date format DD.MM.YYYY
- EMFIP
required
End time
- start time of the unavailability
- time format hh:mm [CET/CEST]
- EMFIP
required
offset
[+/- days]
- additional time period in calendar days in which the
unavailability can be started earlier or finalized later
- EMFIP
required
m
Time Profile
Daily /
Continuously
- to be marked with "X" if the outage or special switching
state is repeated every day referring to the specified times
- EMFIP
required
Mo-Fri
- to be marked with "X" if unavailability is on all week days
- EMFIP
required
Saturday
- to be marked with "X" is unavailability is on Saturdays
- EMFIP
required
Sunday
- to be marked with "X" is unavailability is on Sundays
- EMFIP
required
excluded
days
[date; date]
- dates when the unavailability does not exist
- date format DD.MM.YYYY
- EMFIP
required
m
Time Profile
max
- maximum restitution time in hours
- If no restitution time possible = "N"; if "0"=element can
be switched back on "asap"
- EMFIP
required
daytime
- restitution time during daytime in hours
- EMFIP
required
nighttime
- restitution time during nighttime in hours
- EMFIP
required
weekend
- restitution time on weekends in hours
- EMFIP
required
m
Local Approval Procedure Data Property
Co-ordinatio
n status
This field is used for coordination by both, the requester
TSO and the requested TSO the confirmation status must
be entered here. The following status are possible:
- REQ=requested
- REJ=rejected
- CON=confirmed
- EMFIP
required
case-referen
ce (change
request)
- if two cases affect each other and the status of one
turns to "approved", the status of the other must be
changed to "cancelled" and the case ID of the replacing
case must be entered here for tracking reasons
-
rejection
remark
- If the request is rejected the reason for the rejection
can be entered here
-
m
Generator/Consumer/Compensation Device
unavailable
capacity
- Enter the unavailable capacity in MW for generation
units/consumers and in Mvar for compensation elements
(IND, CAP)
- EMFIP
required
installed
capacity
- Capacity in [MW] for generation and consumption units
- Capacity in [Mvar] for compensation elements such as
CAP and IND
- Negative sign ("-") must be used for consumption units
and and IND; generation units and CAP are given as
positive value
- EMFIP
required
fuel type of
generation
unit
- For generation units add the fuel type of the unit
- EMFIP
required
H. Base System Topology Data
The system model used for composing common system model consists of
system topology, change in state of system topology and scenario data. TSO
used individual system model to provide model merging function capable of
composing common system model.
Base system topology data refers to the base data group defining the
system of TSO. To minimize the transmitted data volume, it is sent from the
field only when the base data changes. The changed files are applied to the
base system topology data to reflect the changes in the field.
To secure data reliability, a new base system topology file reflecting all
changes is sent by a separate cycle.
Section 4. Connected Capacity Calculating
Profile
1. Necessity to Calculate Connected Capacity
EC
regulation
article
16
paragraph
714
(2009)
defines
that
the
maximum connecting capacity for transmission system influencing power flow
between national border to maintain safe system operation be shared to
market participants. Also, it stipulates the need to suggest a solution to
system congestion based on fair market principle for providing efficient and
economic signal to market participants and related TSOs.
This regulation defines the general rules for calculating and distributing
unit connected capacity, this ultimately aims to be introduced to the daily
power market connection in EU systems.
For the power market to be connected, the available connection capacity
between TSOs must be calculated which requires the composition of a
common system model conveying the hourly generation, load and system
status forecast. Available connected capacity is generally calculated based on
power flow which optimizes the available connected capacity in network
system by considering that capacity can be shared via multiple lines rather
than a specific line.
Available connected capacity is a major value used as an entry of other
calculating processes. In EU power market, the economic optimum value is
derived considering the available connected capacity to determine the final
market price. When connected to the market, electricity generally flows from
power market with cheaper unit price to power market with expensive unit
price. MCO (Market Coupling Operator) uses a specific algorithm as the
optimum way of matching the bid with the supply. Due to the exclusive role
of MCO, it becomes a target of regulation. The calculation result of MCO is
faily disclosed to all power exchange centers with each power exchange center
notifying the bidding result to bidder based on this information. Hence, energy
flow within system is determined by the calculation result of MCO. Except
that biddings are made all day rather than single calculation day ahead, a
similar process occurs in the daily power market connection.
Calculation of annual capacity is used in day ahead and real time market,
which update on time using the latest data.
For calculation of connected capacity to have reliability, adjustments are
made at least between TSOs before providing the optimum connected capacity
to the power market. By defining the requirements on entry, calculation
method and verification of calculation used to calculate connected capacity, the
calculation method for connected capacity was established for common use.
Calculation of connected capacity is classified into calculation based on
power flow and calculation based on capacity before transmission. In day
ahead market and real time market with high dependence of connected
capacity, calculation based on power flow is mainly used. This shall be applied
only when sufficient time for exchanging power is given to market
participants. On the other hand, in markets with low dependency of connected
capacity, the calculation based on capacity before transmission is used.
The common system model for European systems was established to
calculate connected capacity. The common system model includes the power
sources, load locations and transmission system models related with calculating
the connected capacity. To create a common system model, timely provision of
accurate data from each TSO is essential.
Through the common system model, each TSO will establish the relevant
TSO system model and provide to TSO that needs merging into system model
establishment. Common system model also includes the information on
generation source and load.
TSO takes consulted measures to deal with internal and connected
congestion issues. It will mediate the measures used in calculating the
connected capacity for more efficient distribution of connected capacity.
For efficient congestion management and for overall market efficiency, the
bidding zones are defined with the permission of separation or merging of
bidding zones. Bidding zones must be applied uniformly between other power
markets with different units of trading time.
2. European Power Market
A. European Power Market
The European power market launched by the order (EU96/92) enforced in
February 2999, could not agree on integration. The need to integrate power
market came to the fore due to the limitation in power source of 15 member
countries and the lack of avialble connected capacity rather than the need of
power market with uniform pricing. With this, European authority enacted a
new regulation law in July 2004 to encourage a market based congestion
managing system that efficiently manages connection and derives facility
investments by proposing proper incentives.
<Figure 3-31> Integration of European Power Market
B. Separation of Power Market
Separation of power market means that energy and capacity are traded at
the same time. During congestion, power market is divided into two or more
bidding zones. Each bidding zone is stabilized to maximize the utilization of
transmission capacity between bidding zones.
In large zones using uniform pricing, the competing system is important,
and in this aspect, separation of power market has many advantages. The
economic effect of separation of power market is similar to the connection of
power market, but the processes vary.
m
Power Market Separation Process (Introduction of NordicPool)
- Separate bidding zones (define power transfer corridors)
- TSO, calculates transmission capacity by corridor (allocate hourly
capacity in day ahead market, provide information to power market
every morning)
- Market participant, bids in each bidding zone (Trade stabilization by
bidding zone is essential)
- Determine hourly market price (By 2am one day ahead)
- Determine non-congestion market price for entire market (review power
flow between bidding zones compared to available transmission
capacity, in the event of breach, separate power market and determine
market price by zone)
- Repeatedly perform so that all corridors meet available transmission
capacity (All market participants are compensated and charged depending
on the corresponding power market price)
- Submit generation schedule by bus to TSO and calculate the change
from schedule for claiming charge (Obligation of all market participants
within each bidding zone)
For separation of power market, the bidding needs to be combined when
the central power market operator determines the price of power market. The
power market separation puts all power market participants in the same
bidding zone, hence it will induce competitive environment. A single market
participants will not accumulate transmission capacity for its own use, hence it
will be assured that the available transmission capacity is faily shared
between market participants. In the event of congestion, power price rise
occurs in vulnerable zones. In this case, proper incentives are given to power
market participants at both ends of the corridor.
Also, power price reflects the value of electricity of participants of power
market. The congestion in bidding zone will cause congestion cost of TSO.
This is in the same manner that the sum of consumer bills do not match the
sum of bidding costs. According to the EU order, the congestion cost can only
be used for transmission capacity investment, reduction of price or connected
trades. When separating the power market, central supply is substituted based
on the market. The supply from this matches in the scheduling stage.
During operation hours, distributed supply is conducted based on the
scheduled values. The system operator has to take caution of any
noncompliance in supply and demand via the power market after the
scheduling stage.
C. Combination of Power Flow Based Power Market
New EU regulating guideline defines the enforcement of combination of
power flow based power market. In the combination of power flow based
power
market,
the
energy
bidding
and
available
capacity
are
evaluated
altogether from repetitive process. A linear relationship between the bidding
defined by PTDF (Power Transfer Distribution Factor)
power flow is assumed to perform optimization of bidding.
matrix and actual
The combination of power flow based power market as implicit as the
separation of power market, but occurs in the reverse order of combination of
power market. First, after the closure of each power market, the power
markets are combined. This is a mixed form of "power flow based modelling"
and "combination of distributed power market". While "power flow based
modelling" uses the actual power flow exchanged between other power
systems, "combination of distributed power markets" operates another power
market adjusted between other power markets complying with the power
market rules within each region.
Considering that a common system is operated along with the region
connected via connected line using the same market price, it needs to be
simplified. The actual power flow between other buses is modelled by the
power flow rate, and the marginal value between buses is calculated by
considering the bottleneck phenomenon of major system element (does not
have to be connected line) capacity.
Bottleneck capacity (Fmax and Fmin) and power flow rate (PTDF) need
to be estimated and notified prior to starting TSO operation by day ahead
market. The information requested by day ahead market is the system status
of temporary transmission system model used for combining power flow based
power market.
3. Use Case
In calculating the capacity considering the system bottleneck of major
system elements causing congestion from operation of power market between
countries, the actual system information is necessary.
Power transmission ability needs to be calculated for each system status.
This is applied to all transmission systems in sub-systems and power trades
between sub-systems. Sometimes, this is accomplished by defining the
transmission corridor (generally connecting line), and determines how much
power flow needs to be transmitted in which direction until reaching unstable
state occuring within thermal limit, prior to voltage disruption or multiple
failure within corridor through dynamic/static simulation. Corridor may include
a number of lines with varying voltage levels.
A. PTC (Power Transfer Corridors)
Sometimes, transmission exceeding the transmission capacity is needed.
In this case, the transmission system is placed under restriction. PTC is
defined to deal with this restriction occurring in power system from EMS.
PTC is a term referring to credible accident through experience and offline
study (N-1),
and becomes
the path that
monitors the safety of power
system
in
the
event
of
system
accident.
Monitoring
PTC
is
extremely
important for reliable operation of transmission system in some TSOs.
PTC can be related with stability such as voltage disruption and thermal
limit. PTC is composed of two or more lines and PTC marginal value uses
the marginal value manually designated by an operator or the marginal value
derived from the system interpretation result using interpretation of thermal
stability and voltage stability based (N-1) credible accident.
The electricity transmission value of PTC is defined as the sum of
weighted values of power flow in the line.
PTCname = W1 * Power FlowLine 1 + W2 * Power FlowLine 2 + W3 * Power
FlowLine=3 + ... + Wn * Power FlowLine n
Here,
Wn
: Weighted value between -1.0 and 1.0
Power Flow Linen : MW or MVA power flow on line n
In the same method as the line marginal value breaching inspection, the
breach of PTC marginal value is inspected and reported through real time
system interpretation and study system interpretation. The marginal value of
PTC is determined online based on thermal stability and voltage stability.
The screen should be designed to indicate the PTC information. Each
PTC information should include the name and the marginal value of
corresponding line, and is used from system interpretation function to inspect
and report breach of marginal value. Meanwhile, the system interpretation
function needs to propose a control for dealing with breach of PTC marginal
value.
In calculating the PTC marginal value, the short term marginal value for
each line is used. In the event of breach of cautious marginal value for each
line, the alarm marginal value is used.
Information related with the PTC monitored by an operator include PTC
name, power flow calculation, thermal marginal value, voltage marginal value,
dynamic stability marginal value, operator designated manual marginal value
and load rate to marginal value.
The operator should be able to search the details of specific PTC and
calculation result related with the credible accident causing breach of marginal
value of the relevant PTC. The list of specific PTC line should include the
power flow weighted value and marginal value of the line.
Case 1) PTC (Tunnsjødal/Kobbelv-snittet)
- Defined by the sum of weighted values of 4 lines
M 300, Tunnsjødal – Namsos (L1flow)
M 300, Tunnsjødal – Verdal (L2flow)
N 420, Kobbelv – Ofoten (L3flow)
M 220, Nedre Røssåga – T_Gejmån (L4flow)
- PTCflow = L1flow + L2flow + L3flow + L4flow (All weighted values are 1)
- Operator designated PTC marginal value : 1,200MW (Based on stability
from experience)
Case 2) PTC (420 Dagali-Nore non-energized)
- Defined by the sum of weighted values of 2 lines
S 300, Hemsil-Sogn (L1flow)
S 300, Nes-Sogn (L2flow)
- PTCflow = 0.4 * L1flow + L2flow (Weighted values are 0.4 and 1.0
respectively)
- PTC marginal values vary by temperature (Short term marginal value
(@20℃/@30℃) : 605/520MW, alarm marginal value (@20℃/@30℃) :
520/435MW )
B. Critical System Element (CWE Region)
The core of an advanced power flow based method is regarding the
interpretation of credible accident as an important part of distribution process
and performing in the similar manner as supply operation safety. In this way,
critical system elements become the combination of power facilities with
additional restrictions such as unscheduled power amount, consumer load
fluctuation, storage capacity and power facility fault outage.
When all restrictions related with the overall system are used, an
enormous amount of restrictive conditions are being handled (e.g. For N-1
interpretation on overall system, 100 million number of restrictive conditions).
The scope of lines tremendously affecting border distribution, target lines
with possibility of restriction due to system safety and "critical system
elements" as observation target with possibility of a number of additional
restrictions has decreased.
The temporary system model used for a number of credible accident
cases, shall only target black lines in <Figure 3-31>.
<Figure 3-31> System Model and Critical System Elements
In power flow based distribution system, each critical system element is
reflected to the following calculations.
- PTDF (Power Transfer Disbribution Factors)
- Power flow befoew distribution (Fref)
- Maximum permissible power flow (Ffmax) [A]
- FRM (Flow Reliability Margin) [MW]
- FAV (Final Adjustment Value) [MW]
- Power flow direction in the event of breaching restrictive value
Critical system elements include the following facilities.
- All connecting lines : Critical line groups sensitive in power trade
between countries always include connecting lines
- Critical lines in power trades between countries : Include in critical line
group if lines are markedly exposed to power trade between come
countries, or cause restriction in power trade between countries
- Restrictive conditions of critical power facilities : Unscheduled
generation, consumer load fluctuation, storage capacity and power
facility fault outage (The importance of critical power facility changes
with the conditions such as the operation of market scenario from the
dispersement of power trade between countries)
The restriction on the direction of power flow within system line is
expressed by one critical power facility in each direction of power flow.
e.g. 6 critical system lines can represent the restriction in marginal value that
can occur from 1 connecting line (2 restrictions considering both directions of
power flow during 1 normal situation and N-1 number of crediblt accidents)
A. Calculation
TSO can precisely determine what the critical system elements are on
the perspective of predicting the knowledge on systems under jurisdiction of
TSO, the importance of each power facility within system and system status
(load, generation, topology, etc.) on a particular date.
By eliminating less important restrictions compared to other restrictions,
this approach can be used. Credible accident causing congestion can include
preselected critical lines while eliminating those that cannot be combined.
Target facility deemed to be critical system element from power
distribution can be changed just in time due to change in topology,
maintenance and expansion of system facility. For this reason, regular reviews
and updates on critical power facility list used in power distribution are
essential.
In general, the number of critical system elements in CWE region
fluctuates between 1,000-2,000, and the total number of 400kV and 225kV
buses is around 10,000. However, in actual cases, reduction to less than 100 is
permitted from mathematical filtering (to maintain system safety).
B. Maximum Permissible Power Flow (Fmax)
As the value for power flow in critical system elements, based on the
power facilities in critical system elements and measures taken for each
system, the maximum permissible power flow can be configured as follows.
- Maximum restriction of power flow of protective relay
- Thermal marginal value of power facility
- Boundary value of voltage disruption
- Boundary value for maintaining voltage stability
- In some cases, the physical marginal value can be changed by
considering the relief of congestion.
Where a line is expressed by n number of critical system elements (e.g.
2 status in both directions, N status and N-1 status), Fmax becomes the
same as n number of critical system elements. However, in special cases
where other measures that can be used in other situations are taken, n
number of critical system elements may be different from N and N-k status
and even different from two other N-k statuses.
C. Flow Reliability Margin (FRM)
Uncertainties occur from this procedure for the following reasons.
- 2 days ahead system load forecast
- Linear system model by PTDF
To prevent the occurrence of power flow exceeding the maximum
permissible power flow of TSO on a corresponding date (day D), the
uncertainty related with power flow based process must be quantified and
discounted during the power distribution process. FRM for quantifying the
influence of uncertainty in each critical system element on power flow can be
defined to deal with this uncertainty.
To assure free space for partially dealing with this uncertainty, FRM has
to reduce the available space for critical system elements.
For each of the critical system elements, FRM cannot be gained from
D-2CF (2 days ahead congestion forecast) base case, and this value is not a
physical value of the line. In other words, FRM is based on the operation
experience from the D-2CF/power flow based process.
FRM can be divided into the following two margins.
-FRM1 : Uncertainty related with 2 days ahead system load forecast (e.g.
marginal quantification by comparing power flow forecast and
actual power flow of each critical system element)
-FRM2 : Uncertainty related with linear system model by PTDF
(Marginal quantification by comparing AC power flow
calculation and DC power flow calculation results)
General methods through testing power flow based methods conducted by
R4CA working group mainly defined FRM of each critical system element as
10% of Fmax. Here, the FRM has a value between 150MW~300MW for 380kV
line or a value between 30MW~60MW for 220kV line. However, the first FRM
setting of each critical system element should be constantly observed and
modified by TSO of jurisdiction during operation test and even after
commencing FBMC.
D. PTDF Matrix Calculation
<Figure 3-32> shows the PTDF matrix calculation for each base case.
<Figure 3-32> FB Parameter Calculation : PTDF Matrix
For all hubs, the process in <Figure 3-32> is repeated. Also, PTDF is
calculated for all restrictive conditions deemed related with TSO. The 1MW
power exchange from bus A to bus B is as follows.
This property is valid due to the linearity (DC power flow calculation) of
PTDF calculation. Hence, "hub-hub" PTDF can easily be derived by deducting
the "hub-reference" PTDF calculated earlier. <Figure 3-33> shows an example
of PTDF matrix.
<Figure 3-33> Example of PTDF Matrix in Netherland
E. Power Shift Key and Load Shift Key
The generation shift key (GSK) for each generator can be defined as:
- Maximum restrictive value of power flow of protective relay
- Thermal marginal value of power facility
F. Adjustment of Base Case Power Flow before Calculating
Power Flow
The influence of trade between encouraged countries is reflected in the
base case power flow (Fref). Using PTDF, the base case power flow can be
adjusted as shown in <Figure 3-34> prior to calculating the power flow.
<Figure 3-34> Adjustment of Base Case Power Flow Prior to Calculating Power Flow
The RAM (Remaining Available Margin) for all critical system elements
used for calculating the power flow based power market combination can be
calculated as follows.
 ′ max   ′    
  max   
 ×        
  
Here, LTA is Long Term Allocated value, and FAV is Final Adjustment Value.
<Figure 3-35> Overview of RAM
G. Nordic Critical System Elements
In Nordic countries, regions with varying power prices may exist in a
country of countries. This means that regions controlled by a single TSO can
be split into many power pricing regions with relevant GSK. Currently, in
CWE, there is a single GSK in each country, but this is not true in Nordic
region. This region can geographically change daily.
<Figure 3-36> Regions with Varying Power Prices in a Country
H. Property of Exchanged Data
Data related with critical system elements and additional restrictive
conditions are as follows.
m
m
Case Data
- Document identification
- Document version
- Sender identification
- Receiver identification
- Creation date & time
- Constraint time interval : Start Date&Time ; End Date&Time
Critical System Elements
- Domain (to check)
- Equipment tree to monitor : identify by MRID
- Imax of this equipment tree (in A), included in reference of relevant
limit set; Direction :
- Monodirection (equipment monitored when active flow is in one
direction), or BiDirection (Equipment monitored whatever active flow
direction)
- Flow Reliability Margin (FRM) : Margin chosen by a TSO for a
critical network element (in MW)
- FAV : Final Adjustment Value (in MW) will increase or decrease the
remaining available margin(RAM) on a Critical Network Element, for
simulating implicit remedial actions or as a consequence of the
verification phase of the Flow-Based domain
m
m
Fault and Restrictive Conditions (Connected to monitoring critical system
facility)
- Identifier of the Fault/Constraint
- Name of the Fault/Constraint
- Equipment tree 1 name of outage, with MRID
- Equipment tree i name of outage, with MRID (in case of multiple
tripping, N-2 for example)
- Impact of this issues on Critical Network Element : Unplanned
production, demand side changes, storage capacity
Recovery Measures (Connected to Fault/Restriction)
- Identifier of the Remedial Action
- Name of the Remedial Action
- Detailed Description
- List of Actions :
For example Equipment Tree MRID and element name
Value (Open, close interconnector, tap position variation,...)
Any other remedial action : Change in Production, Load,...
m
m
m
External Restrictions
- Creation date & time
- Constraint time interval
- Domain
- Max export (MW)
- Max import (MW)
PSK (Power Shift Key)
- Creation date & time
- Constraint time interval date&time
- Domain
- Production :
Node name
Factor or merit order list
- Load :
Node name
Factor or merit order list
LTA/NTC 파일 (Reference)
- Netted AC Commercial exchanges on every European Border
- Name of the border CountryA=>CountryB
- Value of the exchange (MW)
CH 4
Test Case Guideline
for Domestic CIM
Interoperability
Section 1. Essential Compliance of CIM-XML Data for
Interoperability
1. CIM-XML Syntax Compliance for Interoperability
For interoperability of basic CIM-XML, the well-form conditions of RDF
and XML syntax should be determined by complying with the suitability.
Perform basic XML and RDF syntax tests. The test items are as follows.
Items
Missing Start Tag
Missing End Tag
Missing Tag Name
Missing Quotes
Missing Closing Bracket
Missing Closing Quote
Ivalid Empty element tag
Invalid End Tag with attributes
Invalid white space before tag name
Invalid name Space In PI
Invalid white space st start
2. CIM-XML Profile Compliance for Interoperability
IEC 61970-301 CIM model is a group of diverse power models, and hence,
it is classified into various profiles depending on the purpose of use to be
used in actual applications, and is again split into IEC-61970 4xx standards.
The data implementing the schema of profile is expressed by RDF and
composed of IEC-61970-552-4 CIM-XML Model Exchange Format standard.
Part
451
453
454
455
Name
SCADA Data Exchange
CIM
Static Transmission Network
Model Profiles
CIM Based Graphics Exchange
Naming Service
Model Population Interfaces
456
Network Solution Interfaces
457
458
Dynamic Profile
CIM Extension to Generation
452
Remarks
Measurement and Control
Transmission system model
information profile CPSM
Graphic standard profile
System status (interpretation)
profile
<Figure 4-1> Composition of CIM Profile
The following image indicates the purpose of use of each profile.
<Figure 4-2> Purpose of Use of CIM Profile
ENTSO (European Network of Transmission System Operators) have
further expanded the profiles in Part 4, applied the following profiles, and
exchanged data between multiple SCADA to test operate the current system.
<Figure 4-3> ENTSO-E Profile Composition and Data Flow
It determines if CIM-XML is created properly without violating profile.
Profiles are created based on IEC 61970-301 UML model, hence includes
definitive items including class, attribute, relationship and inheritance defined
by UML. Profile compliance test determines if CIM-XML file has been created
without violating these relationships or definitions. The compliance rules of
profile are as follows.
Classification
Test Function
Formal Model for RDF test
Formal Grammar for RDF
RDF Structure
Statements test -3-tuples Validation
Validation
(subject, predicate and object) Test for
omission and error
IdentifiedObject.Name
Naming rule test
Data Range test
Data Unit Type test
Data Type test
RDF:ID
RDF File
Naming rule test
Basic Validation
RDF:ID
Duplicate definition test
RDF Class
Undefined test
RDF Attribute
Undefined test
Remarks
UUID Example)
_f81d4fae-7dec-11d0-a7
65-00a0c91e6bf6
RDF File
Cardinality
Restriction
Violation
CIM Subclassof
Relativity test
CIM SubPropertyOf Relativity test
Non-compliance relativity RDF:ID test
1:1 relationship violation test
1:N,* relationship violation test
Accuracy and omission
Accuracy and omission
Accuracy and omission
Accuracy and omission
The compliance rules of detailed profiles for interoperability are as follows.
Category
Sub-Category
Function
RDF
RDF Composition Test
Formal Model Test
RDF
RDF
Formal Grammer RDF Grammar Test
Syntax test
Test
(W3C
RDF Statemensts
RDF S,P,O Composition Test
Standard
Test
Test)
RDF ID Test
Class Test
Attribute Test
RDFs
Specification
Test
(RDFs
Remarks
Subject,Predicates,Object
Test
UUID Example)
_f81d4fae-7dec-11d0-a765
-00a0c91e6bf6
RDF ID Suitability Test
RDF ID Duplicate Test
Undefined Class Test
CIM Subclassof Relativity Test
CIM SubPropertyOf Relativity Test
Undefined Attribute Test
Inheritance Class
Inheritance Property
Unused Attribute Test
Essential Attribute
System
Source Class
SubGeographical
Substation
VoltageLevel
VoltageLevel
Bay
CurveData
Association
RegularTimePoint
Test
Implementati
[Basic Test]
on Suitability
- Association
Test)
Automatically test
relativity of each
attribute on
program.
Terminal
Test
for
Verification
Can
designate
attribute
of IEC-61970-452
Attribute
Detailed Class
essential
Essential
Target Class
GeographicalRegion
SubGeographicalRegion
Substation
BaseVoltage
VoltageLevel
CurveSchedule
IntervalSchedule
cim:ReactiveCapabilityCurv
cim:GrossToNetActivePower
Curve
cim:ConformLoadSchedule
cim:NonConformLoadSchedu
le
cim:RegulationSchedule
ConnectivityNode
ConductingEquipment
cim:ACLineSegment
cim:SeriesCompensator
cim:Breaker
cim:Disconnector
cim:TransformerWinding
cim:Load
cim:ShuntCompensator
cim:StaticVarCompensator
cim:SynchronousMachine
cim:BusbarSection
cim:LoadBreakSwitch
cim:Switch
cim:NonConformLoad
cim:EnergyConsumer
Category
Sub-Category
Function
Remarks
cim:ConformLoad
cim:StationSupply
cim:InductionMotorLoad
cim:CustomerLoad
cim:EquivalentBranch
cim:EquivalentShunt
ConnectivityNode
PowerTransformer
TransformerWinding
TapChanger
TapChanger
Line
ACLineSegment
SeriesCompensator
Equipment
BaseVoltage
MemberOf_EquipmentC
cim:VoltageLevel
ontainer
Substation
MemberOf_PowerTransf
PowerTransformer
ormer
TransformerWinding
RegulatingControl
SubGeographicalRegion
MemberOf_EquipmentC
Line
ontainer
BaseVoltage
cim:Line
MemberOf_EquipmentC
cim:VoltageLevel
ontainer
cim:Substation
BaseVoltage
Breaker
Disconnector
LoadBreakSwitch
Switch
SynchronousMachine
EquivalentBranch
StaticVarCompensator
Equipment
BaseVoltage
EquivalentShunt
InductionMotorLoad
CustomerLoad
Load
NonConformLoad
StationSupply
ConformLoad
Switch
MemberOf_EquipmentC
[Breaker,Disconnector,
Substation
ontainer
LoadBreakSwitch,Switch]
MemberOf_EquipmentC
ShuntCompensator
Substation
ontainer
ShuntCompensator
RegulatingControl
MemberOf_EquipmentC cim:VoltageLevel
StaticVarCompensator
ontainer
cim:Substation
StaticVarCompensator RegulatingControl
BusbarSection
SynchronousMachine
cim:VoltageLevel
MemberOf_EquipmentC
cim:Bay
ontainer
cim:Substation
MemberOf_EquipmentC
Substation
ontainer
cim:GeneratingUnit
MemberOf_GeneratingU
cim:ThermalGeneratingUnit
nit
cim:HydroGeneratingUnit
RegulatingControl
InitialReactiveCapability
Curve
Category
Sub-Category
Function
GeneratingUnit
HydroGeneratingUnit
ThermalGeneratingUnit
EnergyConsumer
ConformLoad
InductionMotorLoad
Load
NonConformLoad
Remarks
MemberOf_EquipmentC
VoltageLevel, Substation
ontainer
MemberOf_EquipmentC
VoltageLevel, Substation
ontainer
StationSupply
CustomerLoad
EnergyConsumer
ConformLoad
InductionMotorLoad
Load
NonConformLoad
StationSupply
CustomerLoad
ConformLoad
CustomerLoad
Load
InductionMotorLoad
NonConformLoad
SubLoadArea
ConformLoadGroup
NonConformLoadGroup
Analog
Discrete
AnalogValue
DiscreteValue
EquivalentBranch
EquivalentShunt
RegulatingControl
ControlArea
operational limits
Other Class
LoadResponse
LoadResponseCharacteristic
LoadGroup
ConformLoadGroup
LoadGroup
NonConformLoadGroup
LoadArea
SubLoadArea
MeasurementType
Terminal
Unit
MeasurementType
Terminal
Unit
MemberOf_Measurement Analog
MeasurementValueSourc
e
MemberOf_Measurement Discrete
MeasurementValueSourc
e
EquivalentNetwork
Terminal
RegulationSchedule
Consult
WG13 CIM addition,
etc.
ReverseAssociation
Conduct reverse relationship test of association
Cardinality Test
Section 2. Compliance on Perspective of Power System
Interpretation
of
CIM-XML
Data
for
Interoperability
1. Data Conformance Validating Factors of CIM-XML
Power System
For suitability of power system data, the CIM-XML files based on 451,
452 and 456 profiles are tested. Based on the network status and topology of
power system, the following items are tested.
Check Basic Composition of Power System Network : Equipment Level Test
m Test for Network Isolation, Loop, and Wrong Connection : Equipment
Level Test
m Test for Connection of Topology Node Declared in CIM :
Equipment-Topology Level Test
m Test for Invalidity of Network Topology Declared in CIM : Topology
Level Test
m
Apart from the network status, the data compliance for attributes requiring
verification of measurement, essential attribute value and calculation is needed,
and hence the following items are tested. The following items are the basis of
essential data suitability verification as the minimum requirements for system
operation. Failing one of the items can determine that the CIM-XML file has
an error in operation and interpretation and cannot satisfy interoperability.
Testing Standard
Power System
Model Validation
(Item Checking
Minimum Data
Existence)
IEC61970-
Testing Items
Substation
Name Duplicate Test
Electrical Junction(ConnectivityNode)
Name Duplicate Test
Control Area Location Suitability Determination
Base/nominal
kV Noncompliance Determination
Applied
Standard
Telemetered kV SCADA reference
Determine existence of acquired point
High/Low Normal limits (kV)
Determine existence of violating value
AC Line and Other Series Devices
Unique Identifier/Name (including a circuit id if applicable)
Resistance
Reactance
Total Line Charging/suseptance
“From” End
location (Electrical Junction and Substation)
Presence
Presence
Presence
Connection
suitability
“From” End
location SCADA references (MW and Mvar)
Determine existence of acquired point
451 Profile
“To” End
Connection
suitability
location (Electrical Junction and Substation)
“To” End
location SCADA references (MW and Mvar)
Determine existence of acquired point
Normal Rating value
Normal Rating units (MVA or Amps)
Transformer
Unique
Identifier (including a circuit id if applicable)
Resistance
Reactance
451 Profile
Rating range
Unit suitability
location (Electrical Junction andSubstation)
Connection
suitability
“From” End
location SCADA references (MW and Mvar)
Determine existence of acquired point
451 Profile
“To” End
Connection
suitability
“From” End
451 & 452
Measurement *
Equipment
Profile
451 Profile
location (Electrical Junction andSubstation)
“To” End
location SCADA references (MW and Mvar)
Determine existence of acquired point
Normal
Rating/Limit value
Normal Rating Units (MVA or Amp)
Tap Information
“Tap side” Electrical Junction Identifier
Tap type
(voltage magnitude and/or phase angle)
Tap position numbers – min, max and nominal
Tap step
size between max and min – (voltage magnitude
ratio and/or phase angle in
degrees) – taps should reflect
system voltage base values not design voltage
values (i.e.
“effective” tap step size)
“Nominal” tap position ratio on system voltage bases – optional
attribute to capture effective tap where “nominal” is not 1.0.
Normal Tap position
Tap position SCADA reference, if applicable
Load Tap Changer (LTC) information, if applicable
Controlled
location
(Electrical
Junction
andSubstationforbusvoltageorElectricalJunctiondefiningstartingp
ointofflowtroughtransformerforflowcontrol)
Control desired value or max/min range along as well as
units of measure (kV, MW, Mvar)
Normal Control status and, if applicable, SCADA reference for status
Switching Device
Unique
Identifier within Substation
451 Profile
Rating range
Unit suitability
“From” End
“To” End
location (Electrical Junction and Substation)
location (Electrical Junction and Substation)
Type (Breaker, Disconnect Switch, Switch, Fuse)
Normal
position/status
Status SCADA reference
Determine existence of acquired point
Analog SCADA
references (MW and Mvar), if applicable,
determine existence of acquired point
Generator
Unique
Identifier
Location
(Electrical Junction and Substation)
Generation MW Limits (Net) Max and Min
Generation
Net Output SCADA references (MW and Mvar)
Determine existence of acquired point
Mw/Mvar
capability curve data (Mvar max/min at MW max
and min in terms of net values)
Voltage control information
Electrical
location
Junction and Substation identifier of controlled
Connection
suitability
Connection
suitability
451 Profile
451 Profile
Connection
suitability
451 Profile
Connection
suitability
Desired voltage control value or max/min range
Normal
Control status and, if applicable, SCADA reference
for status
Load
Unique
Identifier
Location
(Electrical Junction and Substation)
Load SCADA references (MW and Mvar)
Determine exietence of acquired point
Load Pseudo
measurement/schedules (MW and Mvar)
Determine existence of acquired point
Load Type (conforming/non-conforming)
Shunt Reactive Device
Unique
Identifier
Type(Capacitor,
Reactor, Synchronous Condensor, Static
Var Compensator)
Location
(Electrical Junction and Substation)
Load SCADA
references (MW and Mvar) For
Capacitor/Reactors, determine existence of acquired point
Total Shunt
bank admittance/Mvar at nominal voltage
Number of
bank units (assumed equal sizing in bank) For
Synchronous Condensor/Static Var Compensator
Maximum and
minimum reactive (capacitive/inductive)
power
Voltage control information (for all types)
(Electrical
Junction
and
Substation)identifierofcontrolledlocation
Desired voltage control value or max/min range
Normal
Control status and, if applicable, SCADA reference
for status
Power System
Node Island
Connection
suitability
451 Profile
451 Profile
Connection
suitability
451 Profile
Connection
suitability
Test for
Network
Validation
IEC-61970
451 & 456
Profile
Substation
Validation
Although composed by isolated bus, determine the status of
Connectivity.Terminal circuit breaker to verify if in operation
isolated bus
Terminal.Connected<->TopologyNode
Test for processing suitability
Suitability of
topology
process
Invalid Network Topology
Loop
connection
test
Loop Connection
Wrong Network Connection
Analog Measurement
Check for existence of acquired point
1st BusBar voltage
MTR 1st/2nd voltage/current/MW/MVAR
2nd BusBar voltage
D/L Feeder current
Compare T/L power and MTR 1st power
Discrete Measurement
Verify acquired point
Verify T/L terminal line current and circuit breaker status
Verify MTR 1st/2nd current and circuit breaker status
Verify T/L terminal capacity and bank capacity
Verify feeder breaker capacity/current capacity
Verify energizing status of line within station and
GroundDisconnector status
Verify Connection in Station
Explore loop operation status of 2nd buses
-> Although not abnormal, determine significance in
substation operation
Verify connection of Tie/Sec
2 Data Conformance Validating Factors Acquired by
CIM-XML Power System
The following defines the rules for validating interoperability of data
types and acquired values from system and the system status. Also, this
includes the interoperability elements on topology status created from system
connection status and acquired value.
Category
RDF
Entity
Test
Sub-Category
Enumeration Test
Function
PhaseCode Test
BreakerConfiguration Test
BusbarConfiguration Test
CurveStyle Test
UnitSymbol Test
UnitMultiplier Test
TapChangerControl.RegulatingControl
Remarks
ModeKind Test
TransformerWinding.windingType Test
sVCControlMode Test
SynchronousMachine.type Test
SynchronousMachine.operatingMode
Test
GeneratingUnit.genControlSource Test
Same
as
ThermalGeneratingUnit,
HydroGeneratingUnit
cim:Season Test
ControlArea Test
Other Enumeration Value Test
Consult
WG13 CIM addition, etc.
Basic Rule Test
Evaluate Attribute Null
TapChanger TapChangerControl.RegulatingControl
depending on voltage or
Mode test
ModeKind Test
active mode
Measurement quality flags Bits 0-10
draft IEC 61850 part 7-3
Bits 16-31 for EMS
Measurement For power/current measurement, test Flowing direction requires
Test
for omission of flowing attribute
power flow calculation
Evaluate omission of terminal and
suitability of measuring location
Others
ETC...
Measurement Suitability Test Depending on System Status
Omission
status/If
0
1st BusBar voltage
when energized
MTR
1st/2nd Omission
status/If
0
Voltage/Current/MW/MVAR
when energized
Analog
Omission
status/If
0
Measurement 2nd BusBar voltage
when energized
acquired
Omission
status/If
0
Rule
point
D/L Feeder current
when energized
test
61850
(Minim
Compare T/L power and MTR 1st
suitability
of
acquired
um
power
capacity
item)
Verify T/L terminal line current and
circuit breaker status
Verify MTR 1st/2nd current and circuit
breaker status
Verify T/L terminal capacity and bank
Discrete
Measurement capacity
a c q u i r e d Verify feeder breaker capacity/current 61850
suitability
of
acquired
point
capacity
capacity
Verify energizing status of lines in
station
and
GroundDisconnector
status
Explore loop operation status of 2nd
buses
V e r i f y
-> Although not abnormal, determine
connection
significance
of
substation
in station
operation
Verify Tie/Sec connection
Energizing status, etc.
F a c i l i t y SynchronousMachine
TransformerWinding
GeneratingUnit
ReactiveCapabilityCurve
Curve
RegulationSchedule
Schedule
ConformLoad
NonConformLoad
Version
suitability
Season
test
Other facilities....DataRange etc.
Analog
Discrete
Power System Network Validation Rule
TopologyNode<->ConnectivityNodes,
Terminals
Relativity test
G e n e r a l TopologyNode<->ConnectivityNodes,
relationship Terminals BaseVoltage
a
n
d Conformance test
verification
ConnectivityNode,TopologyNode
ConnectivityNodeContainer
Relativity and conformance test
Check BusNameMarker
Node island is composed by isolated
buses, but determine
Connectivity.Terminal circuit breaker
status to verify if in operation
Network
composition Terminal.Connected<->TopologyNode
Test for processing suitability
verification
Invalid Network Topology
Loop Connection
Wrong Network Connection
MemberOf_PSR
measurable Device
Suitability and definition
test
MemberOf_PSR
measurable Device
Suitability and definition
test
Check
suitability
topology composition
of
Check BaseKV
Test for conformance of
acquired point
Check for duplicate
Test for isolated bus
Suitability
process
of
topology
Loop connection test