the standards based integration company - ems …emmos.org/prevconf/2010/cim and iec 61850...

Systems Integration Specialists Company, Inc.

The Standards Based Integration Company

© Copyright 2010 SISCO, Inc.1

Introduction to CIM, IEC 61850, and CIM-IEC 61850 Harmonization

Ralph MackiewiczSISCO, Inc.6605 19½ Mile RoadSterling Heights, MI 48314-1408 USATel: +1-586-254-0020 x103Fax: +1-586-254-0053Email: [email protected]


Definitions:

InteroperabilityInteroperability

The ability of computer systems to exchange information with other systems.

IntegrationIntegrationThe ability of computer based applications to interact

with other systems in order to perform a useful function for the user.


�Easy to Achieve:

Interoperability and Integration

Nearly anything is possible with enough money and

development effort


A Better Way

� Interoperability and Integration without having to program it all yourself:

� Where applications and devices are inherently capable of interoperating with other systems and performing integrated application functions in a cooperative and distributed manner.

� This is only possible if there are standards to enable it.

� This work is progressing.

� This is the goal of the IEC TC57 standards� IEC 61970 – IEC 61968: CIM � IEC 61850 – Communications and Networks for Power System Automation


A Cautionary Note

� Interoperability and Integration (aka “Plug and Play”) of applications is a path, not an end point.

� By the time we get to were we are going today, someone will havemoved the goal.

� If you don’t set out on the path, you will never make any progress.

� The first on the path will work the hardest and will also reap the most reward.


The Interoperability Dilemma

Meter RTU Recloser Breaker TransformerDiff.

RelayO.C.Relay SOE

EMS/SCADAConnecting protocols using point to point links works for a small number

of devices



Meter RTU Recloser Breaker TransformerDiff.

RelayO.C.Relay SOEMeter RTU Recloser Breaker Transformer

Diff.Relay

O.C.Relay SOEMeter RTU Recloser Breaker Transformer

Diff.Relay


Diff.Relay


Diff.Relay


Diff.Relay


Diff.Relay

O.C.Relay SOE

HUNDREDS OF SUBSTATIONS!

EMS/SCADAThe same

approach does not work scaled up to deal with many protocols

and thousands of devices


RTU

Meter RTU Recloser Breaker Transformer Diff.Relay

O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE


EMS/SCADA


O.C.Relay SOE

RTU

RTUs simplified the communications infrastructure to enable large scale SCADA

systems to work


RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE


EMS/SCADA


O.C.Relay SOE

RTU

DMS CIS OMS

Now, more applications need

this same data


RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE


DMS CIS EMS/SCADA OMS


O.C.Relay SOE

RTU

RTURTURTURTURTURTURTURTU

RTURTURTURTURTURTURTURTU

Installing RTUs for each application

creates an unwieldy communications

architecture


The Integration Dilemma

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOEMeter RTU Recloser Breaker Transformer Diff.

RelayO.C.Relay SOE

RTU


Solution is to integrate the applications



RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU



RelayO.C.Relay SOE

RTU


GIS WOM MaintVSA

Now we have new applications that need

integration



RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU


O.C.Relay SOE

RTU



RelayO.C.Relay SOE

RTU


GIS WOM MaintVSA

Too many applications increases the complexity and the cost


A Better Way� Interoperability and Integration without having to program it all yourself:

� Where applications and devices are inherently capable of interoperating with other systems and performing integrated application functions in a cooperative and distributed manner.

� A model driven approach that provides a means of dealing with the complexity of systems.

� This is only possible if there are standards to enable it.

� This work is progressing.

� This is the goal of the IEC TC57 standards




The Common Information Model (CIM), Generic Interface Definition (GID), Web Services, and IEC 61850

IEC TC57 Integration


Standardized

Interfacing Protocols to Applications

Application1

Driver 1

Application2

Driver 2

Application3

Driver 3

Application4

Driver 4

Application5

Driver 5Not

Standardized

Standardized Protocol

Interface


Impact of Lack of Interface Standards

� Each application developer has to develop drivers for all popular protocols.

� Application developers spent considerable resources on drivers instead of applications.

� Result:� Everybody has to solve the same protocol problems

(less interoperability)� Have to make application decisions based on protocol functionality

(less choice) � Less application functionality� Higher application costs


Using Protocols: Interface Standards Lower Costs

Application1

Driver

Application2

Driver

Application3

Application4

Application5

Driver


Impact of Interface Standards

� Allows developers to focus on applications because client application development can occur independent of the server application

� Enables sharing of interface development and maintenance costs across a larger user base

� Enables 3rd party development of add-ons, plug-ins, etc.� Enables niche application players to exist

� Results� More Functionality� More Choice� Less Proprietary� Lower Costs


Existing Widely Used Interface Standard: OPC

