62357-1 tc57 ref architecture r6 20111001

8/10/2019 62357-1 TC57 Ref Architecture r6 20111001

http://slidepdf.com/reader/full/62357-1-tc57-ref-architecture-r6-20111001 1/118

62357 © IEC:2011 - 1 -

IEC 62357: TC57 Architecture

Part 1: Reference Architecture forPower System Information

Exchange

Second Edition DraftRevision 6

October 1, 2011



62357 © IEC:2011 - 3 -

3.9 61850 Standards for Communications Systems for Distributed EnergyResources (DER) from WG17 ................................................................................ 36

3.9.1 Need for Communications with DER Systems ............................................ 36

3.9.2 IEC 61850-7-420 ....................................................................................... 38

3.9.3 IEC 61850-90-7 DER Inverter Object Models ............................................. 39

3.10 61850 Standards for Hydroelectric Power Plants from WG18 ................................ 40

3.10.1 Basic concepts for hydropower plant control and supervision .................... 41

3.10.2 Principles for W ater Control in a River System .......................................... 42

3.10.3 Principles for E lectrical Control of a Hydropower Plant .............................. 42

3.11 WG19 Harmonization ............................................................................................ 43

4 Current Reference Architecture ...................................................................................... 44

4.1 Overview ............................................................................................................... 44

4.2 SCADA Interfaces ................................................................................................. 46

4.2.1 Data Transformation via Gateways and Adapters ...................................... 47

4.2.2 Harmonization of the Data Models ............................................................. 48

4.3 Inter-Control Center Data Links ............................................................................. 48

4.4

EMS Applications .................................................................................................. 48

4.5 DMS Applications and External IT Applications ..................................................... 49

4.5.1 Substation/Field Devices ........................................................................... 49

5 Abstract Modeling in TC57 ............................................................................................. 50

5.1 Common Information Model (CIM) and Component InterfaceSpecifications (CIS)............................................................................................... 50

5.1.1 CIM ........................................................................................................... 50

5.1.2 CIM Classes and Relationships ................................................................. 55

5.1.3 CIS ............................................................................................................ 57

5.1.4 Interface Reference Model ( IRM) ............................................................... 57

5.2 61850 Data Modeling, ACSI and SCL .................................................................... 57

5.2.1 61850 ACSI ............................................................................................... 59

5.2.2 SCL Modeling Language ........................................................................... 60

5.3 TASE.2 ................................................................................................................. 63

5.4 Data Modeling Techniques Used ........................................................................... 63

5.4.1 61850 ........................................................................................................ 63

5.4.2 61968, 61970 ............................................................................................ 63

5.5 Service Model Techniques Used ........................................................................... 64

5.5.1 61850 ........................................................................................................ 64

5.5.2 61968 ........................................................................................................ 64

5.5.3 61970 ........................................................................................................ 65

5.6

Reconciling CIM and 61850 Standards via a Harmonized Model ........................... 65

5.6.1 Use Cases and Interfaces ......................................................................... 66

5.6.2 Summary of Harmonized Model ReconciliationRecommendations ..................................................................................... 66

6 Technology Mappings for TC57 Standards ..................................................................... 71

6.1 Use of XML ........................................................................................................... 72

6.1.1 61850 SCL Use of XML ............................................................................. 72

6.1.2 61968 and 61970 XML Based on the CIM .................................................. 74



62357 © IEC:2011 - 4 -

6.1.3 Reconciling the Use of XML....................................................................... 75

7 Strategic Use of Reference Architecture for Harmonization and New WorkItems .............................................................................................................................. 76

7.1 Use of Common Object Modeling Language and Rules ......................................... 76

7.2 Harmonization at Model Boundaries ...................................................................... 76

7.3

Resolution of Model Differences ............................................................................ 76

7.4 Basis of a Future Vision for TC57 .......................................................................... 77

7.5 Process of Starting New Work in TC57 .................................................................. 77

8 Future Reference Architecture for Power System Information Exchange ......................... 78

8.1 Vision Statement ................................................................................................... 78

8.2 Fundamental Architecture Pr inciples ..................................................................... 78

8.3 Strategy ................................................................................................................ 79

8.3.1

Information Model ...................................................................................... 79

8.3.2

Business Context ...................................................................................... 80

8.3.3

Interfaces .................................................................................................. 80

8.3.4

Service Model ........................................................................................... 80

8.3.5

Industry Trends to Consider ...................................................................... 81

8.3.6 User Awareness and Usability ................................................................... 82

8.3.7 CIM Modeling Technology and Language Strategy .................................... 83

8.4 Vision for the Next Generation of CIM and Related Standards ............................... 86

8.4.1 Information Layer ...................................................................................... 87

8.4.2 Contextual Layer ....................................................................................... 88

8.4.3 Message Assembly Layer .......................................................................... 89

8.4.4 Exchange Schema Layer ........................................................................... 89

8.4.5 Concrete Messages and the Four Layer Architecture ................................. 89

8.4.6 Next Steps ................................................................................................ 91

8.5

61850 Standards Strategy ..................................................................................... 91 8.5.1 Seamless Profile Concept ......................................................................... 91

9 Conclusion ..................................................................................................................... 92

10 Acknowledgements ........................................................................................................ 92

Annex A Objec t Models and Mappings within TC57 .............................................................. 93

A.1 TC57 Object Models .............................................................................................. 93

A.2 61850 Models and Mappings ................................................................................. 93

Annex B Compar ison of Circuit Breaker Models within TC57 ................................................. 95

B.1 Introduction ........................................................................................................... 95

B.2 61970/68 Circuit Breaker Model in the CIM ........................................................... 95

B.2.2

61970-301 CIM Base Standard for a Circuit B reaker................................ 102 B.3 61850 Circuit Breaker Model ............................................................................... 105

Annex C Strategic Vis ion from the Intell igrid Architecture ................................................... 109

C.1 Introduction ......................................................................................................... 109

C.2 Abstract Model ing ............................................................................................... 109

C.2.1 Object Modeling and Information Models ................................................. 109

C.2.2 Abstract Service/Interface Models ........................................................... 110

C.2.3 Naming .................................................................................................... 110



62357 © IEC:2011 - 5 -

C.2.4 Self-Description and Discovery ................................................................ 110

C.2.5 Security Management .............................................................................. 111

C.2.6 Network Management .............................................................................. 111

C.2.7 Data Management ................................................................................... 112

C.2.8 Integration and Interoperability ................................................................ 112

C.2.9

Technology Independent Design Techniques ........................................... 113 C.3 Methodologies for Using the IntelliGrid Architecture ............................................ 113

Annex D CIM/61850 Mapping Recommendations ................................................................ 114

D.1 Introduction ......................................................................................................... 114

Annex E Bibl iography ......................................................................................................... 117



62357 © IEC:2011 - 6 -

List of Figures

Figure 1-1, Application of TC57 Standards to a Power System ............................................. 13

Figure 1-2, TC57 Organization and Formal Liaisons ............................................................. 15

Figure 3-1, Communication Interface Architecture for IEC 61850 .......................................... 25

Figure 3-2, EMS-API Standards as an Integration Framework ............................................... 28

Figure 3-3, Distribution Management System with IEC 61968 compliant interfacearchitecture .......................................................................................................................... 29

Figure 3-4, 61968 Interface Reference Model (IRM) .............................................................. 31

Figure 3-5, Interrelationship of IEC 62351 Security Standards and the TC57Protocols .............................................................................................................................. 31

Figure 3-6, Two Infrastructures Should Be Managed ............................................................. 33

Figure 3-7, Power Infrastructure Relies on Information Infrastructure .................................... 33

Figure 3-8, Power Infrastructure Relies on Information Infrastructure .................................... 34

Figure 3-9, Energy market communication over the Internet ................................................. 35

Figure 3-10, DER Interactions in Electric Power System Operations ..................................... 38

Figure 3-11, DER Management In teractions.......................................................................... 40

Figure 3-12 – Structure of a Hydropower Plant ..................................................................... 41

Figure 4-1, Current Reference Architecture for Power System InformationExchange ............................................................................................................................. 45

Figure 4-2, SCADA Data Interfaces ...................................................................................... 47

Figure 5-1, Common Information Model (CIM) Top-Level Packages ...................................... 52

Figure 5-2, IEC 61970 CIM Packages ................................................................................... 53



Figure 5-5, 61850 Data Modeling .......................................................................................... 58

Figure 5-6, ACSI Client/Server Model ................................................................................... 59

Figure 5-7, How SCL Files Are Used To Exchange IED Configuration Data .......................... 60

Figure 5-8, SCL Object Model ............................................................................................... 62

Figure 5-9, Proposed Changes to the Substation Equipment UML Model .............................. 67

Figure 5-10, Proposed Linkage of 61850 Classes to CIM PSR Classes in UML ..................... 68

Figure 6-1, Overview of SCL Schema ................................................................................... 72

Figure 8-1, Vision for Next Generation CIM and Related Standards ...................................... 86

Figure 8-2, Role of Architecture Layers in Message Payload Definition ................................ 90

Figure 10-1, Power System and Information Infrastructures ................................................ 111

http://c/Documents%20and%20Settings/tsaxton/My%20Documents/My%20Documents/IEC/WG%2019/Reference%20Architecture/Second%20Edition/62357-1%20TC57%20Ref%20Architecture%20r6%2020110930.docx%23_Toc305502169





62357 © IEC:2011 - 7 -

INTERNATIONAL ELECTROTECHNICAL COMMISSION ____________

TC57 ARCHITECTURE –

Part 1: Reference Architecture for Power System InformationExchange

FOREWORD

1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardizationcomprising all national electrotechnical committees (IEC National Committees). The object of IEC is topromote international co-operation on all questions concerning standardization in the electrical andelectronic fields. To this end and in addition to other activities, IEC publishes International Standards,Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides(hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; anyIEC 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 inthis 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 agreem ents of IEC on technical matters express, as nearly as possible, an

international consensus of opinion on the relevant subjects since each technical committee hasrepresentation from all interested IEC National Committees.

3) IEC Publications have the form of recommendations for international use and are accepted by IECNational Committees in that sense. While all reasonable efforts are made to ensure that the technicalcontent of IEC Publications is accurate, IEC cannot be held responsible for the way in which they areused or for any misinterpretation by any end user.

4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publicationstransparently to the maximum extent possible in their national and regional publications. Any divergencebetween any IEC Publication and the corresponding national or regional publication shall be clearlyindicated in the latter.

5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for anyequipment 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 i njury, propertydamage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legalfees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or anyother IEC Publications.

8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publicationsis 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 subjectof patent rights. IEC shall not be held resp onsible 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 ithas collected data of a different kind from that which is normally published as anInternational Standard, for example "state of the art".

IEC 62357-1, which is a technical report, has been prepared by IEC technical committee57: POWER SYSTEM MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE.

This second edition cancels and replaces the first edition published in 2003 andconstitutes a technical revision. The objectives of the first edition were to

1. provide a framework to show how the various standardisation activities within IECTechnical Committee 57 relate to each other and how they individually and



62357 © IEC:2011 - 8 -

collectively contribute to meeting the objectives of IEC Technical Committee 57,and

2. develop a strategy to combine and harmonize the work of these various activitiesto help facilitate a single, comprehensive plan for deployment of these standardsin product development and system implementations.

The second edition provides updates and defines a layered reference architecture to helpdirect longer term goals and activities, specifically to ensure compatibility of all newstandards developed in TC57 by benefitting from lessons learned during development ofthe current standards and their application on actual utility projects as well as throughapplication of other internationally recognized architecture standards, such as theUN/CEFACT Core Components Technical Specification.

The third edition currently being prepared will reflect the progress recently achieved fromthe international Smart Grid (SG) initiatives and the CIGRE D2.24 large systemarchitecture vision. The third edition will also reflect the most recent editions of the TC 57standards including IEC 61850 Edition 2 and the IEC 61968, 61970, and 62325 CommonInformation Model (CIM) standards.

The text of this technical report is based on the following documents:

Enquiry draft Report on voting

XX/XX/DTR XX/XX/RVC

Full information on the voting for the approval of this technical report can be found in thereport 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 the maintenance result date1) indicated on the IEC web site under"http://webstore.iec.ch" in the data related to the specific publication. At this date, thepublication will be

• reconfirmed,

• withdrawn,

• replaced by a revised edition, or

• amended.

1) The National Committees are requested to note that for this publication the maintenance result date is ....



62357 © IEC:2011 - 11 -

exist in most cases with different definitions for classes, attributes, data types, andrelationships between classes. Furthermore, in most cases different modeling languageshave been used as well.

1.4 Purpose of the Current Reference Architecture

To achieve the first objective of this report, a reference architecture for power system

information exchange is defined to describe all the existing object models, services, andprotocols within TC57 and how they relate to each other. Then, to meet the secondobjective, a strategy can be developed to show where harmonization is needed, and ifpossible, to recommend how to achieve a common model. Where changes cannot bemade due to maturity of standards, then recommendations for adapters to make thenecessary transformations between models are made. The third objective of this report isachieved by defining a vision of a future reference architecture that recognizes theimportance of a single, internally consistent semantic layer to avoid unnecessary seams(i.e., the concept of a seamless architecture), while facilitating information exchange overa variety of industry-standard transport infrastructures. This future vision will provide aframework for growth and incorporation of new, evolving technologies without invalidatingthe existing standards developed by TC57.

1.5 Scope of Reference Architecture

Originally the charter and title of TC57 was Power System Control and AssociatedTelecommunications. The focus was on developing different protocol standards toaddress the data communications requirements of different parts of power systemcontrol, such as data communications over low-speed serial lines, distribution line carrierprotocols, and inter-control center communications protocols.

Later as the scope of the TC57 work broadened to include data exchange betweenapplications within an Energy Management System as well as inter-computer system dataexchange between Distribution Management Systems and deregulated energy marketcommunications, the charter was changed to Power System Management and AssociatedInformation Exchange, so that the focus shifted from lower lever protocol development todevelopment of more abstract data models and generic interfaces at higher levels in thearchitecture. This shift resulted in the creation of new working groups to address the newbusiness functions embraced by the new TC57 Charter, which includes:

Energy management

SCADA and network operation

Substation protection, monitoring, and control

Distribution automation

Distributed Energy Resources (DER)

Demand response and load control

Meter reading and control

Customers

Work

Network expansion planning

Operational planning and optimization

Maintenance and construction

Records and asset management

Market operations



62357 © IEC:2011 - 12 -

Reservations

Financial

Energy Scheduling

The scope of the Reference Architecture for Power System Information Exchangeembraces all these areas from both the abstract information modeling perspective (i.e.,

Platform Independent Models) as well as the technology mappings for implementation(i.e., Platform Specific Models).

1.5.1 IEC Standards Included in Reference Architecture

The Reference Architecture for Power System Information Exchange includes thefollowing IEC TC57 standards (responsible working groups are shown in parentheses):

60495 and 60663: Planning of (single-sideband) power line carrier systems. (WG20)

60870-5: Standards for reliable data acquisition and control on narrow-band serial datalinks or over TCP/IP networks between SCADA masters and substations. (WG3)

60870-6: Standards for the exchange of real-time operational data between control

centers over Wide Area Networks (WANs). This standard is known officially as TASE-2and unofficially as ICCP. (WG7)

61334: Standards for data communications over distribution line carrier systems. (WG9)

61850: Standards for communications and data acquisition in substations. Thesestandards are known unofficially as the UCA2 protocol standards. They also includestandards for hydroelectric power plant communication, monitoring, and control ofdistributed energy resources and hydroelectric power plants. (WG10, 17, 18)

61968: Standards for Distribution Management System (DMS) interfaces for informationexchange with other IT systems. These include the distribution management parts of theCIM and eXtensible Markup Language (XML) message standards for informationexchange between a variety of business systems, such as meter data management,

asset management, work order management, Geographical Information Systems (GIS),etc. (WG14)

61970: Standards to facilitate integration of applications within a control center,exchange of network power system models with other control centers, and interactionswith external operations in distribution as well as other external sources/sinks ofinformation needed for real-time operations. These standards include the generation andtransmission parts of the Common Information Model (CIM), profiles for power systemmodel exchange and other information exchanges, and XML file format standards forinformation exchange. (WG13)

62325: Standards for deregulated energy market communications. (WG16)

62351: Standards for data and communication security. (WG15)

Figure 1-1 shows where some of these standards are used in the utility operationsenvironment. Not all standards listed above are shown and not all end fielddevices/systems are shown. More detailed descriptions and illustrations are provided inSection 3.



62357 © IEC:2011 - 13 -

Figure 1-1, Application of TC57 Standards to a Power System

IEC TC 57

Overview of Standards

Switchgear, Transformers,Instrumental Transformers

6

1 3 3 4

6 0 8 7 0 - 5 - 1 0 2

Protection, Control, Metering

Communication Bus

6 1 9 6 8

61970

SubstationAutomation

System

6 0 8 7 0 - 5 - 1 0 1 / 1 0 4

6 0 8 7 0 - 6 - T A S E . 2

6

1 8 5 0

Inter-CCDatalink

SCADA

EMSApps.

61968

DMSApps.

IT-Systemm

6 1 9 6 8

IT-System1

Control Center A Control Center B

60870-6

RTU

Substation /Field Device

1

60834

Substation /Field Device

n

60870-5-103 61850

61850

61970 61970



62357 © IEC:2011 - 14 -

1.5.2 TC57 Organization and Formal Liaisons

Figure 1-2 shows the organization of the IEC TC57 Working Groups that are responsiblefor producing these standards. The formal TC57 liaisons with external organizations andindustry consortiums are also shown and listed below with additional detail:

CIGRE: Category A

– SC D2-24 Information systems and telecommunications – EMS architecturesfor the 21st century

– SC B5-38: Protection and automation

UCAIug (UCA International User Groups), including CIM, OpenSG, and 61850:Category D with WG 10, WG 13 and WG 14

ebIX (European forum for energy business information exchange): Category Dwith WG 16

ENTSO-E (European Network of Transmission System Operators for Electricity),

responsible for Europe-wide planning and operations for all cross-borderexchanges of electricity: Category D with WG 13 and WG 16

IEEE (Institute of Electrical and Electronic Engineers) PES (Power EngineeringSociety) PSCC (Power Systems Communications Committee) SecuritySubcommittee: Category D with WG 15

UN/CEFACT (United Nations/Center for Trade Facilitations and ElectronicBusiness), a United Nations body that is in charge of trade facilitations and havelaunch an initiative for e-commerce known as ebXML, a suite of specifications toenable enterprises to conduct business over the Internet. Included is amechanism for enterprises to register core components in XML meta-language, sothat other enterprises can determine what information is available, and can thenestablish dynamic interactions automatically: MoU (Memo of Understanding)between IEC and UN/CEFACT

Later in this chapter the activities of each of the IEC TC57 working groups is described. As shown the activities are coordinated by the Convener ‟s Advisory Group (CAG) andWG19, which functions as an architecture board to ensure standards developed fit acommon architectural framework and are compatible with existing standards.



62357 © IEC:2011 - 15 -

Figure 1-2, TC57 Organization and Formal Liaisons

1.5.3 IEC Internal LiaisonsCurrent IEC internal liaisons include:

IEC TC 4 Hydraulic turbines

IEC TC 8 System aspects for electrical energy supply

IEC TC 13 Electrical energy measurement, tariff - and load control

IEC SC 17C High-voltage switchgear and control gear assemblies

TC 57 Organization and Formal

WG14

SIDM

E

TC57

WG

D



62357 © IEC:2011 - 17 -

International Standards Organization (ISO) Security and Metadata RepositoryStandards

Electric Power Research Institute (EPRI), although not a standards organization assuch, was a source for a number of the drafts which became standards within TC57 viathe Control Center Applications Program Interface (CCAPI) project. Specific contributionsare described in Annex B, EPRI Utility Communications Architecture (UCA).

1.6 Purpose of the Future Reference Architecture for Power System InformationExchange

The future Reference Architecture is built upon the current TC57 Reference Architectureand the many utility requirements that went into defining that architecture. However, italso takes into account new concepts and evolving technologies in the informationindustry at large. In some cases these must be incorporated into the future Reference Architecture, not necessarily because they are bet ter than what has been developedtodate, but because the electric industry must and will follow technology trends fromother industries where these are proven to be cost-beneficial. In other cases, the electricpower industry is just now getting into new areas, such as market operations, wheresome of the needed technologies are being defined elsewhere.

2 Abbreviations

This section provides a list of abbreviations used in this report.

ACSI Abstract Communication Service Interface AHW G Ad Hoc Work ing Group API Application Program Interface ASCII American Standard Code for Information Intercha nge ASN Abstract Syntax Notat ion

CASE Computer Aided Software EngineeringCASM Common Access Service MethodsCC Control Center

