Energy management system application program interface (EMS-API) - Part 456: Solved power system state profiles

IEC 61970-456:2013 defines the subset of classes, class attributes, and roles from the CIM necessary to describe the result of state estimation, power flow and other similar applications that produce a steady-state solution of a power network, under a set of use cases which are included informatively in this standard. This standard is intended for two distinct audiences, data producers and data recipients, and may be read from those two perspectives. From the standpoint of model export software used by a data producer, the standard describes how a producer may describe an instance of a network case in order to make it available to some other program. From the standpoint of a consumer, the standard describes what that importing software must be able to interpret in order to consume solution cases.

Interface de programmation d'application pour système de gestion d'énergie (EMS-API) - Partie 456: Profils d'état de réseaux électriques résolus

La CEI 61970-456:2013 définit le sous-ensemble de classes, les attributs de classe et les rôles du CIM, nécessaires pour décrire le résultat de l'estimation d'état, du calcul de répartition et d'autres applications similaires produisant une solution en régime établi d'un réseau électrique dans un ensemble de cas d'utilisation inclus à titre informatif dans la présente norme. La présente norme vise deux publics différents, les producteurs de données et les utilisateurs de données. Elle peut être lue de ces deux points de vue. Du point de vue du logiciel d'exportation de modèles utilisé par un producteur de données, la présente norme présente la façon dont un producteur peut décrire une instance d'un cas de réseau pour le rendre accessible à un autre programme. Du point de vue du client, la présente norme décrit ce que ce logiciel d'importation doit être capable d'interpréter afin de pouvoir absorber les cas de solution du client.

General Information

Status
Published
Publication Date
28-Sep-2015
Current Stage
DELPUB - Deleted Publication
Start Date
19-Mar-2018
Completion Date
28-Apr-2017
Ref Project

Relations

Overview

IEC 61970-456:2013 - part of the EMS-API family - specifies the subset of the Common Information Model (CIM) classes, attributes and roles needed to represent solved power system state profiles (steady-state results from state estimation, power flow and similar applications). The standard describes how to export and import solution cases so that data producers (model exporters) and data recipients (importing software) can exchange solved network states reliably. It includes architecture, use cases, profile definitions and CIMXML examples.

Key topics and technical requirements

  • CIM subset for solutions: Defines concrete classes and attributes from the CIM required to describe state estimation and power flow results (topology and state variables).
  • Profiles: Includes profiles such as the Topology profile and StateVariables profile to modularize datasets used in EMS network analysis and planning power flow.
  • Data model and interfaces: Describes measurement, topology and state-variable interfaces and provides CIMXML examples for interoperability.
  • Instance modularization & model authority sets: Guidance on packaging model instances, merging producer and consumer datasets and maintaining authoritative model partitions.
  • Use cases: Formalizes common workflows (e.g., EMS state estimation, ENTSO‑E day‑ahead congestion forecasting, planning studies, harmonization of planning and operations models).
  • Amendments & data types: Incorporates updates to classes/attributes (for example, changes to SvPowerFlow attributes and SvVoltage.angle units) that affect consumers/producers of solution data.

Applications and who uses it

IEC 61970-456 is practical for organizations and tools that need to exchange or consume solved steady-state network data:

  • Transmission System Operators (TSOs) and Distribution System Operators (DSOs) - sharing state estimation or power flow cases across systems.
  • EMS and SCADA vendors - exporting solved cases in a standard CIM format for downstream applications.
  • Planning tools and market operators - ingesting solved profiles for day‑ahead congestion forecasts, contingency studies and harmonization between planning and operations.
  • Integration teams and system integrators - implementing model merge, dataset modularization and authoritative data exchange workflows.

Practical benefits include standardized interchange of solved network states, reduced custom mapping effort, improved tool interoperability and consistent representation of topology and state variables.

Related standards

  • IEC 61970 series (EMS-API), especially IEC 61970-301 (CIM baseline/model definitions).
  • Other CIM-based EMS/SCADA integration standards and relevant ENTSO‑E processes.

Keywords: IEC 61970-456, EMS-API, CIM, solved power system state profiles, state estimation, power flow, topology profile, state variables profile, CIMXML.

Standard
IEC 61970-456:2013+AMD1:2015 CSV - Energy management system application program interface (EMS-API) -Part 456: Solved power system state profiles Released:9/29/2015
English language
66 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
IEC 61970-456:2013 - Energy management system application program interface (EMS-API) - Part 456: Solved power system state profiles Released:5/7/2013 Isbn:9782832207567
English and French language
78 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


IEC 61970-456 ®
Edition 1.1 2015-09
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Energy management system application program interface (EMS-API) –
Part 456: Solved power system state profiles

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form

or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from

either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or

your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00

CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 15
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 60 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC 61970-456 ®
Edition 1.1 2015-09
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Energy management system application program interface (EMS-API) –

Part 456: Solved power system state profiles

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.200 ISBN 978-2-8322-2948-4

IEC 61970-456 ®
Edition 1.1 2015-09
CONSOLIDATED VERSION
REDLINE VERSION
colour
inside
Energy management system application program interface (EMS-API) –
Part 456: Solved power system state profiles

– 2 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Profile information . 8
4 Overview . 8
5 Use cases . 9
5.1 General . 9
5.2 EMS state estimation. 9
5.3 ENTSO-E Process: Day-ahead congestion forecast . 10
5.4 System planning studies process . 11
5.5 Harmonization of planning and operations models . 12
6 Architecture . 12
6.1 General . 12
6.2 Profile architecture . 12
6.3 Profiles and datasets for EMS network analysis . 15
6.4 Profiles and datasets in a planning power flow . 16
6.5 Model authority sets and instance level data modularization . 17
6.5.1 General . 17
6.5.2 EMS instance modularization . 17
6.5.3 Planning instance modularization . 18
6.6 Principles of instance modularization . 19
7 Applying the standard to business problems . 21
7.1 EMS network analysis integration with external consumers . 21
7.2 Planning network analysis integration with external consumers . 23
8 Data model with CIMXML examples . 24
8.1 Measurement interfaces 2 and 3 . 24
8.2 Topology interface 4 . 24
8.3 State variables interfaces 5a and 5b state estimation . 26
9 Topology profile . 30
9.1 General . 30
9.2 Concrete classes . 30
9.2.1 Terminal . 30
9.2.2 TopologicalNode . 31
9.2.3 Name . 31
9.2.4 NameType . 31
9.3 Abstract classes – IdentifiedObject . 32
10 StateVariables profile . 32
10.1 General . 32
10.2 Concrete classes . 32
10.2.1 TopologicalIsland . 32
10.2.2 SvInjection . 33
10.2.3 SvPowerFlow . 33
10.2.4 SvShortCircuit . 34
10.2.5 SvShuntCompensatorSections . 34