� OPC Foundation (http://www.opcfoundation.org) developed application programming interfaces to enable plug and play of applications and drivers called “OLE for Process Control” (OPC).

� OPC Foundation: 362 member companies (end users and OEMs)� 1500+ companies developing OPC applications (est. OPC Foundation)

� OPC is dominant in the industrial automation and process controlindustries providing connectivity to hundreds of key applications.

� 7500+ different OPC applications (est. OPC Foundation)

� Nearly ALL users in the industrial space expect and demand that their real-time application support OPC to simplify integration and ALL major application providers support OPC.


OPC Features

� Existing OPC Features� Based on Microsoft COM technology

� C++, C#, Visual Basic, Java (3rd Party), and 1 WS Bindings

� OPC Servers expose a namespace determined by the OPC Server itself

� Legacy OPC Shortcomings� Microsoft specific

� OPC Servers expose a namespace determined by the OPC server itself� Applications must adapt to each unique namespace presented by each OPC

server depending on interface developer, device, application, protocol, etc.

OPC LACKED A STANDARDIZED & TECHNOLOGY NEUTRAL METHOD OF REPRESENTING DATA


Common Information Model (CIM) is an object-oriented information model of the power system

Central GeneratingStation

Step-Up Transformer

DistributionSubstation

ReceivingStation



Commercial

Industrial Commercial

Gas Turbine

RecipEngine

Cogeneration

RecipEngine

Fuel cell

Micro-turbine

Flywheel

Residential

Photovoltaics

Batteries

UML – Unified Modeling Language


Benefits of Models

� Models give context and meaning to data improving integration and interoperability.

� The information contained in the model enables automation of setup and maintenance tasks.

� Model aware applications can be made independent of the data.


Read TSUB23PHA4023Read TSUB23PHB4023Read TSUB23PHC4023Read TSUB24PHA6187

Read TSUB76PHB5865Read TSUB76PHC5865Read TSUB76PHA5977Read TSUB76PHB5977Read TSUB76PHC5977

.

.

.

.

.

Read All Transformer Voltages

Other algorithms possible. But,

regardless of algorithm, programs must contain hard coded references

to either names or tables to access.

Data Dependent Application


CIM as a topic tree

Everything needed to access data is contained in

the modelNorth Area

Airport Substation Main

Substation

Breakers Loads Breakers TransformersTransformers

TC57 Physical Model

Company X


Data Independent ApplicationRead All Transformer Voltages

Find Next Substation

Find NextTransformer

Find NextVoltage

Read

Every name defined in the model


Legacy Data Model – Data is Referenced by TagSCADA

I need the primary current of the 345KV transformer in the airport substation


How do users find this today?

With lots of paper documentation and manual maintenance effort subject to manual error detection

and correction.


CIM View Of SCADA Data

ClientHierarchy changes with network model changes

SCADA

Device or other system related views

supported

Access by Description

Bus

XFMR XFMR XFMR XFMR

Bus

Substation


CIM Packages

ERP

Consumer

Assets Documen-tation

Core2

OAG

Generation

Load

Outage

Protection

SCADA

Measurements

Topology

Core

Domain

Financial

EnergyScheduling

Reservation

IEC 61970 from IEC TC57 WG13

IEC 61968 from IEC TC57 WG14

MarketOperations

IEC 62325from

IEC TC57WG16

Wires

Distribution EMS, Transmission & Planning Markets (Euro & NA)


CIM Equipment Models


CIM Transformer Model



The Common Information Model Defines Objects and Relationships

XFMRWinding

Substation

Transformer

VoltageLevels

Measurement

Has

SuperClassof

Has

Associated with

Power System Resource (logical)

SuperClassof

Equipment Container

Conducting Equipment

SuperClassof

Has


CIM As “Populated Instance Model”

Substation

VoltageLevels

Has

SuperClassof

Has

Associated with

Power System Resource (logical)

SuperClassof

Equipment Container

Conducting Equipment

SuperClassof

Has

RealizedBy

RealizedBy

RealizedByRealizedBy

Airport Substatio

n

Has

13KV

HasRealizedBy

Object Instances

XFR 123 Has

Winding ABC

Tag 567

XFMRWinding

Measurement

Transformer


How is CIM Used?

� Power System Model Exchange between neighboring utilities and ISO/RTOs

� Definition of Messages for exchange over an ESB

� Common Data Exchange Model for Application Integration


CIM Files and How They Are Used

� Use Cases. Technically, not a part of the CIM but necessary to determine how to use the CIM, what needs to be deleted or extended.

� UML Model File� Used by development tools to design the model� Available tools include Enterprise Architect and Rational Software Architect.� Used to extend the CIM with missing attributes and classes needed for the use

case

� Create a Profile of the CIM model to suit your business purposes� Eliminate unused attributes and classes from the profile� Tools exist for creating profiles (e.g. CIMTOOL)

� Generate a schema file:� CIM:XML schema using Resource Description Framework Specification format (RDFS).� XML Schema Description file using XSD format.



� Schema File� Describes all the object classes, their class relationships, and

attributes

� Essentially it is the UML file transformed into an XML file.

� How it is used:� Used by message development and processing tools� Used by Enterprise Service Bus (ESB) for message transformations� Used to configure applications with understanding of models to interpret

the content of the “instance files” (e.g. GID data exchange model)



� Instance File – CIM:XML format based on RDFS� A list of all the CIM objects contained within a given application

� All objects are related to the classes in the schema file� All objects are indentified by a unique “master resource identifier”

(MRID) or globally unique identifier (GUID).

� IEC 61970-501: CIM:XML RDFS file format� IEC 61970-552-4: Incremental and partial file format of -501

� Used to exchange data between applications� Power System Model Exchange� Application Data Exchange� Configure application adapters for application integration


Power System Model Exchange

� Schema is typically implied by mutual agreement between the parties.� Typically only instance files are exchanged.

EMS#1

Import Export

EMS#2

Export Import

Power System 1 Power System 2

EMS#1

ExchangeModel

EMS#2

ExchangeModel

NERC CPSM Profile – IEC 61970-452Interconnection Point(s)

Instance File

Instance File


Power System Model Exchange

� Schema is typically implied by mutual agreement between the parties.� Typically only instance files are exchanged.

DMS#1

Import Export

DMS#2

Export Import

Power System 1 Power System 2

DMS#1

ExchangeModel

DMS#2

ExchangeModel

IEC CDPSM Profile – IEC 61968-13Interconnection Point(s)

Instance File

Instance File


Using CIM to Define Messages� One of the IEC 61968-x interface standards defines the messages

� A profile of the CIM is used to define the message payloads.� A combination of IEC 61970-301 and IEC 61968-11, IEC 62325, etc. and

perhaps a standardized profile.

� Combine with the IEC 61968-1-x mapping to middleware (e.g. 1-1 ESB , 1-2 SOAP, etc.).

� The messages are derived from the standard interface message definitions (WSDL) combined with your use case specific profile.

� If the use case is identical, the messages can be. If not, they differ in the payloads at least.


CIM-GID Related Standards Use Middleware to Connect Systems

(AM)Records &

AssetManagement

(OP)OperationalPlanning &

Optimization

(NO)Network

Operations

(MC)Maintenance

&Construction

(EMS)Energy

Management &Energy Trading

(RET)Retail

(SC)SupplyChain &Logistics

Interface Standard Part 3














(CS)Customer

Support

(MR)Meter

Reading &Control

(NE)Network

ExtensionPlanning

(ACT)CustomerAccount

Management

(FIN)Financial

(PRM)Premises

(HR)Human

Resources

Electric Distribution Network, Planning, Constructing, Maintaining, and Operating

Generation and Transmission Management, Enterprise Resource Planning, Supply Chain, and General Corporate Services

Business Functions External To Distribution Management

Distribution Management Business Functions

IEC 61968-1-X Compliant Middleware Services


Message Organization – Message Envelope Structure

� Header: Required for all messages (except for fault response messages), using a common structure for all service interfaces

� Request: optional, defining parameters needed to qualify request messages

� Reply: Required only for response messages to indicate success, failure and error details

� Payload: Sometimes required, used to convey message information as a consequence of the ‘verb’ and ‘noun’ in the message Header


Message Organization – Message Envelope Header

�Verb: Identifies a specific action to be taken. There are an enumerated set of valid verbs, where commonly used values include ‘get’, ‘create’, ‘change’, ‘cancel’, ‘close’ and ‘reply’.

�Noun: to identify the subject of the action and/or the type of the if a payload is provided.

�Source: identifying the source of the message, which should be the ID of the system or organization.

�Revision: To indicate the revision of the message definition. This should be ‘1’ by default.


Message Organization – Message Envelope Header

�Nonce: A unique number that would not be repeated by a source system within the period of at least a day. This could be a sequence number, large random number or a GUID. This is defined by WS-Security. A combination of this number and the timestamp make the message unique for a given time period.

�Created: A timestamp to indicate when the message was created. This value and the Nonce are used to protect against replay attacks. This is defined by WS-Security.

�User: A complex structure that identifies the user and associated organization. Should be supplied as it may be required for some interfaces, depending upon underlying implementations.


Message Organization – Payload

� The structure of a payload is typically defined as a Profile from a UML model

�A payload may or may not be required in a message

�A message payload is required for a Create, Update Request or in a Reply for a successful Get Request


Message Organization - Example Message<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:mes="http://www.iec.ch/TC57/2008/schema/message"

xmlns:oas="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><soap:Header/><soap:Body>

<mes:EventMessage xmlns:mes="http://www.iec.ch/TC57/2008/schema/message"><mes:Header>

<mes:Verb>created</mes:Verb><mes:Noun>EndDeviceEvents</mes:Noun><mes:Context>TESTING</mes:Context><mes:Timestamp>2010-01-05T11:20:35-05:00</mes:Timestamp><mes:Source>L+G</mes:Source><mes:AsyncReplyFlag>false</mes:AsyncReplyFlag><mes:ReplyAddress>//10.3.6.87/EITESTServer.asmx</mes:ReplyAddress><mes:MessageID>19c1bb66-ae09-485e-b6b3-c0ece4a29d70</mes:MessageID><mes:Comment>TEST</mes:Comment>

</mes:Header><mes:Payload>

<ns1:EndDeviceEvents xmlns:ns1="http://iec.ch/TC57/2009/EndDeviceEvents#"><ns1:EndDeviceEvent><ns1:mRID>LGRF100000</ns1:mRID><ns1:category>3.26.9.185</ns1:category><ns1:createdDateTime>2010-01-05T10:20:33-05:00</ns1:createdDateTime><ns1:Assets>

<ns1:mRID>LGRF100000</ns1:mRID></ns1:Assets></ns1:EndDeviceEvent>

</ns1:EndDeviceEvents></mes:Payload>

</mes:EventMessage></soap:Body>

</soap:Envelope>

From IEC 61968-X Interface Spec

(WSDL)

From a profile of the model (CIM-UML)

IEC 61970-452 orIEC 61968-13, etc.




Next Step after Models:

Interface Standards

Generic Interface Definition (GID), Web Services, ESB, and SOA.


Web Services Architecture


Basic Web Service Integration Architecture

SCADA

Asset/WorkManagement

EMSData

Warehouse

GIS

Portal

N*(N-1) Different client/server service combinations

requiring coding

Typically no agreement on common messages, models, services, etc.


Flexible connectivity infrastructure for integrating applications and services to power SOA

� CONVERTING transport protocols between requestor and service

� ROUTING messages between services

� TRANSFORMING message format between requestor and service

� HANDLING business events from disparate sources

What is an Enterprise Service Bus (ESB)?


Components Connect To An ESB Using Web Services

SCADA


EMS Data Warehouse

GISPortal

Enterprise Service Bus

Application wrappers


SOA using ad-hoc web services with an ESB� Significant benefits due to use of widely deployed technology:

� SOAP – HTTP for transport� WSDL to describe the services and messages supported� Numerous development and middleware tools and products

� Ad-hoc because each application specifies its own services� Each service provider independently defines their own SPECIFIC web services

� Get Customer Record� Create Customer Record, etc.

� Each client needing to access a service must discover and adapt to each unique web service provider.

� Application integration still requires significant programming effort unique to:� The specific application functions involved� The developer/brand of the applications

� Result: integration is customized and unique to each and every system


CIM and GID - Enable More Interoperability in a Web Services Environment

� Provide a common agreement on WHAT data is exchanged

� The Common Information Model (CIM)

� Standardized Data and Message Types

� Provide a common agreement on HOW to exchange the data

� The Generic Interface Definition (GID)

� Standardized Interface Services to Exchange Data and Messages


GID provides standardized interface services

� GID provides GENERIC services (not ad-hoc or application specific services) that provide functions that are typically needed by all systems

� Generic Data Access (GDA): For model management and distribution of updates.

� High-Speed Data Access (HSDA): For access to real-time measurement data.

� Time Series Data Access (TSDA): For access to historical measurement data.

� Generic Events and Subscriptions (GES): For pub/sub of generic XML messages.

� GID interfaces reference all data in the context of a common data exchange model, the CIM.


Ad-Hoc Web Service Architecture

SCADA


EMS Data Warehouse

GISPortal


Application wrappers


GID Reduces the Custom Portion of Development

SCADA



EMS/DMS/GIS

Data Warehouse

GISPortal

= GENERIC GID Services

OMS

CIS


Some GID Applications

� Enable model information to be shared and exposed over a message bus to provide a unified data exchange model for applications.� Eliminate application dependencies on internal data representations of

systems.

� Enable self-configuring clients.

� Simplify propagation of system changes across enterprise.

� Expose models and data from legacy systems as CIM data� Eliminates dependencies on legacy table formats from applications needing

data

� Enables lower cost application migrations and enhancements

� Enables data trapped in inflexible legacy systems to be exposed and leveraged without copying/reproduction of the data


GID Application

ModelManager(populatedinstancemodel)

ServerApplication

An application that provides some

data about a CIM object. e.g.:

1. Asset Mgt. that provides information about breaker maintenance

2. Historian that provides information about breaker operations.

Client Application that

wants information on a

CIM object.


Initial Configuration

ModelServer

ServerApplication

Schema Download

Server relates CIM classes to the data

it serves (e.g. breakers)

Server maps the CIM data to its own internal representation

Instance Download


Using GID: GDA Application

GDAServer

GDA Client –

HSDA ServerApplication

UserEntersNew

Breakerinto

PowerSystemModel

GDA Event: New Breaker

GDA Query: Get Parents/properties

Model Data on Breaker

HSDA server determines if new breaker is in its

scope and configures itself

HSDAServer


Using GID: GDA and HSDA Application

GDAServer

GDA Client –

HSDA ServerApplication

UserEntersNew

Breakerinto

PowerSystemModel


GDA Query: Get Parents/properties

Model Data on Breaker

HSDA server determines if new breaker is in its

scope and configures itself

HSDAServer

HSDAClient

HSDA Create Group w/new Breaker


HSDA Advise: New Breaker Status


GID Service Names And Lineage

GID: How data is exchanged

IEC (Platform

neutral): GID

OPC(Windows)

OMG(CORBA)

Generic Data Access(GDA)

High Speed Data Access(HSDA)

Generic Eventing and Subscription

(GES)

Time Series Data Access(TSDA)

OPC Historical Data Access(OPC HDA)

OPC Alarms and Events

(OPC A&E and A&E XML)

OPC Data Access(OPC DA)

Historical Data Access From

Industrial Systems (HDAIS)

Data Access From Industrial Systems

(DAIS)Data Access Facility (DAF)

Extended

New WebServices

OPC Unified Architecture


Future: OPC Unified Architecture (UA)

� OPC Foundation was aware of the limitations of COM based OPC� OPC XML was a first pass of a technology neutral version

� OPC Foundation has released a Unified Architecture that provides a comprehensive set of unified web services for:� Data Access

� Historical Data Access

� Event/Alarm subscriptions

� Commands

� Model Query

� IEC TC57 WG13 GID web service mappings are being migrated to OPC UA specifications.


OPC Unified Architecture

OPC UA Base Services All Necessary Services

Vendor Information Model

DA A&E HDA CMDs OPC Information Model

Information Model Specifications IEC, ISA, OAGi, EDDL…

� Clients can still discover access all data from the derived layers

� Single Set of Unified Services:� Query, read, write, etc.


OPC UA Layering

Abstract UA Specifications

WSDL / SOAPor TCP / BinaryServices Binding

Proxy /Stubs

APITool orLanguageDependent(e.g. .NET)

Scalable Platform Independent Messaging Model with Security and Authentication

OPC Foundation Members Get:

.NET VersionC/C++ VersionJava Version

Business Model, Adaptable to Platform Independent Messaging Models (e.g. WSDL)


Do Interface Standards Work?

� The use of generic interface standards is widely used, accepted, and demanded in the industrial automation industry based on the OPC Foundation Standards.� 300+ members of vendors and users

� 1500+ plus companies supporting OPC products

� 7500+ plus products available

� Tens of Thousands of installations in mission critical systems

� OPC Unified Architecture (UA) is a secure web service based version of the OPC MS-COM based interfaces with hundreds of companies implementing.

� IEC 61970 new platform specific mappings for GID referencing OPC UA enabling multi-industry standardization.




IEC 61850 Overview


Legacy SCADA View of Data

Device Addressing or SCADA Tag Data Base

Flat set of tags

Applications

Applications Access Data by Tag


Legacy View of Data

� Proprietary tag formats.

� Arcane addressing:� Driver� Wire� Rack� Device Register/Index #� Network

� Manually entered.

� Manually verified.

� Applications tied to tag or free form alias.

� Any user tag conventions are proprietary.


Typical Legacy Protocol Data Model

Device

I need the Phase A voltage for the 345KV primary feeder

It is in:Object #6,

Variation #2,Index #27

That’s intuitive?

NO POWER SYSTEM CONTEXT FOR DATA ACCESS


Legacy Object Mapping

� Legacy data objects must be manually mapped to power system for each different device, application, and vendor.

Power System FunctionsLegacy Device

R400040

R400041

R400042

R400043

R400044

R400045

R400046

R400047

R400048

R400049

R40004A

R40004B

Phase A Voltage

Phase B Voltage

Phase C Voltage

Local/Remote Status

Breaker Position

Blocked Open

Activate Phase A

Activate Phase B

Activate Phase C

Measurements

Controls

Protection


Behavior Modeling

� Assume Index #25 is always used to store breaker status.� Does 1 mean open or closed?� Can I write this object to operate the breaker?� Where is the select?� Is it selected?

� Even if every device used Index #25 to hold breaker status this still isn’t enough to provide interoperability.


A New Approach Needed

� For protocols to provide interoperability at the system level they need to:

� Specify the bytes/format of the data on the wire

� Specify the meaning of data

� Specify the behavior of the data


IEC61850 is Different� IEC61850 is an object oriented substation automation standard that defines:

� Standardized names

� Standardized meaning of data

� Standardized abstract services

� Standardized device behavior models

� Standardized mapping of services to protocols for:� Control� SCADA� Protection� Transducers

� Self-describing devices

� Common configuration language


Anatomy of an IEC61850 Object Model

Physical Device – Named IED(network address)

Logical Device(e.g. Relay1)

MMXU1Measurement Unit #1

MXMeasurements

AAmps

PhVVolts

DCDescriptions

AAmps

PhVVolts

XCBR2Circuit Breaker #2

Logical Nodes

STStatus

PosPosition

COControls

PosPosition

IED:Relay1/MMXU1.MX.A IED:Relay1/XCBR2.CO.PosCurrent

MeasurementsBreaker

Position Control

IEC 61850 Object Names Use Power System

Context


Brand Y

IEC61850 View of Devices

Brand X

MMXU1.MX.PhVIEC61850 Name for Phase-to-Ground Voltage Measurements

IOC Relay

PIOC MeasurementsMMXU1

ST DC

Mod Mod

DC MX

PhV PhV

Diff Relay

PDIF MeasurementsMMXU1

ST DC

Mod Mod

DC MX

PhV PhV


IEC 61850 Object Mapping

� NO MANUAL MAPPING NEEDED: IEC61850 objects already portray the power system context.

IEC61850 Device

LD

MMXU1

XCBR1

PIOC1

MX.A.PhsA.cVal.mag.f

MX.A.PhsB.cVal.mag.f

MX.A.PhsC.cVal.mag.f

ST.Loc.stVal

ST.Pos.stVal

ST.BlkOpn.stVal

ST.Op.phsA

ST.Op.phsB

ST.Op.phsC


IEC61850 View of Devices� Only network addressing requires configuration in the remote client.

� Point names portray the meaning and hierarchy of the data with no mapping to I/O required.

� Device configurations can be exchanged using IEC61850-6-1 (SCL) files

� Point names can be retrieved from the device automatically without manual intervention or imported via SCL file.

� All devices share a common naming convention.


More on SCL (IEC61850-6-1)

� SCL – Substation Configuration Language a standardized method of describing

� Substation power systems� Device configuration

� SCL can be used to unambiguously describe user requirements for systems and devices.

� SCL can be used to configure applications without connecting to devices.

� SCL enables third party tools for configuration promoting choiceand flexibility.


Benefits� Reduced configuration costs:

� Eliminates most manual configuration via automatic point name retrieval from devices

� Common naming and object models eliminates ambiguity and manual mapping of data points.

� Equipment migrations occur with minimal impact on applications.

� Application changes have minimal effect on devices, network or other applications.

� Users can specify equipment more precisely eliminating delays and costly rework.

� Adoption of IEC 1850 in the engineering process can significantly reduce the effort to design, test, and deploy substations.


SCL File Types� SSD: System Specification Description.

� XML description of the entire system.

� SCD: Substation Configuration Description.

� XML description of a single substation.

� CID: Configured IED Description.

� XML configuration for a specific IED.

� ICD: IED Capability Description.

� XML description of what is supported by an IED (required for servers).


SCL FilesSSD File – Entire System

SCD File #1Single SubstationSubstation #1

SCD File #2Single SubstationSubstation #n

…CID File forIED #1

CID File forIED #2

…

CID File forIED #n-1

CID File forIED #n

CID File forIED #1

CID File forIED #2

…

CID File forIED #n-1

CID File forIED #n


ICD versus CID Files� CID File = Subset of ICD File

Actually Used + Substation Specific Configuration Info.

� Subset:� Not all logical nodes,

control blocks, I/O, etc. supported by the device are used in a system.

� Substation Configuration Info:� Report control block

presets� Static values for location,

and other descriptions.

ICD File – What an IED is capable of

CID – Configuration for a specific IED

Substation specific

configuration information


SCL Driven Naming


Logical Device and LN Naming = IEDName


SCL Applications

� For users to specify IED requirements.

� For vendors to specify IED capabilities.

� Configure IEC61850 clients w/o IEDs.

� Extract IED configuration from power system design tools.

� Export IED configuration to power system design tools and other applications.




Relay to Relay Applications

GOOSE Protection Messaginga.k.a. “Peer-to-Peer messaging”(misnomer – Multicast messaging)


Legacy Hardwired Architecture

Relay 1Breaker Relay 3 Breaker

Relay 2

Breaker

Relay 4

Breaker

1

5

4

2

3

6

Hardwired signals for relay to relay links


� Requires N*(N-1)/2 links for N relays.

� Requires filtering on links to prevent false trips.

� Reprogramming can require rewiring.

� Don’t know if links are working until you use them.

Legacy Architecture


IEC61850 Network Architecture

Relay 1

Breaker

Relay 2

Breaker

Relay 3

Breaker

Relay 4

Breaker

Network – Multicast Communications

GOOSE

GOOSE - Generic Object Oriented Substation Event (data sets)


� Relays share a common network making sophisticated protection schemes possible even across very large distances.

� Number of links for N relays is N and shared with SCADA.

� Relays send their status to all other relays at once using GOOSE.

� Status exchanged continuously.

� High performance.

IEC61850 Network Architecture


Benefits� Reduction of wiring costs

� More flexible programming is independent of wiring

� Reliability: Link status known before use.

� New capabilities not cost-effective with hardwired systems.

� Higher performance with more data

� ~ 3ms for hundreds of points


Improved Performance�Network access resolves very fast

�Duplex Ethernet switches NO collisions

�Data is transmitted multiple times to avoid missing data.

�Digital error checking instead of analog filtering.

�Use of IEEE 802.1p with Virtual LAN (VLAN) for segmenting and priority tag processing by network switches.


Wide Area Network

GOOSE Wide Area Application

Substation-to-Substation and Substation-to-EMS CommunicationIEC 61850-90-X

Application of VLAN and priority critical




Transducer Interfaces


IEC61850 Substation Architecture

MU

PT1 OpticalCT

MU

PT2 CT2

MU

OpticalPT

OpticalCT

Relay Relay Relay

MU Publishes V/I/Status Datasets

Relay(s) Subscribe to Datasets

I/O I/O I/O

Station Bus 10/100/1000 MB Ethernet

Process Bus

.1/1/10GBEthernet

Clk1 Clk2

RemoteAccess

Network

MU = Merging Unit

PT2 CT2 OpticalPT

OpticalCT

MU Publishes V/I/Status Datasets

Relay(s) Subscribe to Datasets

I/O I/O

.1/1/10GBEthernet

RemoteAccess

Network

MU MU MU

IED IED IED

Clk1 Clk2

GOOSE multicast and TCP/IP client/server communications


Legacy Approach

ProtectionRelay

BayController

A/D A/D A/D A/DInput Input

Voltagesand

currents

Voltagesand

currentsBreakerStatus

BreakerStatus


Legacy Approach

� Individually and redundantly wired to all devices needing the same signals:� CTs� PTs� Status Inputs� Outputs

� Each individual sensor must be calibrated and maintained separately.

� Incremental cost is exponential (signals x devices)

� Result is minimization of I/O

� Analog signal wiring constraints


9-2 Process Bus

IEC61850 Process Bus

Merging UnitA/D A/D Input

Voltagesand

currents

BreakerStatus

Ethernet

BayController

ProtectionRelay

FaultRecorder

RTU

Ethernet Ethernet Ethernet Ethernet


IEC61850-9-2 Process Bus� Transducer and I/O signals are shared via a network.

� Only one transducer or I/O point per signal.

� Minimization of calibration and maintenance.

� Incremental cost is linear (signals only)

� CT/PT signals can be sent across long distances

� Future: Integrated merging unit with digital fiber optic transducers


9-2 Process Bus

What is a bus?


Voltagesand

currents

BreakerStatus

Ethernet

BayController

ProtectionRelay

FaultRecorder

RTU,etc.

Ethernet Ethernet Ethernet Ethernet


What is a Bus?

Ethernet Switch Ethernet Switch Ethernet Switch


Voltagesand

currents

BreakerStatus

Ethernet


Process Bus

What is a Bus?

Ethernet Switch Ethernet Switch Ethernet Switch


Voltagesand

currents

BreakerStatus

Ethernet


New Development in Process Bus – point-to-point!?

Fiber Patch Panel

Merging Unit or “brick”A/D A/D Input

Voltagesand

currents

BreakerStatus

Fiber Optic Connector


Point-to-Point Process Bus – Controversy

� Some say 9-2 does not specify point-to-point links:� Therefore this is NOT process bus!

� Existing implementations of this technology have some non-interoperable “enhancements”� Requires interaction with special GOOSE messages to trigger MU

� Claims about “conformance testing” have been made inaccurately.

� Interesting idea even if it is not strictly 9-2 process bus.




IEC 61850 Standard and Object Models


IEC61850 Standard

Basic principles Part 1

Glossary Part 2

General Requirements Part 3

System and project management Part 4

Communication requirements Part 5

Substation Automation System Configuration Part 6

Basic Communication Structure Part 7

Part 9Sampled Values

Part 8

Conformance testing Part 10

Mapping to Ethernet

Mapping to MMS and Ethernet


IEC61850 Virtual Model

From IEC61850-7-1


IEC61850 Class Model in UML

ObjectNameObjectReference

Name SERVER

LOGICAL-DEVICE(LD)

LOGICAL-NODE(LN)

DATA

DataAttribute

1

1..*

1

1..*

1

3..*

1

1..*“Containment Heirarchy”

UML – Unified Modeling Language

Inheritance

Contains all other objects

Contains LDs and files


Logical Device Structure

IEC61850 Server Physical Device

LogicalNode

LogicalNode

Data Data Data Data

LogicalNode

LogicalNode

Data Data Data Data

Communications Driver

Legacy Device

LogicalDevice

LogicalDevice

Field Signals

. . . . . .

… … … …

1 to N Logical Devices

IEC61850 Clients

ClientFunctions

Process Bus


Logical Node

A named grouping of data and associated services that is logically related to some

power system function.


BreakerSwitch Controller

Current Transformer

Voltage Transformer

Breaker

Breaker

Examples of Logical Nodes


Common Data Classes (CDC)

� Defines structure for common types that are used to describe data objects.

� CDC are complex objects built on predefined simple base types organized into functional constraints (FC)

� Examples:� Single point status (SPS) – on/off� Double point status (DPS) – on/off/transient


IEC 61850 TimeStamp Format

� 4 Bytes = Second Of Century (SOC) Starting January 1, 1970� Based on the Network Time Protocol (NTP) standard� There are 31,536,000 seconds/year (non-leap)� 4 bytes = 4, 294,967,296 counts do not wrap for 136 years or 2106

� 3 Bytes = Fraction of Second� 16,777,216 counts� about 60nsec potential resolution

� 1 Byte = Quality� 1 bit : Leap Seconds not known� 1 bit : Clock Failure� 1 bit : Loss of Synchronization� 5 bits: Number of significant bits in Fraction of Second (N)


IEC 61850 Quality

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

13 bit Bit-String, typically stored in a 16-bit integer

00 Good01 Invalid10 Reserved11 Questionable

OverflowOutofRange

BadReferenceOscillatory

FailureOldData

InconsistentInaccurate

Source = 0 Process= 1 Substituted

Test

OperatorBlocked

MSB LSB


Common Data Classes

Complex Measured ValueCMVMeasured ValueMVBinary Counter ReadingBCRSecurity Violation CountingSECDirectional Protection Activation Info.ACDProtection ActivationACTInteger StatusINS

Harmonic value for DELHDELHarmonic value for WYEHWYEHarmonic valueHMVSequenceSEQPhase to phase measured values for 3-phase systemDEL Phase to ground measured values for 3-phase systemWYESampled ValueSAV

Double Point StatusDPSSingle Point StatusSPSDescriptionName


Common Data Classes

Analogue SettingASGInteger Status SettingINGSingle Point SettingSPGControllable Analogue Set Point Info.APCInteger Controlled Step Position Info.ISCBinary Controlled Step Position Info.BSCControllable Integer StatusINC

Curve Shape DescriptionCSDLogical Node Name PlateLPLDevice Name PlateDPLSetting CurveCURVE

Controllable Double PointDPCControllable Single PointSPCDescriptionName


Functional Constraints

� There are many data attributes in an object like a breaker that have related use

� Control, configuration, measurement, reporting, etc.

� Functional Constraints (FC) is a property of a data attribute that characterizes the specific use of the attribute.

� Useful to functionally organize the data attributes to provide structure and context.


Functional Constraints

Unicast Sampled Value (9-1)USUsed as wild card in ACSIXX

Setting Group EditableSESetting GroupSGDescriptionDCConfigurationCFSubstituted ValuesSVSet pointSPControlCO

Multicast Sampled Value (9-2)MSGSSE ControlGSGOOSE ControlGOLoggingLGUnbuffered ReportRPBuffered ReportBRExtended Definition (naming – read only)EX

Measurands (analog values)MXStatus InformationSTDescriptionFC Name


Logical Node Name Plate - LPL

From IEC61850-7-3


Device Name Plate - DPL

From IEC61850-7-3


Single Point Status (SPS)

AttributeName

per clause 8of IEC61850-7-3

Type Functional Constraint Range of

Values

Mandatory/Optional

From IEC61850-7-3

TriggerOptions


Double Point Status (DPS)

From IEC61850-7-3

2-bit pair in DPS versus boolean in SPS


Integer Status - INS

From IEC61850-7-3


Controllable Double Point

From IEC61850-7-3

Optional if control is supported

Mandatory if control is supported


Logical Node

A named grouping of data and associated services that is logically related to some

power system function.


IEC61850 Logical Node Groups

Power Plant (Set aside for other standards)NxxxBattery (Set aside for other standards)Bxxx

Sensors, Monitoring (4). SxxxProtection Related (10). RxxxProtection (28). PxxxMetering & Measurement (8). MxxxSystem Logical Nodes (2). LxxxInterfacing/Archiving (4). IxxxGeneric Functions (3). Gxxx

Fuel Cells (Set aside for other standards)Fxxx

Hydropower (Set aside for other standards)HxxxSolar (Set aside for other standards)OxxxWind (Set aside for other standards)WxxxOther Equipment (15). ZxxxPower Transformer (4). YxxxSwitchgear (2). XxxxInstrument Transformer (2). Txxx

Supervisory Control (5). CxxxAutomatic Control (4)AxxxDescriptionName


System Logical Nodes

Common Logical Node MANDATORYLLNO

Physical DeviceLPHD

DescriptionName


Automatic Control Logical Nodes

Voltage ControlAVCO

Automatic Tap Changer controllerATCC

Reactive Power ControlARCO

Neutral Current RegulatorANCR

DescriptionName


Supervisory Control Logical Nodes

Switch ControllerCSWI

Point-on-wave switchingCPOW

InterlockingCILO

Cooling Group ControlCCGR

Alarm HandlingCALH

DescriptionName


Generic Function Logical Nodes

Generic Security ApplicationGSAL

Generic Process I/OGGIO

Generic Automatic Process ControlGAPC

DescriptionName


Interfacing and Archiving Logical Nodes

Telemonitoring InterfaceITMI

Telecontrol InterfaceITCI

Human Machine InterfaceIHMI

ArchivingIARC

DescriptionName


Metering and Measurement Logical Nodes

Metering StatisticsMSTA

Sequence and ImbalanceMSQI

MeasurementsMMXU

Non phase related measurementsMMXN

MeteringMMTR

Non phase related harmonics or interharmonicsMHAN

Harmonics or interharmonicsMHAI

Differential measurementsMDIF

DescriptionName


Protection Logical Nodes

Instantaneous overcurrentPIOCGround detectorPHIZHarmonic restraintPHARRate of change of frequencyPFRCDirectional underpowerPDUPDirectional overpowerPDOPDistancePDIS

Phase angle measuringPPAMOver power factorPOPFMotor starting time supervisionPMSSMotor restart inhibitionPMRI

DirectionPDIRDifferentialPDIFDescriptionName


Protection Logical Nodes (cont’d)

Under currentPTUCThermal overloadPTTRProtection trip conditioningPTRCOver voltagePTOVOver frequencyPTOFTime over currentPTOCTransient earth faultPTEF

Zero speed or under speedPZSUVolts per HzPVPHVoltage controlled time over currentPVOCUnder voltagePTUV

Sensitive directional earth faultPSDEProtection schemePSCHDescriptionName


Protection Related Logical Nodes

Auto reclosingRREC

Power swing detection/blockingRPSB

Fault locatorRFLO

Directional elementRDIR

Breaker failureRBRF

Disturbance record handlingRDRS

Disturbance recorder channel binaryRBDR

Synchronism-check or synchronisingRSYN

Disturbance recorder channel analogueRADR

Disturbance recorder functionRDRE

DescriptionName


Sensors and Monitoring Logical Nodes

Monitoring and diag. for partial dischargesSPDC

Insulation medium supervision (liquid)SIML

Insulation medium supervisionSIMG

Monitoring and diagnostics for arcsSARC

DescriptionName


Instrument Transformer Logical Nodes

Voltage transformerTVTR

Current transformerTCTR

DescriptionName


Switchgear Logical Nodes

Circuit SwitchXSWI

Circuit BreakerXCBR

DescriptionName


Power Transformer Logical Nodes

Power transformerYPTR

Power shuntYPSH

Tap changerYLTC

Earth fault neutralizerYEFN

DescriptionName


Other Power System Equipment Logical Nodes

Power overhead lineZLINGas insulated lineZGILGeneratorZGENConverterZCONCapacitor BankZCAPPower cableZCABBushingZBSH

Thyristor controlled reactive componentZTCRThyristor controlled frequency converterZTCFSurge arrestorZSARRotating reactive componentZRRCReactorZREAMotorZMOT

BatteryZBATAuxiliary networkZAXNDescriptionName


Logical Node Names� Example for Breaker:

ddd XCBR01

Optional Application Specific Prefix

Logical Node Name perIEC 61850-7-4 (circuit breaker)

Logical Node Instance #

prefix digits + instance digits � 7


Logical Node Classes

InheritedRelationships

LN

LPHD Common LN

LLN0 Domain Specific LNs (i.e. XCBR)

An IEC 61850 device must contain LPHD, LLN0, and 1 or more domain specific logical nodes.


Common Logical Node Class

From IEC61850-7-4

ALL other logical nodes contain these attributes even though they are not listed in the other logical node description tables.



From IEC61850-7-4

NamPlt is mandatory and contains the nameplate for the individual logical node


Logical Node Name Plate - LPL

From IEC61850-7-3



From IEC61850-7-4

If the logical node is logically connected to some external equipment (e.g. breaker controller or server is a proxy, etc.) then EEName can contain the nameplate for that external device.


LLN0 Containment

ContainmentRelationship

InheritedRelationship

From IEC61850-7-2


Logical Node Description - XCBR

Data Object NamesCommon Data Class

Mandatory/Optional

Description

SPS

From IEC61850-7-4

From IEC61850-7-4

Loc


Single Point Status (SPS) CDC(e.g. loc)

stVal

From IEC61850-7-3

Data Attribute NamesData Type of Attribute


Object Name for Local/Remote Attribute of XCBR1

XCBR1.ST.Loc.stVal

Logical NodeFunctional Constraint

DataAttribute


Mapping of Names via 8-1

� Section 8-1 maps the IEC61850 LN and Data Object Names to MMS (ISO9506)

� MMS allows only numbers, letters, “$”, and “_” in object names.

� Resulting MMS Object Name:

XCBR1$ST$Loc$stVal


Alternate Object Name Sometimes Used

XCBR1.Loc.stVal[ST]

Logical Node

FunctionalConstraint

DataAttribute


Breaker Position

DPC

From IEC61850-7-4

From IEC61850-7-4

Pos


Breaker Position – DPC Class

stVal

From IEC61850-7-3


Object Name for Breaker Position Attribute of XCBR1

XCBR1.ST.Pos.stVal

Logical NodeFunctional Constraint

DataAttribute




Report Model


Reporting

� Unbuffered Reporting allows clients to receive data from the server without polling.

� If network connection (association) between client and server islost, data is lost.

� Buffered reporting enables the server to retain data if associations are lost enabling the client to retrieve ALL data.

� Reports are sent using the MMS InformationReport� Functionally equivalent to sending a Read response without the

client having issued a Read request.


Report-Log Model

From IEC61850-7-2


Report Control Block Attributes

General InterrogationGIPurge the report buffer (buffered only)PurgeBufStart reporting from a specific entry in the buffer (buffered only)EntryIDStart reporting from a specific entry time (buffered only)TimeOfEntry

Include buffer status in report (buffered only)buffer-overflowInclude the entry ID in the report (buffered only)entry-ID

Send report on integrity period expirationintegritySend report on change in qualityquality-changeSend report on data change exceeding deadbanddata-change

Integrity PeriodIntPd

The reason the report was sent (dchg, qchg, etc.)reason-for-inclusionInclude a report time stamp (even if DATA is time stamped)report-time-stampInclude the sequence numbersequence-number

Optional Fields to Include in the ReportOptFldsConfiguration Revision Number (can track Data Set changes)ConfRevName of the DATA-SET referenceDatSet= 1 In-use by client, =0 AvailableResv

Send report when requestedgeneral-interrogation

Trigger ConditionsTrgOpSequence NumberSqNumBuffer Time (the fastest that reports will be sent)BufTim

Include the current value of the ConfRev in the reportconf-revision

Include the names of the DATA elements in the reportdata-referenceInclude the DATA-SET name in the reportdata-set-name

= 1 Reports enabled, = 0 Reports disabledRptEnaName assigned to this RCBRptIDDescriptionAttribute Name


Buffered Reporting with GI Example

SqNum = 01, data change, <data>

time


SqNum = 03, integrity, <data>









IEC 61850Client

Client enables BRCB

report

report

report

report

report

reportCommunications Terminated

Communications Reestablished – Client Re-Enables the BRCB

Client request General-Interrogation

report

report

report

report

report

report

SqNum = 10, general-interrogation, <data>

SqNum = 10 flags when the GI was issued by the client to identify data that was reported while disconnected.




Controls


Control Model Objects

� Enables control of ACSI Objects:� Controllable Single Point (SPC)

� Controllable Double Point (DPC)

� Controllable Integer Status (INC)

� Binary Controlled Step Position (BSC)

� Integer Controlled Step Position (ISC)

� Controllable Analog Set Point (APC)


Control Model (ctlModel)

� 0: Status only. No control allowed.

� 1: Direct control with normal security (direct-operate)

� 2: SBO control with normal security (operate-once or operate-many)

� 3: Direct control with enhanced security (direct-operate)

� 4: SBO control with enhanced security (operate-once or operate-many)


Direct Control with Normal Security

From IEC61850-7-2


SBO Control with Enhanced Security

From IEC61850-7-2(modified)

Report_req(int)




IEC 61850 and CIM:

Overview and How They Fit


CIM versus IEC 61850: What they define

� Detailed Power System Topology

� Asset Model

� Consumer and load models

� Financial

� Scheduling and transactions

� Market operations

� Work management

� SCADA and Measurements

� GIS – Location

� Business Messaging (WG14)

� Interface Services (GID)

� Power System Topology Model

� Device Configuration Description

� Device Models

� Service Models� Reporting� Controls� Protection

� Performance/Requirements

� Object and Data Naming Conventions

� Protocols

CIM IEC 61850


CIM Asset-Power System Models & IEC 61850 Device Models

IEC61970/68 CIM IEC61850

Device Models

Measurements

Power System Models

Asset, trading,

etc.

Power System Models

WG19 Harmonization


CIM versus IEC 61850: What they define

� Detailed Power System Topology

� Asset Model

� Consumer and load models

� Financial

� Scheduling and transactions

� Market operations

� Work management

� SCADA and Measurements

� GIS – Location

� Business Messaging (WG14)

� Interface Services (GID)

� Power System Topology Model

� Device Configuration Description

� Device Models

� Service Models� Reporting� Controls� Protection

� Performance/Requirements

� Object and Data Naming Conventions

� Protocols

CIM IEC 61850


CIM Based Modeling Tool


IEC 61850 Based Modeling Tool (SCL)

Logical Node Designators


Two Different Purposes – Two Solutions are OK, BUT

� Detailed system wide description� Model exchange for high-level systems� Power flow, state estimation, etc.� Market operations� Planning and system design

� Substation design and modeling� Device configuration management� Protection and device control� SCADA, protection, & control data exchange


CIM and IEC 61850 Difference in Topology

IEC 61850-6-1 SCL Diagram

IEC 61970-301 EMS Diagram

Are these thesame objects?


Why the need for persistent IDs

� IEC 61850-6-1 Substation Configuration Language (SCL) files are used to define substation power system toplogy and IED functions and configuration.

� SCL files have internal referential integrity through the use of names.� When merged/imported into a unified model, names can be duplicated.� It is difficult to pick up changes if the name changes.

� CIM uses GUIDs

� GUIDs are the better solution� Common usage� Not ambiguous� Isolates identification of objects from names


Other Harmonization Issues

� IEC 61850 use of SI Units to be brought into CIM

� Adding topological elements to IEC 61850 and CIM to enable easier path back and forth� All IEC 61850 topology is within a substation

� References from CIM objects (like Protection Relay) to IEC 61850objects formalized� Enables unified model of settings, configuration, and SCADA tags

� Unification of control functions that work on power systems resources to IEC 61850 controls and services




Why do CIM and IEC 61850 Need to fit together better?


Simplified Planning Process

� Well defined processes and tools for designing new power system extensions, simulating their impact, defining new contingencies, etc.

New Subdivision & Shopping Mall

Studies on Existing Systems

Design New Systems

Studies on New Systems

Finalize New Design Submit Prints, specs


Moving Design to Operations

� Since the advent of the CIM the ability to move models from planning to operations (and vice-a-versa) in a multi-vendor environment has improved.� To be expected through use of standards.

� Eventually enable wide exchange of planning models like ENTSO-E and WECC.

� EMS and planning use a set of tools that have been harmonized toenable the flow of information between them.


Moving the Design to Substations

� Power system engineers use a completely different set of tools supporting a completely different set of standards to define the substation automation and protection systems.


It’s About Productivity

� The effort and knowledge put into the planning and operations models that isn’t embodied in the one-line diagrams is lost and has to be transferred manually into the substation design through the engineering process duplicating previous effort.

� If the tools used a common set of standards the flow of information can be automated enabling topology, SCADA, protection, communications, settings, etc. to be preserved and leveraged through the engineering process.


The Holy Grailof Harmonization

SCADA

Connectiv

ity

Asset

Communicatio

n

Properly designed intersectionfacilitates myriads of businessapplications.




CIM and IEC 61850 Harmonization

Summary of work performed for EPRI sponsored project that is feeding WG19


Integration of CIM – IEC 61850

� IEC TC57 WG19: “Interoperability Within TC 57”

� Integration of non-overlapping models into a single unified model

� Rules and procedures for transforming overlapping models when needed.� Convert from one model form to another to suit the application

� Transformations are not bi-directional� IEC 61850 SCL cannot be transformed into a complete CIM model

� Complete integration may require some mapping in special circumstances

� Most applications can use transformation.� Substation engineering and operations use different tools and have different

purposes.


Which Standard Provides What?

SCADAConnec

tivity

Asset

Communicatio

n

CIM

6185

0

Some areas don’t really overlap

CIM an

d 6185

0

CIM

and

6185

0

Some have overlap


DER


Process issue: Who has the correct information?

EMS

Substation

• EMS one-lines do not accuratelyreflect the actual constructionof a substation.

• Substation one-lines havetoo much detail for the EMS.

• Neither top-down or bottom-updesign methodologies work foran entire substation life-cycle.

• Harmonization of CIM and 61850decided to address this issuethrough lossless conversion of61850 Substation ConfigurationLanguage (SCL) to/from CIM.

Substation ConfigurationLanguage (SCL)

CIM


Aligning Topology/Connectivity

�Requires agreements on semantics of objects� Is a battery a consumer vs. asynchronous machine?

� What is conducting, regulating, or just power equipment?

�CIM and 61850 already had similar constructs to electrically connect equipment.

�Equipment containership needed to be enhanced in 61850 to allow lines and plants to be containers.

�Need to agree that a WindFarm is a type of Plant.


The SCADA opportunity

� Decrease life cycle costs through the possibility of auto-configuration.

�Requires:� Communication Address information to be persisted and available to

the EMS (comes from 61850).� Agreement about types of “control”

� Direct, SBO, etc..� Defined and enumerated in 61850� Ability to freeze/control accumulator values

� Linkage from 61850 object models to CIM Measurement model.


True SCADA requires communication addressing

�Communication addressing found in IEC 61850

�Proposed to add this to the harmonized model in such a way that the CIM SCADA package could use it.

�Extended to support addressing for DNP, IEC 60870-5, ICCP, as well as IEC 61850.


Measurement Model

�Proposed adding a “vector” MeasurementValue object so that magnitude and angle measurements are easily conveyed (needed forsynchrophasors).

�Allowing a MeasurementValueSource to be a IED or Remote Unit (includes RTUs). This allows the auto-configuration of SCADA.


Reconciling Units of Measure (UOM)

� CIM based upon electrical quantities only.

� IEC 61850 uses full SI units to support:� Electrical

� Hydro

� Wind

� DER

� Weather

� Etc..

�Proposed that CIM be aligned to support full SI units.


Ongoing efforts and results:

�Presented to the coordination working group (WG19) of TC57 and it seems that we have achieved consensus on the approach.� Resolving semantics were the key to concensus:

� harmonization vs. unification

� IEC TC57 WG10 (owners of 61850) have endorsed the approach.

�Major players in IEC TC57 WG13 have endorsed the approach, hopefully full endorsement will be forthcoming from the upcoming meeting.

�Has been accepted as by PAP-8 and PAP-12 of the NIST Smart Grid initiative. It is becoming the foundation for semantic harmonization within the initiative.


Why is it important to Smart Grid

�Need for harmonization was identified early on in Roadmap:

“Develop a Common Semantic Model – …. The objective will be to unify the models of CIM (IEC61970, IEC61968) and IEC 61850 including correspondences with ANSI C12.19 and ASHRAE 135 to form a common representation of information models constructed by these standards efforts for the Smart Grid. “ [from Report to NIST on the Smart Grid Interoperability Standards Roadmap; page 91 of June 17, 2009 ]


One last important Smart Grid objective:

�“Extend IEC 61968 standard for DER: IEC 61968 needs DER models, but should be harmonized with the existing DER object models in IEC 61850-7-420,…” “[from Report to NIST on the Smart Grid Interoperability Standards Roadmap; page 143 of June 17, 2009 ]




Validation of concept through implementation

Jay MashburnPrinciple Consultant for Wind Power

Common Information Model in Smart Grid, Distribution, Transmission Workshop

September 9, 2010


Validation of concept

SISCO, OSIsoft and IBM to use concept for a IBM Wind Power solution.

Problem Case� IBM created the Wind Power suite to help wind farm operators that have several disparate systems that

provide a limited view of the field operations information. � There is typically no integrated set of applications that ties all of the various systems together to

allow them to optimize and focus on running and maintaining the assets.

� Incomplete information about the rapidly growing number of different kinds of turbines is hampering the operator’s ability to make effective decisions concerning the cost of operations.

� Expensive Turbine Downtime. During a wind turbine’s expected 20-year service life, maintenance problems are not a question of "if," but "when." When maintenance problems ultimately occur, farms face the downside of exorbitant crane mobilization costs, lost energy production, escalating costs per kilowatt-hour and limited supplies of spare parts due to intense industry demand for components.


Industry standards needed for the Wind SolutionSmarter power for a smarter planet

Challenge:� Wind Farm operator has many different SCADA systems over the fleet of WTGs, from the various manufacturers to the different generations of WTGs within one manufacturer.

Solution:� Transform into IEC 61400-25 standards to allow harmonizing into one normalized data set.

Result:� Able to roll up views of the wind farms and compare different wind farms across the fleet.ster )


