TECHNICAL REPORTIEC TR 62357First edition 2003-07

Power system control and associated communications - Reference architecture for object models, services and protocols

CONTENTS

FOREWORD...........................................................................................................................3

0 Introduction.......................................................................................................................5

Trend toward Integration of planning and control systems................................................51 General...............................................................................................................................6

1.1...........................................Scope and purpose of reference architecture..................................................................................................................................61.2........................................................................Reference documents..................................................................................................................................9

2 IEC Technical Committee 57 Standards...........................................................................92.1..IEC 60870-5 Standards from IEC Technical Committee 57 Working group 392.2..IEC 60870-6 Standards from IEC Technical Committee 57 Working group 7102.3....IEC 61334 Standards from IEC Technical Committee 57 Working group 9112.4.IEC 61850 Standards from IEC Technical Committee 57 Working groups 10 to 12.......................................................................................................................112.5 Future IEC 61970 Standards from IEC Technical Committee 57 Working group 13 .... 122.6...IEC 61968 Standards from IEC Technical Committee 57 Working group 14152.7......IEC Technical Committee 57 Working group 15 Standards for Data and Communications Security.....................................................................................172.8. IEC Technical Committee 57 Working group 16 Standards for a Framework for Deregulated Energy Market Communications................................................17

3 Reference Architecture....................................................................................................173.1..............................SCADA Interfaces.....................................................................................................193.2.........................................................................Inter-CC Data Links193.3...........................................................................EMS Applications203.4.....................................DMS Applications and External IT Applications203.5...................................................................Substation/Field Devices20

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.......265.1.....................................................Adoption of Reference Architecture................................................................................................................................265.2..........................................Use of Common Object Modeling Language................................................................................................................................265.3.....................................................Harmonization at Model Boundaries................................................................................................................................265.4.........................................................Resolution of Model Differences................................................................................................................................27

6 Conclusion.......................................................................................................................27

Annex A Objects Modeled within IEC Technical Committee 57..........................................28Annex 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.........................................................................................15Figure 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

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:

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.

The committee has decided that the contents of this publication will remain unchanged until 2004V At this date, the publication will be

* reconfirmed;

• withdrawn;

* replaced by a revised edition, or

Enquiry draft Report on voting

57/611A/DTR 57/627/RVC

• amended.

0 Introduction

IEC Technical Committee 57 develops standards for electric power system control and associated telecommunications in the areas of generation, transmission and distribution realtime 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 factorsThere 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

There is a need to have a comprehensive vision of how to deploy these standards for actual system implementation and integration effortsThere 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 standardsTrend toward integration of planning and control systemsIn 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 systemsMost previous efforts to define system architectures nave dealt primarily with the horn (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 for protocol profiles 2 However the increasing use of object modeling techniques to define the 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

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:

* ІEС 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:

• ІЕС 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.

• ІЕС Technical Committee 57 Working group 7 - standards for the exchange of realtime 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 realtime 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.

• 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)

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.

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

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 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 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 WLANs. This resulted in IEC 60870-5-104, which provides network access for IEC 60870-5-101 using standard transport profiles? primarily TCP/IP. TCP/IP.

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 TEC 60870-6 Standards from lEC 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 centeps3 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.4

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.

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

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 communications 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. 1

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 (СІМ) which provides an abstract model for a complete power system using Unified Modeling Language (UML) notation. The СІМ is part of the overall EMS-API framework The СІМ specifies the semantics for this API. Other parts of this standard specify the syntax for the API.

2.5.1 Common Information Model (СІМ)

The СІМ 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 СІМ, such as generation equipment, generation dynamics, schedules, energy schedules, financial, and reservations. Other parts of the power system are modeled in both the СІМ and elsewhere, such as substation equipment including transformers, switches, breakers, etc.

The comprehensive СІМ 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-* defines the Energy Scheduling, Reservation, and Financial packages. Future IEC 61970-* 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 СІМ object classes. In other words, the СІМ is used as a data dictionary for defining the contents of the information exchanged between applications.

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.

Figure 3 - EMS-API Standards as an Integration Framework

The EMS-API standard requires that data presented at the interface comply with the ClM 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 Adapter4 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.

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.

Figure 5 - Distribution Management System with IEC 61968 compliant interface architecture