© IEC 2015
10.2.6 SvTapStep . 35
10.2.7 SvVoltage . 35
10.2.8 TopologicalNode . 35
10.3 Abstract classes . 35
10.3.1 StateVariable . 35
10.3.2 ActivePower . 36
10.3.3 AngleDegrees . 36
10.3.4 ApparentPower . 36
10.3.5 ReactivePower . 36
10.3.6 Voltage . 37
Bibliography . 38

Figure 1 – TSO sends a case to be merged with the overall model . 11
Figure 2 – Profile relationships . 13
Figure 3 – Instance example of the CIM connectivity model . 14
Figure 4 – EMS datasets by CIM profiles . 15
Figure 5 – Planning power flow datasets by CIM profile . 16
Figure 6 – State estimation case sequence . 17
Figure 7 – Instance modularization applied in an EMS . 18
Figure 8 – Instance modularization applied to planning power flow models . 19
Figure 9 – Model merge process . 20
Figure 10 – EMS datasets to an external client . 21
Figure 11 – EMS boundary dataset example . 22
Figure 12 – Bus-branch Integration architecture . 23
Figure 13 – Bus-branch modeling of bus coupler and line transfer . 23
Figure 14 – CIM topology model . 24
Figure 15 – Topology solution interface . 25
Figure 16 – CIM state variable solution model . 27
Figure 17 – State solution interface example . 29

Table 1 – Profiles defined in this document . 8

– 4 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 456: Solved power system state profiles
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
This consolidated version of the official IEC Standard and its amendment has been prepared
for user convenience.
IEC 61970-456 edition 1.1 contains the first edition (2013-05) [documents 57/1327/FDIS and
57/1342/RVD] and its amendment 1 (2015-09) [documents 57/1591/FDIS and 57/1620/RVD].
In this Redline version, a vertical line in the margin shows where the technical content is
modified by amendment 1. Additions are in green text, deletions are in strikethrough red text.
A separate Final version with all changes accepted is available in this publication.

© IEC 2015
International Standard IEC 61970-456 has been prepared by IEC technical committee 57:
Power systems management and associated information exchange.
61970 UML version CIM14. The amendment is based on IEC 61970-301 Edition 5 (2013) and
the 61970 UML version CIM15.
For the Topology profile Amendment 1 includes the following changes with respect to the
previous edition:
a) The classes Name and NameType classes have been added.
b) The class TopologicalNode has been extended with the role ConnectivityNodeContainer.
c) The attribute IdentifiedObject.description has been removed.
For the StateVariables profile this edition includes the following changes with respect to the
previous edition:
a) The role TopologicalIsland.ToplogicalNodes has been replaced by
ToplogicalNode.TopologicalIsland.
b) The documentation of attributes SvPowerFlow.p and SvPowerFlow.q has been updated.
c) The attribute SvShuntCompensatorSections.sections has been changed from Integer to
Float.
d) The attribute SvShuntCompensatorSections.continuousSections is removed.
e) The attribute SvTapStep.position is changed from Integer to Float.
f) The attribute SvTapStep.continuousPosition is removed.
g) The attribute SvVoltage.angle is changed from radians to degrees.
h) The data types have been elaborated.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of the IEC 61970 series, under the general title: Energy management system
application program interface (EMS-API), can be found on the IEC website.
The committee has decided that the contents of the base publication and its amendment will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
INTRODUCTION
This standard is one of several parts of the IEC 61970 series that defines common information
model (CIM) datasets exchanged between application programs in energy management
systems (EMS).
The IEC 61970-3xx series of documents specify the common information model (CIM). The
CIM is an abstract model that represents the objects in an electric utility enterprise typically
needed to model the operational aspects of a utility.
This standard is one of the IEC 61970-4xx series of component interface standards that
specify the semantic structure of data exchanged between components (or applications)
and/or made publicly available data by a component. This standard describes the payload that
would be carried if applications are communicating via a messaging system, but the standard
does not include the method of exchange, and therefore is applicable to a variety of exchange
implementations. This standard assumes and recommends that the exchanged data is
formatted in XML based on the resource description framework (RDF) schema as specified in
61970-552 CIM XML model exchange standard.
IEC 61970-456 specifies the profiles (or subsets) of the CIM required to describe a steady-
state solution of a power system case, such as is produced by power flow or state estimation
applications. It describes the solution with reference to a power system model that conforms
to IEC 61970-452 in this series of related standards. (Thus solution data does not repeat the
power system model information.) IEC 61970-456 is made up of several component profiles
that describe: topology derived from switch positions, measurement input (in the case of state
estimation), and the solution itself.

© IEC 2015
ENERGY MANAGEMENT SYSTEM APPLICATION
PROGRAM INTERFACE (EMS-API) –
Part 456: Solved power system state profiles

1 Scope
This part of IEC 61970 belongs to the IEC 61970-450 to IEC 61970-499 series that, taken as
a whole, defines at an abstract level the content and exchange mechanisms used for data
transmitted between control centers and/or control center components.
The purpose of this part of IEC 61970 is to rigorously define the subset of classes, class
attributes, and roles from the CIM necessary to describe the result of state estimation, power
flow and other similar applications that produce a steady-state solution of a power network,
under a set of use cases which are included informatively in this standard.
This standard is intended for two distinct audiences, data producers and data recipients, and
may be read from those two perspectives. From the standpoint of model export software used
by a data producer, the standard describes how a producer may describe an instance of a
network case in order to make it available to some other program. From the standpoint of a
consumer, the standard describes what that importing software must be able to interpret in
order to consume solution cases.
There are many different use cases for which use of this standard is expected and they differ
in the way that the standard will be applied in each case. Implementers should consider what
use cases they wish to cover in order to know the extent of different options they must cover.
As an example, this standard will be used in some cases to exchange starting conditions
rather than solved conditions, so if this is an important use case, it means that a consumer
application needs to be able to handle an unsolved state as well as one which has met some
solution criteria.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61970-452, Energy Management System Application Program Interface (EMS-API) –
Part 452: CIM Static Transmission Network Model Profiles
IEC 61970-453, Energy Management System Application Program Interface (EMS-API) –
Part 453: Diagram Layout Profile
IEC 61970-552, Energy Management System Application Program Interface (EMS-API) –
Part 552: CIM XML Model Exchange Format
—————————
To be published.
To be published.
– 8 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
3 Profile information
The profiles defined in this document are based on the UML version CIM14v14 CIM15v33.
The profiles are listed in Table 1.
Table 1 – Profiles defined in this document
Name Version URI Revision
date
StateVariables 1 2 http://iec.ch/TC57/61970-456/StateVariables/CIM14/1 2010-03-24
http://iec.ch/TC57/2011/61970-456/StateVariables/CIM15/2  2011-09-09
Topology 1 2 http://iec.ch/TC57/61970-456/Topology/CIM14/1 2010-03-24
http://iec.ch/TC57/2011/61970-456/Topology/CIM15/2 2011-09-09
4 Overview
This document describes an interface standard in which CIM/XML payloads are used to
transfer results created during typical steady-state network analysis processes (e.g. state
estimation or power flow solutions). Major requirements/objectives driving the design of this
standard include:
• Power flow solution algorithms and output are virtually the same whether run in operations
or planning contexts. State estimator output shares a common core with power flow. A
single standard is desired so as to minimize software development and enable use cases
that cross between environments.
• While some users of this standard might only be interested in the output state, the more
general situation is that users continue to perform follow-on analyses (e.g. voltage
stability) and require both the input on which the solution was based and the output result.
• Real life analytical processes often involve a series of solutions in which most of the input
data remains the same from one solution to the next, and the standard must support these
processes in a way that does not repeat data unnecessarily.
In order to meet these requirements, this standard depends on modularizing the potentially
voluminous overall input and output data into subsets that would each be realized as smaller,
separate CIM/XML payloads. An instance of one of these subsets is referred to herein as a
‘dataset’.
Two types of partitioning into datasets are utilized. In the first, the data is modularized
according to what kind of data is produced (which generally corresponds with what kind of
application produces the data). CIM ‘profiles’ (subsets of the complete CIM) define the
classes and attributes that make up of each kind of modularization. The second type of
partitioning is by ‘model authority set’ (MAS), which divides data into sets of object instances
according to which utility or entity in an interconnection is responsible for the data. This
partitioning occurs at the instance level and produces multiple datasets governed by the same
profile that combine to form the complete set of data for that profile. Understanding the
partitioning approach is critical to understanding how to use this standard to implement a
particular business scenario.
This standard is flexible and designed to satisfy a wide range of analytical scenarios in the
planning and operating business environments. We expect that where parties are using it to
collaborate in some business process, those parties will often want to create additional
business agreements that describe any restrictions and customizations of the standard that
are deemed necessary for their process. In most cases, these additional agreements will be
local agreements and will not be IEC industry standards.