Wind Company Farm example for demo purposes

Small Benbrook Wind farm

Control Room, Maintenance Shop, Substation, and StoreroomNorth Area – 10 GE 1.5 MW Turbines – owned and maintained by Wind Company

South Area – 15 Vestas 1.8 MW Turbines – maintained by Wind Company

5 – Owned by True Wind Company

5 – Owned by Real Wind Company

5 – Owned by Windy Company

Wind

Company

Smarter power for a smarter planet


Could have done what has been done before:

Performing Custom Integration


Standards Success Requires Broad VisionSmarter power for a smarter planet

� Partners

� Competitors

� Complementary

� Early Code (POC)

� Early Customer Engagements

� Public Relations

� ISVs, Adjacent Standards

� Intellectual Property� Competitive Initiatives

� Standards Bodies

IBM’s invests widely to develop and influence standards, enhance consumablity and drive standards-based business strategies.

� Industry Groups

� Products


But what standards to use: CIM and 61850 align with Smart Grid initiatives



Using the Harmonized Model, allowed creation of:

Monitoring Farm /Turbine Operations

Investigation of alarmmanagement and detail drill

down

Work Order Request is created, Dispatch of PM work to do while tech is at the

turbine

Operations verifies turbine restored to normal Operation

2 3

Safety Permits signed on and