CCAPI Control Center Application Program InterfaceCCTS Core Component Technical SpecificationCDA Common Data AccessCES Component Execution SystemCIM Common Information ModelCIS Common Interface SpecificationCMIP Communication Management Information ProtocolCOM Common Object ModelCPSM Common Power System ModelCS Common Services

DA Data AccessDAF Data Access FacilityDAIS Data Acquisition from Industrial SystemsDBMS Database Management SystemDCOM Distributed Common Object ModelingDER Distributed Energy ResourceDLC Distribution Line CarrierDLMS Distribution Line Messaging SystemDMS Distribution Management SystemDOM Document Object ModelDTD Document Type DefinitionDTF Domain Task Force



62357 © IEC:2011 - 18 -

EAI Enterprise Architecture IntegrationebXML e business XMLEDI Electronic Data InterchangeEDIFACT Electronic Data Interchange for Administration Commerce and TransportEII Enterprise Information IntegrationEJB Enterprise Java BeansEMS Energy Management SystemEPRI Electric Power Research InstituteERP Enterprise Resource PlanningETL Extract, Transform, and LoadEV Electric Vehicle

FTP File Transfer Protocol

GDA Generic Data AccessGES Generic Eventing and SubscriptionGID Generic Interface DefinitionGIS Geographic Information SystemGOOSE Generic Object Oriented Substation Event

GSSE Generic Substation Status EventGUI Graphic User InterfaceGUID Globally Unique Identifier

HDAIS Historical Data Access from Industrial SystemsHIS Historical Information SystemHMI Human Machine InterfaceHSDA High Speed Data AccessHTML Hypertext Markup Language

ICCP Inter-Control Center ProtocolIEC International Electrotechnical CommissionIED Intelligent Electronic Device

IEEE Institute of Electrical and Electronics EngineersIEM Information Exchange ModelIP Internet ProtocolIRM Interface Reference ModelISO International Standards Organization or Independent IS International StandardIT Information Technology

J2EE Java 2 Enterprise Edition

LAN Local Area NetworkLD Logical DevicesLV Low Voltage

MAC Media Access ControlMDA Model Driven ArchitectureMDI Model Driven IntegrationMDR Metadata RepositoryMIB Management Information BaseMMS Manufacturing Messaging SpecificationMRID Master Record Identification NumberMV Medium Voltage



62357 © IEC:2011 - 19 -

NDR Naming and Design RulesNERC North American Electric Reliability CorporationNWIP New Work in Progress

OAG Open Application GroupOLE Object Linking and EmbeddingOMG Object Management GroupOPC OLE for Process ControlORB Object Request BrokerOSI Open System InterconnectOWL Ontology Web Language

PC Personal ComputerPIM Platform Independent ModelPLC Programmable Logic ControllerPSM Platform Specific ModelPV PhotoVoltaic

RDBMS Relational Database Management SystemRDF Resource Description Framework

RDFS RDF SchemaRFP Request for ProposalRTO Regional Transmission OperatorRTU Remote Terminal UnitRWO Real World Objects

SAS Substation Automation SystemSCADA Supervisory Control and Data AcquisitionSCD System Configuration DescriptionSCL Substation Configuration LanguageSCSM Specific Communication Service MappingSGML Standard Generalized Markup LanguageSIDMS System Interfaces for Distribution Management Syste

SMV Sample Measured ValueSNMP Simple Network Management ProtocolSOA Service Oriented ArchitectureSOAP Simple Object Access ProtocolSPAG Strategic Policy Advisory GroupSQL Structured Query LanguageSSD Substation System Description

TASE Telecontrol Application Service ElementTC Technical Committee or Time ConstantTCP/IP Transport Control Protocol/Internet ProtocolTLS Transport Layer SecurityTSDA Time Series Data Access

UCA Utility Communication ArchitectureUDDI Universal Description and Discovery InformationUML Unified Modeling LanguageUMM UN/CEFACT Modeling MethodologyUMP UML ProfileUN/CEFACT United nations Center for Trade Facilitation and Electronic BusinessURI Uniform Resource IdentifierURL Universal Resource LocatorURN Universal Resource Name



62357 © IEC:2011 - 20 -

VLPGO Very Large Power Generation OperatorsVPN Virtual Private Network

WAN Wide Area NetworkWG Working GroupW3C World Wide Web ConsortiumWSDL Web Services Definition Language

XMI Extensible Mark-Up Language Metadata InterchangeXML Extensible Mark-up LanguageXSD XML Schema DefinitionXSL Extensible Style Sheet LanguageXSLT Extensible Style Sheet Language Template



62357 © IEC:2011 - 21 -

3 IEC TC57 Standards

As in most standards act ivit ies , the working documents that eventually become standardsfrom TC57 have their genesis within the individual working groups of TC57. Theseworking groups were formed from the bottom up rather than from an initial visionembodied in an umbrella framework or reference architecture handed down by TC57.That is, within the original charter of TC57, which was “power sy stems control andassociated telecommunications”, working groups were formed whenever a membercountry took the initiative to propose a new work item.

The first working groups focused on protocols and services for data links from controlcenters to substations and distribution feeders, and to other control centers (WG3, WG7,and WG9). This work primarily provided standards for exchanging SCADA data andcontrolling substation/field devices.

As new working groups were subsequent ly formed, the emphasis sh ifted more tomodeling and semantics of data (i.e., the what of information exchange rather than thehow , as previously mentioned) with transport mechanisms provided by world-wide,industry-independent standards provided by ISO, W3C, and others. WG10 applied these

modeling techniques to substation automation and control, while WG13 and 14 focusedon information exchange between transmission and distribution applications and systems,with the focus on message payload definitions and service definitions independent of theunderlying transport mechanisms. WG16 extended this approach to market operations.WGs 17 and 18 further extended the application domain to DER and hydroelectric plants,respectively. WGs15 and 19 deal with security and harmonization issues, respectively, toensure a common approach and internal consistency across all TC57 working groups.

In parallel with this and in recognition of this shift in the subject of TC57 standards, thecharter of TC57 was changed to “power system management and a ssociated informationexchange.”

The following sections describe the standards developed within each of these workinggroups.

3.1 60870-5 Telecontrol Protocol Standards from WG3

WG3 initially focused on providing standards for reliable communications on narrow-bandserial data links traditionally used for communications between a SCADA master in acontrol center and RTUs located in transmission substations in the field. The first WG3standard, 60870-5-101, resulted in a three-layer protocol stack custom designed for highreliability and high transmission efficiency for use on wires capable of only low bit rates.Later the scope of WG3 was broadened to include telecontrol protocols mapped ontodata networks, such as router-based WANs. This resulted in 60870-5-104, which providesnetwork access for 60870-5-101 using standard transport profiles, primarily TCP/IP.

These standards implicitly assume an “anonymous point -oriented model” to identify thevalues 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 pointnumber or name. This is in contrast to the “device-oriented models” being developed inWG10 in the 61850 standards, where real world substation and field devices arerepresented by object models and the value of the object is identified by a structuredname identifying the device that supplies it and the object it contains. In fact, the entiredevice is modeled to include other information, such as nameplate data.



62357 © IEC:2011 - 22 -

3.2 60870-6 Standards from WG7

WG7, which is no longer active, focused on providing protocols that could run over aWAN to interconnect control centers3 with heterogeneous databases and EMSapplications. 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 60870-6-501,-502, -504, and -701,which is based on the ELCOM-90 protocol from Norway over an OSI protocol stack. WhileTASE.1 includes enhanced functionality, the primary objective of TASE.1 is to provide foroperation of an existing ELCOM-90 protocol over an OSI protocol stack. The applicationprogram interface for TASE.1 was maintained exactly as defined in the ELCOM-90protocol documents to facilitate replacement of ELCOM-90 with TASE.1.

The second standard published was TASE.2, comprising 60870-6-503, -505, -702, and -802. The major objectives of TASE.2 are to provide (1) increased functionality and to (2)maximize the use of existing OSI-compatible protocols, specifically the ManufacturingMessaging Standard (MMS) protocol stack. TASE.2 provides a utility-specific layer overMMS.

In addition to SCADA data and device control functionality as provided in TASE.1, the

TASE.2 standards also provide for exchange of information messages (i.e., unstructured ASCII tex t or short binary fi les) and structured data objects, such as transmiss ionschedules, transfer accounts, and periodic generation reports. This standard is alsoknown unofficially as ICCP, from the name given by the EPRI project that sponsored thedevelopment of the draft specifications for this s tandard (See Annex B for a description ofthe EPRI ICCP project).

The TASE.2 standards make use of a client/server model, in which the client initiatestransactions that are processed by the server. Object models were used to define thetransactions and services for transferring this data, such as Association, Data Value,Data Set, Transfer Sets, Device Control, etc. The actual data to be transferred wasseparated from these services and defined as static data objects, such as IndicationPoints, 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 totransfer the data.

However, since the primary objective of TASE.2 was to support the exchange of real-timeSCADA data or schedules and accounting information, the information needed waslargely independent of the source of the information. That is, the knowledge of thephysical device supplying measurands or status data was immaterial, as long as a powersystem model within the control center could make the association of the received pointdata with its location in the network topology. For that reason, point-oriented modelswere used to represent the data values received and control commands sent to anothercontrol center or substation host computer acting as a SCADA master for the subs tation.In other words, while an object model approach is used to define the data objects andservices, an anonymous point-oriented model is used to identify the values received anddevices controlled, as was done in WG3.

IEC 60870-6-503 defines the services and protocols, including a mapping of the abstractservices 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

3 The term control center here also includes power plants and automated substations that contain a hostcomputer acting as a SCADA master located within the substation itself.

4 The scope of TC57 and WG7 was later modified to embrace the use of TCP/IP for the Transport Layer aswell.



62357 © IEC:2011 - 23 -

60870-6-702 defines an Application Profile for the TASE.2 protocol stack in the upper 3layers. IEC 60870-6-505 is a User Guide for TASE.2.

3.3 61334 Standards from WG9

These standards developed by WG9 (inactive) support distribution automation usingdistribution line carrier systems. These standards address protocols for accessing

distribution devices in the field from distribution operations management systems overexisting distribution power lines.

The scope of these standards covers communications using distribution line carriertechnology on both, medium voltage (MV) and low voltage (LV) distribution networks. Thedistribution line communication system provides two-way communications which can beused for a large number of devices with various functions (e.g., station control units,remotely controlled feeder switches, meters, transformer station concentrators, portableinput unit, light control, load management, and traffic lights).

Standard 61334-4-1 defines the Reference Architecture based on the client-server model.In 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 ofdistribution devices. The protocol data units of the application protocol supporting the

model are described in Abstract Syntax Notation.1 (ASN.1). In addition, efficientencoding-rules are provided (61334-6).

The standard series 61334-5-1 to 61334-5-5 define several physical and Media AccessControl (MAC) layers using different modulation technologies suited for LV and MVcommunication. 61334-4-511 and -512 specify the management framework and themanagement procedures, respectively, for the 61334-5-1 profile. Standards 61334-3-21and -22 define the requirements for coupling the Distribution Line Carrier (DLC) signalsinto the MV line considering the necessary safety requirements.

3.3.1 Relation to "external" standards

The DLMS standard 61334-4-41 forms the basis for a series of standards developed byIEC TC13 WG14 for metering applications. In particular, series 62056 provides a

complete communication stack - including the meter device models - which is compatiblewith 61334-4-41.

3.4 61850 Standards for Power System IEC Communication and Associated DataModels from WG10

As the need for standards to address substation automation was ident ified, new workinggroups were formed (WG10-12) to develop standards for architectures and interfaceswithin substations and on distribution feeders. Because of similar and closely relatedobjectives, these three working groups eventually merged into a single working group – working group 10 which produces standards for power system IED communication andassociated data models. Work is underway to extend the scope of 61850 to includesubstation-to-substation communications and substation to control centercommunications

As the application use cases for 61850 expanded, two new working groups were createdto address these new areas:

WG17 – Communications Systems for Distributed Energy Resources (DER)

WG18 – Hydroelectric Power Plants – Communication for Monitoring and Control

The standards produced by WG17 and WG18 which are also part of the 61850 series ofstandards are discussed later in sections 3.9 and 3.10 respectively.



62357 © IEC:2011 - 25 -

Figure 3-1, Communication Interface Architecture for IEC 61850

Standardized mappings of these abstract services to different application layercommunication protocol profiles are defined in IEC 61850-8-x (client servercommunication and real time communication) / 61850-9-x (raw analog sample values), sothat common utility functions will be performed consistently across all field devicesindependent of the underlying communication stacks.

As descr ibed ear lier, the architecture of the “IEC 61850 bus” and its communicationservices enables bay/unit level devices to interact in a peer-to-peer fashion. It alsosupports the remote monitoring of these devices either directly (e.g., peer-to-peer) orthrough some type of information aggregator (e.g., sub-Scada master, RTU, or baycontroller) at the Station Level. However, the use of aggregation coupled with protocolconversion (e.g., a sub-Scada master that attaches to the “station bus” with IEC 61850,but transfers information to the Scada master through TASE.2 or IEC 60870) will typicallycause some IEC 61850 services to become un-available to the Scada master. Annex Ashows which parts of 61850 currently contain the mappings of the abstract services and ifthose services could be mapped through a TASE.2 aggregator.

3.4.2 Substation Configuration description Language

Another standard in the 61850 series is the configuration descript ion language for

communication in electrical substations related to IEDs, known as the SubstationConfiguration description Language (SCL), IEC 61850-6, an XML-based configurationlanguage for the binding of logical nodes (i.e., functional atoms within physical devices)to primary equipment, and specifying configuration and parameter data, and the structureand addressing of the communication network. The intended use is to provide aninteroperable way to exchange IED and SA system configuration information between theengineering tools of different (IED) manufacturers.



62357 © IEC:2011 - 27 -

systems, the CIS enables a single adapter to be built for a given infrastructure technologyindependent of who developed the other systems.

For a specific type of application, it is necessary to define what object classes andattributes are exchanged as well as what interface is used. These object classes andattributes typically consist of subsets or views of the CIM object classes. In other wordsthe CIM is used as the basis for “what” information is exchanged between applicationsand the CIS is used to define “how” data is exchanged between applications as well asdefining specific data content for each message (i.e., the message payload).

The CIS (or profiles) in use today are primarily used to define the data content forinteractions between systems, such as network model exchange between TransmissionSystem Operators (TSOs) or between Independent System Operators/RegionalTransmission Operators (ISO/RTOs) and distribution utilities. A series of profiles areplanned for additional information exchanges, such as a SCADA database or planningapplications and a historical archive. Since the intent of the EMS-API standards is todefine interface standards rather than to define standard applications, the scope of theseCIS can best be understood by considering the list of typical application categories thatwill be supported by the EMS-API standards. The application categories include, but arenot limited to, the following:

SCADA

Alarm Processing

Topology Processing

Network Applications (e.g., State Estimator, Optimal Power Flow, etc.)

Load Management

Generation Control

Unit Commitment

Load Forecast

Energy/Transmission Scheduling Accounting Settlements

Maintenance Scheduling

Historical Information System

External systems (e.g., Distribution Management Systems (DMS), weather,wholesale power marketing, etc.)

Asset Management

3.5.3 61970 Standards as an Integration Framework

Figure 3-2 illustrates the concept of an integration framework within a control centerbased on the use of EMS-API standards. Application data is integrated via theComponent Interfaces as specified in the EMS-API CIS standards. The CIS can be usedto solve not only application integration, but also the data integration required for datawarehousing and content management. The actual middleware technology (referred to asa Component Execution System (CES) in Figure 3-2) used to interconnect theapplications can be chosen by the system implementer from among the best of breed andis not the subject of the EMS-API standards. As long as the public appearance of thedata at the component interface to the CES conforms to the CIM and CIS standards, anyapplication that also conforms will be able to receive and interpret the data. The CIM thus



62357 © IEC:2011 - 28 -

provides the “common language” for information exchange and understanding betweenapplications possibly developed independently by different vendors, creating a modeldriven approach to integration for utilities as described earlier. The GID on the other handprovides for more complete interoperability by specifying how applications interact.

Component Execution System

and Component Adapters (e.g., Integration Bus)

Legacy

Wrapper

Programs Programs Programs

Alarm

Processor

LoadManagement

Generation

ControlAccounting/

Settlement

Programs

Public

DataTASE.2

Network

TASE.2

SCADA

Network

User

PCs

Programs CIM Server

Network

ApplicationsTopology

Processor

Public

Data

Public

Data

Public

Data

Public

Data

Public

DataPublic

Data

Programs

Public

Data

Distribution

Management

Systems

Component

Interface

Legacy

SCADA

System

Legacy

System

Programs

Figure 3-2, EMS-API Standards as an Integration Framework

The EMS-API standard requires that any data presented at the interface comply with thestandard regarding semantics and syntax, so that any application that wants to receivedata from another application should conform to the CIM and GID. For SCADA data, forexample, this means that a transformation must be made from the data representation ofthe protocol used to acquire the data to the CIM representation and the SCADA CIS,which employs an HSDA service interface, should be used for data exchange with otherapplications.

3.6 61968 System Interfaces for Distribution Management Standards from WG14

WG 14 was formed shortly after Working Group 13 to address the need for standards forSystem Interfaces for Distribution Management Systems (SIDMS). The IEC 61968 seriesis intended to facilitate inter-application integration of the various distributed softwareapplication systems supporting the management of utility electrical distribution networks.These standards define requirements, integration architecture, and interfaces for themajor elements of a utility‟s Distribution Management System (DMS) and otherassociated external IT systems. Examples of DMS include Asset Management Systems,Work Order Management Systems, Geographic Information Systems, CustomerInformation Systems, while Customer Resource Management is an example of anexternal IT system interface. The message-based technology used to mesh these



62357 © IEC:2011 - 29 -

applications together into one consistent framework is commonly referred to asEnterprise Application Integration (EAI); IEC 61968 guides the utility‟s use of EAI. Figure3-3 clarifies the scope of IEC 61968-1 graphically in terms of business functions.

Figure 3-3, Distribution Management System with IEC 61968 compliant interfacearchitecture

Standard interfaces are being defined for each class of applications identified in the IEC61968-1 Interface Reference Model (IRM), as shown in Figure 3-4 below. A series ofnormative CIM-based XML message payloads have been and are being defined for each

Part identified in the yellow boxes to ensure interoperability between the systems thatprovide the functionality shown in the green and magenta boxes. In addition to theseParts, the 61968 CIM is also being actively deployed for achieving the Smart Grid visionof interoperability from DMS systems to edge networks and networks. For example,message payloads based on the CIM are being defined for Demand Responseapplications as well as Zigbee Smart Energy (SE) profiles for home and buildingautomation.



62357 © IEC:2011 - 30 -

WG14 is using the Unified Modeling Language (UML) to define additional Real WorldObjects (RWO) classes in the CIM that are relevant to inter-application informationexchange in the distribution domain. The resulting CIM classes (specified in both 61970-301 and 61968-11) govern the semantics used in message types being defined for theInformation Exchange Model (IEM), which is to be included in IEC 61968 Parts 3-9.

XML is a data format for structured document interchange particularly on the Internet.One of its primary uses is information exchange between different and potentiallyincompatible computer systems. XML is thus well-suited to the domain of SystemInterfaces for Distribution Management. Therefore, where applicable, IEC 61968 Parts 3

to 9 will define document structures in XML. In addition to close cooperation with WG13,WG14 is also working collaboratively with the OAG to improve utilities' ability to integratebetween T&D applications (IEC TC57 domain) & Enterprise Resource Planning (ERP)applications (OAG domain). OAG message exchange is defined using XML.

As descr ibed above, WG14 is bas ing their standards on the same CIM as WG13, withextensions specifically needed for the distribution systems addressed in WG14. ThusWG14 and WG13 are both using the CIM for inter-application information exchange andbuilding an IEM as needed to define the specific semantics and syntax for theseexchanges.

Legend



62357 © IEC:2011 - 31 -

Note that the use of object modeling techniques internal to each of theapplications/systems integrated with either WG13 or WG14 standards is not arequirement or an issue here. It is only relevant for describing data at the interface thatis to be shared. Thus the CIM is the canonical language for semantics and syntax on thenetwork interconnecting applications/systems.

3.7 62351 Standards for Data and Communications Security from WG15

WG15 is chartered with undertaking the development of standards for security of thecommunication protocols defined by IEC TC 57, specifically the IEC 60870-5 series, theIEC 60870-6 series, the IEC 61850 series, the IEC 61970 series, and the IEC 61968series, as well as undertaking the development of standards and/or technical reports onend-to-end security issues.

The interrelationship of these security standards and the protocols are illustrated inFigure 3-5, Interrelationship of IEC 62351 Security Standards and the TC57 Protocols.

