IEC TR 62357:2003

TECHNICAL IEC
REPORT
TR 62357
First edition
2003-07
Power system control and
associated communications –
Reference architecture for object models,
services and protocols
Reference number
IEC/TR 62357:2003(E)
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the

60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,

edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the

base publication incorporating amendment 1 and the base publication incorporating

amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (http://www.iec.ch/searchpub/cur_fut.htm)
enables you to search by a variety of criteria including text searches, technical
committees and date of publication. On-line information is also available on
recently issued publications, withdrawn and replaced publications, as well as
corrigenda.
• IEC Just Published
This summary of recently issued publications (http://www.iec.ch/online_news/
justpub/jp_entry.htm) is also available by email. Please contact the Customer
Service Centre (see below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:
Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
TECHNICAL IEC
REPORT
TR 62357
First edition
2003-07
Power system control and
associated communications –
Reference architecture for object models,
services and protocols
 IEC 2003  Copyright - all rights reserved
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 the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch  Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale
U
International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue

– 2 – TR 62357  IEC:2003(E)
CONTENTS
FOREWORD . 3

0 Introduction. 5

Trend toward integration of planning and control systems. 5

1 General . 6

1.1 Scope and purpose of reference architecture. 6

1.2 Reference documents. 9

2 IEC Technical Committee 57 Standards. 9

2.1 IEC 60870-5 Standards from IEC Technical Committee 57 Working group 3 . 9
2.2 IEC 60870-6 Standards from IEC Technical Committee 57 Working group 7 .10
2.3 IEC 61334 Standards from IEC Technical Committee 57 Working group 9 .11
2.4 IEC 61850 Standards from IEC Technical Committee 57 Working groups 10 to 12 . 11
2.5 Future IEC 61970 Standards from IEC Technical Committee 57 Working group 13 . 12
2.6 IEC 61968 Standards from IEC Technical Committee 57 Working group 14 .15
2.7 IEC Technical Committee 57 Working group 15 Standards for Data and
Communications Security .17
2.8 IEC Technical Committee 57 Working group 16 Standards for a Framework for
Deregulated Energy Market Communications.17
3 Reference Architecture .17
3.1 SCADA Interfaces.19
3.2 Inter-CC Data Links .19
3.3 EMS Applications.20
3.4 DMS Applications and External IT Applications.20
3.5 Substation/Field Devices .20
4 Data Modeling in IEC Technical Committee 57.21
4.1 Common Information Model (CIM) and Component Interface Specifications (CIS).21
4.2 IEC 61850 ACSI and Logical Devices .24
5 Strategic Use of Reference Architecture for Harmonization and New Work Items.26
5.1 Adoption of Reference Architecture .26
5.2 Use of Common Object Modeling Language .26
5.3 Harmonization at Model Boundaries .26
5.4 Resolution of Model Differences .27
6 Conclusion.27

Annex A Objects Modeled within IEC Technical Committee 57 .28
Annex B EPRI Utility Communications Architecture (UCA) .29
Figure 1 – Coordination among standards activities . 7
Figure 2 – Application of Technical Committee 57 Standards to a power system . 8
Figure 3 – EMS-API Standards as an Integration Framework .14
Figure 4 – SCADA Data Interfaces .15
Figure 5 – Distribution Management System with IEC 61968 compliant interface
architecture.16
Figure 6 – Technical Committee 57 Reference Architecture .18
Figure 7 – Common Information Model (CIM) Packages .22
Figure 8 – ACSI Client/Server Model.25

TR 62357  IEC:2003(E) – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
POWER SYSTEM CONTROL AND ASSOCIATED COMMUNICATIONS –

Reference architecture for object models, services and protocols

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, 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 provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
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.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC 62357, which is a technical report, has been prepared by IEC technical committee 57:
Power system control and associated communications.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
57/611A/DTR 57/627/RVC
Full information on the voting for the approval of this technical report 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.

– 4 – TR 62357  IEC:2003(E)
The committee has decided that the contents of this publication will remain unchanged until
2004 . At this date, the publication will be

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

• amended.
___________
IEC Technical Committee 57 will revise this document immediately in order to accommodate comments
received during the voting process with the goal of reflecting recent developments.

TR 62357  IEC:2003(E) – 5 –
0 Introduction
IEC Technical Committee 57 develops standards for electric power system control and

associated telecommunications in the areas of generation, transmission and distribution real-

time operations and planning. The primary purpose of this Technical Report is to provide a

reference architecture to show how the various standardisation activities within IEC Technical

Committee 57 relate to each other and how they individually and collectively contribute to

meeting the objectives of IEC Technical Committee 57. A second objective is to develop a
strategy to combine and harmonize the work of these various activities to help facilitate a
single, comprehensive plan for deployment of these standards in product development and

system implementations.
The need for this framework is motivated by at least two major factors:
1. There are multiple independent standard initiatives that need to be coordinated and
harmonized to minimize the need for data transformation to exchange data between
systems using these various standards.
2. There is a need to have a comprehensive vision of how to deploy these standards for
actual system implementation and integration efforts.
There are several different initiatives within IEC Technical Committee 57, each dealing with a
selected part of the real-time operations and planning. Each has a specific objective and may
have sufficient breadth of scope to provide the bulk of the relevant standards needed for
product vendors to develop products based on those standards.
Trend toward integration of planning and control systems
In today’s utility enterprise where information exchange between the various generation,
transmission and distribution management systems and other IT systems is not only desirable
but necessary in most cases, each system plays the role of either supplier or consumer of
information, or more typically both. That means that both data semantics and syntax need to
be preserved across system boundaries, where system boundaries in this context are
interfaces where data is made publicly accessible to other systems or where requests for data
residing in other systems are initiated. In other words, the what of the information exchange is
actually much more important for system integration purposes than how the data is
transported between systems.
Most previous efforts to define system architectures have dealt primarily with the how (i.e.,
definition of protocols for transporting the data), with a focus on utilizing as many existing ISO
or TCP/IP standards to provide the various layers in the ISO OSI seven-layer reference model
However, the increasing use of object modeling techniques to define the
for protocol profiles.
data for information exchange within the different standards initiatives has appropriately

shifted the focus away from the how to the what. This is the good news. The bad news is that
each initiative has chosen its own modelling language/notation and more importantly
generated its own object model definitions. This was not done intentionally, and in fact each
initiative had perfectly good reasons for their choices, given the limited scope of their domain
of application. But the consequence is that instead of one object model for each physical
entity in the generation, transmission and distribution operations domain being standardized,
at least two or more object models exist in most cases with different definitions for classes,
attributes, data types, and relationships between classes. Furthermore, in most cases
different modeling languages have also been used.
___________
The original EPRI UCA project, for example, had the focus of settling on the use of MMS and a few standard
profiles for transporting data rather than on the semantics of information transfer between systems.

– 6 – TR 62357  IEC:2003(E)
POWER SYSTEM CONTROL AND ASSOCIATED COMMUNICATIONS –

Reference architecture for object models, services and protocols

1 General
1.1 Scope and purpose of reference architecture

The first objective of a reference architecture is to describe all the existing object models,

services, and protocols and how they relate to each other. A strategy can then be developed

to show where common models are needed, and if possible, recommend how to achieve a
common model. Where changes cannot be made due to maturity of standards, then
recommendations for adapters to make the necessary transformations between models are
made.
This report deals with the following standardisation initiatives and their relationships:
1. IEC Technical Committee 57, which is responsible for developing standards for power
system control and associated telecommunications. Technical Committee 57 comprises a
number of working groups of which the following are covered in this Technical Report:
• IEC Technical Committee 57 Working group 3 – standards for reliable data acquisition
and control on narrow-band serial data links or over TCP/IP networks between SCADA
masters and substations.
• IEC Technical Committee 57 Working group 7 – standards for the exchange of real-
time operational data between control centers over Wide Area Networks (WANs).
• IEC Technical Committee 57 Working group 9 – standards for data communications
over distribution line carrier systems.
• IEC Technical Committee 57 Working groups 10, 11 and 12 – standards for
substations.
• IEC Technical Committee 57 Working group 13 – standards to facilitate integration of
applications within a control center, including the interactions with external operations
in distribution as well as other external sources/sinks of information needed for real-
time operations.
• IEC Technical Committee 57 Working group 14 – standards for Distribution
Management System interfaces for information exchange with other IT systems.
• IEC Technical Committee 57 Working group 15 – standards for data and
communication security.
• IEC Technical Committee 57 Working group 16 – standards for deregulated energy

market communications.
2. The Electric Power Research Institute (EPRI), which is responsible for the following
projects that have contributed to the work of IEC Technical Committee 57:
• CCAPI project, which is developing interfaces for information sharing between
application programs in a control center with a scope that includes transmission,
distribution, and generation (provides input to IEC Technical Committee 57 Working
groups 13 and 14)
• UCA2, which focuses primarily on communications to substation and substation
devices in transmission and distribution substations (provides input to IEC Technical
Committee 57 Working groups 10 to 12)
• ICCP, also known as TASE.2, for inter-control center communications, but also
applicable to substation communications in certain circumstances (provides input to
IEC Technical Committee 57 Working group 7)

TR 62357  IEC:2003(E) – 7 –
There are other standards-related activities that are relevant to IEC Technical Committee 57
and are the source of either existing or planned standards that can be adopted (perhaps with

some tailoring to meet utility-specific needs). Figure 1 graphically depicts these activities and

domain of application. Of particular interest are the following:

• Object Management Group (OMG), an industry consortium responsible for the CORBA

standards for open distributed computing. IEC Technical Committee 57 Working group 13

is working closely with the OMG Utilities Domain Task Force (DTF) to develop standards

for common data access and acquisition of SCADA data.

• Open Application Group (OAG), an industry consortium responsible for Enterprise

Application Integration (EAI) solutions. IEC Technical Committee 57 Working group 14 is

working closely with the OAG to develop standard XML messages for information
exchange between distribution management systems and other IT systems.
While there are liaisons between individual IEC Technical Committee 57 working groups and
these organizations, they are not the subject of this Technical Report and are therefore not
discussed further. The interested reader is referred to working groups mentioned above and
the websites of these organizations for more information.
Important Standardization Activities
Standards and Open
Component Container
TC57
Application
Technology
Technology
Group
____________
WG9
_________________
WG3
ISO ODP
Distribution
CORBA (OMG)
RTUs
Feeders
IEEE
Enterprise Java Beans
WG7
CIRED
Control
DCOM (Microsoft)
Open GIS SPAG
Centers
DistribuTECH
WG14
GITA
WGs 3,10,11,12
DMS
T&D
Substations
EPRI
WG13
UCA2
Utility
EMS
Integration Project
EPRI
OLE
Bus
CCAPI
Process
Project Object
Control
Mgmt.
(OPC)
Group
IEC  2042/03
Figure 1 – Coordination among standards activities
Figure 2 shows the scope of activity encompassed by the IEC Technical Committee 57
working groups identified above. The standards shown in Figure 2 are described in the
following Clause.
– 8 – TR 62357  IEC:2003(E)
IEC TC 57
Overview of Standards
IT-System IT-System
1 m
Control Center A Control Center B
EMS DMS
Apps.
Apps.
Future
IEC 61968
IEC 61970
Communication Bus
Future Future
IEC 61970 IEC 61970
Inter-CC
IEC 60870-6
SCADA
Datalink
Substation / Substation /
Field Device Field Device
1 n
Substation
RTU Automation
System
IEC 60870-5-103
IEC 61850
IEC 60834
Protection, Control, Metering
IEC 61850
Switchgear, Transformer,
Instrumental Transformers
IEC  2043/03
Figure 2 – Application of IEC Technical Committee 57 Standards to a power system
IEC 60870-5-102
IEC 61334
IEC 60870-5-101/104
IEC 60870-6-TASE.2
IEC 61850
IEC 61968
IEC 61968
TR 62357  IEC:2003(E) – 9 –
1.2 Reference documents
IEC 60870-5 (all parts), Telecontrol equipment and systems - Part 5: Transmission protocols

IEC 60870-6 (all parts), Telecontrol equipment and systems - Part 6: Telecontrol protocols

compatible with ISO standards and ITU-T recommendations

IEC 61334 (all parts), Distribution automation using distribution line carrier systems

IEC 61850 (all parts), Communication networks and systems in substations

IEC 61968 (all parts), Application integration at electric utilities – System interfaces for
distribution management
IEC 62056 (all parts), Electricity metering - Data exchange for meter reading, tariff and load
control
ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
ISO/IEC 8824-2, Information technology - Abstract Syntax Notation One (ASN.1): Information
object specification
ISO/IEC 9506 (all parts), Industrial automation systems - Manufacturing message
specification
2 IEC Technical Committee 57 Standards
As in most standards activities, the working documents from Technical Committee 57 that
eventually become standards originate within the individual working groups of Technical
Committee 57. These working groups were formed from the bottom up rather than from an
initial vision embodied in an umbrella framework or reference architecture handed down by
IEC Technical Committee 57. That is, within the broad charter of IEC Technical Committee
57, which is “power systems control and associated telecommunications”, working groups
were formed whenever a member country took the initiative to propose a new work item.
The first working groups focused on protocols and services for data links from control centers
to substations and to other control centers (IEC Technical Committee 57 Working groups 3
and 7). This work primarily provided standards for exchanging SCADA data and controlling
substation devices.
2.1 IEC 60870-5 Standards from IEC Technical Committee 57 Working group 3
IEC Technical Committee 57 Working group 3 initially focused on providing standards for
reliable communications on narrow-band serial data links traditionally used for
communications between a SCADA master in a control center and RTUs located in
transmission substations in the field. The first IEC Technical Committee 57 Working group 3
standard IEC 60870-5-101 resulted in a three-layer protocol stack custom designed for high
reliability and low bit rate on the wire. Later, the scope of IEC Technical Committee 57
Working group 3 was broadened to include telecontrol protocols mapped onto data networks,
such as router-based WANs. This resulted in IEC 60870-5-104, which provides network
access for IEC 60870-5-101 using standard transport profiles, primarily TCP/IP.

– 10 – TR 62357  IEC:2003(E)
These standards implicitly assume an “anonymous point-oriented model” to identify the values
received and devices controlled. This means that the source of a data value, such as analog

measurement, status, or accumulator (i.e., counter) value, is an RTU point number or name.

This is in contrast to the “device-oriented models” being developed in IEC Technical

Committee 57 Working groups 10, 11 and 12 in the IEC 61850 standards, where real world

substation and field devices are represented by object models and the name of the value

identifies the device that supplies it. In fact, the entire device is modeled to include other

information, such as nameplate data.

2.2 IEC 60870-6 Standards from IEC Technical Committee 57 Working group 7

IEC Technical Committee 57 Working group 7, on the other hand, focused on providing
protocols that could run over a Wide Area Network (WAN) to interconnect control centers
with heterogeneous databases and EMS applications. The goal was to develop protocols and
services compliant with the OSI 7-layer reference model using existing ISO standards to the
maximum extent possible.
The first standard published was TASE.1, comprising IEC 60870-6-501, IEC 60870-6-502,
IEC 60870-6-504, and IEC 60870-6-701, which is based on the ELCOM-90 protocol from
Norway over an OSI protocol stack. While TASE.1 includes enhanced functionality, the
application program interface was maintained exactly as defined in the ELCOM-90 protocol
documents.
The second standard published was TASE.2, comprising IEC 60870-6-503, IEC 60870-6-505,
IEC 60870-6-702, and IEC 60870-6-802. In addition to SCADA data and device control, these
standards also provide for exchange of information messages (i.e., unstructured ASCII text or
short binary files) and structured data objects, such as transmission schedules, transfer
accounts, and periodic generation reports. This standard is also unofficially known as ICCP,
from the name given by the EPRI project that sponsored the development of the draft
specifications for this standard (See Annex B for a description of the EPRI ICCP project).
The TASE.2 standards make use of a client/server model, in which the client initiates
transactions that are processed by the server. Object models were used to define the
transactions and services for transferring this data, such as Association, Data Value, Data
Set, Transfer Sets, Device Control, etc. The actual data to be transferred was separated from
these services and defined as static data objects, such as Indication Points, Control Points,
Transfer Account, Device Outage, etc. Thus an attempt was made to separate the data
objects to be transferred from the underlying services used to transfer the data.
However, since the primary objective of TASE.2 was to support the exchange of real-time
SCADA data or schedules and accounting information, the information needed was largely
independent of the source of the information. That is, the knowledge of the physical device

supplying measurands or status data was immaterial, as long as a power system model within
the control center could make the association of the received point data with its location in the
network topology. For that reason, point-oriented models were used to represent the data
values received and control commands sent to another control center or substation host
computer acting as a SCADA master for the substation. In other words, while an object model
approach is used to define the data objects and services, an anonymous point-oriented model
is used to identify the values received and devices controlled, as in IEC Technical Committee
57 Working group 3.
___________
The term control center here also includes power plants and automated substations that contain a host
computer acting as a SCADA master located within the substation itself.
The scope of IEC Technical Committee 57 and IEC Technical Committee 57 Working group 7 was later
modified to embrace the use of TCP/IP for the Transport Layer as well.

TR 62357  IEC:2003(E) – 11 –
IEC 60870-6-503 defines the services and protocols, including a mapping of the abstract
services and data types defined in the server objects onto MMS services and data types.

IEC 60870-6-802 defines the data objects and their mapping onto MMS data types.

IEC 60870-6-702 defines an Application Profile for TASE.2 protocol stack in the upper 3

layers. IEC 60870-6-505 is a User Guide for TASE.2.

2.3 IEC 61334 Standards from IEC Technical Committee 57 Working group 9

IEC Technical Committee 57 Working group 9 provides standards for distribution automation

using distribution line carrier systems. These standards address protocols for accessing

distribution devices in the field from distribution operations management systems over

existing distribution power lines.
The scope of these standards covers communications using distribution line carrier
technology on both medium voltage (MV) and low voltage distribution (LV) networks. The
distribution line communication system provides two-way communications which can be used
for a large number of devices with various functions (for example, station control units,
remotely controlled feeder switches, meters, transformer station concentrators, portable input
unit, light control, load management, and traffic lights).
Standard IEC 61334-4-1 defines the reference architecture based on the client-server model.
In IEC 61334-4-41, known as the Distribution Line Messaging System (DLMS), an abstract,
object oriented server model is provided. This model considers the limited resources of
distribution devices. The protocol data units of the application protocol supporting the model
are described in ASN.1. In addition, efficient encoding rules are provided (IEC 61334-6).
The IEC 61334-5-1 to IEC 61334-5-5 series defines several physical and MAC layers using
different modulation technologies suited for LV and MV communication. IEC 61334-4-511 and
IEC 61334-4-512 specify the management framework and the management procedures,
respectively, for the IEC 61334-5-1 profile. IEC 61334-3-21 and IEC 61334-3-22 define the
requirements for coupling the DLC signals into the MV line considering the necessary safety
requirements.
2.3.1 Relation to "external" standards
The DLMS standard IEC 61334-4-41 forms the basis for a series of standards developed by
IEC Technical Committee 13 Working group 04 for metering applications. In particular, the
IEC 62056 series provides a complete communication stack – including the meter device
models – which is compatible with IEC 61334-4-41.
2.4 IEC 61850 Standards from IEC Technical Committee 57 Working groups 10 to 12

As the need for standards to address substation automation was identified, new working
groups were formed (IEC Technical Committee 57 Working groups 10, 11 and 12) to develop
standards for architectures and interfaces within substations and on distribution feeders to
access field devices directly rather than indirectly through an RTU. This was also in
recognition of the desire to be able to access devices from different vendors in a common way
to accomplish engineering tasks, such as reconfiguring a device or obtaining name plate data
on newly installed devices for asset management purposes or other purposes not related to
just real-time control.
These standards define a reference architecture based on a client/server model, similar to the
TASE.2 standards, in which the client initiates transactions that are processed by the server.
However, unlike the TASE.2 standards, the physical field devices are modeled directly as
objects with attributes and methods. A client then interacts with an object model of the field
device directly in order to access it for purposes of reading attribute values, such as
nameplate data or measured values, or to control the device. The common services needed
by all substation devices, especially field devices, are modeled as server objects, which are
defined in the IEC 61850-7 Abstract Communication Service Interface (ACSI). These abstract

– 12 – TR 62357  IEC:2003(E)
communication services are defined using object modeling techniques as well. Field devices,

then, incorporate these services by specifying which objects within their models inherit the

class objects defined in the ACSI. For example, if a model of a utility field device contains a

measured value which needs to be read by a substation host, the object inherits the attributes

and methods associated with the class object Basic Data Class defined in IEC 61850-7-2.

Standardized mappings of these abstract services to different application layer communi-

cations protocols are defined in IEC 61850-8-x (station bus) / IEC 61850-9-x (process bus), so

that common utility functions will be performed consistently across all field devices

independent of the underlying communication stacks.

Similar to the TASE.2 standards, the ACSI description makes use of a client/server model.
However, since the primary objective of the ACSI is to provide access to device objects, the
field objects are modeled directly in IEC 61850.
This work is based on object models for substation devices that originated with the EPRI-
sponsored UCA2 project, and IEEE Technical Report 1550, described in Annex B.
2.5 Future IEC 61970 Standards from IEC Technical Committee 57 Working group 13
IEC Technical Committee 57 Working group 13 was formed to develop EMS API standards to
facilitate the integration of EMS applications developed independently by different vendors,
between entire EMS systems developed independently, or between an EMS system and other
systems concerned with different aspects of power system operations, such as generation or
distribution management. This is accomplished by defining standard application program
interfaces to enable these applications or systems to access public data and exchange
information independent of how such information is represented internally.
These standards are built around a Common Information Model (CIM) which provides an
abstract model for a complete power system using Unified Modeling Language (UML)
notation. The CIM is part of the overall EMS-API framework The CIM specifies the semantics
for this API. Other parts of this standard specify the syntax for the API.
2.5.1 Common Information Model (CIM)
The CIM is an abstract model that represents all the major objects in an electric utility
enterprise typically contained in an EMS information model. This model includes public
classes and attributes for these objects, as well as the relationships between them.
Many aspects of the power system of concern to Technical Committee 57 are modeled only in
the CIM, such as generation equipment, generation dynamics, schedules, energy schedules,
financial, and reservations. Other parts of the power system are modeled in both the CIM and

elsewhere, such as substation equipment including transformers, switches, breakers, etc.
The comprehensive CIM is partitioned into several packages for convenience. Future IEC
61970-301 defines a base set of packages which provide a logical view of the physical
aspects of Energy Management System information, including the Core, Topology, Wires,
Outage, Protection, Measurements, Load Model, Generation, and Domain. Future IEC 61970-
302 defines the Energy Scheduling, Reservation, and Financial packages. Future IEC 61970-
303 defines the SCADA package.
2.5.2 Component Interface Specifications (CIS) for Information Exchange
For a specific type of application and type of exchange, it is necessary to define what object
classes and attributes are exchanged. This means defining interface message structures to
hold the data. These structures may be subsets or views of CIM object classes. In other
words, the CIM is used as a data dictionary for defining the contents of the information
exchanged between applications.

TR 62357  IEC:2003(E) – 13 –
A series of Component Interface Specifications (CIS) are used to actually define the data

content and behavior for each of the applications in an EMS. The CIS comprises a set of

interface classes specified using UML notation for each information exchange. Since the

intent of the EMS-API standards is to define interface standards rather than to define

standard applications, the scope of these CIS can best be understood by considering the list

of application categories that will be supported by the EMS-API standards. The application

categories defined for which a CIS is being prepared includes, but is not limited to, the
following:
• SCADA,
• Alarm Processing,
• Topology Processing,
• Network Applications (for example, State Estimator, Optimal Power Flow, etc.),
• Load Management,
• Generation Control,
• Unit Commitment,
• Load Forecast,
• Energy/Transmission Scheduling,
• Transaction Information Systems,
• Accounting Settlements,
• Maintenance Scheduling,
• Archive,
• Equipment Data Definition,
• Generic User Interface,
• Dynamic Simulation,
• Dispatcher Training Simulator,
• External systems (for example, Distribution Management Systems (DMS), weather,
wholesale power marketing, etc.),
• Asset Management.
The actual APIs defined in the EMS-API standards are generic in nature (i.e., independent of
actual data content). The content of the information to be exchanged is defined in the CIS
interface classes. In an actual deployment of these standards, the system implementer or
integrator would define the applications or systems to be integrated and then build an
information exchange model (IEM) repository containing the metadata about all information

exchanges.
2.5.3 Future IEC 61970 Standards as an Integration Framework
Figure 3 illustrates the key interfaces within a control center based on the use of EMS-API
standards. SCADA data is made available to EMS applications via the Component Interfaces
as specified in the EMS-API CIS standards. The actual middleware technology (referred to as
a component execution system (CES) in Figure 3) used to interconnect the applications can
be chosen by the system implementer from among the best ones available and is not the
subject of the EMS-API standards. As long as the public appearance of the SCADA data at
the SCADA component interface to the CES conforms to the EMS-API standards for SCADA
data, any application that also conforms will be able to receive and interpret the data.

– 14 – TR 62357  IEC:2003(E)
Legacy
System
Alarm Topology Network Load Accounting/ Generation
Applications Management Control
Processor Processor Settlement

Legacy
SCADA
SCADA
Programs Programs
Network System Programs Programs CIM Server
Programs
Public Public
Public
Public Public Public
Legacy
Data Data Data
Data
Data Data
Wrapper
Component Execution System
and Component Adapters (e.g., Integration Bus)
User
Distribution
PCs
Management Public
Public
TASE.2
Data
Data
Systems
Network
Component Programs
Programs
Interface
TASE.2
IEC  2044/03
Figure 3 – EMS-API Standards as an Integration Framework
The EMS-API standard requires that data presented at the interface comply with the CIM
regarding semantics and syntax, so that any application that that wants to receive SCADA
data only needs to conform to the CIM. This means that a transformation must be made from
the data representation of the standard used to acquire the data to the CIM representation.
Figure 4 illustrates the relevant interfaces and the transformations required. SCADA data
received via IEC 60870-6 TASE.2 links from either another control center or from a SCADA
master in a substation is transformed in the TASE.2 Adapter to be compliant with the future
IEC 61970 CIM. More specifically, it is transformed to comply with the SCADA CIS defined as
part of the EMS-API standards. In a similar fashion, SCADA data received via IEC 61850
ACSI links from either substation or field devices is transformed in the ACSI Adapter to be
CIM-compliant. SCADA data from an existing SCADA system that uses the IEC 60870-5
standards, DNP, or some proprietary RTU protocol is transformed by a custom SCADA

System Adapter to be CIM-compliant. The effect of the use of adapters is that all SCADA
data, regardless of the protocols/services and data representation used to obtain the data
from the field or from other control centers, has the same representation on the integration
bus. This means that any applications that operate on SCADA data, including data
repositories or historical information systems, need to be designed to support only a single
interface, the future IEC 61970 EMS-API CIS SCADA interface, to be able to be integrated
into a system framework.
TR 62357  IEC:2003(E) – 15 –
Substation Substation
Control
Center Device Device
RTU
IEC 60870-5, DNP,
Proprietary
Historical EMS TASE.2 ACSI
SCADA
Information Proprietary Blocks Discovery/
System
System Database 1&2 Reporting
IEC IEC
Proprietary
60870-6 61850
SCADA
Database Database TASE.2 ACSI
System
Adapter Adapter Adapter Adapter
Adapter
Future
IEC
Bus Connector Bus Connector
Integration Bus
IEC  2045/03
Figure 4 – SCADA Data Interfaces
Figure 4 also illustrates the use of database adapters to transform data from proprietary
representations in an EMS database or from industry standard representations in a Historical
Information System to the CIM representation for access via the integration bus.
2.6 IEC 61968 Standards from IEC Technical Committee 57 Working group 14
IEC Technical Committee 57 Working Group 14 was formed shortly after IEC Technical
Committee 57 Working Group 13 to address the need for standards for System Interfaces for
Distribution Management Systems (SIDMS). The IEC 61968 series is intended to facilitate
inter-application integration of the various distributed software application systems supporting

the management of utility electrical distribution networks. These standards define
requirements, an integration architecture, and interfaces for the major elements of a utility’s
Distribution Management System (DMS) and other associated external IT systems. Examples
of DMS include Asset Management Systems, Work Order Management Systems, Geographic
Information Systems and Customer Information Systems, while Customer Resource
Management is an example of an external IT system interface. The message-based
technology used to mesh these applications together into one consistent framework is
commonly referred to as Enterprise Application Integration (EAI); IEC 61968 guides the
utility’s use of EAI. Figure 5 clarifies the scope of IEC 61968-1 graphically, in terms of
business functions.
– 16 – TR 62357  IEC:2003(E)
UUttililitity Cy Coonnttrrooll
CeCentnteerr
Utility
Utility
Network
Network
Customer
Customer
Business
ExExpapansnsiionon Business
Inquiry
Inquiry
Planning
Planning Systems
Systems
(ERP, Billing,
(ERP, Billing,
EEnneerrgygy t trradadining,g,

Meter other systems)
Meter other systems)
RReeaadding &ing &
Control
Control
Network IEC 61968
Network IEC 61968
Operation
Operation
Distribution Automation
Distribution Automation CoCompmplialianntt
Corporate
Corporate
Interface
Interface
LAN
LAN
Architecture
Architecture
ReReccoordr
...