work ordercompletions

45

6

1

Work Order completion triggers Bill creation for work performed



IBMIBM’’s Wind Power Suite Solutions Wind Power Suite SolutionSmarter power for a smarter planet

AssetManagement Real-time &

Historical Database

Cockpit /Dashboard

Analytic Tools /Reports

Enterprise Service Busincl. Complex Event Processing, Mapping, Mediation, …

Various

SCADA

Management

Systems

Analyticsand

ReportingReal time

Weather Forecast

Optimizationand

Forcasting

WorkManagement

WorkforceMobility

InventoryPurchasing

Deep Thunder

Geospacial


IBM Wind Power SolutionIBM Wind Power SolutionSmarter power for a smarter planet

AssetManagement Real-time &

Historical Database

Cockpit /Dashboard

Analytic Tools /Reports

Enterprise Service Busincl. Complex Event Processing, Mapping, Mediation, …

Various

SCADA

Management

Systems

AnalyticsandReporting

Real time

Weather Forecast

OptimizationandForcasting

WorkManagement

WorkforceMobility

InventoryPurchasing

Deep Thunder

Geospacial

IEC 61400-25-2/61850

- Uses harmonized model

- CIM

- CIM, 61850, and extensions

- CIM messaging and interfaces




Persistent IDs

Changes to SCL