Figure 3-5, Interrelationship of IEC 62351 Security Standards and the TC57

Protocols3.7.1 Security for TCP/IP-based profiles

IEC 62351-3 provides security for any profile that includes TCP/IP. Rather than re-inventing the wheel, it specifies the use of TLS which is commonly used over the Internetfor secure interactions, covering authentication, confidentiality, and integrity. This partdescribes the parameters and settings for TLS that should be used for utility operations.

Specifically, IEC 62351-3 protects against eavesdropping through TLS encryption, man-in-the-middle security risk through message authentication, spoofing through Security

CIM-based 61850-based

WG3

Telecontrol

Protocols

WG20

Power Line

Carrier

Conveners

Advisory Group

CAG

Figure 3-4, 61968 Interface Reference Model (IRM)IEC 62351 -

1 Introduction IEC 62351 -

2 Glossary IEC 62351 - 3 TCP Profiles IEC 62351

- 4 MMS Profiles IEC 62351 - 5 60870 - 5 and derivatives

IEC 62351 - 6 IEC 61850 peer

-

to

-

peer

IEC 62351

-

7 Objects for Net Mgmt TASE.2 / ICCP IEC 101/102/103

IEC 61850 IEC 104 DNP3

IEC 62351 Secu r i ty Standards IEC 62351 -




IEC 62351 - 6 IEC 61850 peer

-

to

-

peer

IEC 62351

-

7 Objects for Net Mgmt TASE.2 / ICCP IEC 101/102/103

IEC 61850 IEC 104 DNP3

IEC 62351 Secu r i ty Standards IEC 62351 -




IEC 62351 - 6 IEC 61850 peer

-

to

-

peer

IEC 62351

-



62357 © IEC:2011 - 32 -

Certificates (Node Authentication), and replay, again through TLS encryption. However,TLS does not protect against denial of service. This security attack should be guardedagainst through implementation-specific measures.

3.7.2 Security for MMS ISO 9506

IEC 62351-4 provides security for profiles that include MMS, including IEC 60870-6

(TASE.2) and IEC 61850. It primarily works with TLS to configure and make use of itssecurity measures, in particular, authentication (i.e., the two entities interacting with eachother are who they say they are).

It also allows both secure and non-secure profiles to be used simultaneously, so that notall systems need to be upgraded with the security measures at the same time.

3.7.3 Security for IEC 60870-5 and Derivatives

IEC 62351-5 provides different solutions for the serial version of IEC 61870-5 (i.e., IEC60870-5-101) and for the networked versions (IEC 60870-5-104 and IEEE 1815).Specifically, the networked versions that run over TCP/IP can utilize the securitymeasures described in IEC 62351-3, which includes confidentiality and integrity providedby TLS encryption. Therefore, the only additional requirement is authentication.

The serial version is usually used with communications media that can only support lowbit rates or with field equipment that is compute-constrained. Therefore, TLS would betoo compute-intense and/or communications-intense to use in these environments.Therefore, the only security measures provided for the serial version include someauthentication mechanisms which address spoofing, replay, modification, and somedenial of service attacks, but do not attempt to address eavesdropping, traffic analysis, orrepudiation that require encryption. These encryption-based security measures could beprovided by alternate methods, such as Virtual Private Networks (VPNs) or “bump-in-the-wire” technologies, depending upon the capabilities of the communications andequipment involved.

3.7.4 Security for IEC 61850 Peer-to-Peer Profiles

IEC 61850 contains three protocols that are peer-to-peer multicast datagrams on asubstation LAN and are not routable. The messages need to be transmitted within 4milliseconds, so encryption or other security measures which affect transmission ratesare not acceptable. Therefore, authentication is the only security measure included, soIEC 62351-6 provides a mechanism that involves minimal compute requirements forthese profiles to digitally sign the messages.

The different communication profiles of IEC 61850 require security enhancements toensure that they can be implemented and used in non-secure environments.

1. Client/Server, which will specify security primarily through TLS and MMS, but mayinclude additional security measures such as VPNs

2. GOOSE – analogue and digital multicast

3. GSSE – digital only multicast, MMS involved4. GSE Management

5. SMV

3.7.5 Management Information Base (MIB) Requirements for End-to-End NetworkManagement

In addition to security standards for SCADA protocols, standards are also beingdeveloped to provide end-to-end security, which involves security policies, access controlmechanisms, key management, audit logs, and other critical infrastructure protection



62357 © IEC:2011 - 34 -

Once the Information Management requirements are defined, they can be structured asabstract objects, and formatted as standardized Management Information Base (MIBs) tobe compliant with information industry (i.e. IETF‟s Simple Network Management Protocol- SNMP) standards. The ISO CMIP and the IETF SNMP standards for NetworkManagement rely on Management Information Base (MIB) data to monitor the health ofnetworks. MIB data, which can be mapped to IEC 61850, 60870-5, or 60870-6 for powersystem operations, should be developed to support utility networks.This uses a broaderdefinition of security, with the concept that network management is a key component ofend-to-end security.

The primary purpose of the WG15 MIB development effort is to define what information isneeded to manage the power industry operations information infrastructure as reliably asthe power system infrastructure is managed, and to develop standardized MIBs for powerindustry operations. Two types of MIBs are planned:

MIBs for network management focused on the detection of security violationsand/or intrusions in communications networks used for power systemoperations.

MIBs for end devices or systems used in power system operations. Theseinclude information on the status of the systems, applications within thesystems, devices, etc.

3.8 62325 Standards for a Framework for Deregulated Energy MarketCommunications from WG16

This working group is chartered with developing a framework for deregulated energymarket communications with a focus on the interface between utilities and the energymarket (see Figure 3-8).

utility control functions(distribution, transmission,

generation)

marketparticipant

marketparticipant

utility businessfunctions

B2B

B2P

P2P

B2B

B2B = business-to-businessP2P = process-to-processB2P = business-to-process

relevant to process securityrelevant to business security

B2B

IEC TR 62210 focus onutility control functions security

market utility

„business security “

„process security “

Figure 3-8, Power Infrastructure Relies on Information Infrastructure



62357 © IEC:2011 - 37 -

Part of that challenge can be met by IEC 61850 object models for DER, as thestandardized communications interface for DER devices. Standardized communicationinterfaces permit the interoperability between different systems from different vendors,thus increasing the cost benefit to all owners, operators, and users of DER systems.

DER systems involve more than just turning a DER unit on and off. DER systems involvethe following:

Management of the interconnection between DER units and the power systemsthey connect to, including local power systems, switches and circuit breakers, andprotection.

Monitoring and controlling DER units as producers of electrical energy

Monitoring and controlling individual generators, excitation systems, andinverters/converters

Monitoring and controlling energy conversion systems, such as reciprocatingengines (e.g. diesel engines), fuel cells, photovoltaic systems, and combined heatand power systems

Monitoring and controlling auxiliary systems, such as interval meters, fuelsystems, and batteries

Monitoring physical characteristics of equipment, such as temperature, pressure,heat, vibration, flow, emissions, and meteorological information

The information requirements for DER systems are illustrated in Figure 3-10 below.These IEC 61850 DER object models cover all operational aspects of DER systems, butdo not address market operations.



62357 © IEC:2011 - 38 -

Figure 3-10, DER Interactions in Electric Power System Operations

3.9.2 IEC 61850-7-420

IEC TC57 WG17 is developing the communication architecture for integrating DER intothe IEC 61850 body of communication standards. IEC 61850-7-420 is the first standardto be produced by WG-17. It provides standards for object models for exchanginginformation with DER devices. DER devices are generation and energy storage systemsthat are connected to a power distribution system. Object models for four specific typesof DER are provided:

1. Photovoltaic systems

2. Reciprocating engines

3. Fuel cells

4. Combined heat and power

The approach taken by the working group in developing these models was to seek wide

applicability of the models. Accordingly, no assumption was made as to DER owne rship.Ownership could reside with a utility or an alternative party. No limitations were placedon the type of distribution system (networked or radial) or on where in the distributionsystem the DER might be located. The requisite distribution design engineering for DERinstallations must address the distribution system electrical issues and determine whereDER can safely be placed in the distribution system and what alterations to the electricalsystem may be needed. The focus is specifically on the ability to communicate with theDER and dispatch the services it may be intended to provide for the distribution systemoperator, such as emergency power and voltage support.



62357 © IEC:2011 - 39 -

The object models provide the structured, standard identification and naming of theattributes that need to be included in the information exchange with the DER. Theseobject models will become a part of the IEC 61850 body of communication standards forelectric power systems. The goal is to achieve interoperability of DER with the powersystem, including current components and new technologies that are coming in thefuture. Interoperability of all intelligent electronic devices (IEDs) in the system is desired,and DER is one such IED type. IEC 61850 is the principal body of internationalcommunication architecture standards evolving to support real-time automated operationof the power system of the future. As such, it is intended that the DER object models bea part of this communication architecture and not be used as a standalone entity. Inother words, if a power system operator specifies that DER should conform to the 61850family of standards, it is because they are intending to migrate their whole automatedsystem to 61850 conformity.

3.9.3 IEC 61850-90-7 DER Inverter Object Models

IEC 61850-90-7 is being developed as a Technical Report of IEC 61850 DER inverterobject models.

DER systems challenge traditional power system management. The increasing numbersof DER systems are also leading to pockets of high penetrations of these variable andoften unmanaged sources of power which impact the stability, reliability, and efficiency ofthe power grid. No longer can DER systems be viewed only a s “negative load” andtherefore insignificant in power system planning and operations. Their unplannedlocations, their variable sizes and capabilities, and their fluctuating responses to bothenvironmental and power situations make them difficult to manage, particularly as greaterefficiency and reliability of the power system is being demanded.

At the same time, DER devices cou ld become very powerful tools in managing the powersystem for reliability and efficiency. The majority of DER devices use inverters to converttheir primary electrical form (often direct current (dc) or non-standard frequency) to theutility power grid standard electrical interconnection requirements of 60Hz (or 50Hz) andalternating current (ac). Not only can inverters provide these basic conversions, butinverters are also very powerful devices that can readily modify many of their electrical

characteristics through software settings and commands, so long as they remain withinthe capabilities of the DER device that they are managing and within the standardrequirements for interconnecting the DER to the power system.

DER systems are becoming quite “smart” and can perform autonomously according topre-established settings. They can “sense” local conditions of voltage levels, frequen cydeviations, and temperature, and can receive broadcast emergency commands andpricing signals, which allow them to modify their power and reactive power output. Theycan also operate according to schedules or in response to direct control commands.

Given these ever more sophisticated capabilities, utilities and energy service providers(ESPs) are increasingly desirous (and even mandated by some regulations) to make useof these capabilities to improve both power system reliability and efficiency.

61850-90-7 covers many of the key inverter functions, including:

Immediate control functions for inverters

Volt-VAr management modes

Frequency-watt management modes

Voltage management settings for dynamic grid support during voltage dips



62357 © IEC:2011 - 40 -

Watt-power factor management modes

Voltage-watt management modes

Non-power-related modes

Parameter setting and reporting

At least three levels of information exchanges are env isioned:

Tightly-coupled interactions focused on direct monitoring and control of theDERs with responses expected in “real-time”.

Loosely-coupled interactions which request actions or “modes” that areinterpreted by intelligent DER systems for undertaking autonomous reactions tolocal conditions or externally provided information. Information is then sent backon what actions they actually performed.

Broadcast/multicast essentially one-way requests for actions or “modes”,without directly communicated responses by large numbers of DERs.

These different DER management interactions are shown in Error! Reference sourcenot found.3-11.

Figure 3-11, DER Management Interactions

3.10 61850 Standards for Hydroelectric Power Plants from WG18

This working group is chartered with developing standards for hydro power plant

communication, monitoring, and control. The approach is to extend the present IEC61850 models to also cover hydroelectric power plants. The initial work of WG10 waslimited to substations. Since IEC 61850 provides detailed models for all field equipment,additions must be made whenever the standard is to be used for a new field ofapplications. While most of the electric equipment in a power plant is already covered bythe current version of IEC 61850, in order to fully support the requirements of hydropowerplants, new models (logical nodes) for turbines and related equipment, dams, gates, etc.are needed.

DER System, with Autonomous Behavior

DER

Generator

DERStorage

Controller

Controller

DER Energy Management

System at Utility Site or

Customer Site

Distributed Energy Resources (DER) Site

One-way Broadcast/

Mult icast of Mode

and/or Schedule

Requests

Loosely -coupled

Two-way Interactive

Requests

Tightly-coupled

Direct Control

Tightly-coupled

Direct Control

DER Management: Interactions between Components

Loosely -coupledTwo-way Interactive

Requests

Utility/ESP DER

Management System

Broadcast/Mult icast

OR

Loosely-coupled Interactive

OR

Tightly-coupled Direct Control



62357 © IEC:2011 - 41 -

Most of the Logical Nodes defined by WG18 are not specific for hydropower plants; theycan be of use in any type of plant in a power system (e.g., all sensor logical nodes).There are some conceptual deviations from the original principles of IEC 61850; one suchmodification relates to the specification of more or less generic logical nodes. Ratherthan having a number of logical nodes that are named after what they control, theworking group decided to name them after the basic algorithm used, or behaviour of thefunction, and is proposing a prefix naming structure to define what they are controlling.

3.10.1 Basic concepts for hydropower plant control and supervision

3.10.1.1 Functionality of a hydropower plant

Figure 3-123 below is based on the substation structure described in IEC 61850-6. Atypical power plant will include a “substation” part that will be identical to what isdescribed in the IEC 61850 series. The generating units with their related equipment areadded to the basic structure.

A generating uni t consists of a turbine – generator set with auxiliary equipment andsupporting functions. Generator transformers can be referenced as normal substationtransformers; there is not always a one-to-one connection between generating units andtransformers.

The dam is a different case. There is always one dam associated with a hydropowerplant. There are however reservoirs that are not related to any specific power plant aswell as power plants from which more than one dam is being controlled. While all otherobjects can be addressed through the power plant, dams might have to be addresseddirectly.

Figure 3-12 – Structure of a Hydropower Plant

There is, however, no standardised way of arranging overall control functions; thestructure will depend on whether the plant is manned or remotely operated, as well astraditions within the utility that owns the plant. In order to cover most arrangements, someof the Logical Nodes defined in this standard are more or less overlapping. This will allowthe user to arrange Logical Devices by selecting the most appropriate Logical Nodes thatsuits the actual design and methods of operation of the plant. Other Logical Nodes arevery small, in order to provide simple building blocks that will allow as much freedom aspossible in arranging the control system.

TASE.2 /

IEC

IEC 61850

IEC 104

IEEE

Riv

Hydro station Unit

7 Ob ects



62357 © IEC:2011 - 43 -

Synchronised in condenser mode (- in motor mode) – The generator is synchronised.However it does not primarily produce active power. In condenser mode it will produce orconsume reactive power; in motor mode (for pumped storage), it consumes active power.

PSS control – The Power Swing Stabiliser device has detected a power swing in the gridto which the generator is connected and uses the vol tage control function trying to reduceit.

Island operation mode – The external network has been separated and the power plantmust control the frequency.

Local supply mode – In case of a larger disturbance of the external network, one or moregenerators in a power plant can be set at minimum production to provide power for localsupply only. This type of operation is common in thermal power plants to shorten thestart-up time once the network is restored, but can also be used in hydropower plants forpractical reasons.

3.11 WG19 Harmonization

The charter of WG19 is to address harmonization issues between the other TC57 workinggroups and to chart a roadmap for future standards development in TC57. As such,

WG19 functions primarily as an architecture board, providing the expertise needed todeal with technical issues that cross individual working group boundaries. WG19 mayalso produce standards and/or technical reports that cross individual working groupboundaries (e.g., XML Naming and Design Rules).

WG19 deals with the technical strategies for TC57 while the Convener Advisory Group(CAG) comprised of all the WG conveners serves as an advisory board for overallcoordination of TC57 and its relationship to other IEC technical committees.



62357 © IEC:2011 - 45 -

Application To Application (A2A)

and Business To Business

(B2B) Communications

Market Operation

Apps

60870-6-503

App Services

SCADA Apps EMS Apps DMS AppsEngineering &

Maintenance AppsExternal

IT Apps

Data Acquisition and Control Front-End / Gateway / Proxy Server / Mapping Services / Role-based Access Control

61850-8-1

Protocols

TC13

WG14

Meter

Standards

61334

DLMS

60870-5

101

&

104

61970 Component Interface Specification (CIS) / 61968 SIDMS

61970 / 61968 Common Information Model (CIM)

Inter-System / Application Profiles (CIM XML, CIM RDF)

61850Substation

Devices

61850 IED

DevicesBeyond the

Substation

60870-6

TASE.2

60870-5

RTUsor

Substation

Systems

IEDs, Relays, Meters, Switchgear, CTs, VTs

E n d - t o - E n d S e c u r i t y S t a n d a r d s a n d R e c o m m e n d a t i o n s ( 6 2 3 5 1 - 6 )

IEC TC57 - Reference Architecture for Power System Information Exchange

External Systems

(Symmetric client/server

protocols)

Specific Communication

Services Mappings

Specific Object

Mappings

Application/System

Interfaces

Equipment and Field

Device Interfaces

Communication Industry Standard Protocol Stacks(ISO/TCP/UDP/IP/Ethernet)

Object Models

61850-6

Engineering

Protocol Profiles

Field Devices

and Systems

using

Web Services

Communications

Media and Services

Field

Devices

Utility Customers

Energy

Market

Participants

Other

Businesses

Utility

Service

Providers

N e t w o r k , S y s t e m , a n d D a t a M a n a g e m e n t ( 6 2 3 5 1 - 7 )

TC13

WG14

*Notes: 1) Solid colorscorrelate different parts of protocols within thearchitecture.

2) Non-solid patterns represent areas that are futurework, or work in progress, or related work provided by another IEC TC.

61850-7-2

ACSI

61850-7-3, 7-4

Object Models

Customer

Meters

Peer-to-Peer 61850over

Substa tion bus and Process

bus

60870-6-802

Object Models

60870-6-702

Protocols

Field ObjectModels

Technology Mappings

CIM Extensions Bridges to Other Domains

DERs

and Meters

Other

Control Centers

Mapping to

Web Services

Figure 4-1, Current Reference Architecture for Power System Information Exchange



62357 © IEC:2011 - 46 -

Application Interface: the view looking i nwa rd toward other layer 4applications/systems (e.g., back office systems) or external systems, such as EnergyMarket Participants, Utility Customers, Utility Service Providers, or other businesses forthe purposes of exchanging information. In this view, the layer 4 applications/systemsinteract with each other as peers, typically using either a client/server model, where eachsystem may function as both client and serve, or an event-driven model, where anapplication publishes to multiple subscriber applications.

Information exchange between these applications/systems on the application interface isbased on the semantics and syntax specified in the 61970/61968 CIM standards. Thecomplete specification of the message contents and behavior associated with thesemessages are specified in the 61970 CIS for control center applications and in the 61968SIDMS for DMS applications and systems being developed by Working Groups 13 and14, respectively. These standards are shown in the upper layers of the reference model.

Some applications/systems in layer 4 have both equipment and system interfaces as wellas application interfaces, such as SCADA, inter-control center communications, or someDMS applications. In these cases, whereas the system acts as a client regarding theequipment and system interface, it acts in turn as a server on the application interface,being a source of data to other applications. For example, a SCADA system with an ACSI

client which talks to ACSI servers using 61850 standards to access data from substationand field devices, now may act as a server using 61970 standards to exchange data withEMS applications, such as Topology Processor or State Estimator, in a control centerenvironment.

4.2 SCADA Interfaces

Among the applications shown is SCADA for real -t ime data acquisition and devicecontrol. While there are several protocol/service and interface standards in TC57 forSCADA operations on the equipment and system interface, as shown in the referencearchitecture, the 61970 SCADA CIS defines the standard SCADA data representation andGID service for exchanging SCADA data with other EMS/DMS applications for real-timeoperation and control on the application interface.

As can be seen, there are several standar ds def ined for access ing substation and fielddevices. These include standards from WGs 3, 9, and 10 plus standards from other TCs.TASE.2 from WG7, while intended primarily for inter-control center communications, canalso be used to access SCADA data in a substation when a SCADA master is located atthe substation itself.

The data representation and service used to expose data is different for each of theseworking groups as defined in their respective standards (i.e., 60870-5, 60870-6, and61850) as previously described. Therefore, there is a need to have the SCADA datarepresentations from each of these SCADA services to be harmonized with the CIMrepresentation of SCADA data. There are two approaches to accomplish this:

1. Provide for data transformation processing in the SCADA system or at theinterfaces to the SCADA system using the existing standards models.

2. Resolve the differences in models within the developing standards before theybecome finalized to negate the need for real-time data transformation. In fact,work is in progress in WG19 to achieve this harmonization between IEC 61850and the 61970 CIM on an object model level.