© IEC 2015
The CIM/XML formatting of partitioned payloads is defined in IEC 61970-552. This method of
formatting has the useful characteristic that valid XML describing a complete model could be
achieved simply by concatenating the XML for each partition. Thus ‘merge’ and ‘extract’ of
pieces of the modeling require no separate ‘stitching’ instructions and is conceptually a very
simple process. IEC 61970-552 also describes how payload headers provide information as to
how payloads fit together.
How to read this document:
• Clause 5, "Use cases", gives examples of business problems that this standard is
intended to address.
• Clause 6, "Architecture", summarizes how the model partitioning works and describes how
the parts described in this document work with parts described in other
IEC 61970 series standards.
• Clause 7, "Applying the standard to business problems", describes how to go about
applying the standard to your particular business problem.
• Clause 9, "Topology profile" defines the kinds of datasets controlled by this standard.
(This section is auto-generated from CIMTool and is where you see the CIM modeling
detail.)
5 Use cases
5.1 General
Clause 5 presents some of the business problems that were considered in the design of this
standard and discusses how the standard is expected to provide value to the industry.
5.2 EMS state estimation
EMS operations typically run state estimator automatically, usually triggered either by
occurrence of certain events or by a time period. Periods of 10 min or more used to be the
norm, but currently many state estimator installations are running with much shorter periods
approaching 5 s and nearly the same periodicity as SCADA (supervisory control and data
acquisition) and consequently rendering event based triggering of state estimator important.
The state estimator’s job is to create the best view of the state of the system, based on the
latest available snapshot of the SCADA measurements. The resulting steady state solution of
the power system is used as input data for a number of important functions:
• A traditional EMS is usually configured by the EMS vendor with contingency analysis
running on the result of the state estimator. While a standard is usually not necessary for
applications from the same vendor, there is industry interest in being able to run alternate
algorithms for either state estimation or contingency analysis.
• A growing number of other analytical functions that were not originally part of the EMS are
also using the state estimator result as the starting point for real-time analysis (e.g.
voltage stability).
• Where market systems exist, they normally require real-time exchange of state estimation
result from the EMS to the market system, and these systems often are supplied by
different vendors.
• Users are interested in being able to connect advanced user interface and situation
awareness modules from different vendors into an EMS, and these modules need to
acquire state estimator data.
• It is desirable to be able to run historical analysis as well as real-time analysis from state
estimator results. This requires estimator results can be archived efficiently, and users
shall be able to import results into network planning tool environments that are normally
not supplied by the EMS vendor.

– 10 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
All of these situations require an efficient standard method of producing state estimator
results and making them available to other applications.
If the complete set of input data and output data were stored for a large interconnection model
running on, say, a 10 s period, it would produce a great deal of data and pose a considerable
challenge to any real-time exchange. However, there are some obvious characteristics of this
problem that may be exploited to reduce the data burden.
• The network model is by far the largest part of the data. It changes infrequently and when
it does change, the changes are a small set of data. Only the initialization of the system
actually requires a complete large model.
• The topology of the system changes more frequently (when switching devices change
position), but still is relatively infrequent and again the changes are small compared to the
complete topology.
• Analog measurement input changes completely each run, but in many of the use cases,
this data is not required by the consumer. Analog data may also usually be approximated
from an analog history if it is not stored.
• Solution state variables change at each run.
What is required of the standard in order for each kind of business exchange to take
advantage of these characteristics is that the network model and the topology may be
updated only when they change. It is also valuable if updates can be represented in
incremental form, rather than by re-transmission of a full model. Consumers of the data then
are able to initialize themselves with a full network model and topology when they start, but
only receive updates if there were changes. This reduces the data volume problem from
Gbytes/solution and Tbytes/day to a more manageable Mbytes/solution and Gbytes/day.
5.3 ENTSO-E Process: Day-ahead congestion forecast
A daily analytical operational process called day ahead congestion forecast (DACF) is
currently applied in the ENTSO-E regional group continental Europe. In this process,
• each TSO prepares a power flow case covering exactly its own territory representing each
hour of the following day (based on day-ahead market outcomes). These cases are
transferred to a central server;
• the full set of submitted cases may be checked for mutual compatibility. (i.e. do the
boundary exchange conditions match);
• once all cases are submitted, each TSO downloads from the central server the cases
posted by their neighboring TSOs. These are combined with their own models to form a
set of study models on which they can analyze the congestion in their region for the next
day;
• congestion result cases may be exchanged among TSOs, as the situation warrants.
This work is carried out primarily with planning tools running bus-branch models (although an
obvious possible variation on the process would be to generate cases with EMS tools).
Even though the DACF process is not a real-time process like state estimation, it is quite
similar in that a sequence of cases is produced representing periodic intervals. The solution
values will change at each case, but the network model will change rarely and the topology
will change occasionally. Conserving file size is a concern, and that concern is addressed if
the standard allows the network model and topology to be exchanged incrementally.
DACF raises another set of requirements, however. Unlike the state estimator scenarios,
which feature complete transfer of a solution, the DACF involves a lot of merging and
extracting of pieces of solutions. In Figure 1, TSO A runs power flows to develop a picture of
—————————
European network of transmission system operator-electricity.