Why the need for persistent IDs

� SCL files have internal referential integrity through the use of names.

� When merged/imported into a unified model, names “will be”duplicated.

� Use of names also means that it is different to pick up changes.


Introduced RDFID and RDFIDREF to SCL

� RDFID is the equivalent to rdf:id in CIM XML

� RDFIDREF is used in the same manner as rdf:resource


Two types of IDs

Tool Assigned Standard Defined

Used to define specific instances that shouldbe the same regardless of model/SCL.

Examples in the unified model are:LNClassCDC types


RDFID Introduction of SCL was made possible via:

The optional attributes added. Eventually would need to be mandatory.


Referencing other instances

Added

Referenced via name

Did not have to create alnTypeRef since SCL fileshave referential integrity. Thefact that LNodeType has anRDFID means that the interfacecan use the appropriate IDswithin the unified model.




Substation Harmonization


Substation Topology Issues

� Selection of objects of interest� Based upon Profiles (CPSM, Planning, Dynamics)

� CDPSM and Metering was also looked at

� Based upon selection of CIM objects, tried to align with IEC 61850 substation objects via definitions.� Problems with definitions

� Made appropriate changes to UML to add missing classes � 2 items (CT/PTs) changed from Equipment to ConductingEquipment

� Additional objects/enumerations created in SCL