Each of these approaches is described in more detail in the following two sections.



62357 © IEC:2011 - 47 -

4.2.1 Data Transformation via Gateways and Adapters

Figure 4-2 illustrates the relevant interfaces and the transformations required when thesestandards are applied today. SCADA data received via 60870-6 TASE.2 links from eitheranother control center or from a SCADA master in a substation is transformed in theTASE.2 Adapter to be compliant with the 61970 CIM. More specifically, it is transformedto comply with the SCADA CIS defined as part of the EMS-API standards. In this case,

the GID HSDA service is used to expose the data. This data is then exposed to theintegration bus via one of the standard interfaces. In a similar fashion, SCADA datareceived via 61850 ACSI links from either substation or field devices is transformed in the ACSI Adapter to be compliant with the CIM and the same HSDA service inter face.SCADA data from an existing SCADA system that uses the 60870-5 standards, IEEE1815, or some proprietary RTU protocol is transformed by a custom SCADA System Adapter to be CIM/GID-compliant.

The effect of the use of adapters is that all SCADA data, regardless of theprotocols/services and data representation used to obtain the data from the field or fromother control centers, has the same representation on the integration bus. This meansthat any applications that operate on SCADA data, including data repositories orhistorical information systems, need to be designed to support only a single interface, the61970 EMS-API CIS SCADA interface, to be able to be integrated into a systemframework.

Historical

Information

System

Database

Adapter

Database

Adapter

EMS

Proprietary

Database

TASE.2

Adapter

ACSI

Adapter

SCADA

System

Adapter

TASE.2

Blocks

1&2

ACSI

Discovery/

Reporting

SCADA

System

Control

Center

Substation

Device Device

Substation

RTU

Bus Connector Bus Connector

Integration Bus

61970

60870-5, DNP, Proprietary

Proprietary6185060870-6

Figure 4-2, SCADA Data Interfaces



62357 © IEC:2011 - 48 -

Figure 4-2 also illustrates the use of database adapters to transform data fromproprietary representations in an EMS database or from industry standardrepresentations in a Historical Information System to the CIM representation for accessvia the integration bus.

4.2.2 Harmonization of the Data Models

Although adapters will always be required to trans late proprietary data formats in legacysystems, a goal is to harmonize standards within TC57 so that a single representation ofSCADA data is used in all TC57 standards, thus eliminating the need for translation inadapters. This would lead to a seamless architecture and is part of the vision of thefuture reference architecture described in Chapter 7.

In the mean time, efforts have been undertaken to harmonize existing standards to themaximum extent possible. These efforts are somewhat constrained by the fact that manyof these standards have been published and are extensively implemented in existingproducts and systems, so there is some resistance to change at this point. However,harmonization has been achieved in some key areas and more is planned. Chapter 6describes these efforts.

4.3 Inter-Control Center Data Links

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

The data representation in 60870-6-503 and –802 is not harmonized with the CIMrepresentation. However, since these standards are now in wide use, it seems that datatransformation is the only practical answer in the near term. The mapping of TASE.2objects to the CIM is a work in progress.

There are additional standards for exchanging metadata information between controlcenters that are not shown in the reference architecture. An XML version of the CIM isused to exchange power system models between control centers, where the XML tags

are based on the CIM classes and attributes. Standards exist for transferring thefollowing:

Complete models,

Partial models (i.e., add a new substation), and

Incremental updates to existing power system models (i.e., change the resistan ceand reactance of an AC line, remove a load, etc.).

Since the files transferred are XML documents, any protocol that can transport an XMLdocument can be used, such as FTP over TCP/IP or GID-based Web services usingSOAP over HTTP.

4.4 EMS Applications

Most EMS applications rely on the SCADA application or inter-control center data links toprovide real-time operational data. As a result, there are no relevant TC57 standards onthe equipment and system interface side of these applications, so there are no data orobject model harmonization issues between TC57 standards.

However, there are issues between proprietary interfaces used in the many EMSapplications currently available from EMS vendors and the CIM/GID standards contained



62357 © IEC:2011 - 49 -

in the 61970 standards being developed by WG13. In actual deployment of thesestandards, one of two possible integration scenarios is possible:

1. Existing EMS applications are “wrapped” to transform the existing proprietaryapplication interface to the interface specified in the CISs and the datarepresentation specified in the CIM.

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

4.5 DMS Applications and External IT Applications

The distinction between application interfaces and equipment and system interfaces blurssomewhat with DMS applications/systems such as Asset Management, Work OrderManagement, Geographic Information, Customer Information, etc., which are designedprimarily as stand-alone systems. The exception is Network Operations, which interfacesto field devices and distribution feeders via the Equipment and System Interface usingthe 61334 power line carrier, TC13 WG14 Meter Standards, or any of the other protocolsshown. All other interfaces between these systems and with external IT systems that arenot strictly utility systems, such as Customer Resource Management, are the subject ofthe 61968 standards. Since the CIM provides the model for information exchangebetween these systems, the interfaces are considered as application interfaces in Figure4-1.

4.5.1 Substation/Field Devices

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

As described in Section 4.2, RTUs provide limited access to typical SCADA point-oriented data only via 60870-5 standards. Since these standards are published and quitemature, the only practical approach to harmonization i s through data transformation in thecontrol center.

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

Although not shown in the diagram, 61850-6 def ines an XML-based configurationlanguage for the binding of logical nodes (i.e., functional groups within physical devices)to primary equipment, configuration data, and the structure of the communicationnetwork. The intended use is to provide an interoperable IED and system configurationdata exchange between engineering tools of different manufacturers.



62357 © IEC:2011 - 51 -

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 therelationships between them. The objects represented in the CIM are abstract in natureand may be used in a wide variety of applications.

The CIM is described in class diagrams using UML notation. While the model ispartitioned into several packages for convenience, as shown in the following figures, it isactually one single inter-connected class diagram. A package is a general purposemeans of grouping related model elements. There is no specific semantic meaning. Thepackages have been chosen to make the model easier to design, understand and review.The Common Information Model consists of the complete set of packages. Entities mayhave associations that cross many package boundaries. Each application will useinformation represented in several packages.

Many aspects of the power system of concern to TC57 are modeled only in the CIM, suchas generation equipment, generation dynamics, schedules, energy schedules, financial,and reservations. Other parts of the power system are modeled in both the CIM andelsewhere (e.g., IEC 61850), such as substation equipment including transformers,switches, breakers, etc.

Figure 5-1 shows the top-level package structure defined for the CIM. The dashed linesindicate a dependency relationship, with the arrowhead pointing from the dependentpackage to the package on which it has a dependency.



62357 © IEC:2011 - 52 -

Figure 5-1, Common Information Model (CIM) Top-Level Packages

Figure 5-2 shows the packages included in the 61970 CIM standards.

At the time of this edit ion was prepared, addit ions to the 61970 CIM are being approv edto add a Graphics package to support exchange of diagrams, such as one-lineschematics, and to add dynamic equipment models that can be associated with theexisting static models for generators and loads, for example, to enable informationexchanges for dynamic system assessment and planning studies that require systemsimulation.

class PackageDependencies

TC57CIM::CombinedVersion

+ date: AbsoluteDate [0..1] = 2011-02-05 {readOnly}

+ version: Str ing [0..1] = iec61970CIM15v1... {readOnly}

IEC6197

(from TC57CIM)

PackageDependenciesCIMVersion


+ version: String [0..1] = 2 {readOnly}

IEC61968

(from TC57CIM)

IEC62325

(from TC57CIM)

PackageDependencies

(from TC57CIM)

IEC62325::IEC62325CIMVersion


+ version: Str ing [0..1] = IEC62325CIM01v03 {readOnly }

IEC61968::IEC61968CIMVersion


+ version: Str ing [0..1] = IEC61968CIM11v06 {readOnly }

IEC6197 ::IEC6197 CIMVersion

{root}


+ version: Str ing [0..1] = IEC61970CIM15v15 {readOnly}



62357 © IEC:2011 - 53 -

Figure 5-2, IEC 61970 CIM Packages

Figure 5-3 shows the major packages included in the IEC 61968 CIM standards. They areorganized by Part number from the Interface Reference Diagram (IRD) described inSection 5.1.4. The packages shown are all normative, in that there are normativeinterface standards that reference their contents. There is also an Informative grouppackages that contain many additional packages that have no normative interfacestandards at this time which use the classes contained in these packages. As interfacestandards are defined, the contents of the applicable packages will be validated andmoved to normative status.

class Main

Equivalents

Protection

SCADA

Genera tion

OutageoadModel

Topology

Meas

Wires

Domain

Core

IEC6197 CIMVersion

{root}


+ version: String [0..1] = IEC61970CIM15v15 {readOnly}

OperationalLimits

ControlArea

GenerationDynamics

(from Generation)

Production

(from Generation)

Contingency



62357 © IEC:2011 - 54 -


Figure 5-4 shows the major packages included in the IEC 62325 CIM standards whichprovide a framework for deregulated energy market communications. These models aregrouped into four major packages: MarketOperations, Financial, Reservation, andEnergyScheduling.

pkg IEC61968Overview

IEC61968CIMVersion

+ date: Date [0..1] = 2011-04-27

+ version: String [0..1] = IEC61968CIM11v10

Meter ing Pay mentMeter ing

Par ts 4, 13

Part 6

Part 8

Part 9

Common

Assets

Work

Customers

LoadControl

AssetInfo



62357 © IEC:2011 - 55 -


5.1.2 CIM Classes and Relationships

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

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

It should also be noted that the CIM is defined to facilitate data exchange. As defined inthis document, CIM entities have no behavior other than default create, delete, update

and read. In order to make the CIM as generic as possible it is highly desirable to make iteasy to configure for specific implementations. In general it is easier to change the valueor domain of an attribute than to change a class definit ion. These principles imply that theCIM should avoid defining too many specific sub-types of classes. Instead the CIMdefines generic classes with attributes giving the type name. Applications may then usethis information to instantiate specific object types as required. Applications may needadditional information to define the set of valid types and relationships.

Classes have attributes that describe the characteristics of the objects. Each class in theCIM contains the attributes that describe and identify a specific instance of the class.



62357 © IEC:2011 - 56 -

Only the attributes that are of public interest to EMS appl ications are included in the classdescriptions.

Each attribute has a type, which identifies what kind of attribute it is. Typical attributesare of type integer, float, boolean, string, and enumeration, which are called primitivetypes. However, many additional types are defined as part of the CIM specification. Forexample, CapacitorBank has a MaximumActivePower, attribute of type Voltage. Thedefinition of data types is contained in the Domain Package.

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

The use of the CIM goes far beyond its application in an EMS. This standard should beunderstood as a tool to enable integration in any domain where a common power systemmodel is needed to facilitate interoperability and plug compatibility between applicationsand systems independent of any particular implementation.

The original purpose of the CIM was to model that portion of the power system of interestto EMS applications being handled in WG13. However, the scope has since been

broadened to embrace the scope of WG14, and therefore now includes models neededfor DMS applications and systems. Additional extensions to support market operationsare expected in the future.

Some of the important features of the CIM are:

The CIM is hierarchical . Attributes common to more than one subclass of object areinherited from a common class.

The CIM is normalized . All attributes are unique and belong to only one class,although they may be incorporated into other classes via one of the classrelationships supported, which include generalization, association, andaggregation. This makes the model useable by a variety of applications, all ofwhich may not have been foreseen when the CIM was originally constructed. The

alternative is make the model de-normalized, creating new classes and duplicatingattributes to optimize the structure for each application‟ s view of the model.

The CIM is static. The CIM is an information model wherein a physical object may berepresented by a number of interrelated classes. Since no specific application wasin view when the model was constructed, the objects that an application may wantto access through some method may not be represented by a single class. Thatis, the CIM comprises many “small objects”, not necessarily the “big objects” thatwould be subject of some operation by an application. Therefore, it is notappropriate to try to add operations/methods to the actual class definitions in theCIM.

The CIM is modeled in UML . The entire CIM exists as a UML model file viewablewith UML modeling tools as well as in an Internet browser using the HTMLversion. This unified model includes definitions of all the classes, attributes, types,

and relationships as well as class diagrams created to assist viewers inunderstanding and referencing various parts of the model. Viewing the CIM in thisfashion provides a graphical navigation interface that permits all CIM specificationdata to be viewed via point-and-click from the class diagram in each package.

The CIM IEC standards documents are auto-generated using the electronic UMLmodel.

The CIM has a representation in XML. Power system models are represented inXML using the RDF Schema and a simplified RDF syntax as a part of the 61970



62357 © IEC:2011 - 59 -

beneath some generic UML models used to document the general concepts, 61850 usestables and text for object modeling rather than UML. The ASN.1 language is used in theprotocol mapping (SCSM) for describing the abstract structure of the data present in amessage. It does so by providing a notation for structured data types and referring toMMS basic data types.

The following sections provide more detail on 61850 ACSI and SCL.

5.2.1 61850 ACSI

In ACSI, a client/server model is assumed, in which the client initiates transactions thatare processed by the server. The ACSI server hides real data and devices, using objectsto represent them instead. Objects that are directly accessible by a client through anetwork are contained in an object from the server class. The servers, and the objectinstances they contain, are mapped to the communication stacks for communication withthe real devices. Figure 5-6 illustrates this concept.

ACSI Client

Real

Data/DevicesACSI Server

(Virtual World)

Object

Object

Object

ACSI

Services

Virtual Device

H i d e / e n c a p s u l a t e r e a l W o r l d

Figure 5-6, ACSI Client/Server Model

5.2.1.1 Logical Devices

Logical Devices are a composite of function atoms, which are represented by LogicalNodes, and which have to be commonly managed. The collection of these Logical Nodesprovides the functionality of the logical device. A physical device can implement one ormore logical devices. For example, a distribution relay device might include severalstandardized relay functions. In addition, an electronic distribution relay would likely havea capability to measure the voltages and currents in the conductors it is controlling. Torepresent this device in 61850, a Logical Device would be created that contained a

nameplate, Device Identity, a measurement unit Logical Node, and one or morestandardized relay function Logical Nodes. Alternatively, the physical device can containa logical device for measurement and a logical device for protection.

It should be noted that 61850 allows for arbitrary assembly of Logical Nodes into LogicalDevices. The composition of a Logical Device is left to the manufacturer and can alwaysbe determined by reading the SCL description of the physical device, or by browsing aninstance of a physical device with the ACSI directory services.



62357 © IEC:2011 - 60 -

With the use of SCL offline or the ACSI directory services online, the online properties ofeach IEC61850 server device can be discovered and used to populate a database in thecontrol center. Any changes in the field (i.e., new installations, revisions to existinginstallations, removal of field equipment, etc.) can be discovered automatically as thechanges are made, rather than requiring a separate manual data entry at the controlcenter.

5.2.2 SCL Modeling Language

SCL is used to describe IED configurations and communications systems defined in the61850-5 and -7xx standards. The main purpose is to allow the exchange of IED andcommunication system configuration data between an IED configuration tool and asystem configuration tool from different vendors. Files created using SCL are also usedto transfer the IEC configuration data from the IED configuration tool to IEDs in theswitchyard.

5.2.2.1 SCL Uses and Data Exchanges in the Engineering Process

Figure 5-7 below illustrates the types of data exchanges where SCL is used. The textboxes describe the type of information exchanged.

Figure 5-7, How SCL Files Are Used To Exchange IED Configuration Data

5.2.2.1.1 System Specification – SSD File

As shown in Figure 5-8, an SCL file may be generated by planning applications to supplythe system specification to a system configuration tool (i.e., System Configurator). Thesystem specification comprises a single line diagram with an allocation of logical nodes(LNodes) to parts and equipment in the single line diagram to indicate the neededfunctionality. This uses the SCL file type SSD as defined in 61850-6.



62357 © IEC:2011 - 61 -

5.2.2.1.2 IED Capability Description – ICD File

An SCL fi le may be used to provide data on pre-configured IEDs to the Sys temConfigurator. The file may originate from either (1) an IED database or (2) exporteddirectly by a tool from the IED. This data consists of LNode description type definitionsand may contain optional substation model information. This data exchange uses SCL filetype ICD.

5.2.2.1.3 Substation Automation System Description – SCD File

An SCL fi le is used to transfer a complete system configuration from the SystemConfigurator to an IED configuration tool (i.e., IED Configurator). The systemconfiguration specifies how IEDs are bound to process functions and primary equipmentusing the IED and Substation parts of the SCL model (see following clauses for adescription of the SCL model). This system configuration also includes the substationcommunications configuration information in terms of the access point connections foreach IED and possible subnetwork paths for clients to access them using the IED andCommunication parts of the SCL model. This data exchange uses SCL file type SCD.

5.2.2.1.4 IED Configuration Description – CID File

An SCL fi le can be used to transfer configuration data from the IED Configurator to an

IED. The configuration data contains a communications section (using theCommunications part of the SCL model) with the assigned address of the IED. If anoptional substation section (using the Substation part of the SCL model) is included, itwill provide the name values assigned. This file is essentially the same as the SCD filestripped down to only what the targeted IED needs in the way of configurationinformation.

5.2.2.2 SCL Model in XML

There are three parts to the SCL model(see Figure 5-88):

1. Substation part. This is a hierarchical model describing switchyard equipment(Substation, VoltageLevel, Bay, and Equipment) from a functional view and theirinterconnection via Terminal and ConnectivityNode. These classes have direct

parallels in the CIM. The model also includes classes for Function, Subfunction,SubEquipmentPhase, and separate classes for individual devices, but not basedon the CIM (e.g., CBR for circuit breaker)

2. Product (IED) part. This part models substation automation equipment, such asIEDs, and the application level communications between them (i.e., how data isgrouped into data sets for sending, how IEDs trigger the sending and whichservice they choose, which input data from other IEDs is needed by an IED). Todo this the model defines classes for LNode, Data, LDevice, Server, Router,Clock, and IED. These classes are not modeled in the CIM.

3. Communication part. This part models how IEDs are physically interconnected vianetworks and subnetworks and specifies which communications ports are used.

The model comprises Subnetwork and AccessPoint classes for this purpose. Thecommunication connections between IEDs are described in terms of logical nodesas clients and servers. This is not modeled in the CIM.



62357 © IEC:2011 - 63 -

5.2.2.2.2 Product (IED) Model

The product model only covers the IEDs that form the substation automation equipment,not the primary switchyard equipment. Primary devices as products are outside the scopeof SCL, only their functional side is modelled by the substation hierarchy for functionalnaming purposes.

5.2.2.2.3 Communication ModelThe purpose of this model is to model the possible logical connections between IEDs viaaccess points and subnetworks. Client LNodes use the address attribute of the accesspoint to build up associations to server LNodes on other IEDs.

5.3 TASE.2

The TASE.2 models represent a virtual control center rather than an individual substationor field devices. The TASE.2 models for SCADA operations are point-oriented, asexplained earlier. That is, there are no models of physical devices being monitored orcontrolled. Management of physical devices in the field was not within the scope of WG7,so there is no provision for configuration of devices or discovery of new devices as thereis in the 61850 standards.

Regarding data acquisition with TASE.2, the assumption is that the topologicalinformation associated with point data received via TASE.2 is stored locally in a powersystem model in the receiving control center database. TASE.2 provides updates tomeasurement and status values using a unique reference number for each point that wasagreed to by both sending and receiving control centers when the Bilateral Tables usedfor access control are established.

5.4 Data Modeling Techniques Used

5.4.1 61850

IEC 61850 uses UML diagrams and text to document the basic ideas behind the function,data and service models, and then describes the details by means of text and tables.SCL (which is defined in 61850-6 and is based on XML) is used to describe the IED

configurations and communications systems defined in the 61850-5 and -7xx standards.While UML is used to show the relations between SCL model parts and elements, SCL isused to document the abstract data model in terms of XML elements and data types.

5.4.2 61968, 61970

IEC 61968 and 61970 use UML to define the abstract information model in thesestandards. UML class diagrams are used to document the CIM in its entirety in terms ofUML classes, attributes and relationships. Although UML is used, certain conventionsdefined in the UML standards are not strictly followed. For example, although the UMLspecification may state that all attributes defined for a class are mandatory, in the CIMeach attribute is treated as optional. So in this sense, the CIM serves as a semanticmodel or common language for information exchange.

For a given application of the CIM, it is therefore important to define external to the CIMwhich classes, attributes, and relationships are in fact mandatory and which are optionalto ensure interoperability between different users of the CIM model. These are defined asProfiles in the 61970 series of CIM standards. An example is the NERC minimum datarequirements for a Common Power System Model (CPSM) used to exchangetransmission power system models.

The 61968 series of information exchange standards define message payloads instead ofprofiles. These standards specify which CIM classes are mandatory and optional for