Standards interfaces are being defined for each class of applications identified in the IEC 61968-1 Interface Reference Model (IRM) IEC Technical Committee 57 Working group ;14 uses the Unified Modeling Language (UML) to define additional Real World Objects, (RWO) classes in the CIM that are relevant to inter-application information exchange in distribution domain. The resulting CIM classes (specified in both future IEC 61970-3xx and IEC 61968-11) govern the semantics used in message types being defined for the Information Exchange Model (IEM), which is to be included in Parts 3 to 10 of IEC 61968.

The extensible Markup Language XML is a data format for structured document interchange, particularly on the Internet. One of its primary uses is information exchange between different and potentially incompatible computer systems. XML is thus well-suited to the domain of System Interfaces for Distribution Management. Therefore, where applicable, Parts 3 to 10 of IEC 61968 will define document structures in XML. In addition to close cooperation with the CCAPI Task Force and IEC Technical Committee 57 Working group 13, IEC Technical Committee 57 Working group 14 also works collaboratively with the Open Applications Group (OAG) to improve the ability of utilities to integrate between T and D applications (IEC Technical Committee 57 domain) and Enterprise Resource Planning (ERP) applications (OAG domain). OAG message exchange is defined using XML.

As described above, IEC Technical Committee 57 Working group 14 is basing their standards on the same CIM as IEC Technical Committee 57 Working group 13, with extensions specifically needed for the distribution systems addressed in IEC Technical Committee 57 Working group 14. Thus IEC Technical Committee 57 Working group 14 and IEC Technical Committee 57 Working group 13 are both using the CIM for inter-application information exchange and building an IEM as needed to define the specific semantics and syntax for these exchanges.

Note that the use of object modeling techniques internal to each of the applications/systems Integrated with either IEC Technical Committee 57 Working group 13 or IEC Technical Committee 57 Working group 14 standards is not a requirement or an issue here. It is only relevant for describing data at the interface that is to be shared. Thus, the CIM is the canonical language for semantics and syntax on the network interconnecting applications/ systems.

* IEC Technical Committee 57 Working group 15 Standards for Data and Communications Security

IEC Technical Committee 57 'Working group 15 is chartered with developing security standards which encompass all the work of Technical Committee 57. At the present time (2003), this work has just begun and as a result, no standards currently exist. It is expected that future editions of this Technical Report will incorporate these standards.

* IEC Technical Committee 57 Working group 16 Standards for a Framework for Deregulated Energy Market Communications

This working group is chartered with developing a framework for deregulated energy market communications. At the present time (2003) this work has just begun and as a result, no standards currently exist. It is expected that future versions of this paper will incorporate these standards.

3 Reference Architecture

In this Clause, we attempt to organize these standards into an integrated framework architecture, referred to hereafter as a Technical Committee 57 reference architecture. The . primary purpose is to identify the interfaces where data transformation is required.

Figure 6 is one view of;this reference, architecture. This diagram presents a top-down view of the IEC Technical Committee 57/, standards, starting with a top layer 1 concerned with integration of systems/applications via inter-application messaging as provided via commercial off-the-shelf middleware. The next two layers 2 and 3 provide for data representation (as specified in the CIM) and application program interfaces, respectively, as specified in the interface standards of future IEC 61970 and IEC 61968.

Figure 6 - Technical Committee 57 Reference Architecture

The next layer 4 represents the various transmission and distribution computer systems/applications for which integration standards are being developed in IEC Technical, Committee 57. This includes the following:

* SCADA systems,

* EMS applications, including inter-control center data links,

* a variety of distribution systems, such as meter reading and control, customer inquiry, records and asset management, maintenance and construction, operational planning, etc.

For each of these layer 4 applications, an "inboard" interface and an "outboard" interface is shown. For the purposes of this diagram, these interfaces are defined as follows:

Outboard interface: the view looking outward toward the external systems/devices with which these layer 4 applications/systems communicate to acquire data and/or control devices.

In this view, some layer 4 applications/systems act as clients initiating transactions with remote servers in the field. The client and server can be connected by various types of communication networks. Communication media may have geographic and utilisation constraints, such as limited bit rates, proprietary data link layers, restricted times for use, and satellite hop delays. Network topology may be hierarchical, with a few "central" sites authorising and managing the interactions with a large number of "field" sites, or it may be networked with peer-to-peer interactions. Communication media may have varying configurations, such as point-to-point, multi-drop, mesh, hierarchical, WAN-to-LAN, intermediate nodes acting as routers, as gateways, or as data concentrators.

