EN 61970-456:2013

SLOVENSKI STANDARD
01-oktober-2013
3URJUDPVNLYPHVQLN]DVLVWHP]DXSUDYOMDQMHHQHUJLMH(06$3,GHO3URILOL
VWDQMDVSURãþHQHJDHOHNWURHQHUJHWVNHJDVLVWHPD
Energy management system application program interface (EMS-API) - Part 456: Solved
power system state profiles
Interface de programmation d'application pour systèmes de gestion d'énergie (EMS-API)
- Partie 456: Profils d'état de réseaux électriques résolus
Ta slovenski standard je istoveten z: EN 61970-456:2013
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 61970-456
NORME EUROPÉENNE
August 2013
EUROPÄISCHE NORM
ICS 33.200
English version
Energy management system application program interface (EMS-API) -
Part 456: Solved power system state profiles
(IEC 61970-456:2013)
Interface de programmation d'application Schnittstelle für Anwendungsprogramme
pour système de gestion d'énergie für Netzführungssysteme (EMS-API) -
(EMS-API) - Teil 456: Globale Stabilitätsbeurteilung
Partie 456: Profils d'état de réseaux (IEC 61970-456:2013)
électriques résolus
(CEI 61970-456:2013)
This European Standard was approved by CENELEC on 2013-06-11. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the CEN-CENELEC Management Centre or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and notified
to the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus,
the Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2013 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 61970-456:2013 E
Foreword
The text of document 57/1327/FDIS, future edition 1 of IEC 61970-456, prepared by IEC TC 57 "Power
systems management and associated information exchange" was submitted to the IEC-CENELEC
parallel vote and approved by CENELEC as EN 61970-456:2013.
The following dates are fixed:
• latest date by which the document has (dop) 2014-03-11
to be implemented at national level by
publication of an identical national
standard or by endorsement
(dow) 2016-06-11
• latest date by which the national
standards conflicting with the

document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such patent
rights.
This document has been prepared under a mandate given to CENELEC by the European Commission
and the European Free Trade Association.
Endorsement notice
The text of the International Standard IEC 61970-456:2013 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards indicated:
IEC 61970-1 NOTE  Harmonised as EN 61970-1.
IEC/TS 61970-2 NOTE  Harmonised as CLC/TS 61970-2.
IEC 61970-301 NOTE  Harmonised as EN 61970-301.
IEC 61970-501 NOTE  Harmonised as EN 61970-501.

- 3 - EN 61970-456:2013
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

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.

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

IEC 61970-452 - Energy Management System Application EN 61970-452 -
Program Interface (EMS-API) -
Part 452: CIM static transmission network
model profiles
IEC 61970-453 - Energy Management System Application EN 61970-453 -
Program Interface (EMS-API) -
Part 453: Diagram Layout Profile

IEC 61970-552 - Energy Management System Application EN 61970-552 -
Program Interface (EMS-API) -
Part 552: CIM XML Model Exchange Format

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 e
...