62357 © IEC:2011 - 64 -

business transactions of various types. The standards are defined as XML schemas formessages, where the XML elements and attributes are based on the CIM class attributes.

5.5 Service Model Techniques Used

5.5.1 61850

The 61850 services are task specific (i.e., device specific). Device communication is

tightly coupled. In this case a client needs to be assured that it has control of a server.The services defined in ACSI include:

Association – the services to establish an association between a client and aserver. With the exception of the high-speed peer-to-peer services, all otherservices of IEC 61850 rely on an established client – server association.

Get or Set Data – A general purpose request/reply interface for reading orwriting data objects defined in the IEC 61850 run-time model.

Controls – Several services for writing data with varying levels of reliabilitychecking and confirmation beyond that of a simple “set” operation. Used foroperating equipment within the substation.

Data Sets – The ability to group together data under a single name forreading, writing, reporting or logging. May be grouped statically atconfiguration time or dynamically at run-time.

Reporting – Unsolicited Reporting services used by a server to spontaneouslytransmit data to a single client either periodically or when the data changes.Reports may or may not be buffered at the reporting device, depending on thelevel of reliability required. Intended for maintaining synchronization of run -time databases.

Logging – Services to store events locally in the server and to retr ieve them asneeded by the client.

High-Speed Peer-to-Peer – Several services that are similar to reportingexcept that data is multicast to many devices in a substation simultaneously

using a very efficient transport profile. The Generic Object-Or ientedSubstation Event (GOOSE) service is intended to replace point-to-point logicconnections between protection relays and typically carries informationrequired for interlocking logic for control devices. Sampled Measured Value(SMV) service transmits waveform samples in real-time.

Self-Description – a set of services permitting a client to query the run-timemodel in use within a device at any given moment.

Settings Groups – a set of services used to change configurations quickly atrun-time without restarting the device. Permits a new set of parameters to be“pre-loaded” by a client and then switch them all into use together with asingle request.

Substitution – A service intended to temporarily “force” data to certain values,

typically during upgrades of the system, to hide the fact that the realmeasurements are corrupted or not available.

File transfer – the ability to read or write files of data for purposes that may berelated to configuration, logging, fault recording, or any of several othersubstation applications.

5.5.2 61968

IEC 61968-1-1 and 61968-1-2 (soon to be replaced by 61968-100) specify Webservice implementation profiles and JMS profiles, respectively, for enterprise



62357 © IEC:2011 - 65 -

integration. More specifically these documents describe how message payloadsdefined by Parts 3-9 of IEC 61968 are conveyed using Web Services and theJMS. Guidance is also provided with respect to the use of Enterprise service Bus(ESB) technologies. The goal is to provide details that would be sufficient toenable implementations of IEC 61968 to be interoperable. In addition, thisdocument is intended to describe integration patterns and methodologies thatcan be leverages using current and future integration technologies. Web ServiceDescription Language (WSDL) templates are included in this document for bothgeneric and strong types service interfaces.

5.5.3 61970

61970 services rely on existing protocol standards for transporting power systemnetwork model files and other information exchanges defined in the 61970 seriesof standards. These include File Transport Protocol (FTP), OPC Unified Architecture (UA) specification (see Reference 2 in Annex E) has been adoptedas IEC 62541, and the 61968-100 Web services. These services are used toachieve loosely coupled integration where clients request a server to performsome action, but it is up to the server to decide how to respond to the request.

5.6 Reconciling CIM and 61850 Standards via a Harmonized Model

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

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

2. The substation (i.e., protection) view of a smaller number of more complexdevices. The data model to support this view is designed to allow substationfunctions to span multiple physical devices, and to separate the function orientedmodel from the communication related model.

Annex A is an attempt to compare the types of models discussed above. This is not anexhaustive list, only representative of the models. As shown, there is a range of overlapin all models in the SCADA area for analog measurands, status changes, and controlpoints. For substation and feeder device models, 61970 and 61850 models overlap. Foryet other areas, such as contracts and generation, there is no overlap.

Annex B provides a more detailed comparison of the dif ferent model ing techniques usedby providing a concrete example of how a circuit breaker is modeled with the differentapproaches currently used in TC57. The model contained in the 61850 standards isdescribed first followed by the model used for the 61970 standards.

An EPRI-funded project completed in 2010 proposed to harmonize the CIM and 61850standards through the creation of a harmonized information model (described as a unifiedinformation model in the report) that provides a common set of semantics for use by both

the CIM and 61850 standards. Utilities should be able to exchange information betweensystems and devices using a common language supported by both, regardless of thespecific interface involved. This can be achieved by having a common semantic modelfrom which the specific information to be exchanged can be derived, thus avoiding theproliferation of endless point-to-point links, each based on a different set of semantics.While mapping is still required from a system‟s native representation of d ata to thestandards-based common language for information exchange, this approach ensures thatan accurate and lossless transformation occurs at every interface to another systemwhere the common semantic model is applied. This is, in fact, the stated vision for the



62357 © IEC:2011 - 68 -

Figure 5-10, Proposed Linkage of 61850 Classes to CIM PSR Classes in UML

5.6.2.2 SCL Changes

The following additions of enumerated values to the XSD Types are recommended:

To tPredefinedCommonConductingEquipmentEnum, the following enumerationvalues are proposed to be added:

o BBS - – BusBarSectiono CND – Conductor

o CON – Connector

o EnergyConsumer

o RINV – RectifierInverter

o SCMP – Series Compensator

To tPredefinedGeneralEquipmentEnum, the following enumeration values areproposed to be added:

o GEN – GeneratingUnit

o PROT – Protection Equipment

An attribute was added to tConnectivityNode to indicate if the node wasgrounded or not.

A tSwitch production was added to allow a closer alignment to CIM Switches.The enumerated values proposed for this type are:

o DIS – Disconnector

o FUSE

o GNDDIS – Ground Disconnector



62357 © IEC:2011 - 69 -

o JMP – Jumper

o GEN – General Switch

o CBR – Breaker (was removed fromtPredefinedCommonConductingEquipmentEnum)

The production of tTapChanger was enhanced to allow a “TypeOfLTC”

parameter so that there could be differentiation between regular, phase, andratio tap changers.

Changes to the Equipment Container relationship were made in order to alignwith CIM and allow other equipment containers besides Substations, Bays,and VoltageLevels.

Additionally, a new section type has been added to support planninginformation.

5.6.2.3 Mapping Recommendations

In order to relate the UML model classes for equipment to the 61850 SCL representationof equipment, it is necessary to unambiguously map one to the other. Annex Dsummarizes the recommended mappings.

5.6.2.4 General Recommendations

Need to agree to common definitions for all the classes used to model thesubstation. Recommendations for the definition to use are made from amongthe possible sources of definitions, including IEC Glossary, IEC TC57Glossary, IEC 61970/68 UML model, and IEEE Dictionary. 61850 does notprovide any authoritative definitions for the terms used within the SCLSubstation section/XSD.

Need persistent IDs in 61850. Recommendation is to add RDFID (equivalentto rdf:id in CIM XML)

o SCL files have internal referential integrity through the use of names.However, when merged/imported and mapped to the CIM, names willbe duplicated.

o Use of names only would also make it difficult to pick up incrementalchanges.

Units need to be aligned

Proposed alignment for CIM Measurements and MeasurementValues with61850 measurement objects.

Proposed alignment for SCADA and Control

Proposal to expand Communications models in the CIM to align with 61850communications objects

61850 needs to make better use of CIM Profiles (Layer 2) to restrict generalCIM model for specific business purpose rather than creating specialized UML

models

5.6.2.5 Naming Conventions

In CIM, when RDF Schemas are used (as in 61970 with CIM XML), elements corresponddirectly with UML classes, attributes or associations. The element tag names consist of:

The class name when they represent a UML class, e.g.PowerSystemResource



62357 © IEC:2011 - 70 -

The class and attribute names concatenated, when they represent a UMLattribute, e.g., PowerSystemResource.pathName, wherePowerSystemResource is the class name and pathName is the attribute name

The class and association end-side role name, when they represent a UMLassociation, e.g. PowerSystemResource.OperatedBy_Companies, wherePowerSystem Resource is the class name and OperatedBy_Companies is the

association end side role name

In XML Schemas, there is a difference between elements or attributes and their type.

In CIM, when XML Schemas are used (as in 61968), elements correspond directly withUML classes and attributes:

The element tag names consist of the UML class or attribute name

The names of the type of these elements are the same as the element names

In 61850, SCL Schemas distinguish between elements (or attributes) and their types.This is reflected in the corresponding UML diagrams. So in SCL :

The name of the XML type of an element is the name of the UML class (this is

reflected by the “t” character tha t prefixes all UML class names) The name of the XML type of an attribute is the name of the UML attribute

type. These attribute types are either prefixed with a “t” when it is an SCLdefined type or with “xs:” when the attribute type is an XML datatype

The name of the XML element is the name of the association end-side rolename corresponding to a UML class

The name of an XML attribute is the name of the UML attribute

So there are differences between the CIM and 61850 in UML naming and XML naming.These should be aligned. There are two key issues:

The naming conventions used for UML naming of classes, attributes andassociations are different

The naming transformation rules between UML and XML and RDF aredifferent.

Regarding the transformation from CIM classes to SCL, the following rules are suggestedfor SCL:

Element names should follow the CIM UML class name convention, which isthe UpperCamelCase rule, e.g., PowerSystemResource

Element type names should be UML Class class names prefixes with “t” (notethis changes the UpperCamelCase rule and should be reconsider latter to getconsistent rules that would require a “T”), e.g., tPowerSystemResource

Attribute names are the same as UML attributes names and follow a

lowerCamelCase rule, e.g., pathName

Attribute type names are the UML attribute type name prefixed with a “t” whenthe attribute type is a CIM datatype or prefixed with the “xs” prefix when itmatches an XML datatype

5.6.2.6 Instance Naming

To be able to share CIM and 61850 SCL models, it is essential that a consistentapproach to naming be adopted. Both the CIM and SCL share similar naming attributes,



62357 © IEC:2011 - 72 -

2. As Platform Specific Models (PSMs), which specify implementations in varioustechnologies, such as XML, Java, Web services, etc. PSMs ensure interoperabilitybetween different vendor‟s products for a given choice of technology.

For most of the TC 57 standards, such as 60870-6 (TASE-2), 61850, 61968, and 61970,services are written in a generic fashion that permits several different technology profilesto be used. For instance, IEC 61850 may be implemented using either the Manufacturing

Message Specification (MMS) or IEC 61870-5, while IEC 61970 may use web services ora legacy technology platform such as Microsoft COM.

6.1 Use of XML

XML is being used in several TC57 standards as a standard way to exchangeinformation:

1. 61850 – basis of the Substation Configuration Language (SCL) to describe IEDconfigurations and communications systems. XML files based on the XML schemadefined in SCL are used primarily to exchange IED and communication systemconfiguration data between an IED configuration tool and a system configurationtool from different vendors. Files created using SCL are also used to transfer theIEC configuration data from the IED configuration tool to IEDs in the switchyard.

2. 61968 – basis for developing message payload standards for exchanginginformation between independent systems and applications concerned withdistribution management and market operations. XML schemas based on the CIMare defined for each message payload defined in the 61968-x series of standards.

3. 61970 – basis for exchanging power system network models that are used inenergy management systems and market systems. RDF schemas derived directlyfrom the CIM UML models are used to define the information content for theseexchanges as an XML document.

6.1.1 61850 SCL Use of XML

The SCL is based on XML. The SCL syntax definition is described as an XML Schema.While UML is used to illustrate the inheritance structure of the main SCL elements as wellas the containment relations between the SCL language elements, an XML schema

definition is the normative specification for SCL. The UML diagram in Figure 6-1 providesan overview of how the SCL schema is structured.

Figure 6-1, Overview of SCL Schema

As can be seen, the SCL schema is considered to be an SCL element derived from themore general BaseElement schema type (which provides for containment of Private andText definitions) and functions as a container. The SCL element can then contain



62357 © IEC:2011 - 73 -

elements like substations, IEDs, communications, and data type templates as well as aheader. All these elements have a type. The transformation rule from UML to XMLSchema is the element name are the role name and the their type is the UML class name(that is prefixed with “t”).

It is important to note that this and all other UML diagrams used in the 61850-6 standardare in fact Profiles that are used to show relations between SCL language elements, andnot between the objects represented by the elements, which are shown in Error!Reference source not found. . An attempt was made, however, to keep the XML elementrelations as close to the object relations as possible.

In CIM,UML diagrams are used to model physical class relationships, so that all aspectsof the objects represented by these classes are captured in the class definitions andrelations between classes. When represented in XML Schemas, the elements and typesare all derived directly from the UML class. But when Profiles (like CPSM or 61968messages) are created and represented, only the relevant elements and types arederived directly from the UML class.

For example, the tSubstation element type shown above in Figure 6-1 is not the same asa Substation class in the CIM, because it has only the required elements needed for

substation configuration. The tSubstation element type shown in the diagram refers to theSubstation section of the SCL XML schema, where all the other elements, such astVoltageLevel and tBay are defined. By contrast in the CIM UML, the Substation isdefined in UML as a class with a definition, attributes, and associations to other classes,such as VoltageLevel. Although an XML Schema for the CIM can then be automaticallygenerated from the CIM UML for all or a portion of the CIM, XML schema is only oneformat for the CIM that can be derived from the UML. Additional formats include RDFschema, XMI, OWL, PTL, and MDL. Others can be added as technology evolves..

6.1.1.1.1 Substation Section

The Substation section contains multiple Substation elements. Each of these elementscorrespond to the objects in the SCL Substation model part. To describe whole networks,it is possible to have several substation sections, one for each substation served by the

substation automation system (SAS). By means of logical nodes attached to the primarysystem elements, this section additionally defines the SA system functionality (forexample, in an SSD file), or, in the case where the logical nodes are already allocated toIEDs (SCD file), the relation of IED functions to the power system.

UML diagrams are used to describe the detailed relations and constraints between thevarious elements comprising this section. However, all the various types of elementscomprising this section are defined in XML, as described above.

6.1.1.1.2 IED Section

The IED section describes the configuration of an IED: its access points, logical devices,and LNodes instantiated on it. It also defines the communication services offered andinstantiated data and its default or configuration values. There is one IED section for

each IED in the SAS.

contains multiple IED elements. Each of these elements correspond to the IED objects inthe SCL IED model part. All the IEDs comprising a substation automation system for thesubstation specified in the Substation section are contained in this section.

6.1.1.1.3 Communication Section

The Communication section describes the communication connection possibilitiesbetween LNodes by means of logical buses (i.e., subnetworks) and IED access points.The IED sections already describe which LDs and LNodes are reachable across a certain



62357 © IEC:2011 - 74 -

access point on an IED. The communication section describes how these access pointsare connected to a common subnetworks.

6.1.1.1.4 Data Type Templates Section

This section defines LNode types in terms of templates of the data for a LNode. Thesetemplates are built from Data elements.

6.1.2 61968 and 61970 XML Based on the CIM

In the IEC 61968 and 61970 series of standards use of XML, it is important to understandthat behind all information exchanges defined in these standards is a single, commonsemantic model (or ontology), the Common Information Model (CIM), which isdocumented in UML. This ensures consistency across all currently defined exchanges aswell as any future exchanges defined in XML or any other exchange format, such as Javaor C++. It also permits XML to be autogenerated from the UML via software tools asdescribed below.

6.1.2.1 61968 XML Schemas for Messaging

The message payloads that comprise the 61968 standards for information exchangebetween distribution management systems are specified using W3C XML schema. 61968-

3 to -10 specify the information content of a set of message types that can be used tosupport the business functions defined in the IRM. Each part addresses a different part ofthe IRM.

UML use cases are used to identify the message types needed for each set of businessfunctions. UML can also be used to show which CIM classes are used in each messagepayload.

The contents of the message payloads are based on a static information model defined inUML (the CIM) to ensure consistency of XML element names and data types. In otherwords, the XML element names and data types used in each message schema arederived directly from the definitions provided by the CIM UML rather than in the XMLitself. The exception is for the elements used to define the message header. This is

referred to as CIM/XML Schema-based messaging.

6.1.2.2 61970 XML Documents Using RDF Schema

The 61970 standards use RDF/XML as a way to format the exchange of various types ofinformation exchanges between applications within an EMS or between an EMS andother systems involved in utility generation and transmission operations. RDF/XML is justone of the ways used to create a serial format of instantiated models specified in UML.The content of the resulting XML documents is based on the CIM static information modeldefined in UML. Similar to the 61968 approach, the resulting XML element names anddata types used in each XML document are derived directly from the definitions providedby the CIM UML rather than in the XML itself.

As mentioned above, CIM Profiles are def ined as separate standards to specify whichparts of the CIM are mandatory and optional to satisfy the information exchangerequirements of a particular use case. The most important profile currently in use is theCommon Power System Model (CPSM) profile standard 61970-452. The W3C RDFschema is used to specify the syntax of the resulting XML files. The use of RDF forexchanging power system models is specified in 61970-501 and 61970-552-4. The latterdocument describes how complete power system network models as well as incrementaland partial updates to an existing base network model are to be formatted. This isreferred to simply as CIM/XML file transfers.



62357 © IEC:2011 - 75 -

6.1.3 Reconciling the Use of XML

It is preferable that a single common information model (i.e., the CIM) be used to createthe XML according to well-defined rules (i.e., XML Naming and Design Rules (NDR)) toensure all XML schemas are consistent and use the same tags with the same name andmeaning.

61968 and 61970 are currently developing an XMl NDR document in order to share acommon XML schema for all XML that is based on the CIM. It is recommended that theSCL in 61850 and all other XML uses also be based on this XML NDR documentwherever objects that are needed are already represented in the CIM. This should startwith the hierarchical relationships for containers and inheritance in the CIM (i.e.,ControlArea, Substation, VoltageLevel, Bay, Transformer, etc.). At some more detailedlevel in the hierarchy, it may then make sense to specialize one of the existing classes inthe CIM to embrace existing 61850 models, if the CIM does not adequately represent thedevice properties needed. However, even here the CIM can be extended to add neededspecializations, as WG14 has done with that portion of the 61968 standards that neededspecialized device models or other specialized objects used in distribution applications.

If the SCL is intended to be an external view of configuration data to be archived andmade available to other applications, then it would be most helpful if the XML schemaused by the SCL were based on the same information model used by those applications.



62357 © IEC:2011 - 76 -

7 Strategic Use of Reference Architecture for Harmonization and New WorkItems

The reference architecture defined in this document provides a foundation for determiningwhere harmonization is needed. The following are suggested as starting points.

7.1 Use of Common Object Modeling Language and Rules

The Unified Modeling Language (UML) was selected by TC57 as the language of choicefor object modeling. UML provides notations for class diagrams, state diagrams, eventsequence diagrams, and a host of other types of model notations that are independent ofthe underlying technology platform. One of the main advantages of this approach is thatit facilitates harmonization between data models in different working groups by facilitatingthe acceptance of a common semantic model for all new standards in TC57. Without acommon language, it is difficult to maintain and leverage a common semantic model. Forexample, the use of UML for both the 61968 and 61970 series of standards ensures atransformer, for example, is represented in exactly the same way and with the samedefinitions whether the technology used for information exchange at system interfaces isbased on XML schema, RDF schema, or even Java.

Another benef it is that there are several CASE tools ava ilable for UML to :

Prepare models and navigate them as well as to auto-generate the Worddocuments needed by the IEC to progress them as standards.

Generate XML documents for file or message payload creation whether usingXML schema or RDF schema.

Generate WSDLs for Web Service implementations based on the CIM.

UML has already been adopted by WG13, WG14, WG16 and more recently by WG10where possible. It is recognized that other modeling languages are also in use andprobably cannot be changed where standards are already published, but the goal shouldbe to have a single, common modeling language.

7.2 Harmonization at Model Boundaries

The reference architecture provides a way to relate the various TC57 standards. Asstated earlier, from a harmonization point of view, the two most important places wherehaving identical models really matters is:

1. At interfaces where software implementing one standard must interface tosoftware implementing another standard. An example is a SCADA server thatacquires data using one model (e.g., 60870-5-101, TASE.2 or 61850) and mustserve it to applications using another model (e.g., CIM).

2. Where these object models purport to represent the same physical real-worldobject. Ideally it would seem to be desirable to have one set of models usedconsistently by all interfaces. At a minimum, the attributes shared by both modelsshould 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.

References 1 and 2 in the Bibliography provide more details on this use of the referencearchitecture.

7.3 Resolution of Model Differences

WG19 was created to resolve model differences where there is overlap and to develop avision for TC57 for the future. In this role it functions as a sort of architecture board forTC57. The reference architecture provides a framework for relating all the various



62357 © IEC:2011 - 78 -