� Containership alignment


Definition Issues regarding Substation Topology

� IEC 61850 does not contain the definitions for any of the equipment/PSRs.

� There are multiple “authoritative” sources for definitions:� IEC 61970/61968

� IEC Glossary

� IEEE Dictionary

� Some CIM definitions are too restrictive.

� Some CIM defintions are not found in the IEC Glossary or IEEE Dictionary (this is an issue for WG19)

� Some IEEE terms may be more general and more widely accepted.


Close definitions, but which is better (Substation)?

� IEC: A part of an electrical system, confined to a given area, mainly including ends of transmission or distribution lines, electrical switchgear and controlgear, buildings and transformers. A substation generally includes safety or control devices (for example protection).

NOTE – The substation can be qualified according to the designation of the system of which it forms a part. Examples: transmission, substation (transmission system), distribution substation, 400 kV or 20 kV substation.

� CIM: A collection of equipment for purposes other than generation or utilization, through which electric energy in bulk is passed for the purposes of switching or modifying its characteristics.

� IEEE: An assemblage of equipment for purposes other than generation or utilization, through which electric energy in bulk is passed for the purpose of switching or modifying its characteristics (definition excerpted from ANSI/IEEE 100-1988).


Example of Restrictive Definition: Line

� CIM Line: A component part of a system extending between adjacent substations or from a substation to an adjacent interconnection point.