information exchange on the outboard interface is defined by the Technical Committee 57 standards developed in IEC Technical Committee 57 Working Groups 3, 7, 9, 10, 11, and 12, as shown in the reference architecture. The client/server interaction and communication protocol stacks between clients and servers are the subject of these standards. These standards are shown in the lower layers of the reference architecture.

Inboard interface: the view looking inward toward other layer 4 applications/systems for the purposes of exchanging information typically in a peer-to-peer fashion.

In this view, the layer 4 applications/systems interact with each other typically as peers, although some may use a client/server model, where each system functions as both client and server. Information exchange between these applications/systems on the inboard interface is based on the semantics and syntax specified in the future IEC 61970/IEC 61968 CIM. The actual message contents and behavior associated with these messages are specified in the future IEC 61970 CIS for control center applications and in the IEC 61968 SIDMS for DMS applications and systems being developed by IEC Technical Committee 57 Working Groups 13 and 14, respectively. These standards are shown in the upper layers of the reference model.

Some applications/systems in layer 4 have both outboard and inboard interfaces, such as SCADA, inter-control center communications, or some DMS applications. In these cases, whereas the system acts as a client regarding the outboard interface, it acts in turn as a aerver on the inboard interface, being a source of data to other applications. For example, a SCADA system with an ACSI client which talks to ACSI servers using IEC 61850 standards to access data from substation and field devices, now may act as a server using future IEC 61970 standards to exchange data with EMS applications, such as Topology Processor or State Estimator, in a control center environment.

3.1 SCADA Interfaces Among the applications shown is SCADA for real-time data acquisition and device control. .Whiter.there are-severaI protocol/service and interface standards in IEC Technical Committee 57-for SCADA operations on the outboard interface,- as shown in the reference architecture, : the' fUtufe IEC 61970 SCADA CIS "defines the standard SCADA data representation and b^h^vror -for exchanging. SCADA data with other EMS/DMS applications for real-time operation and control on the inboard interface.

As can be seen, there are several standards defined for accessing substation and field devices. These include standards from IEC Technical Committee 57 Working groups 3, 7, 9, 10 and 11 plus standards from other Technical Committees. The data representation is different for these working groups as defined in their respective standards (i.e., IEC 60870-5, IEC 60870-6, and IEC 61850) as previously described. Therefore, there is a need for the SCADA data representations from each of these SCADA services to be harmonized with the CIM representation of SCADA data. There are two approaches to accomplish this:

* Provide for data transformation processing in the SDADA system or at the interfaces to the SCADA system using the existing standards models.

* Resolve the differences in models within the developing standards before they become finalized to negate the need for real-time data transformation.

In addition, although not shown, a separate interface for accessing substation and field devices via a Web server can be used for purposes of configuring these devices and accessing data not normally collected by SCADA This may be used for engineeringpurposes or for real-time data access via Web browsers from any location that has access to the supporting network. This interface on the inboard side can exploit the full functionality of the IEC 61850 ACSI, including device discovery, access to all object model data stored on intelligent devices, as well as the normal SCADA data. The object models, if used separately in this fashion from the object models used within the control center, need not be harmonized with the object models as defined in the CIM.

3.2 Inter-CC Data Links

The inter-control center data link services/protocols are provided by IEC 60870-6-503, IEC 60870-6-702, and IEC 60870-6-802. There are no other standards for this service in IEC Technical Committee 57. These standards are now complete and extensively deployed in commercial products in the field at many utilities around the world.

The data representation for SCADA data in IEC 60870-6-503 and IEC 60870-6-802 is not harmonized with the CIM representation. However, since these standards are now in wide use, it seems that data transformation is the only practical answer in the near term. For the future, it may be desirable to incorporate the capability to transfer specific objects.

There are additional standards for exchanging information between control centers that are not shown. An XML version of the CIM is used to exchange power system models between control centers. No special protocol is required for this exchange. Current implementations include file transfer using FTP over TCP/IP.

* EMS Applications

Most EMS applications rely on the SCADA application or inter-control center data links to provide real-time operational data. As a result, there are no relevant IEC Technical Committee 57 standards on the outboard interface side of these applications, so there are no data or object model harmonization issues between IEC Technical Committee 57 standards.