8 Future Reference Architecture for Power System Information Exchange

This chapter addresses the vision of a future reference architecture for power systeminformation exchange and a long term strategy for TC57 that reaches beyond simplyresolving the differences in existing standards TC57 standards.

8.1 Vision Statement

The future reference architecture for power system information exchange is intended toprovide a roadmap for future work in standards development within TC57 that takes intoconsideration new utility industry needs, directions in new available technology toaddress these needs, and other relevant activites of a broader nature. It also seeks toestablish a strategy for addressing these needs, such as IntelliGrid, the GridWise Architecture Counc il, etc. Where as exist ing TC57 standards have focused on theexchange of information, the future vision needs to focus on enabling the broader use ofthat information to support electic power industry business processes, such asinformation management, integration, presentation, decision making, etc.

A related goal of th is vision to support bus iness needs is to enable the concep t ofentering data once, having it associated with a common utility semantic model, and thenbeing able to share it with all applications, systems, and other utilities and suppliers thatneed access to this data.

8.2 Fundamental Architecture Principles

The fundamental architectural principles espoused by TC57 include:

1. Focus not on expanding the scope of the current TC57 charter, but rather toimprove what we do within that scope.

2. Guide the work of TC57 to ensure the standards produced fit into a well-thoughtout framework rather than attempting to provide a prescriptive architecture for useby utilities in their enterprise.

3. Embrace both TC57 standards (models, services, etc.) as well as other relevant

IEC and IT industry standards. In particular, need to strive for seamlessarchitecture which includes all TC57 standards and to elaborate harmonizationneeds and approaches where seams are needed or cannot be avoided.

4. Embrace best practices for foundational aspects of architecture, such as security,network management, metadata management, etc., from ground up.

5. Consider interfaces to and the scope of other related TCs and industryconsortiums via liaisons, technology transfer, and coordination activities tofacilitate use and development of their standards (and vice-versa). Examplesinclude IEC TC‟s 88, 65, and 8 ; OPC; OMG ; UN/CEFACT and their CoreComponents Technical Specification (CCTS).

6. Build on best industry thinking regarding architectures, such as those envisioned

by Intelligrid, CIGRE D2.24 EMS Architectures for the 21st

Century, and theGridWise Archtitecture Council.

7. TC57 standards should be model-driven and metadata-driven to ensure theyshare a common semantic model. The primary value of the CIM is to provide asemantic model behind all information exchanges between systems andapplications rather than for direct use in interfaces.

8. A layer of insulation is needed to protect interfaces from changes in the CIMmodel.



62357 © IEC:2011 - 79 -

9. Interfaces in real-world systems need to reflect specific user-driven businessconstraints in addition to embracing a standard semantic model.

10. Embrace layered architecture based on internationally accepted concepts, suchas those specified by the UN/CEFACT Modeling Methodology (UMM) and CoreComponents Technical Specification (CCTS) to include:

a. An abstract information model which is independent of any specificapplications or business function. This layer should provide a way tocombine information models from different sources in a seamless fashionto define utility semantic model.

b. A business context layer to restrict the abstract information model to suitspecific enterprise information requirements.

c. Business entities that can be related directly with business processobjects.

11. TC57 architecture should be independent of any particular IT framework, such asService Oriented Architecture (SOA), but support implementation over all current

and future IT platforms.

a. A corollary is that standards should be developed and maintained at anappropriate level of abstraction to allow independence from technologiesused to deploy the standards (i.e., using platform independent models(PIMs).

b. Where mappings to a specific technology are needed to ensureinteroperability, such mappings should be developed as companionplatform specific model (PSM) standards

12. Include a criteria for determining when a system complies with the referencearchitecture.

13. Architecture should explicitl y identify interfaces where compliance to standardscan be validated.

14. Include guidelines for when to apply which standards/technologies included withinscope of TC57.

15. Include stratgegies for integration with legacy systems.

16. Give priority to user awareness and usability

8.3 Strategy

The basic strategy is to start with these foundational principles and drive to more explicitstatements reflecting those principles. This section describes a strategy for developmentof standards that are based on the CIM and other abstract information models as thesource of the semantics embodied in the TC57 standards.

8.3.1 Information Model

The information model comprises the CIM plus other project-based CIM extensions,models from other industries incorporated via semantic mapping, and enterprisecorporate models to provide a path for a utility to create a custom information model thatmaximizes the use of the CIM while permitting the inclusion of information models fromother sources. Having this layer separated from the business context layer would provide



62357 © IEC:2011 - 80 -

greater international acceptance since it would make the information model itself moreindependent of individual country or regional differences.

Within TC57, the CIM should be utilized wherever possible across TC57 as TC57 ispromoting a common modeling methodology using UML across all Working Groups.WG19 believes that it would be preferable if both CIM and SCL experts are involved inthis process. As described in 57/732e/INF, the Maintenance Use Case illustrates theimportance of seamless control center to substation modeling; data entry should beperformed once and then electronically propagated as needed.

All new TC57 standards should use/extend the CIM as the common semantics for theirconfiguration/engineering modeling, and 61850 for SCADA oriented/IED/field]communications. Other existing standards would likely take a mapping approach.

In recognition of the fact the most CIM users need to customize their information modelwith private extensions (i.e., add new classes, attributes, and relationships) as well asusing different names for some business entities, the TC57 architecture needs to provideguidance in how to make these extensions, and then to submit them as proposals forchanges to the CIM standard in some cases. Therefore, there needs to be a consistentprocess articulated for how to submit changes, track progress on acceptance, and access

the revised standards.

8.3.2 Business Context

The purpose of the business context is to tailor the Information Model to suit specificapplication needs or specific country and regional constraints by applying restrictions onthe Information Model. Examples include tightening cardinality and defining specificfeatures as mandatory, restricting string lengths, and changing data types from string to autility‟s specific enumerated values. There may be certain contexts that are the subject ofstandards. However, the architecture should embrace both development of such standardcontexts as well as provide a standard methodology for developing custom contexts.

There is a need for recognition of a separation or boundary between the informationmodel and the business context layer that is used both in developing standard profiles or

interfaces as well as by the end user in applying business contexts unique to anenterprise.

8.3.3 Interfaces

Interfaces in real-world systems will usually have specific requirements imposed by theend user utility that go beyond the standards. For example, each utility using TC57standards will almost always go beyond the CIM to add additional classes, attributes, andrelationships as well as naming rules.

Naming and Design Rules ( NDR) should be used by all TC57 working groupsdeveloping interface standards as well as end users to design interfaces based on theCIM. NDR allows a user to define their own interfaces based on the CIM. NDR conceptsapply to any type of interface independent of implementation aproach – i.e., for XML

schema, RDF schema, OWL, and others.

8.3.4 Service Model

Services are defined to be independent of underlying technology implementations.Mappings to specific technologies are also the subject of standards to ensureinteroperability.

Service models are designed to be independent of the payloads., and vice versa.



62357 © IEC:2011 - 81 -

Services include 61850 services, GID services, and other industry-independent servicessuch as Web services. Mainstream information technologies should be evaluated prior tocreating new equivalent approaches.

Guidance is needed on when to use each of these services, since there is a fair amountof overlap in functionality. There is also a need to clearly articulate the need for the GIDand where and how the GID standards should be applied in the world of SOA and WebServices.

8.3.5 Industry Trends to Consider

Following up on the principal of embracing best practices from other relevantorganizations, the following in particular should be considered in the future TC57reference architecture.

8.3.5.1 Trends

1. Many standards organizations that deal with business vocabularies are rampingup their work on XSD Naming and Design Rules, often dubbed as NDR. The workwithin TC57 to develop NDRs for TC57 standards should be an importantcomponent of future TC57 standards.

2. UN/CEFACT Core Components Technical Specification has been adopted byother standards organizations (OAGi, OASIS UBL, etc.) as a foundation to definebasic data types and business semantics. More importantly, the UN/CEFACTTMG BCSS group is working with OAGi to develop the UML Profile (UMP) forrendering the CCTS in UML. There are also groups within UN/CEFACT working todevelop actual core component library of business objects, NDR, standards formessage assembly etc.

3. There are other standards such as the UMM of UN/CEFACT, the SOA relatedstandards being developed at OASIS, etc. that will have an impact on the use ofbusiness vocabulary standards such as CIM.

4. Development of Ontology Definition Metamodel (ODM) from OMG, which could

provide a bridge from UML to OWL, could have an impact on how CIM is to beprofiled.

8.3.5.2 Industry Consortiums

8.3.5.2.1 ISO/RTO Council (IRC)

Created in 2003, the IRC serves as a coordination vehicle formed “for the purpose ofpromoting communication, providing mutual assistance, developing effective processesand tools, and otherwise coordinating in areas of mutual consent.” The IRC is made up ofthe RTO/ISO Chief Executives.

8.3.5.2.2 ISO/RTO Information Technology Committee (ITC)

Formed “for the purpose of promoting communication, the ITC provides mutual

assistance and coordinating in areas of mutual consent with regard to the development ofinformation technology practices affecting ISO/RTO operations in electric industry.” TheITC acts to further the goals and purposes of the IRC. It also facilitates interactionsamong the ISOs/RTOs and provides a means to collaborate and identify areas oftechnology standardization for the ISO/RTO entities. As appropriate, the ITC submitsrecommendations to the IRC for review and approval. In addition, the ITC coordinatesinteraction with the ISO/RTO Standards Review Committee (“SRC”), an entity thatmanages standardization activities between the IRC, NERC, and NAESB.



62357 © IEC:2011 - 82 -

8.3.5.2.3 ITC’s Enterprise Architecture Standardization (“EAS”) Project

The EAS was formed to create a technical reference architecture and supportingstandards that will facilitate ISO/RTO cost reductions by increasing competition amongsoftware vendors and enable improvements in operational efficiency. The goals of theEAS project are to:

Create a Technical Reference Architecture for the ISO/RTO community;

Identify the core set of ISO/RTO Functions (Architecture Framework);

Define interoperability standards for selected applications within theEnergy Management and Market Operations Sub-Systems.;

Define an extendable standard to enable Business Process monitoring andlogging; and

Provide a template that can be used in RFP‟s and as part of vendorcontracts