© IEC 2015
its territory for the following day. This would be done with models that include representations
of neighboring TSOs. They shall post, however, only the part of the model representing their
own territory, and this shall be a stand-alone solved power flow. (In ENTSO-E, boundaries
between TSOs are, by agreement, always at the mid-point of tie-lines, and single TSO cases
are formed with equivalent injections at each tie-line mid-point.) At the central site, or at any
TSO, submitted internal cases shall be able to be reliably and automatically re-combined to
form models with coverage appropriate to whatever task is at hand.
DACF merged model
Solving      complete     model
TSO A Bndry TSO B
Bndry TSO NN
authority authority
TSO A
authority
export
TSO A Bndry
authority
Inj
TSO A
TSO A Bndry TSO B
authority authority
Inj
IEC  875/13
Figure 1 – TSO sends a case to be merged with the overall model
The octagons in Figure 1 represent datasets. The colors of the sets have the following
meanings:
• magenta - data described by state variables profile;
• green - data described by the topology profile;
• blue - data described by the equipment profile.
Refer also to Figure 2.
5.4 System planning studies process
There are many synchronous interconnections worldwide (such as ENTSO-E discussed
above) that require cooperative construction of future models by its members in order to
support planning of the interconnection. Typically, “base cases” are constructed representing
future time frames by combining submittals from each interconnection member, a process that
closely resembles that depicted in Figure 1 for operational analysis. Instead of day-ahead, a
planning case may represent years ahead; instead of daily update, a planning case must be
reconstructed as plans change; instead of a known functioning power system, a planning case
is not real yet. But in terms of process and in terms of data requirements, the assembly of
base cases for planning is the same as in Figure 1, and it is the objective of this standard to

– 12 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
support both construction of base cases and the exchange of solution cases that necessarily
occurs among members during the analysis based on these cases.
5.5 Harmonization of planning and operations models
Network analysis is universally carried out with what is known as ‘bus-branch’ modeling,
where most or all zero impedance switching devices are eliminated to form logical buses, and
where load, generation and regulation parameters have been selected for a single point in
time. However, there are significant differences in the way that network models are handled in
operations and planning contexts.
• Planners tend to work extensively with a few selected bus-branch ‘cases’. For example,
they will set up the conditions that represent a summer peak load for a future network, and
then study variations on that case. Planning tools typically provide for direct entry of buses
and single point in time parameters.
• Operations environments (EMS) require the ability to set up bus-branch cases
automatically for any point in time. They typically begin with a network model with
switching detail, and with schedules for time-varying parameters – and then the EMS will
have applications that compute the bus topology from switch status, and compute specific
parameters from time-varying schedules.
Our goal here is to create a standard that can support the following situations effectively:
i) power system modeling where planning and operations are managing their models
independently;
j) consolidated modeling, where a single source supports both planning and operations;
k) initialization of planning cases from operations results, regardless of whether modeling is
consolidated;
l) initialization of operations models from planning models;
m) construction of external operations models from models of neighboring systems;
n) construction of interconnection planning models from models of the constituent systems.
Most of the requirements derived from the above list bear more strongly on the static
modeling of the power network, which is covered in IEC 61970-452. From the standpoint of
solution exchange, it is simply important to remain consistent with all these requirements.
6 Architecture
6.1 General
The main architectural feature of this standard is data modularization:
• modularization by data model (CIM) profiles (usually reflects the application that produces
the data);
• modularization by grouping of instance data into model authority sets (MAS) (usually
reflects regional responsibility).
6.2 Profile architecture
Figure 2 shows the profiles that are covered by the IEC 61970-450 to 61970-499 series
specifications and depicts the relationships between them. The profiles are defined in
different IEC 61970-450 specifications where each specification defines a group of profiles:
• Static network model profiles defined in IEC 61970-452
– equipment profile. The static modeling information describing power system physical
elements and their electrical connections;
– schedules profile. The time-varying specifications for power system quantities;

© IEC 2015
– measurement specification profile that defines power system measurements.
• Schematic display layout exchange profiles defined in IEC 61970-453
– schematic layout exchange profile. Describe the elements of schematic or geographic
displays that typically shall be amended when new elements are added to a network
model.
• Steady-state solution profiles defined in IEC 61970-456 (this document)
– topology profile. The bus-branch result as is produced by a topology processor;
– state variables profile. The result of a state estimator or power flow, or the starting
conditions of state variables;
– discrete (status) measurement profile. A set of switch states at a given points in time;
– analog measurement profile. A set of analog measurements at a given points in time.

61970-456 61970-451
profiles profiles
Discrete
State
measurements
variables
profile
profile
Analog
Topology
measurements
profile
profile
61970-452
profiles
Equipment
model
profile
61970-453
Schematic
profiles
layouts
profile
IEC  876/13
Figure 2 – Profile relationships
These modules satisfy the needs of network analysis business processes used in operations
settings (with node-breaker models), in planning settings (with bus-branch models), and for
transfers between operations and planning.
In Figure 2, an arrow between profiles indicates that there are relationships defined between
classes in the two profiles. The directionality indicates that classes in the “from” profile
depend on classes in the “to” profile. For data this means that “from” class data refers to or
depends on “to” class data. Example: an instance of an equipment model may have many
state variable instances that refer to that equipment model.
In IT-systems, datasets corresponding to the profiles in Figure 2, are exchanged between
functions and/or applications. Some examples of applications and their dataset exchange are
described below.
– 14 – IEC 61970-456:2013+AMD1:2015 CSV
© IEC 2015
The equipment model has detailed substation connectivity based on the ConnectivityNode
and terminal classes, refer to Figure 3. The terminal class is central in that it is used by the
topology, state variables and schematic layout profiles as well as to associate
ConnectivityNodes with ConductingEquipment. Hence the Terminal is an integral part of the
equipment model.
It would be possible to create a connectivity profile by factoring out the ConnectivityNode and
the Terminal.ConnectivityNode reference. This then introduces complexity and data
duplication that mitigate the creation of the connectivity profile.
Topology profile State variable profile
Topological
SvStatus
node
Conducting Connectivity
Terminal
equipment node
Equipment model
profile
DiagramObject
Schematic layout profile
IEC  877/13
Figure 3 – Instance example of the CIM connectivity model