However, there are issues between proprietary formats of data as used in the many EMS applications currently available from EMS vendors and the CIM/CIS standards contained in the future IEC 61970 standards being developed by lEC Techincal Committee 57 Working group 13. In the actual deployment of these standards, one of two possible integration scenarios are possible:

* Existing EMS applications are "wrapped" to transform the existing proprietary application interface to the interface specified in the CISs and the data representation specified in the CIM.

* EMS applications are rewritten to provide the API specified in the future IEC 61970 standards. For new applications, the standard interface would be incorporated into the original design to avoid the need for wrappers.

* DMS Applications and External IT Applications

The distinction between inboard and outboard interfaces blurs somewhat with DMS applications/systems such as Asset Management, Work Order Management, Geographic Information, Customer Information, etc., which are designed primarily as stand-alone systems. All interfaces between these systems and other external IT systems that are not strictly utility systems, such as Customer Resource Management, are the subject of the IEC 61968 standards. Since the CIM provides the model for information exchange between these systems, the interfaces are considered as inboard interfaces in Figure 6.

* Substation/Field Devices

Switchgear, transformers, and other substation or field devices can be accessed indirectly via an RTU or directly through the use of substation automation and intelligent devices.

RTUs provide limited access to typical SCADA point-oriented data only via IEC 60870-5 standards. Since these standards are published and quite mature, the only practical approach to harmonization is through data transformation in the control center.

Substation automation with the IEC 61850 standards provides more extensive access to devices using device-oriented data models. In addition to real-time operational SCADA data used by EMS applications, configuration, topological, and asset information can also be accessed and used in the power system model maintained in the CIM in the EMS. For this reason, it is important to try to harmonize object and attribute names and data types by adopting common conventions for those portions of the device models used in the EMS.

4 Data Modeling in IEC Technical Committee 57

As can be seen from the above descriptions, there are a number of different ways that data are modelled. That is, there are different ways of representing the data that is to be transferred over data links or across interfaces that are the subject of standards in IEC Technical Committee 57. The way data is represented at the lower layers of a protocol stack is of concern when addressing interoperability of products from different vendors at each end of a data link or logical association. From a harmonization point of view however, the only place it matters is at the interfaces where software implementing one standard must interface to software implementing another standard.

Or another way to look at harmonization is to view data to be exchanged in terms of object models. Where these object models purport to represent the same physical object, ideally it would seem to be desirable to have one set of models used consistently by all interfaces. In this section, we describe the object models now in use within IEC Technical Committee 57.

Annex A provides a summary of what is modelled in each of the major IEC Technical Committee 57 models.

4.1 Common Information Model (CIM) and Component Interface Specifications (CIS) 4.1.1 CIMThe CIM is perhaps a logical place to start, since it attempts to model the entire power system, both from an operational point of view and more recently from an asset-management of view, at least for those aspects of assets needed to manage real time operations. 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 these objects, as well as the relationships between them. The objects represented in the CIM are abstract in nature and may be used in a wide variety of applications.

The CIM is described in class diagrams using UML notation. While the model is partitioned into several packages for convenience, as shown in Figure 7, it is actually one connected class diagram. A package is a general purpose means of grouping related model elements. There is no specific semantic meaning. The packages have been chosen to make the model easeier to design, understand and review. The Common Information Model consists of the complete set of packages. Entities may have associations that cross many package boundaries. Each application will use information represented in several packages.

Figure 7 - Common Information Model (СІМ) Packages

Figure 7 shows the packages defined for the СІМ and their dependency relationships. The dashed line indicates a dependency relationship, with the arrowhead pointing from me dependent package to the package on which it has a dependency. Many aspects of the power system of concern to IEC Technical Committee 57 are modelled only in the СІМ, such as generation equipment, generation dynamics, schedules, energy schedules, financial, arid reservations. Other parts of the power system are modeled in both the СІМ and elsewhere, such as substation equipment including transformers, switches, breakers, etc.

4.1.2 СІМ Classes and Relationships

The UML class diagram(s) for each СІМ package shows all the classes in the package and their relationships. Where relationships exist with classes in other packages, those classes are also shown with a note identifying the package which owns the class.