8.3.5.2.4 EAS and CIGRE D2 WG24 (formerly VLPGO WG#2)

It is important to clearly distinguish between the activities of Working Group 2 of the VeryLarge Power Grid Operators (VLPGO), known as EMS Architectures of the 21st Century(now CIGRE D2 WG24), and the Enterprise Architecture Standardization project. Whilethese activities share some similar high-level goals, they are largely focused in different(and complementary) areas and are taking different approaches.

The EAS project is addressing the simplification of the integration of system componentsfrom multiple vendors; the group plans to submit its work to the IEC for incorporation intothe appropriate international standards. This will incorporate other IEC standards (suchas CIM) as appropriate and focuses on the information exchange between individualsystems components.

Rather than developing new standards, the VLPGO work is directed toward producing a

universal, reusable set of technical (not functional) specifications for the individualsystem components, to be made publicly available for incorporation into solicitations forsuch software. While it refers to various standards, it will not create a new standard:rather, it is focused on the publication of a common reference document that can form thebasis for the evaluation of the technical characteristics for such system components.

The VLPGO activity is focused on the design, performance, and other characteristics ofthe software components that would be integrated using the work of the EAS project. Ifboth projects are successful, more robust, scalable, and maintainable components will beavailable for integration using standardized messages and interactions. The VLPGOwould include the EAS work (or the standards that result from it) in its specifications,while software that conforms to the VLPGO specifications would be more easilyadaptable to incorporate the EAS-developed standard messages.

8.3.6 User Awareness and Usability

1. Leverage open communications between CIMug, IEC TC57 and the workinggroups to develop a set of consistent and concise marketing materials to clearlydefine what CIM and related standards are about, what values they bring, whatareas they can be used, and how they can be used.

2. Define the process for ownership, version management, model inputs, modelextension, and model issue resolutions for CIM. This will build stronger credibility



62357 © IEC:2011 - 83 -

of the standards and help preserve the user‟s investments in CIM basedimplementations.

3. Enforce similar communications and better documentation for related standardsfrom CIM.

4. Create more detailed and enforceable specifications to ensure standards

compliance can be tested consistently and independently, which will allow toolvendors to provide necessary tools for validation and compliance testing.

8.3.7 CIM Modeling Technology and Language Strategy

Currently the CIM is modeled in UML, which provides a GUI in the form of classdiagrams, activity/sequence diagrams, use cases, and other graphical forms. UML toolspermit model maintenance to be accomplished via this GUI.

UML is also a good language for expressing and viewing semantic models, which is animportant capability for supporting the end user needs to implement and managebusiness processes, business entities and relationships in a platform independent way. Itcan also be used with software tools to automatically generate standard XML documentsfor exchanging models, including XMI and RDFS-formatted XML. Proprietary format

versions are also available, such as .mdl and .cat that are supported by IBM Rationaltools.

OWL and RDF excel in ontological modeling, where there is a need to mathematicallyexpress relationships between entities more precisely, but is not as well suited forsupporting a common semantic model for use in defining and deriving specific messagepayloads and file contents. For instance, class diagrams and other graphicrepresentations provided by UML are not currently defined for OWL and RDFS – editingis usually done directly in XML dealing with XML tags with XML editing tools. However,the power of precisely defining relationships could be an important future capability thatshould be utilized by TC57 in an appropriate way.

Currently TC57 supports RDF Schema and XML Schema (referred to as CIM/RDF and

CIM/XSD, respectively) to provide serialization formats for encoding the UML model forinformation exchange. Given there are legitimate use cases for each, TC57 shouldsupport these encoding standards and others as the need arises. In addition,consideration should be given to adding OWL to provide more in depth support forbusiness intelligence, data analysis, and semantic integration needs. The followingsubsections recommend a strategy to be followed for each.

8.3.7.1 CIM/UML - Modeling

1. CIM, the UML model itself, should remain in the form of UML.

2. CIM needs have a UML Profile (UMP) to ensure that the evolution and extensionof the model is consistent, and the resulting model is semantically expressive,controlled and unambiguous. This UMP is different than the NERC profile conceptwhich acts on the model itself. This profile is a way to specify a subset of UMLconstructs to use when developing the CIM, therefore allowing for a much moreconsistent model representation. A potential candidate for such a UMP couldcome from UN/CEFACT TMG. Alternatively, IEC TC57 could develop its ownprofile as long as it meets a set of requirements agreed upon by the CIMug. Thegoal should be consistency and precise semantic expression so that forwardengineering to other formats becomes predictable with a defined set of rules.



62357 © IEC:2011 - 85 -

2. There are several options regarding the current CIM/RDF standard:

a. Maintain it along side a new standard based on CIM/OWL in recognition ofthe existing field implementations currently in use.

b. Move CIM/RDF to CIM/OWL so that it can provide better semantic controland data type definitions. Since OWL standard builds on top of RDF, it is a

natural evolution for CIM/RDF.

c. Move CIM/RDF to CIM/XSD so that the structure and data type of itsinstance data is much more precise and defined. As long as the specificXSD structure provides a good referencing model so that the resultingXSD and XML document is not just hierarchical in nature, it is a technicallyviable alternative that takes advantage of XSD technology.

3. CIM/OWL in general will have many other uses cases. Therefore whenconsidering CIM/RDF and CIM/OWL, one must consider all possible use casesbefore settling on a technical solution. This could complicate the development ofCIM/OWL for power model exchange. Use cases should be separated andperhaps the CIM/OWL for power model exchange could be a subset of CIM/OWL

in general. The CIM/OWL could open up more opportunities for utilities toleverage CIM as a common information model. Its development will pose new anddifferent requirements are to how CIM should evolve as well.

8.3.7.2.2 CIM/XSD

1. A Naming and Design Rules (NDR) document describes a standard way to createXML Schema from a message payload definition in UML. As creating XMLSchema for an information model can be made in many different ways, the NDR isessential to ensuring interoperability is achieved when XSD defined messagepayloads are exchanged. The message payload itself is XML.

2. WG14 standards should also address rules for extension, restriction, andcompliance. Whether that is part of the NDR is not significant, but these topics

need to be covered so that specifications are developed to enable tool vendors todevelop a suite of capabilities for implementation and independent compliancetesting.

3. TC57 should develop methodologies for end users to create their own interfaces(see earlier discussion). The NDR based on XSD is an important enabler for th is.

4. XSD is the prevailing technology to express data types for data exchange,especially for system integration. XSD will be major technology to be used with aCIM-based semantic model. With Web services and the robust tool supportavailable, XSD offers many advantages to expressing an inplementation modelwhile maintaining semantic links back to the CIM.

5. All information exchanges except for power system model exdchanges should be

based on XSD. This also offers the end user utilities the broadest choice for toolsupport.

8.3.7.3 Transformation Between the Different CIM Formats

Rules for converting from CIM/UML to CIM/RDF, CIM/OWL, and CIM/XSD, as well asrules for transformation between the XML-based formats needs be clearly documented.The CIM/UML Profile needs to provide for a set of default rules to be defined so that theforward engineering from CIM/UML as a Platform Independent Model (PIM) to a PlatformSpecific Model (PSM) is predictable. A proper version management framework must be in



62357 © IEC:2011 - 86 -

place for both the model and its derivative formats such that there is a clear relationshipbetween a version of CIM and a version of RDF or XSD or OWL. Vendors and userscould implement a version of PSMs while allowing the CIM to continue to evolve.

8.4 Vision for the Next Generation of CIM and Related Standards

The following diagram depicts a vision for the next generation of CIM and its related

standards (see Figure 8-1).

CIM RDF

CIM/UML

CPSMProfile

CIMCIM Ext

Bridge Foreign

WG 14Profiles

Other Profiles

Messages

XMLSchema

OWL DataBase

Schema

CIMRDF

XMLNDR

Other Rules

Information

Context

Message

Assembly

Exchange

Schema

Rules

UML

Modelling

LogicalSchemas

Bridging

WG 14Messages

Figure 8-1, Vision for Next Generation CIM and Related Standards

As shown, the future vis ion enbraces some new concepts in a three layer architec ture notcurrently incorporated into the CIM and related standards architecture:

1. Information Layer – This layer includes the CIM/UML but provides for the realitythat there are other sources of information as well as the CIM that need to betaken into consideration when creating CIM-based information exchanges orrepositories. These different models/standards and ways of bridging themtogether comprise the Information layer.

2. Contextual Layer – This layer formally recognizes that only a subset of themodels in the Information Layer are needed for any particular interface ormessage definition. The Profiles contained in the CIS standards defined in thislayer:

a. define a subset of the models in the Information layer needed for aparticular business purpose as well as constraining those model elementsto address specific business needs, and

b. provide a way to incorporate model elements from the different informationsources in the Information layer in addition to the CIM.



62357 © IEC:2011 - 87 -

3. Message Assemby Layer - This layer defines the structure of a Message thatcarries the Profile Information and what kind of operation should be performedwith message payload.

4. Exchange Schema Layer – This layer provides for specific schemas for the

Profiles defined in the Contextual layer.

An impor tant feature of th is layered architecture is that for the first time there are clearboundaries defined between the information models in the Information Layer and thebusiness context in the Contextual Layer. Without this distinction the current CIM hassuffered from an “identity crisis” trying to be an information model that also incorporatesbusiness context in a non-uniform way. The tension is created by trying to have the CIMbe both general and generic enough to be used in any application while being as specificand constrained as possible to include descriptions more useful to an application in aspecific business context. It‟s not possible to satisfy both objectives in an informationmodel, although attempts have been made in some cases by incorporating poor modelingpractices, such as having an attribute mean one thing if the context is A, but somethingelse if the context is B, where the context is indicated by the value of a flag attribute.

Another impor tant concept embodied in the layer archi tec ture is the not ion that layers 1-3

represent a Platform Independent Model (PIM) of an information exchange or interface,thus creating a clear boundary between the PIM and the Implementation Layer, wherethere may be multiple technology implementations of that profile. The standards in theExchange Schema Layer then are the Platform Specific Models (PSMs). So it can beseen that the TC57 layered architecture embraces the OMG Model Driven Architecture(MDA) concepts of PIMs and PSMs.

For example, the CPSM profile has been standardized in the IEC 61970-452 CIS and isone layer of the Platform Independent Model (PIM). The other PIM layers are theInformation and Message Assembly layers. One PSM is the RDF/XML schemaimplementation of this profile which has been standardized as IEC 61970-501 and 61970-552-4.

In Figure 8-1, the Common Profile object as shown can be implemented in several

technologies, each with its own schema, including RDF/XML schema, XML schema, anda relational database schema. This implies that a Profile must be specified at a highenough level of abstraction to allow it to be implemented in various, differenttechnologies.

Each layer is described in more detail in the following subsections.

8.4.1 Information Layer

The important architectural features enabled by the layer are described in the followingsubsections.

8.4.1.1 Multiple Sources of Information and Metadata

In the current CIM standards, the CIM in UML is the only recognized source of metadatafor defining XML messages or files. Although it is possible to extend the CIM with privateextensions, and in fact is expected, the goal has been to eventually incorporate thoseextensions into a later revision of the CIM UML model if the extensions prove to begenerally accepted. In any case, the standard CIM UML model with private extensions isthe only recognized source for creating a semantic model as the basis for a model-drivenarchitecture.

The Information Layer in the future reference architecture vision, on the other hand,embraces the notion that there are other sources of metadata that a utility enterprise



62357 © IEC:2011 - 88 -

needs to include in its semantic model without trying to make it a part of the CIMstandard. Conceptually, some kind of a Bridge, as shown in Figure 8-1, is needed tocreate links to these other metadata, similar to the way associations between classes inUML link different parts of the UML model. Whether or not this Bridge becomes thesubject of future standards is unclear.

These other information models denoted as Foreign sources in the diagram could includemodels from other standards bodies or industry consortiums, such as GML or MultiSpeak.Other possible sources include other TC57 standards, such as the IEC 61850 Substation Automation standards. In fact, th is is a very powerful way of achieving harmonizat ion ofthe 61968/70 CIM-based standards with the 61850 standards. Rather than trying tochange these standards to be the same in the Information Layer where there is overlap,the differences can be resolved in the Contextual Layer by making it possible to includeattributes from both sets of standards in a Profile, as elaborated more completely in theContextual Layer section below.

8.4.1.2 Abstract General Purpose Information Models

Recognizing the Information Layer as separate and distinct from the Contextual Layerhas other benefits as well. The CIM can now be thought of as purely an abstractinformation model that is general enough to be used in a variety of business contexts. Sofor example, when defining an attribute describing a generator control mode, the CIM cansimply provide a string data type. In the Contextual Layer, the string can be replaced withan enumeration that is appropriate for the country where the CIM is being used. This hasthe advantage of making the generator control mode in the CIM reusable in manydifferent contexts as well as providing a standard way to constrain the permissablevalues in a particular business context. This has the benefit of providing for the possibilityof validity checking of the instance data to ensure only one of the permitted values isused in an information exchange implementation that includes this attribute.

Another problem this addresses is caused by the use of inher itance in the CIM model. Attr ibutes that are inher ited from a parent class have only a general purpose name. In theContextual Layer the name can be changed to include some reference to the specializedclass where it is being used, so that in a particular message payload or file in the

Implementation Layer, it will be clear what object the attribute applies to.

8.4.2 Contextual Layer

The Contextual Layer provides for the definition of Profiles to define a subset of theinformation models contained in the Information Layer that are needed in a specificbusiness context. Business context or constraints are also applied in this layer. Thisnotion embraces many of the concepts described in the UN/CEFACT Core ComponentsTechnical Specification (CCTS). Profiles may also incorporate the identification ofservices to be used for information exchange.

8.4.2.1 Profile as a Subset of the CIM

The notion of Profiles is not new. For example, the CPSM Profile shown in Figure 8-1 iscurrently used to define the subset of classes and attributes that are needed to exchange

power system models between RTO/ISOs for maintaining network models of neighboringregions. So the context is transmission grid reliability.

8.4.2.2 Profiles and Multiple Information Sources

In the new vision shown in the diagram, the concept of a Profile has been substantiallyexpanded, so that a Profile can apply a business context to a subset of metadata frommultiple information models via the Bridge concept. As shown in Figure 8-1, the Profileobject in the Contextual Layer incorporates metadata from the CIM, private extensions tothe CIM, and via the Bridge, other information models as well. The key is maintain



62357 © IEC:2011 - 89 -

traceability back to the source to facilitate long term management and maintenance of theProfiles as new versions of the information model standards are published.

8.4.3 Message Assembly Layer

This layer defines the structure of a Message and what kind of operation should beperformed on the payload of the message in a given Business Context. It should specify:

The message header, including what kind of action is to be performed on themessage payload

The way that context elements could be grouped to provide some structure forfor the payload data

Sequencing of complex elements in the payload

Where user-defined extensions are allowed

8.4.4 Exchange Schema Layer

This layer includes standards for concrete implementations of information exchanges andinterfaces to the level of specificity required for achieving interoperability betweenproducts/applications/systems from different suppliers. These standards also form the

basis for compliance testing to validate system interfaces. As such, they must betechnology specific.

Since these PSM standards are based on the PIMs in the upper layers, it is important thatthey include clear rules for how they are derived from the PIMs. For example, there areseveral XML Schema structures that can be generated from a single Profile definition – each one correct but different, and not interoperable. So it is important that the PSMstandards also include rules for creating the PSM from the PIM. For example, as shownin Figure 8-1, three different PSMs may be derived from the Common Profile. Each has adifferent set of rules that must be defined. For generating CIM/XML files based on RDFSchema, rules are needed to define the subset of and extensions to the RDF Schemaelements as defined by W3C to be used. These are incorporated in 61970-552 standardso that there is one accepted way of using RDF schema to create the file metadata.Similarly, for the XML Schemas defined by WG14 for message exchange betweendistribution systems, a set of rules is needed to define how the XML schemas are to bederived from the common profile. These are defined in the NDR technical report. As a lastexample, a project may define a new technology mapping to a relational database with itsown set of rules outside the standards arena.

8.4.5 Concrete Messages and the Four Layer Architecture

Figure 8-2, Role of Architecture Layers in Message Payload Definition

illustrates how this four layered architecture all fits together to define a concretemessage payload for information exchange based on the CIM. Note that this illustrationshows only the CIM as a source of the information metada, but the concepts apply

regardless of the information source.



62357 © IEC:2011 - 90 -

Message Assembly

CIMInformation

Model

ConcreteMessagePayload

Profile

Schema

Based on CIM UML

Based on Profile

Based on Message

Assembly

Conforms to

Exchange Schema

Restricts/Narrows CIM

Is assembled as

Is mapped to


The CIM information model is shown as the source of the information metadata used inthe message payload. The Profile defines the subset of the CIM that is to be used in themessage payload, thus restricting the CIM to only those parts needed for the particularbusiness process and information exchange in view. It also adds business context to thatsubset of the CIM to take the CIM from a general purpose application-independentinformation model to a semantic model that better represents the specific businesscontext and is thus application-dependent. However, at this point the Profile is stillabstract (i.e., technology neutral). The Message assembly layer then defines the specificstructure of the message payload according to specific rules. The Message XML Schemais then generated from the Message assembly, Profile and CIM following the standardrules for mapping to XML Schema, when the desired concrete message payload is to bean XML document.

As may be seen in the diagram, the concrete message payload needs to conform to onlythe message payload standard defined in the XML Schema for compliance testing,although traceability should be maintained back to:

1. the CIM/UML for the information metadata,

2. the Profile for the business context restrictions, and



62357 © IEC:2011 - 91 -

3. the Message Assembly for the structure of the message.

With this view of conformance, compliance testing can be better understood. This is anarea that is currently not well defined from an architectural perspective, i.e., how to testfor compliance with CIM standards, or even more basic, what is the meaning ofcompliance with CIM standards.


illustrates where compliance is necessary to achieve interoperability and claim“compliance with the CIM.”

8.4.6 Next Steps

To implement this vision, a strategy needs to be developed to put the new architecture inplace. That will require a number of actions:

1. Review of existing standard specifications to determine what changes are neededto realize the vision

2. Preparation of missing specifications so the CIM and its related standards canwork as a complete and interoperable set. This is an evolution from the semantics

point of view, but there needs to be a major overhaul from the syntactic point ofview to ensure usability and consistency among various CIM related standards.

3. More collaboration by TC57 with other similar standards bodies

4. Acceleration of the pace of CIM-related standards development

This new architecture described here is intended fto provide a vision of where TC57standards should be heading. However, the development of the strategy is beyond thescope of this document.

8.5 61850 Standards Strategy

The long range vision for the 61850 standards is to extend as much as possible the use

of IEC 61850 at the field level, as one of the Smart Grid pillars, as well as supportingcommunication between the field and remote control centers. In addition, realizing theconcept of a seamless profile as articulated in the next subsection continues to be a goal.

8.5.1 Seamless Profile Concept

For historical reasons the first protocols specified by TC 57 were the telecontrol protocolsof the IEC 60870-5 series based on remote terminal units (RTUs) in substations for thecommunication between substations and control centers. Such RTUs are connected tothe equipment in substations by a parallel wired interface. This RTU technology is still inplace but will increasingly be replaced by computerized substation systems withdistributed Intelligent Electronically Devices (IED‟s) using local communication networks.With the Standard series IEC 61850 the communication in substations is described byvirtual (not standardized) devices consisting of standardized logical nodes with functional

grouping of objects using abstract communication services mapped to “real” protocols.

In such computerized substation systems it is still possible to connect to control centerswith RTU-based telecontrol protocols, as e.g. with a protocol of the IEC 60870-5 seriesusing a virtual RTU gateway for protocol conversion (objects and services). This alsoincludes the use of IEC 60870-5-104 over IP networks. But as an option, the client-serverbased protocol part specified by the IEC 61850 series for the LAN-environment can beused as well as telecontrol protocols in the WAN eliminating the need for such gateways.This solution is called a seamless communication profile allowing seamlesscommunication from the primary process equipment and IEDs in substations up to the



62357 © IEC:2011 - 92 -

control centre and any other application that needs to exchange information with IEDs,e.g., engineering station and condition monitoring station. It is important to note thatseamless in this sense implies the existence an abstract communication layer (abstractnodes, objects and services) similar to the PIM layer described earlier. Seams will stillexist on the real communication layer (i.e., PSM layer) if different protocols are used forsubstation communication and telecontrol. Even if the same protocols are used, seamsmay still exist with substation proxies. Nevertheless the seamless abstractcommunication layer allows a more efficient data management of the overall controlsystems eliminating unnecessary protocol conversions and has the potential to reducecost of implementation and over the live cycle of systems. This is analagous to having acommon semantic model in the IT world.

A typical system implementing the seamless profile would either directly interconnect theIEDs over the substation network with a router to the control centre or via a centralsubstation host acting as a proxy. Typically such a substation host has a process database and can perform application services needed by the control centre such as routing,filtering, general interrogation.

Before any communication between control centre and substation can take place, theprocess data models and system configurations of both sites must be synchronized by

the exchange of configuration data common to both substation and control centre. Thesubstation configuration data is defined with the substation configuration language (SCL)and is a subset of the total set of substation configuration data as well as including asdevice specific data the description of related power resources (topology and primaryequipment), the mapping to real protocols, and communication network configurations.Device specific object names can be associated with power resources names and aliasnames to enable the association of device objects to instances of power resourcesgoverned by the Common Information Model (CIM) used in control centers. Note thatwork is in progress at TC 57 to harmonize the SCL with CIM as far as possible to supportthe seamless profile and other profiles with minimum conversion and mapping.

9 Conclusion

A new reference model for TC57 is proposed to provide a framework for future standardsdevelopment and for resolution of differences in object models within standards currentlyunder development. It is hoped that by providing an overview and more concreteframework for standards development, more insight will be available to all contributors forthe harmonization of TC57 object models. This will in turn lead to greater acceptance ofTC57 standards in new product development and fewer incompatibilities requiring customadapters and gateways for implementing new computer systems and network for powersystem control.

Furthermore, now that the TC57 standards, especially the 61968/61970 CIM and 61850standards, have been recognized as pillars for realization of the Smart Grid objectives ofinteroperability and device management, it is imperative that a correct understanding ofthese standards and their application be made available to the key stakeholders and allother interested parties involved in implementing the Smart Grid.

The Reference Architecture for Power System Information Exchange is constantlyevolving as new standards are developed and existing standards are modified. As aresult, this report should be treated as a living document, wherein future editions of thisdocument will be needed to reflect the latest new developments as well the results ofharmonization efforts within TC57.



62357 © IEC:2011 - 93 -

10 Acknowledgements

The editor would like to acknowledge all the IEC members who contributed to thecontents of this document as well as those who took the time to review and comment onthis second edition of this report.



62357 © IEC:2011 - 94 -

Annex AObject Models and Mappings within TC57

A.1 TC57 Object Models

Table A-1 below shows some of the common elements of a power system that aremodeled in the different standards produced by TC57. While this list is not complete, itdoes illustrate the overlap between the different standards.

Table A-1, TC57 Object Models

ObjectsModeled

61970/68CIM

61850 ACSI 60870- 6TASE.2

60870- 5- 101/104

Measurand x x x x

Status x x x x

SCADA Point x x x x

Control Point x x x x

Substation x SCL/IdSwitch x SCL/Id

Transformer x SCL/Id

Connectivity x SCL

Schedule x x

InformationBuffer

x x

Generator x SCL/Id

GeneratorOutage Report

x

Contract x

A.2 61850 Models and Mappings

IEC 61850-7-2 specifies several models and abstract services, known as the ACSI, tofacilitate horizontal and vertical information exchange on and between station level, baylevel and process level. Since IEC 61850-7-2 is abstract (e.g., no concretecommunication packets defined), other parts of IEC 61850 are used to map the abstractservices and models into concrete communication protocols and packets.

IEC 61970-4 and 61970-5 specify a service model known as the GID. 61970-4 specifiesa Platform Independent Model (PIM) for services, while 61970-5 specifies the mappingof the abstract GID services to specific platforms (i.e., Platform Specific Models (PSM),such as Web Services.

IEC 61968 specifies a set of verbs that can be used as a short hand way of describingservices. 61968 verbs are completely abstract since 61968 does not describe specifictechnologies. 61970-402 Annex C contains a mapping of 61968 verbs to 61970 services.

Table A-2 below shows which parts of 61850 currently contain the mappings of the61850, 61970, and TASE.2 abstract services as well as 61968 verbs (see Section 3.4.1for issues involving a TASE.2 aggregator).



62357 © IEC:2011 - 96 -

Annex BComparison of Circuit Breaker Models

within TC57

B.1 Introduction

This annex compares the different models of a circuit breaker within TC57.

B.2 61970/68 Circuit Breaker Model in the CIM

The model of a circuit breaker in the CIM is quite complex, due to the fact that the CIMmodels all aspects of a circuit breaker – both its role as an electrical device in a networkand its role as an asset owned by a utility. All aspects are modeled in UML in the CIM asone, contiguous electronic model, even though the classes that comprise the CIM modelmay reside in different Packages and be part of more than one series of standards of IECstandards. The result is a normalized model that is independent of any particularapplication‟s use of that model.

B.2.1.1 Role as Network Electrical Device

The CIM provides a model of a circuit breaker as an electrical device in a network. FigureB-1 shows the circuit breaker modeled as the Brea ker class, which is a specialization of amore generic Switch. In fact, the total set of attributes modeled for a Circuit breaker is acomposite of all the attributes inherited from its several parent classes as shown inFigure B-1 as follows: Switch, ConductingEquipment, Equipment, andPowerSystemResource. (Like the Breaker, most all classes in the CIM that can beinstantiated inherit naming attributes from the Naming class). The Breaker is containedby an EquipmentContainer. The Breaker ‟s electrical connectivity to other devices to forma topological network is modeled via a Terminal and ConnectivityNode on each side ofthe Breaker. The state of a Breaker is an attribute of DiscreteValue (a specialization ofMeasurementValue) associated with the Breaker via the Terminal. Any othermeasurements associated with a Breaker are also modeled as MeasurementValuesassociated with the appropriate Terminal. Measurements typically also are associated toan EquipmentContainer instance as well. The Packages that each class belongs to areshow in paranthesis for each class.

This electrical model is part of the 61970-301 CIM Base standard. It is modeled in UMLas part of the overall CIM model. Since a circuit breaker is one device in a completepower system model, its relationships with other devices is an essential part of themodel.



62357 © IEC:2011 - 97 -

Figure B-1, 61970 CIM Model for a Circuit Breaker

Voltage level

Bay

Sub-function

Equipment

- Added

IIdentifiedObject

(from Core)

ConductingEquipment

(from Core)

Breaker

(from Wires)

Switch

(from Wires)

ConnectivityNode

(from Topology)

Equipment (from Core)

EquipmentContainer

(from Core)

0..n

1 0..n

1 0..1 0..n 0..1

0..n

Terminal

(from Core)

0..n

1 0..n

1 0..n

0..1 0..n

0..1 MeasurementValue (from Meas) DiscreteValue

(from Meas)

Discrete

(from Meas)

1

1..*

1

1..*

PowerSystemResource

(from Core)

Asset (from AssetBasics) 0..n 0..n 0..n

0..n

Measurement

(from Meas)

0..n

0..1

0..n



62357 © IEC:2011 - 98 -

B.2.1.2 A Simple Network Example with a Circuit Breaker

To illustrate how the circuit breaker object would appear in an electrical network, a simpleexample is given in Figure B-2. The example shows a transmission line with a T-junctionspanning two substations and a substation having two voltage levels with a transformerbetween them. The transmission line consists of two different cables. One of the voltagelevels is shown with a busbar section having a single busbar and two very simple

switchgear bays connecting to the busbar. The circuit breakers are shown as dark squareboxes – one between the busbar section and the high side transformer windings oftransformer T1, and one between a disconnect switch (shaded diamond) and the AC linesegment Cable 1.

SS1

SS2

400KV

110KV

12345 MW

12345 KV

12345 MW

Cable1 Cable2

SS1-SS2

T1

BB1

SS4

Cable3

Figure B-2, Simple Network Example with Two Breakers

Figure B-3 shows how connectivity is modeled in the CIM as well as one way (but notnecessarily the only way) containment is modeled for the diagram in Figure B-2. Theshaded square boxes represent EquipmentContainers, and the white square boxesrepresent ConductingEquipment. Darker shading indicates the EquipmentContainer ishigher up in the containment hierarchy (i.e., Substation is highest, VoltageLevel next,etc.). White circles represent ConnectivityNodes, and black small circles representTerminals. A Terminal belongs to a ConductingEquipment, and a ConnectivityNodebelongs to an EquipmentContainer. This means that the borders (or contact points)between ConductingEquipment are their Terminals interconnected via ConnectivityNodes.



62357 © IEC:2011 - 99 -

SS3SS 1

Cable2

SS 2

110KV

400KV

Cable1 CN2CN3BR1

DC2 CN4

P1

(MW)

CN5

BB1

T 1

TW 1

TW 2

CN7

CN6

Volts

(KV)

BR3

P2

(MW)

CN1

SS1-SS2

C a b l e 3

SS 4

CN8

Figure B-3, Simple Network Connectivity Modeled with CIM Topology

The Line SS1-SS2 has two ACLineSegments - Cable1 and Cable2. A collapsedSubstation SS3 with ConnectivityNode CN2 models the connection point between the ACLineSegments as wel l as a T-junction to Cable3, which provides a connection toSubstation 4. Each ACLineSegment has two Terminals. Cable1 is connected to CN3 andCN2 via these Terminals. CN3 is contained by the VoltageLevel 400KV. The breaker BR1has two terminals of which one is connected to CN3. The rest is left to the interestedreader to trace.

Measurements are represented by square callouts where the arrow points to a Terminal.P1 is connected to the right Terminal belonging to breaker BR1. Note that P1 is drawninside the box representing BR1. This is because a Measurement may belong to a

PowerSystemResource (PSR), as is the case with BR1. P2 is drawn inside theVoltageLevel 400KV, which means it belongs to the 400KV VoltageLevel instead of BR3.

B.2.1.3 Role as an Asset

Figure B-1 shows how the breaker is also modeled as an asset via the associationbetween the parent classes PowerSystemResource and Asset. In this way all aspects ofthe breaker as an asset are modeled via specialization of the Asset class andassociations with other entities, such as Location, ActivityRecord, Organization, etc. thatare contained in the 61968-11 CIM model.

Figure B-4 shows how the location of the breaker as an electrical device in a network aswell as a physical asset performing this role is modeled in the CIM.



62357 © IEC:2011 - 101 -

Figure B-5, Top of Asset Hierarchy

Figure B-6 shows the types of document relationships inherited by a breaker. Thesespecialized document classes include QualificationRequirement, AssetProperty, AssetRating, Inspect ionRoutine, and MaintenanceProcedure.



62357 © IEC:2011 - 102 -

Figure B-6, Types of Document Relationships Inherited by all Assets

Figure B-7 shows the model for activity records associated with a circuit breaker, such aswhen it was installed, when maintenance was performed, etc. Associations betweenactivity records and other classes complete the model.



62357 © IEC:2011 - 103 -

Figure B-7, Activity Records Associated with a Circuit Breaker

This asset model is part of the 61968-11 CIM standard developed by WG14. It is modeledin UML as part of the overall CIM model portions of which are developed by WG13.

B.2.2 61970-301 CIM Base Standard for a Circuit Breaker

This section contains an excerpt from the published standard for a circuit breaker, whichas stated earlier is modeled as a Breaker in the Wires package of the CIM.

Breaker

A mechanica l switching dev ice capable of making, carrying, and break ing currents undernormal circuit conditions and also making, carrying for a specified time, and breakingcurrents under specified abnormal circuit conditions e.g. those of short circuit. ThetypeName is the type of breaker, e.g., oil, air blast, vacuum, SF6.

Breaker Attributes

Native Attributes ampRating (CurrentFlow) Fault interrupting rating in amperes inTransitTime (Seconds) The transition time from open to close, in



62357 © IEC:2011 - 104 -

seconds

Inherited AttributesSwitch.normalOpen (Boolean) Set if the switching device is normally open. Switch.switchOnCount (Counter) The switch on count since the switch was last

reset or initialized. Switch.switchOnDate (AbsoluteDat

eTime)The date and time when the switch was lastswitched on.

ConductingEquipment.phases

(PhaseCode) Describes the phases carried by a conductingequipment. Possible values { ABCN , ABC, ABN, ACN, BCN, AB, AC, BC, AN, BN, CN, A,B, C, N }.

Naming.aliasName (String) Free text name of the object or instance.Naming.description (String) Description of the object or instance. Naming.name (String) Unique name among objects owned by the

same parent. Naming.pathName (String) pathName is a concatenation of all names from

each container.

Breaker Associations

Native Roles 0..n) OperatedBy_Protecti

onEquipments (0..n ) ProtectionEqui

pment Circuit breakers may beoperated by protection relays.

1) RecloseSequences (0..n ) RecloseSequence