© IEC 2015
6.3 Profiles and datasets for EMS network analysis
Analog
measurements
SCADA
Discrete
measurements
Topology
Data Equipment Topology
State
State
model
State
modeler processor
variables
estimator
variables
Any
State
power flow
variables
application
Schedule
Schedule
updater values
IEC  878/13
Figure 4 – EMS datasets by CIM profiles
Figure 4 shows how datasets governed by the different CIM profiles that are produced in an
EMS. The octagons in the EMS show datasets that are described by the profiles. The rounded
octagons represent typical application modules. Data typically flows from producers to
consumers as follows. The modeler application produces the equipment model.
The SCADA application uses equipment measurement model as input and produces,
periodically, new analog and discrete (e.g. status) measurements.
The topology application uses equipment model from the modeler and discrete measurements
from SCADA to determine the starting conditions for a state estimation algorithm, which
results in topology and state variable datasets.
The state estimation application uses the analog measurements, the equipment model, the
topology and the state variable datasets as input and produces the solved state expressed as
a state variable dataset. (Note here the same profile, state variables, governs a dataset used
for input and a different dataset containing the solution.)
Any power flow based application, e.g. contingency analysis, uses equipment model, topology
and solved state
...


IEC 61970-456 ®
Edition 1.0 2013-05
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Energy management system application program interface (EMS-API) –
Part 456: Solved power system state profiles

Interface de programmation d'application pour système de gestion d'énergie
(EMS-API) –
Partie 456: Profils d'état de réseaux électriques résolus

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form

or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,

please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les

microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.

Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette

publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

Useful links:
IEC publications search - www.iec.ch/searchpub Electropedia - www.electropedia.org
The advanced search enables you to find IEC publications The world's leading online dictionary of electronic and
by a variety of criteria (reference number, text, technical electrical terms containing more than 30 000 terms and
committee,…). definitions in English and French, with equivalent terms in
It also gives information on projects, replaced and additional languages. Also known as the International
withdrawn publications. Electrotechnical Vocabulary (IEV) on-line.

IEC Just Published - webstore.iec.ch/justpublished Customer Service Centre - webstore.iec.ch/csc
Stay up to date on all new IEC publications. Just Published If you wish to give us your feedback on this publication
details all new publications released. Available on-line and or need further assistance, please contact the
also once a month by email. Customer Service Centre: csc@iec.ch.

A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.

Liens utiles:
Recherche de publications CEI - www.iec.ch/searchpub Electropedia - www.electropedia.org
La recherche avancée vous permet de trouver des Le premier dictionnaire en ligne au monde de termes
publications CEI en utilisant différents critères (numéro de électroniques et électriques. Il contient plus de 30 000
référence, texte, comité d’études,…). termes et définitions en anglais et en français, ainsi que
Elle donne aussi des informations sur les projets et les les termes équivalents dans les langues additionnelles.
publications remplacées ou retirées. Egalement appelé Vocabulaire Electrotechnique
International (VEI) en ligne.
Just Published CEI - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications de la CEI.
Just Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur
Disponible en ligne et aussi une fois par mois par email. cette publication ou si vous avez des questions
contactez-nous: csc@iec.ch.
IEC 61970-456 ®
Edition 1.0 2013-05
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Energy management system application program interface (EMS-API) –

Part 456: Solved power system state profiles

Interface de programmation d'application pour système de gestion d'énergie

(EMS-API) –
Partie 456: Profils d'état de réseaux électriques résolus

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX W
ICS 33.200 ISBN 978-2-83220-756-7

– 2 – 61970-456 © IEC:2013
CONTENTS
FOREWORD . 4

INTRODUCTION . 6

1 Scope . 7

2 Normative references . 7

3 Profile information . 8

4 Overview . 8

5 Use cases . 9
5.1 General . 9
5.2 EMS state estimation. 9
5.3 ENTSO-E Process: Day-ahead congestion forecast . 10
5.4 System planning studies process . 11
5.5 Harmonization of planning and operations models . 12
6 Architecture . 12
6.1 General . 12
6.2 Profile architecture . 12
6.3 Profiles and datasets for EMS network analysis . 15
6.4 Profiles and datasets in a planning power flow . 16
6.5 Model authority sets and instance level data modularization . 17
6.5.1 General . 17
6.5.2 EMS instance modularization . 17
6.5.3 Planning instance modularization . 18
6.6 Principles of instance modularization . 19
7 Applying the standard to business problems . 21
7.1 EMS network analysis integration with external consumers . 21
7.2 Planning network analysis integration with external consumers . 23
8 Data model with CIMXML examples . 24
8.1 Measurement interfaces 2 and 3 . 24
8.2 Topology interface 4 . 24
8.3 State variables interfaces 5a and 5b state estimation . 26
9 Topology profile . 30
9.1 General . 30

9.2 Concrete classes . 30
9.2.1 Terminal . 30
9.2.2 TopologicalNode . 31
9.3 Abstract classes – IdentifiedObject . 31
10 StateVariables profile . 32
10.1 General . 32
10.2 Concrete classes . 32
10.2.1 TopologicalIsland . 32
10.2.2 SvInjection . 32
10.2.3 SvPowerFlow . 33
10.2.4 SvShortCircuit . 33
10.2.5 SvShuntCompensatorSections . 33
10.2.6 SvTapStep . 34
10.2.7 SvVoltage . 34

61970-456 © IEC:2013 – 3 –
10.3 Abstract classes . 34

10.3.1 StateVariable . 34

10.3.2 ActivePower . 34

10.3.3 AngleRadians . 35

10.3.4 ApparentPower . 35

10.3.5 ReactivePower . 35

10.3.6 Voltage . 35

Bibliography . 36

Figure 1 – TSO sends a case to be merged with the overall model . 11
Figure 2 – Profile relationships . 13
Figure 3 – Instance example of the CIM connectivity model . 14
Figure 4 – EMS datasets by CIM profiles . 15
Figure 5 – Planning power flow datasets by CIM profile . 16
Figure 6 – State estimation case sequence . 17
Figure 7 – Instance modularization applied in an EMS . 18
Figure 8 – Instance modularization applied to planning power flow models . 19
Figure 9 – Model merge process . 20
Figure 10 – EMS datasets to an external client . 21
Figure 11 – EMS boundary dataset example . 22
Figure 12 – Bus-branch Integration architecture . 23
Figure 13 – Bus-branch modeling of bus coupler and line transfer . 23
Figure 14 – CIM topology model . 24
Figure 15 – Topology solution interface . 25
Figure 16 – CIM state variable solution model . 27
Figure 17 – State solution interface example . 29

Table 1 – Profiles defined in this document . 8

– 4 – 61970-456 © IEC:2013
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
ENERGY MANAGEMENT SYSTEM APPLICATION

PROGRAM INTERFACE (EMS-API) –
Part 456: Solved power system state profiles

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