Classes and objects model that in a power system which needs to be represented in a common way to EMS applications. A class is a description of an object found in the real world, such as a power transformer, generator, or load that needs to be represented as part of the overall power system model in an EMS. Other types of objects include things such as schedules and measurements that EMS applications also need to process, analyze, and store. Such objects need a common representation to achieve the purposes of the EMS-API standard for plug-compatibility and interoperability. A particular object in a power system with a unique identity is modeled as an instance of the class to which it belongs.

It should also be noted that the СІМ is; defined to facilitate data exchange. As defined in this document, СІМ entities have no behavior other than default create, delete, update and read. In order to make the СІМ as generic as possible it is highly desirable to make it easy to configure for specific implementations. In general, it is easier to change the value or domain of an attribute than to change a class definition. These principles imply that the СІМ should avoid defining too many specific sub-types of classes. Instead, the СІМ defines generic classes with attributes giving the type name. Applications may then use this information to instantiate specific object types as required. Applications may need additional information to define the set of valid types and relationships.

Classes have attributes that describe the characteristics of the objects. Each class in the СІМ contains the attributes that describe and identify a specific instance of the class. Only the attributes that are of public interest to EMS applications are included in the class descriptions.

Each attribute has a type, which identifies what kind of attribute it is. Typical attributes are of the types integer, float, Boolean, string, and enumeration, which are called primitive types. However, many additional types are defined as part of the СІМ specification. For example, CapacitorBank has a MaximumkV attribute of type Voltage. The definition of data types is contained in the Domain Package.

Relationships between classes reveal how they are structured in terms of each other. СІМ < classes are related in a variety of ways, including generalization, simple association, composite and shared aggregation.

The use of the СІМ goes far beyond its application in an EMS. This standard should be understood as a tool to enable integration in any domain where a common power system model is needed to facilitate interoperability and plug compatibility between applications and systems independent of any particular implementation.

Much of the work of this group, especially the СІМ, is based on proposals received from the EPRI-sponsored Control Center Application Program Interface (CCAPI) project described in the next section.

The original purpose of the СІМ was to mpdel that portion of the power system of interest tc EMS applications being handled in IEC Technical Committee 57 Working group 13. However the scope was recently'.broadened to embrace the scope of IEC Technical Committee 57 Working, group 14, and is now-being expanded to include models needed for DMS applications and systems. Fer a''Complйtй description of the entire СІМ model, see future IEC 61970-301, future IEC 61970-302, and future IEC 61970-303.

Some of the important features of the СІМ are:

The СІМ is hierarchical. Attributes common to more than one subclass of object are inherited from a common class.

TOie СІМ is normalized. Allattributes are unique and belong to only one class, although thev may be incorporated intotcrther classes via one of the class relationships supported, which include