This definition prohibits it use within Distribution.

� IEC Line: A device connecting two points for the purpose of conveying electromagnetic energy between them.

Which should be used?

Double Click on Document


Additional Topological Elements added

- Added

Dynamics Package still working on fixing model


Example of Definitions leading to restrictive use:

CIM definition implies that all such machines are Rotating. Theresult is the following….


SynchronousMachines and Dynamics

Dynamics has made all Synchronousand Asynchronous machines Rotating.

DER (e.g. IEC 61850-7-420) hasseveral DER types that are not rotating (e.g. PV, Fuel Cell, …).

Should these be modeled asGenSync?


Added new SCL Items

� To tPredefinedCommonConductingEquipmentEnum, the following enumeration values are proposed to be added:� BBS – BusBarSection

CND – ConductorCON – ConnectorEnergyConsumerRINV – RectifierInverterSCMP – Series Compensator

� To tPredefinedGeneralEquipmentEnum, the following enumeration values are proposed to be added:� GEN – GeneratingUnit

PROT – Protection Equipment


Alignment looks like: Double click on Doc


Equipment Containership Differences

CIM 61850 SCL ED.2


Recommendation to align with IEC 61970+

Also Added:

Line and CircuitSection*as EquipmentContainers

Eventually will need toaddress Plants