International Standard IEC 61970-456 has been prepared by IEC technical committee 57:
Power systems management and associated information exchange.
The text of this standard is based on the following documents:
FDIS Report on voting
57/1327/FDIS 57/1342/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of the IEC 61970 series, under the general title: Energy management system
application program interface (EMS-API), can be found on the IEC website.

61970-456 © IEC:2013 – 5 –
The committee has decided that the contents of this publication will remain unchanged until

the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data

related to the specific publication. At this date, the publication will be

• reconfirmed,
• withdrawn,
• replaced by a revised edition, or

• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – 61970-456 © IEC:2013
INTRODUCTION
This standard is one of several parts of the IEC 61970 series that defines common information

model (CIM) datasets exchanged between application programs in energy management

systems (EMS).
The IEC 61970-3xx series of documents specify the common information model (CIM). The

CIM is an abstract model that represents the objects in an electric utility enterprise typically

needed to model the operational aspects of a utility.

This standard is one of the IEC 61970-4xx series of component interface standards that

specify the semantic structure of data exchanged between components (or applications)
and/or made publicly available data by a component. This standard describes the payload that
would be carried if applications are communicating via a messaging system, but the standard
does not include the method of exchange, and therefore is applicable to a variety of exchange
implementations. This standard assumes and recommends that the exchanged data is
formatted in XML based on the resource description framework (RDF) schema as specified in
61970-552 CIM XML model exchange standard.
IEC 61970-456 specifies the profiles (or subsets) of the CIM required to describe a steady-
state solution of a power system case, such as is produced by power flow or state estimation
applications. It describes the solution with reference to a power system model that conforms
to IEC 61970-452 in this series of related standards. (Thus solution data does not repeat the
power system model information.) IEC 61970-456 is made up of several component profiles
that describe: topology derived from switch positions, measurement input (in the case of state
estimation), and the solution itself.

61970-456 © IEC:2013 – 7 –
ENERGY MANAGEMENT SYSTEM APPLICATION

PROGRAM INTERFACE (EMS-API) –
Part 456: Solved power system state profiles

1 Scope
This part of IEC 61970 belongs to the IEC 61970-450 to IEC 61970-499 series that, taken as
a whole, defines at an abstract level the content and exchange mechanisms used for data
transmitted between control centers and/or control center components.
The purpose of this part of IEC 61970 is to rigorously define the subset of classes, class
attributes, and roles from the CIM necessary to describe the result of state estimation, power
flow and other similar applications that produce a steady-state solution of a power network,
under a set of use cases which are included informatively in this standard.
This standard is intended for two distinct audiences, data producers and data recipients, and
may be read from those two perspectives. From the standpoint of model export software used
by a data producer, the standard describes how a producer may describe an instance of a
network case in order to make it available to some other program. From the standpoint of a
consumer, the standard describes what that importing software must be able to interpret in
order to consume solution cases.
There are many different use cases for which use of this standard is expected and they differ
in the way that the standard will be applied in each case. Implementers should consider what
use cases they wish to cover in order to know the extent of different options they must cover.
As an example, this standard will be used in some cases to exchange starting conditions
rather than solved conditions, so if this is an important use case, it means that a consumer
application needs to be able to handle an unsolved state as well as one which has met some
solution criteria.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61970-452, Energy Management System Application Program Interface (EMS-API) –
Part 452: CIM Static Transmission Network Model Profiles
IEC 61970-453, Energy Management System Application Program Interface (EMS-API) –
Part 453: Diagram Layout Profile
IEC 61970-552, Energy Management System Application Program Interface (EMS-API) –
Part 552: CIM XML Model Exchange Format
—————————
To be published.
To be published.
– 8 – 61970-456 © IEC:2013
3 Profile information
The profiles defined in this document are based on the UML version CIM14v14.

The profiles are listed in Table 1.

Table 1 – Profiles defined in this document

Name Version URI Revision
date
StateVariables 1 http://iec.ch/TC57/61970-456/StateVariables/CIM14/1 2010-03-24

Topology 1 http://iec.ch/TC57/61970-456/Topology/CIM14/1 2010-03-24

4 Overview
This document describes an interface standard in which CIM/XML payloads are used to
transfer results created during typical steady-state network analysis processes (e.g. state
estimation or power flow solutions). Major requirements/objectives driving the design of this
standard include:
• Power flow solution algorithms and output are virtually the same whether run in operations
or planning contexts. State estimator output shares a common core with power flow. A
single standard is desired so as to minimize software development and enable use cases
that cross between environments.
• While some users of this standard might only be interested in the output state, the more
general situation is that users continue to perform follow-on analyses (e.g. voltage
stability) and require both the input on which the solution was based and the output result.
• Real life analytical processes often involve a series of solutions in which most of the input
data remains the same from one solution to the next, and the standard must support these
processes in a way that does not repeat data unnecessarily.
In order to meet these requirements, this standard depends on modularizing the potentially
voluminous overall input and output data into subsets that would each be realized as smaller,
separate CIM/XML payloads. An instance of one of these subsets is referred to herein as a
‘dataset’.
Two types of partitioning into datasets are utilized. In the first, the data is modularized
according to what kind of data is produced (which generally corresponds with what kind of
application produces the data). CIM ‘profiles’ (subsets of the complete CIM) define the

classes and attributes that make up of each kind of modularization. The second type of
partitioning is by ‘model authority set’ (MAS), which divides data into sets of object instances
according to which utility or entity in an interconnection is responsible for the data. This
partitioning occurs at the instance level and produces multiple datasets governed by the same
profile that combine to form the complete set of data for that profile. Understanding the
partitioning approach is critical to understanding how to use this standard to implement a
particular business scenario.
This standard is flexible and designed to satisfy a wide range of analytical scenarios in the
planning and operating business environments. We expect that where parties are using it to
collaborate in some business process, those parties will often want to create additional
business agreements that describe any restrictions and customizations of the standard that
are deemed necessary for their process. In most cases, these additional agreements will be
local agreements and will not be IEC industry standards.

61970-456 © IEC:2013 – 9 –
The CIM/XML formatting of partitioned payloads is defined in IEC 61970-552. This method of
formatting has the useful characteristic that valid XML describing a complete model could be

achieved simply by concatenating the XML for each partition. Thus ‘merge’ and ‘extract’ of

pieces of the modeling require no separate ‘stitching’ instructions and is conceptually a very

simple process. IEC 61970-552 also describes how payload headers provide information as to

how payloads fit together.
How to read this document:
• Clause 5, "Use cases", gives examples of business problems that this standard is