A breaker may have zero ormore automatic reclosuresafter a trip occurs.

Roles Inherited From Switch 0..n ) SwitchingOperations (0..n ) SwitchingOper

ation A switch may be operated bymany schedules.

Roles Inherited From ConductingEquipment

1 )Terminals

(0..n ) Terminal ConductingEquipment has 1 or2 terminals that may beconnected to otherConductingEquipmentterminals viaConnectivityNodes

0..n ) BaseVoltage (0..1 ) BaseVoltage Use association toConductingEquipment onlywhen there is no VoltageLevelcontainer used

1 ) ClearanceTags (0..n ) ClearanceTag Conducting equipment mayhave multiple clearance tagsfor authorized field work

0..n ) ProtectionEquipment

s

(0..n ) ProtectionEqui

pment

Protection equipment may be

used to protect specificConducting Equipment.Multiple equipment may beprotected or monitored bymultiple protection equipment.

Roles Inherited From PowerSystemResource 0..n ) OperatedBy_Compa

nies (0..n ) Company A power sys tem resource may

be part of one or more



62357 © IEC:2011 - 105 -

companies 0..n ) PSRType (0..1 ) PSRType 0..1 ) Contains_Measurem

ents (0..n ) Measurement Measurement-PSR defines the

measurements in the naminghierarchy.

1 ) OutageSchedule (0..1 ) OutageSchedule

A power sys tem resource mayhave an outage schedule

0..n ) BusinessUnit (0..1 ) BusinessUnit A power sys tem resource maybe operated by oneBusinessUnit at a time.



62357 © IEC:2011 - 106 -

B.3 61850 Circuit Breaker Model

A model of a circuit breaker is con tained only in SCL and not on the communicating IEDs,i.e. it is used for system / application configuration purposes. The abstract UML basedmodel is similar to the CIM UML model (see Figure B-1) with the restriction that thehigher power system structure levels above EquipmentContainer, not shown in Figure B-1, are a bit more restricted than in CIM. Further, the contents of the container andequipment objects is mainly restricted to their instance identification and description.Online available are the functions (logical nodes) which deal with the circuit breaker,typically of classes XCBR as interface to the physical circuit breaker, and CSWI, whichhandles commands to the circuit breaker and checks interlocking (at logical node CILO),blockings (at logical node XCBR) and synchrocheck (at logical node RSYN) beforeforwarding the command execution request to the XCBR logical node.

The following gives an example of a modelled circuit breaker identified as P2E1Q2QA1,i.e. circuit breaker QA1 in bay Q2 of voltage level E1 in substation P2 (name structureand used coding according to IEC 61346), and the other objects needed to configure itsusage within a SA system.

The positions of each of its three phases are accessable via three XCBR logical nodes atthe phases L1, L2 and L3, while a fourth XCBR logical node directly at QA1 offers thethree phase view. The switch control CSWI, synchrocheck RSYN and interlocking CILOwork on the three phase (single line) view. From the full logical node instance names itcan be seen that they are hosted by the IED P2KA1, and all except RSYN within thelogical device C1.

From the single line view in Figure B-8, it can be seen that the circuit breaker is part of aline bay containing also other switches (see hierarchy view as well as graphical part inthe Figure). As shown, SCL models the single line topology by terminal links toconnectivity nodes, here P2/E1/Q2/L16 and L17 on both sides of QA1.



62357 © IEC:2011 - 107 -

Figure B-8, Single Line View of Circuit Breaker

Figure B-9 below illustrates the communication and IED view as described by SCL. The

Subnetwork P2WA1 connects the control IED P2KA1 with the network control gateway

P2Y1 and the system master clock P2P21TS. Further, the logical device C1 on IEDP2KA1 and some of the contained logical nodes are shown in the tree view.



62357 © IEC:2011 - 108 -

Figure B-9, Communications and IEC View

Table B-1 shows the online accessible data of the circuit breaker at its interface logical

node XCBR is described in 61850 (excerpt from IEC 61850-7-3; M means mandatorydata, o optional data)

Table B-1, Accessible Data for Circuit Breaker at LN XCBR

XCBR class

Attribute Name Attr. Type Explanation T M/O

LNName Shall be inherited from Logical-Node Class (see IEC 61850-7-2)

Data

Comm on Log i c a l Node I n f o rma t i o n

LN shall inherit all Mandatory Data from Common Logical Node Class M

Loc SPS Local operation (local means without substation automationcommunication, hardwired direct control)

M

EEHealth INS External equipment health OEEName DPL External equipment name plate O

OpCnt INS Operation counter M

Con t r o l s

Pos DPC Switch position M

BlkOpn SPC Block opening M

BlkCls SPC Block closing M

ChaMotEna SPC Charger motor enabled O



62357 © IEC:2011 - 109 -

XCBR class

Attribute Name Attr. Type Explanation T M/O

Mete red Va lues

SumSwARs BCR Sum of Switched Amperes, resetable O

S t a tu s I n f o rma t i o n

CBOpCap INS Circuit breaker operating capability M

POWCap INS Point On Wave switching capability O

MaxOpCap INS Circuit breaker operating capability when fully charged O



62357 © IEC:2011 - 110 -

Annex CStrategic Vision from the Intelligrid Architecture

C.1 Introduction

The strategic vision for the IntelliGrid Architecture reflects the ultimate objectives for adistributed computing infrastructure that can meet business needs, includingconfiguration requirements, quality of service requirements, security requirements, anddata management requirements. This strategic vision is based on:

Abstract Modeling

Security Management

Network and System Management

Data Management

Integration and Interoperability

Technology Independent Design Techniques

IntelliGrid Methodologies for Using the IntelliGrid Architecture

The Intelligrid strategic vision is described in the following subclauses.

C.2 Abstract Modeling

Modeling is one of the most powerful tools available for understanding, documenting, andmanaging the complexity of the infrastructures required to operate the energy system ofthe future. It is far less expensive to construct a model to test theories or techniques thanto construct an actual entity only to find out that one crucial technique is wrong and theentire entity must be re-constructed.

Models have been used extensively by many industries as the basis to analyze anddesign complex systems. The telecommunications industries have made extensive use ofmodeling to develop the diverse communications infrastructure(s) in widespread usetoday. Physical models are used in many industries, ranging from airplanes and MarsLanders to circuit breakers and transformers. Building architects use paper models(blueprints) to capture all the complexity in a modern high-rise building. Virtual modelsare increasingly being used to model even more complex concepts, from weatherpatterns to cosmology and, of particular interest to IntelliGrid Architecture project, toinformation management.

C.2.1 Object Modeling and Information Models

These models define data names and structures. These information models can bedescribed informally as consisting of nouns. Nouns consist of data names and their

structure. Examples include simple data points such as a point called „State‟ that consistsof one 8-bit integer, as well as more complex data points that include the value, thequality of the value, the description of the point, etc. These nouns can also range tocomplete descriptions of a utility‟s power system, for example „ABCPowerSystem‟, whichconsists of thousands of components in some well -known structure. There can be millionsof nouns in any system.

In the power industry, IEC61850 includes such a model, which is focused on field devicecharacteristics. Another information model is IEC61970 Common Information Model(CIM), which is focused on modeling what information about the power system structure



62357 © IEC:2011 - 111 -

is to be exchanged among application programs. It has been expanded to model othertypes of information to be exchanged among application programs. As an informationmodel specifies what information is exchanged, it is part of an RM ODP information view.

C.2.2 Abstract Service/Interface Models

A service model describes the functionality that a software application provides.

IntelliGrid Architecture‟s Common Services describe common functionality needed tooperate a utility. For example, the common service of „LogOn‟ specifies the commonfunction of initiating a secure session with a software application.

Interface models define the mechanics of how data is passed to get the right informationto the right destination at the right time. These interface models can be describedinformally as consisting of verbs. Verbs are the abstract services used to exchange thenouns, such as „request‟, „send‟, „report if changed‟, „add to log‟, etc. Although differentverbs/services are used in different environments, the number of different types ofabstract verbs/services is generally on the order of 10 to 20.

In the power industry, IEC61850 includes such a model, which is focused on field deviceoperation. Another service model is IEC61970 Generic Interface Definition (GID) , which isfocused on how information about the power system structure is to be exchanged among

application programs. An interface model specifies how information is exchanged; it ispart of an RM ODP Computational View.

C.2.3 Naming

One aspect of information models is the need to uniquely identify all objects within themodel. In addition, as the number of names being used proliferates, there is a need toavoid „name‟ collisions. That is the same name used with two different meanings. This ishandled by namespace allocation. Namespace allocation is a very simple concept:different groups can have the authority to give names their own objects so long as thosenames are unique within the group‟s domain; however, they do not need to be universallyunique. This permits different groups, whether they are whole industries, or standardsorganizations, or types of products, or a department within a company, to define theirown terminology and abstract model names and structure.

Namespace allocation for the electric power industry should be performed in a top-downmanner that clearly captures the different arenas. Although some namespaces should beas broad as possible (i.e., valid across the entire electric power industry), additionalnamespaces should be allowed as part of a formal scheme to permit specific utilities,specific vendors, specific functions, and other groups to apply for and register their ownnamespaces.

An example of namespaces within the IEC TC 57 is the allocation substations to theIEC61850 namespace and the allocation of transmission power system applications tothe IEC61970 namespace.

C.2.4 Self-Description and Discovery

Future advanced automation systems must have more capable methods for managingnetworks, connected equipment and the applications that run on this equipment. This willrequire more sophisticated systems to assist system administrators in managing largescale networks and massively distributed equipment. Concepts such as self-descriptionand discovery will become a necessary part of future systems or maintenance couldeasily become unwieldy.



62357 © IEC:2011 - 112 -

C.2.5 Security Management

Security is one of the strongest drivers for applying architecture principles across theindustry. The cyber security of advanced automation and consumer communicationssystems is one of the most important and challenging technical issues of our time.Increasing demand for information technology and reliance on advanced automation hascreated substantial challenges for system administrators as they try to keep their cyber

systems secure from attack. Higher levels of integration across the industry and usingopen systems combine to raise the challenges of securing systems. Security policyimplementation, a recommended practice, requires many of the concepts thatarchitectures bring forward including system documentation, and structure.

Security must be planned and designed into systems from the star t. Security functionsare integral to the designs of systems. Planning for security, in advance of deployment,will provide a more complete and cost effective solution. Additionally, advanced planningwill ensure that security services are supportable (may be cost prohibitive to retrofit intonon-planned environments. This means that security needs to be addressed at all levelsof the architecture.

C.2.6 Network Management

As can be seen in the figure below, two inf ras tructures must now be managed: the PowerSystem Infrastructure and the Information Infrastructure. The management of the powersystem infrastructure is increasingly reliant on the information infrastructure asautomation continues to replace manual operations, and is therefore affected by anyproblems that the information infrastructure might suffer.

Figure 10-1, Power System and Information Infrastructures

Network and systems management are those functions required to manage thecommunication networks and the connected communications equipment. Systemsmanagement includes managing remote equipment. These are functions a systemadministrator uses in managing the distributed computing infrastructure and connectedequipment. The development of these functions is taking place both within and outside ofthe energy community.



62357 © IEC:2011 - 113 -

In the future, the problem of network and systems management will become increasinglycomplex as a variety of systems are anticipated as well as greater demands on thecapabilities of these systems to assist system administrators. Traditional SCADA systemswill no longer have exclusive control over the communications to the field, which may beprovided by telecommunication providers, or by the corporate networks, or by otherutilities. Intelligent Electronic Devices (IEDs) will have applications executing within themwhose proper functioning is critical to power system reliability. Field devices will becommunicating with other field devices, using channels not monitored by any SCADAsystem. Information networks in substations will rely on local „self -healing‟ proceduresthat will also not be explicitly monitored or controlled by today‟s SCADA s ystems.

The technology industry has developed two network management technologies: SimpleNetwork Management Protocol (SNMP) for the Internet-based functions, and CommonManagement Information Protocol (CMIP) as an ISO standard. In each of thesetechnologies, Management Information Base (MIB) objects must be specifiedrepresenting the state of different equipment, applications, and systems. Although manyMIB objects are generic enough to be used by electric power systems, some specializedMIB objects will need to be developed to represent some of the very specializedequipment used in power system operations.

C.2.7 Data Management

Data management is one of the most difficult aspects of the information infrastructure. Alltoo often a very carefully designed system that has been designed to provide excellentbenefits to power system operations is ignored, or actually turned off, because the inputdata is just not accurate or available enough for the results of the function to be trusted – „Garbage in; Garbage out‟. Data management must address a complex set of issues,which include the following:

Validating source data and data exchanges

Ensuring data is up-to-date

Managing time-sensitive data flows and timely access to data by multiple

different users

Managing data consistency and synchronization across systems

Managing data formats in data exchanges

Managing transaction integrity (backup and rollback capability)

Managing the naming of data items (namespace allocation and naming rules)

Maintaining database and data exchange

Logging, reports, and audit trails

No single technology exists that can be globally applied to handle all of these datamanagement issues, but increasing attention is being paid to develop „best practices‟ and

to promote various technologies that solve part of the data management problems. Theseefforts and technologies then form the vision for data management.

C.2.8 Integration and Interoperability

The goal of interoperable systems can be very hard to achieve in a diverse environmentwith many different requirements, many different vendors, and a wide variety ofstandards. Interoperability is particularly difficult where legacy systems prevent the use ofmore modern approaches. No one answer exists on how to integrate these older, less



62357 © IEC:2011 - 114 -

flexible systems, but the following technologies and best practices can help toward thatinteroperability.

Using object and services modeling

Using technology independent techniques

Using „Metadata‟ Using standards

Using gateways and protocol converters

C.2.9 Technology Independent Design Techniques

Using a technology independent design is an important concept when developinginteroperable systems and equipment today. A technology independent design mustfocus on the behavior and structure of the components within a system and abstract theimplementation details of any particular technology. This key concept allows for differentimplementations and technologies to exist, yet still allow these components to be usedinterchangeably. Using technology independent design enables a coherent architecture tobe created independently of deployment specifics. When implemented, the technologiesare chosen to meet requirements but are implemented in a way that complies with thetechnology independent design.

C.3 Methodologies for Using the IntelliGrid Architecture

The IntelliGrid Architecture also describes the overall methodology for undertakingprojects consisting of the following phases:

Phase 1: Executives use Business Cases to approve projects in order to meetBusiness Needs. Although this step in the process involves executive decisionsbased on cost-justification and other non-technical factors, from the IntelliGrid Architecture point of view, the key requirement for these executives in makingdecisions to approve projects is that they should require all IntelliGrid StrategicVision issues to be addressed in the Business Cases. Specifically, the Business

Cases should explicitly state whether or why not the Strategic Vision issues willbe part of the project, including Use Case modeling, use of abstract data models,security issues, network and system management, data management, andintegration/interoperability.

Phase 2: Domain Expert Stakeholders describe their User Requirementsthrough the formal Use Case process. Use Cases permit these experts to expresstheir requirements in a formalized manner that can then be coordinated andsolidified into more detailed functional and performance requirements in the nextphase.

Phase 3: Project Engineers develop the more detailed functional andperformance requirements from the Use Cases that were developed by thedomain experts.

Phase 4: Project Engineers and IT Specialists assess applicability to theproject of the standards, technologies, and best practices identified in theappropriate IntelliGrid Environments.

Phase 5: Design Engineers develop Technical Specifications based on StrategicVision, Tactical Approach, & Standards



62357 © IEC:2011 - 115 -

Annex DCIM/61850 Mapping Recommendations

D.1 Introduction

This annex contains a table of recommended mappings between CIM UML

Classes/Attributes and 61850 SCL Types.

UML SCL

Class Attribute Abbreviation Type

ACLineSegment LIN tPredefinedCommonConductingEquipmentEnum

BaseVoltage tVoltage

Battery BAT tPredefinedCommonConductingEquipmentEnum

Bay tBay

Breaker CBR tSwitch

BusBarSection BBS tPredefinedCommonConductingEquipmentEnum

CapacitorBank CAP tPredefinedCommonConductingEquipmentEnum

Conductor CND tPredefinedCommonConductingEquipmentEnum

Conductor InsulationType=Gas

GIL tPredefinedCommonConductingEquipmentEnum

ConnectivityNode tConnectivityNode

Connector CON tPredefinedCommonConductingEquipmentEnum

CurrentTransformer CTR tPredefinedCommonConductingEquipmentEnum

Disconnector DIS tSwitch

EnergyConsumer EnergyConsumer

tPredefinedCommonConductingEquipmentEnum

Fan FAN tPredefinedCommonConductingEquipmentEnum

Fuse FUSE tSwitch

GeneratingUnit GEN tPredefinedGeneralEquipmentEnum

Ground tConnectivityNode with grounded=True

GroundDisconnector GNDDIS tSwitch

Jumper JMP tSwitch



62357 © IEC:2011 - 116 -

UML SCL


Junction CAB tPredefinedCommonConductingEquipmentEnum

Line tLine

LoadBreakSwitch LBS tSwitch

Motor MOT tPredefinedCommonConductingEquipmentEnum

Peterson Coil EFN tPredefinedCommonConductingEquipmentEnum

PowerTransformer tPowerTransformer

ProtectionEquipment PROT tPredefinedGeneralEquipmentEnum

Reactor REA tPredefinedCommonConductingEquipmentEnu

m

RectifierInverter RINV tPredefinedCommonConductingEquipmentEnum

Resistor RES tPredefinedCommonConductingEquipmentEnum

RotatingReactiveComponent

RRC tPredefinedCommonConductingEquipmentEnum

SCR SCR tPredefinedCommonConductingEquipmentEnum

SeriesCompensator SCMP tPredefinedCommonConductingEquipmentEnum

ShuntCompensator PSH tPredefinedCommonConductingEquipmentEnum

StaticVarCompensator TCR tPredefinedCommonConductingEquipmentEnum

Substation tSubstation

SurgeArrestor SAR tPredefinedCommonConductingEquipmentEnum

Switch GEN tSwitch

SynchronousMachine SMC tPredefinedCommonConductingEquipmentEnu

m

TapChanger General tTapChanger

PhaseTapChanger Phase tTapChanger

RatioTapChanger Ratio tTapChanger

Terminal tTerminal



62357 © IEC:2011 - 117 -

UML SCL


TCF TCF tPredefinedCommonConductingEquipmentEnum

TopologicalIsland tTopologicalIsland

TopologicalNode tTopologicalNode

TransformerWinding tTransformerWinding

VoltageLevel tVoltageLevel

PotentialTransformer VTR tPredefinedCommonConductingEquipmentEnum



62357 © IEC:2011 - 118 -

Annex EBibliography

This annex lists the publications referenced in this document.

1. Harmonizing the International Electrotechnical Commission CommonInformation Model (CIM) and 61850 Standards via a Unified Model: Key to Achieve Smart Grid Interoperabi li ty Object ives. EPRI, Palo Alto, CA: 2010.1020098.

2. OPC Unified Architecture (UA) Part 1 - Overview and Concepts 1.01Specification, 9 February 2009.

3. POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATIONEXCHANGE – TC57 Good Working Practice (GWP) Technical Report, 2010.