Units


Overview

� Current IEC 61970 Unit class is empty of attributes.

� There are the following enumerations:� UnitSymbol

� UnitMultiplier


Unit Symbol

61850, and derivatives, need additional units to supportDER, Hydro, and other.

Recommended to change Unit Symbol to SIUnit and matchIEC 61850 enumerations. May need to add a couple of non-SIunits.

It is unclear if UnitSymbolspecifies units or the visual unit symbol(semantic issue).

IEC 61850 units

(based on ISO 1000)


Unit Multiplier (not full ISO 1000)

Recommended that the “” for none, in SCL, be replaced with “none”


Design Template Issues

Vs

Class Instances Property Values

Recommended to go with instances/association.




Data Hierarchy


Needed to maintain Measurements/MeasurementValues unchanged

The difference


The proposed solution

Can be extended to handled other collections as well (e.g. DataSets,…)

Use to store SCL definition.


More…

Needed to define Standardized GUIDs/IDs for the Standardized Objects…




SCADA and Control


SCADA

Current

Proposed


Communication Link was specialized


Control

Current Proposed




Design Pattern Issues


Design Pattern issues

� Definitions

Need to make use of more general definitions and provide exampledocumentation within the model.

� Not using profiles to their full extent(will give 2 examples)

� Need better communication (take the dynamics issue as an example)


Profiles not used to their full capability

� 2 examples

State Values

Readings


State Values

Could specializations of Measurements +profiling accomplished the same as opposedto introducing a new model?


Reading

Current Model

Proposed Model

Project will not have time to address the issue of a harmonized quality…

Is ReadingQuality required or should the model only have one quality?


Inconsistencies even within IEC “61850” Standards

Should just be an ENUM. CODED ENUMs should be restricted to IEC 61850-7-2/3 or only be used formutually exclusive values.

How do we get this and other issues harmonized/corrected? This is a coordination issue between TC57 and TC88!




How Do You Make This Work In Your Enterprise?

Business Justification


The Justification Dilemma

COSTSBENEFITS



Engineer’s View of Justification

COSTS

BENEFITS



Accountant’s View of Justification

COSTS

BENEFITS


The Tragedy of Integration and Automation

There are no benefitswithout some cost


About Benefits & Justification� Identify all the benefits (obvious).

� ALSO Identify ALL the costs:� Equipment� Installation� Engineering� Commissioning� Utilization Costs� Impact on External Systems� Costs to Change/Migrate in Future� Intangibles (new capability)

� Requires a complete view of cost.

� Requires a longer time frame.


The benefit of using technology is not in the purchase.

The benefit is in using technology to improve operations AFTER the

purchase.


Cost Justification – Small Use Cases?

SCADAOutageManagement

A “one-off” point to point link will always be cheaper if the cost to integrate future

applications is ignored.


Control Center Databases

Documents, E-mail, Generic

Files Gateways to Customer

Sites

Control Center Systems and ApplicationsSubstation Data

Concentrators and Masters

IntraNet and Internet Access

Energy Market and

eCommerce Applications

Multitude of Legacy

Applications and Systems

IT Networking and Computer

Systems

The Result of Justification One App at at Time

RTUs, IEDs, and Other

Field Devices


“Verbs” include: request, send, query, authenticate, publish, subscribe …

Common Services/Protocols

Information Object Models

“Nouns” includes: power system data, application data, network management

data, security data …

Control Center Databases

Documents, E-mail, Generic Files

RTUs, IEDs, and Other Field

Devices

Gateways to Customer Sites

Control Center Systems and Applications

Substation Data Concentrators and

Masters

IntraNet and Internet Access

Energy Market and eCommerce

Applications

Multitude of Legacy Applications and

Systems

IT Networking and Computer Systems

Model Driven Integration Addresses Cost, Efficiency, and Complexity for the LONG RUN

IntelliGrid Architecture http://www.intelligrid.info


Model-Driven Cost JustificationC

ost

TimePurchase

Payback

BENEFITTraditional

Approaches

ModelDriven

Approaches


“Obstacles are those frightful things that appear when you take your eyes off your objective.”

- Henry Ford

� Ralph’s Corollaries:� If you don’t set out on the path, you will never make any progress.

� The first on the path will reap the most reward.

There is no reason that the energy industry can’t take advantage of standardized interface services and models to lower integration costs.




Thank You

Ralph MackiewiczSISCO, Inc.6605 19½ Mile RoadSterling Heights, MI 48314-1408 USATel: +1-586-254-0020 x103Fax: +1-586-254-0053Email: [email protected]