intended to address.
• Clause 6, "Architecture", summarizes how the model partitioning works and describes how
the parts described in this document work with parts described in other
IEC 61970 series standards.
• Clause 7, "Applying the standard to business problems", describes how to go about
applying the standard to your particular business problem.
• Clause 9, "Topology profile" defines the kinds of datasets controlled by this standard.
(This section is auto-generated from CIMTool and is where you see the CIM modeling
detail.)
5 Use cases
5.1 General
Clause 5 presents some of the business problems that were considered in the design of this
standard and discusses how the standard is expected to provide value to the industry.
5.2 EMS state estimation
EMS operations typically run state estimator automatically, usually triggered either by
occurrence of certain events or by a time period. Periods of 10 min or more used to be the
norm, but currently many state estimator installations are running with much shorter periods
approaching 5 s and nearly the same periodicity as SCADA (supervisory control and data
acquisition) and consequently rendering event based triggering of state estimator important.
The state estimator’s job is to create the best view of the state of the system, based on the
latest available snapshot of the SCADA measurements. The resulting steady state solution of
the power system is used as input data for a number of important functions:
• A traditional EMS is usually configured by the EMS vendor with contingency analysis
running on the result of the state estimator. While a standard is usually not necessary for

applications from the same vendor, there is industry interest in being able to run alternate
algorithms for either state estimation or contingency analysis.
• A growing number of other analytical functions that were not originally part of the EMS are
also using the state estimator result as the starting point for real-time analysis (e.g.
voltage stability).
• Where market systems exist, they normally require real-time exchange of state estimation
result from the EMS to the market system, and these systems often are supplied by
different vendors.
• Users are interested in being able to connect advanced user interface and situation
awareness modules from different vendors into an EMS, and these modules need to
acquire state estimator data.
• It is desirable to be able to run historical analysis as well as real-time analysis from state
estimator results. This requires estimator results can be archived efficiently, and users
shall be able to import results into network planning tool environments that are normally
not supplied by the EMS vendor.

– 10 – 61970-456 © IEC:2013
All of these situations require an efficient standard method of producing state estimator

results and making them available to other applications.

If the complete set of input data and output data were stored for a large interconnection model

running on, say, a 10 s period, it would produce a great deal of data and pose a considerable

challenge to any real-time exchange. However, there are some obvious characteristics of this

problem that may be exploited to reduce the data burden.

• The network model is by far the largest part of the data. It changes infrequently and when
it does change, the changes are a small set of data. Only the initialization of the system
actually requires a complete large model.

• The topology of the system changes more frequently (when switching devices change
position), but still is relatively infrequent and again the changes are small compared to the
complete topology.
• Analog measurement input changes completely each run, but in many of the use cases,
this data is not required by the consumer. Analog data may also usually be approximated
from an analog history if it is not stored.
• Solution state variables change at each run.
What is required of the standard in order for each kind of business exchange to take
advantage of these characteristics is that the network model and the topology may be
updated only when they change. It is also valuable if updates can be represented in
incremental form, rather than by re-transmission of a full model. Consumers of the data then
are able to initialize themselves with a full network model and topology when they start, but
only receive updates if there were changes. This reduces the data volume problem from
Gbytes/solution and Tbytes/day to a more manageable Mbytes/solution and Gbytes/day.
5.3 ENTSO-E Process: Day-ahead congestion forecast
A daily analytical operational process called day ahead congestion forecast (DACF) is
currently applied in the ENTSO-E regional group continental Europe. In this process,
• each TSO prepares a power flow case covering exactly its own territory representing each
hour of the following day (based on day-ahead market outcomes). These cases are
transferred to a central server;
• the full set of submitted cases may be checked for mutual compatibility. (i.e. do the
boundary exchange conditions match);
• once all cases are submitted, each TSO downloads from the central server the cases
posted by their neighboring TSOs. These are combined with their own models to form a
set of study models on which they can analyze the congestion in their region for the next
day;
• congestion result cases may be exchanged among TSOs, as the situation warrants.
This work is carried out primarily with planning tools running bus-branch models (although an
obvious possible variation on the process would be to generate cases with EMS tools).
Even though the DACF process is not a real-time process like state estimation, it is quite
similar in that a sequence of cases is produced representing periodic intervals. The solution
values will change at each case, but the network model will change rarely and the topology
will change occasionally. Conserving file size is a concern, and that concern is addressed if
the standard allows the network model and topology to be exchanged incrementally.
DACF raises another set of requirements, however. Unlike the state estimator scenarios,
which feature complete transfer of a solution, the DACF involves a lot of merging and
extracting of pieces of solutions. In Figure 1, TSO A runs power flows to develop a picture of
—————————
European network of transmission system operator-electricity.

61970-456 © IEC:2013 – 11 –
its territory for the following day. This would be done with models that include representations

of neighboring TSOs. They shall post, however, only the part of the model representing their

own territory, and this shall be a stand-alone solved power flow. (In ENTSO-E, boundaries

between TSOs are, by agreement, always at the mid-point of tie-lines, and single TSO cases

are formed with equivalent injections at each tie-line mid-point.) At the central site, or at any

TSO, submitted internal cases shall be able to be reliably and automatically re-combined to

form models with coverage appropriate to whatever task is at hand.

DACF merged model
Solving      complete     model
TSO A Bndry TSO B
Bndry TSO NN
authority authority
TSO A
authority
export
TSO A Bndry
authority
Inj
TSO A
TSO A Bndry TSO B
authority authority
Inj
IEC  875/13
Figure 1 – TSO sends a case to be merged with the overall model
The octagons in Figure 1 represent datasets. The colors of the sets have the following
meanings:
• magenta - data described by state variables profile;

• green - data described by the topology profile;
• blue - data described by the equipment profile.
Refer also to Figure 2.
5.4 System planning studies process
There are many synchronous interconnections worldwide (such as ENTSO-E discussed
above) that require cooperative construction of future models by its members in order to
support planning of the interconnection. Typically, “base cases” are constructed representing
future time frames by combining submittals from each interconnection member, a process that
closely resembles that depicted in Figure 1 for operational analysis. Instead of day-ahead, a
planning case may represent years ahead; instead of daily update, a planning case must be
reconstructed as plans change; instead of a known functioning power system, a planning case
is not real yet. But in terms of process and in terms of data requirements, the assembly of
base cases for planning is the same as in Figure 1, and it is the objective of this standard to

– 12 – 61970-456 © IEC:2013
support both construction of base cases and the exchange of solution cases that necessarily

occurs among members during the analysis based on these cases.

5.5 Harmonization of planning and operations models

Network analysis is universally carried out with what is known as ‘bus-branch’ modeling,

where most or all zero impedance switching devices are eliminated to form logical buses, and

where load, generation and regulation parameters have been selected for a single point in

time. However, there are significant differences in the way that network models are handled in
operations and planning contexts.

• Planners tend to work extensively with a few selected bus-branch ‘cases’. For example,