generalization, association, and aggregation. This makes the model useable by a ;-jv.f variety of applications, all of which may not have been foreseen when the СІМ was ne originally-constructed. The alternative is to make the model denormalized, creating new • [«-classes arrd'duplicating attributes to

optimize the structure for each application's view ol the model.The СІМ is static. The СІМ is an information model, wherein a physical object may be represented by a

number of interrelated classes. Since no specific application was in view when the model was constructed, the objects that an аpplication may want to access through some, method .-may not be represepteзl by a single c|.as,s. That is, the comprises many "small'objetоts", not necessarily the "big objйctis" that would be subjлct' фf some operation by an application. Therefore, it is not appropriate to try to add operations/methods to the actual class definitions in the СІМ.

The СІМ is modeled in Rational ROSE. The СІМ was constructed using Rational ROSE Version 4.0 from Rational Software Corporation. The entire СІМ exists as a .mdl file viewable with Rational ROSE, including the class diagrams and descriptions of classes, attributes, types, and relationships. Viewing the СІМ in this fashion provides a graphical navigation interface that permits all СІМ specification data to be viewed via point-and-click from the class diagram in each package. Each top level packageJs also distributed as a .cat file, allowing new models to be constructed from the СІМ packages.

The СІМ IEC documents are auto-generated using Rational SODA.

The СІМ has a representation in XML using an RDF schema.

The СІМ is an OMG standard.

The СІМ is in use in many production systems.

The CIM is meant to contain classes and attributes that will be exchanged over public interfaces between major applications.

The goal is to keep, as much as possible, only the generic features from which a detailed implementation may be derived. In general, it is easier to change the value or domain of an attribute than to change a class definition. This makes the model more robust because it is able to support a broader class of requirements, and more stable because new requirements may be able to be handled without requiring changes to the model.

4.1.3 CIS

Whereas the CIM is a static model, the CIS documents which are the subject of the future IEC 61970-4xx standards, define the behavior of real world objects that must be modeled as well as the common services needed to exchange data. The future IEC 61970 reference model is based on a component architecture, as defined in the software industry by de facto standard component models, such as the CORBA component model, Enterprise Java Beans (EJB), and Microsoft COM/DCOM.

The component models in the CIS define interfaces in terms of events, methods, and properties, completely independent of the underlying infrastructure used to communicate between components. The CIS thus defines the syntax for inf,ea:-mation exchanges, while the CIM provides the semantics or content of the transfer.

4.2 IEC 61850 ACSI and Logical Devices

In IEC 61850, Logical Device models represent the behavior of real devices. This is accomplished by defining standard classes and objects (instances of classes) built up through ... Jnheritance and aggregation from a common set of Abstract Communication Server Interface (ACSI) class definitions. The ACSI is defined^ in IEC 6185.0-7-2 and basically defines the :yserve.r:Objects that are used for communicating with field devices, but not the content of the • information transferred. Logical Devices, which are the. subject of IEC 61850-7-3 and IEC 61850-7-4. define the content of the information transferredc; .

Users of ACSI-based devices can access the device features through well-defined network services operating on the objects. The ACSI data access model defines the rules for defining and organizing the object models specified by industry groups into objects that can be used in communications.

The IEC 61850 standards incorporate the services and models from the EPRI Common Access Service Methods (CASM)5 with some revisions based on more recent developments. The object-oriented terminology used in these standards is similar to the UML used in the CIM and includes: class, object, method, attribute, inherit, instantiate, and aggregate. However, IEC 61850 uses the object modelling facilities of ASN.1, ISO/IEC 8824-2 rather than UML. The type language specified in ISO/IEC 8824-1 is used for describing the abstract structure of a protocol, that is, the data present in a message. It does so by providing a notation for data values and data types.

4.2.1 IEC 61850 ACSI

in ACSI, a client/server model is assumed, in which the client initiates transactions that are processed by the server. The ACSI server hides real data and devices, using objects tc represent them instead. Objects that are directly accessible by a client through a network are contained in an object from the server class. The servers, and the object instances the; contain, are mapped to the communication stacks, for communication with the real devices Figure 8 illustrates this concept.

Figure 8 - ACSI Client/Server Model

* Logical Devices

Logical Devices are virtual representations of real substation sggtfjgfield devices. A? in r§al devices, LogrcaLDevicB^are: a composite of multiple parts, which are represented by Logical Nodes. The collection'of these Logical Nodes provide the functionality of the complete device. For example, a distribution relay:device might include several standardized relay function^, in addition, an electronic distribution relay would be likely to have the capability of measuring the voltages and currents in the conductors it is controlling. To represent this device with IEC 61850, a Logical Device would be created that contained a nameplate, Device Identity, a measurement unit Logical Node, and one or more standardized relay function Logical Nodes.

It should be noted that IEC 61850 allows for arbitrary assembly of Logical Nodes into Logical Devices. The composition of a Logical Device is left to the manufacturer and can always be determined from an^irrstance of a Logical Device via the communications services of ACSI.

With the use of«lЂC 61850 Logical Devices and the ACSI for communication with substation and field devices, ttae- properties of each device can be discovered and used to populate a database in the control center. Any changes in the field (i.e., new installations, revisions to existing'mstallations, removal of field equipment, etc.) can be discovered automatically as the changes are made, rather than requiring a separate manual data entry at the control center.

* TASE.2

The TASE.2 models represent a virtual control center rather than an individual substation or field devices. The TASE.2 models for SCADA operations are point-oriented, as explained earlier. That is, there are no models of physical devices being monitored or controlled. Management of physical devices in the field is not within the scope of IEC Technical Committee 57 Working group 7, so there is no provision for configuration of devices or discovery of new devices as there is in the IEC 61850 standards.

Regarding data acquisition with TASE.2, the assumption is that the topological information associated with point data received via TASE.2 is stored locally in a power system model in the receiving control center database. TASE.2 provides updates to measurement and status values using a unique reference number for each point that was agreed to by

both sending and receiving control centers when the Bilateral Tables used for access control are established.

4.2.4 Comparison of Data Models

The data models developed to date have evolved as several overlapping models to suit different users. Broadly speaking, the models can be classified as:

* The control center and distribution management view (i.e., EMS, DMS) of a network with large numbers of simplified devices. This view also- includes many non-power system objects, such as consumers, schedules, documents, assets, etc. to ensure data. consistency across all information exchanges between participating systems, and

* the substation (i.e., protection) view of a smaller number of more complex devices..

Object models are different because they are designed for different applications and users. A major area of overlap within IEC Technical Committee 57 standards occurs with:

* Substation and equipment identification including hierarchical relationships, and

* discrete and analog status (i.e., measurements) including units and quality.

Annex A is an attempt to compare the types of models discussed above^ This is not an exhaustive list, only representative of the models. As shown, there is a range of overlap in all models in the SCADA area for, analog measurands, status^changes, and.ppntrol points. For substation and feeder device models, future IEC 61970 anj3"lЈC 61850'rrrodels overlap! I^or other areas, such as contracts and generation, there is no o\/l?lap.

5 Strategic Use of Reference Architecture for Harmonization and New Work Items

It is beyond the scope of this.paper to resolve the differences between object/data models identified. However, it is suggested that this reference architecture. could be used^ii a foundation for determining where harmonization is needed. The following are suggested Ws starting points. ,

• Adoption of Reference Architecture

The first step is to agree to a common reference architecture so that terminology and interfaces can be identified and made consistent across the architecture. This architecture can then serve as a reference and guideline for future work. It is suggested that the reference model proposed in this paper be reviewed and revised until consensus is achieved on a model.

• Use of Common Object Modeling Language

The next step is to agree to a common modeling language. It is suggested that the Unifiec Modeling Language (UML) become the common language for IEC Technical Committee 57 foi object modeling. UML provides notations for class diagrams, state diagrams, event sequence diagrams, and a host of other types of model notations. One of the main advantages is tha there are several CASE tools available to prepare models and navigate them as well as tc auto-generate the Word documents needed by the IEC to promote them as standards. UMI has already been adopted by IEC Technical Committee 57 Working groups 13 and 14.

• Harmonization at Model Boundaries

As stated earlier, from a harmonization point of view, the two most important places wher having identical models really matters are:

1. At interfaces where software implementing one standard must interface to softwar implementing another standard. An example is a SCADA server that acquires data usin one model (for example, IEC 60870-5-101, TASE.2 or ACSI) and must serve it t applications using another model (for example, CIM).

2. Where these object models purport to represent the same physical real-world object. Ideally it would seem to be desirable to have one set of models used consistently by all interfaces. As a minimum, the attributes shared by both models should have consistent naming and data representation. Where object models are needed by EMS applications, there would be an advantage to having a control-centric view of the device models.

5.4 Resolution of Model Differences

To resolve model differences where there is overlap, it is suggested that the model experts from each of the affected working groups meet to determine where commonality and consistency are needed, and how it can be achieved. Where there are common classes or attributes, the goal should be to have consistent names and data representation to eliminate the need for naming mappings and data transformation. This has, in fact, already been accomplished for most of the SCADA data items in the CIM and ACSI. Where important classes or attributes are missing from a model, then an attempt should be made to add the missing items to the model.

6 Conclusion

A reference model for Technical Committee 57 is proposed to provide a framework for future standards development and for resolution of differences in object models within standards currently under development. It is hoped that by providing an overview and framework for standards development, more insight will be available to all contributors for the harmonization of IEC Technical Committee 57 object models. This will in turn lead to greater acceptance of IEC Technical Committee 57 standards in n.ew product development and fewer incompatibilities requiring custom adapters and gateways for implementing new computer systems and network for power system control.

Annex B

EPRI Utility Communications Architecture (UCA)

In parallel to the development of standards within IEC Technical Committee 57, EPRI initiated a number of research and development efforts targeted at the development of a comprehensive set of standards to facilitate the integration of power system applications and devices to support real-time operations. Unlike the work in IEC Technical Committee 57, this effort began with an analysis of the entire electric utility enterprise in order to create a vision from the top down to determine where standards were needed and to make recommendations for the use of a common set of protocols and protocol stacks within the framework of the seven-layer OSI reference model. This project resulted in the initial version of the UCA.

Within UCA, all real-time data acquisition and control applications make use of the application • layer standard ISO/I EC 9506. The MMS specification defines a common message format for providing a wide range of services to the applications. MMS services include, for example, reading, writing, and reporting of variables (simple or arbitrarily structured data types), event management, journaling, remote program control, and uploading/downloading of data and programs. The MMS protocol provides a rich real-time network-programming environment to support a very wide range of distributed applications.

To implement these recomrnen<iatipns, the MMS Forum was created. The MMS Forum comprised a number- of tea^ns^each addressing the application of MMS to one of the six major' domains within a utility identified in the UCA:

* control center,

* power plants,

* transmission substations,

* distribution substations and feeders,

* customer interface,

* corporate information systems.

The exchange of realrlime data acquisition and control information within the utility industry breaks down into iwo primary classes of applications: access to data in real-time databases (such as energy management system (EMS) and supervisory control data acquisition system (SCADA))*- and access to real-time end devices (switchgear, meters, remote terminal units (RTUs>)^etc.). The two classes of applications are characterized by somewhat different data models and access control requirements. The set of MMS services and data representation allows both classes of applications to be supported, but with different data formats and different interpretations.

ICCP

The Control Center team, in conjunction with the UCS project, another EPRI project established earlier to address control center communications with MMS, developed the ICCP specifications, which were the basis for the TASE.2 standards developed by IEC Technical Committee 57 Working group 7. This was the first successful application of MMS to the UCA vision and introduced the use of object models to describe the services supported by TASE.2 as well as static object models (i.e., attributes but no methods/operations) to describe the data structures to be exchanged. The power plant team also adopted ICCP as the basis for power plant to control center communications, with the addition of a set of power plant data objects that are included in the TASE.2 standards.

When applying the OSI reference model to a given application environment, protocols must be selected for each of the OSI layers, resulting in a communications profile for that environment. UCA Version 2.0 includes profiles employing protocols from both the OSI and TCP/IP families of protocols. Profiles are specified for both connection-oriented and connectionless (datagram, used in UCA for multicast) communications, running over common local area and wide area networks (LAN and WAN), as well as various utility-specific media such as radio. Reduced profiles, which eliminate the protocol of layers three through six (and the underlying functionality), are identified for low bandwidth environments, and also for devices that may not have the processing/memory capabilities to support the full 7-layer profiles.

TASE.2 supports models of real-time SCADA database elements as well as a variety of scheduling and other data exchange models. TASE.2 standards, as specified in the standards IEC 60870-6-503, IEC 60870-6-802, and IEC 60870-6-702, were based primarily on inpjuL from MMS Forum Control Center Working Group and the earlier EPRI-sponsore&UCS project,. The Power plant team also adopted TASE.2 as the basis for power plant to control center communications, with the addition of a set of power plant data objects that are deluded in the TASE.2 standards. This was the first successful application of MMS to thenUOA vision and introduced the use of object models to describe the services supported by TftSЈ,2 as well as static object models (i.e., attributes but Q O methods/operatjon3) to describe the data structures to be exchanged.

UCA2

For UCA real-time device access, the next phase of the UCA project, UCA2; produced detailed device object models that identify the set of variables, algorithms, etc., required to support the basic functionality of the each device class. For example, major voltage regulator/tap changer vendors have agreed to the base object model common to their devices. Each of their devices, when accessed via MMS, provide a common set of-variables, using common naming (such [as "tap_position") and data formats, which allow the: devices-to be "plug compatible" when supporting the basic regulation control, ind^pendenti of vendor, model,, or version.

UCA devices are self-describing. The self-describing vendor-independent device objecl models, when combined with the supporting profiles, provide a seamless view of real-time data throughout the utility enterprise. Using standard commercial off-the-shelf PC and/or workstation packages (for example, MMS browsers), individual users anywhere in the UCЈ enterprise can, subject to security and access controls, directly access real-time data from substation devices, feeder devices, or customer interface - and

beyond. Platforms supportec range from large-scale systems (such as EMS), through PCs and workstations, down to the smallest embedded systems such as pole-top field devices and low-cost meters.

EPRI CCAPI Project

At approximately the same time, a need was identified for standards to address the interfaces of applications within control centers, specifically EMS applications, including interfaces tc certain distribution systems external to the control center. This project has been the primary source of material for the IEC Technical Committee 57 Working group 13 EMS-API standards drafts and is described in the section dealing with IEC Technical Committee 57 Working group 13 future IEC 61970 standards above.