they will set up the conditions that represent a summer peak load for a future network, and
then study variations on that case. Planning tools typically provide for direct entry of buses
and single point in time parameters.
• Operations environments (EMS) require the ability to set up bus-branch cases
automatically for any point in time. They typically begin with a network model with
switching detail, and with schedules for time-varying parameters – and then the EMS will
have applications that compute the bus topology from switch status, and compute specific
parameters from time-varying schedules.
Our goal here is to create a standard that can support the following situations effectively:
a) power system modeling where planning and operations are managing their models
independently;
b) consolidated modeling, where a single source supports both planning and operations;
c) initialization of planning cases from operations results, regardless of whether modeling is
consolidated;
d) initialization of operations models from planning models;
e) construction of external operations models from models of neighboring systems;
f) construction of interconnection planning models from models of the constituent systems.
Most of the requirements derived from the above list bear more strongly on the static
modeling of the power network, which is covered in IEC 61970-452. From the standpoint of
solution exchange, it is simply important to remain consistent with all these requirements.
6 Architecture
6.1 General
The main architectural feature of this standard is data modularization:

• modularization by data model (CIM) profiles (usually reflects the application that produces
the data);
• modularization by grouping of instance data into model authority sets (MAS) (usually
reflects regional responsibility).
6.2 Profile architecture
Figure 2 shows the profiles that are covered by the IEC 61970-450 to 61970-499 series
specifications and depicts the relationships between them. The profiles are defined in
different IEC 61970-450 specifications where each specification defines a group of profiles:
• Static network model profiles defined in IEC 61970-452
– equipment profile. The static modeling information describing power system physical
elements and their electrical connections;
– schedules profile. The time-varying specifications for power system quantities;

61970-456 © IEC:2013 – 13 –
– measurement specification profile that defines power system measurements.

• Schematic display layout exchange profiles defined in IEC 61970-453

– schematic layout exchange profile. Describe the elements of schematic or geographic

displays that typically shall be amended when new elements are added to a network

model.
• Steady-state solution profiles defined in IEC 61970-456 (this document)

– topology profile. The bus-branch result as is produced by a topology processor;

– state variables profile. The result of a state estimator or power flow, or the starting
conditions of state variables;

– discrete (status) measurement profile. A set of switch states at a given points in time;
– analog measurement profile. A set of analog measurements at a given points in time.

61970-456 61970-451
profiles profiles
Discrete
State
measurements
variables
profile
profile
Analog
Topology
measurements
profile
profile
61970-452
profiles
Equipment
model
profile
61970-453
Schematic
profiles
layouts
profile
IEC  876/13
Figure 2 – Profile relationships

These modules satisfy the needs of network analysis business processes used in operations
settings (with node-breaker models), in planning settings (with bus-branch models), and for
transfers between operations and planning.
In Figure 2, an arrow between profiles indicates that there are relationships defined between
classes in the two profiles. The directionality indicates that classes in the “from” profile
depend on classes in the “to” profile. For data this means that “from” class data refers to or
depends on “to” class data. Example: an instance of an equipment model may have many
state variable instances that refer to that equipment model.
In IT-systems, datasets corresponding to the profiles in Figure 2, are exchanged between
functions and/or applications. Some examples of applications and their dataset exchange are
described below.
– 14 – 61970-456 © IEC:2013
The equipment model has detailed substation connectivity based on the ConnectivityNode
and terminal classes, refer to Figure 3. The terminal class is central in that it is used by the

topology, state variables and schematic layout profiles as well as to associate

ConnectivityNodes with ConductingEquipment. Hence the Terminal is an integral part of the

equipment model.
It would be possible to create a connectivity profile by factoring out the ConnectivityNode and

the Terminal.ConnectivityNode reference. This then introduces complexity and data

duplication that mitigate the creation of the connectivity profile.

Topology profile State variable profile
Topological
SvStatus
node
Conducting Connectivity
Terminal
equipment node
Equipment model
profile
DiagramObject
Schematic layout profile
IEC  877/13
Figure 3 – Instance example of the CIM connectivity model

61970-456 © IEC:2013 – 15 –
6.3 Profiles and datasets for EMS network analysis

Analog
measurements
SCADA
Discrete
measurements
Topology
Data Equipment Topology
State
model State
modeler processor State
variables
estimator variables
Any
State
power flow
variables
application
Schedule
Schedule
values
updater
IEC  878/13
Figure 4 – EMS datasets by CIM profiles
Figure 4 shows how datasets governed by the different CIM profiles that are produced in an
EMS. The octagons in the EMS show datasets that are described by the profiles. The rounded
octagons represent typical application modules. Data typically flows from producers to
consumers as follows. The modeler application produces the equipment model.
The SCADA application uses equipment measurement model as input and produces,
periodically, new analog and discrete (e.g. status) measurements.
The topology application uses equipment model from the modeler and discrete measurements

from SCADA to determine the starting conditions for a state estimation algorithm, which
results in topology and state variable datasets.
The state estimation application uses the analog measurements, the equipment model, the
topology and the state variable datasets as input and produces the solved state expressed as
a state variable dataset. (Note here the same profile, state variables, governs a dataset used
for input and a different dataset containing the solution.)
Any power flow based application, e.g. contingency analysis, uses equipment model, topology
and solved state variables to produce multiple contingency solutions also expressed as state
variables.
– 16 – 61970-456 © IEC:2013
The scheduler update application uses the equipment schedules model from the data modeler
with state va
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...

Frequently Asked Questions

IEC 61970-456:2013 is a standard published by the International Electrotechnical Commission (IEC). Its full title is "Energy management system application program interface (EMS-API) - Part 456: Solved power system state profiles". This standard covers: IEC 61970-456:2013 defines the subset of classes, class attributes, and roles from the CIM necessary to describe the result of state estimation, power flow and other similar applications that produce a steady-state solution of a power network, under a set of use cases which are included informatively in this standard. This standard is intended for two distinct audiences, data producers and data recipients, and may be read from those two perspectives. From the standpoint of model export software used by a data producer, the standard describes how a producer may describe an instance of a network case in order to make it available to some other program. From the standpoint of a consumer, the standard describes what that importing software must be able to interpret in order to consume solution cases.

IEC 61970-456:2013 defines the subset of classes, class attributes, and roles from the CIM necessary to describe the result of state estimation, power flow and other similar applications that produce a steady-state solution of a power network, under a set of use cases which are included informatively in this standard. This standard is intended for two distinct audiences, data producers and data recipients, and may be read from those two perspectives. From the standpoint of model export software used by a data producer, the standard describes how a producer may describe an instance of a network case in order to make it available to some other program. From the standpoint of a consumer, the standard describes what that importing software must be able to interpret in order to consume solution cases.

IEC 61970-456:2013 is classified under the following ICS (International Classification for Standards) categories: 33.200 - Telecontrol. Telemetering. The ICS classification helps identify the subject area and facilitates finding related standards.

IEC 61970-456:2013 has the following relationships with other standards: It is inter standard links to IEC 61970-456:2013/AMD1:2015, IEC 61970-456:2018. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase IEC 61970-456:2013 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of IEC standards.