ankush sharmaiitk.ac.in/smartcity/qip/download/ppt/day-5/smart_grid... · 2019-05-15 · circuit...

Ankush SharmaAssistant Professor

Dept. of EE, IIT KanpurE-mail: [email protected]

IEC CIM

MultiSpeak

Green Button

SEP 2.0

SunSpec

Common Information Model (IEC 61970, IEC 61968 & IEC 62325)

Common Information Model

Abstract, generalized, platform and context‐independent representation

Used to establish common semantics among stakeholders

Helps in standardization of information exchange

Domain Model represents a vocabulary of basic terms

Represented using Unified Modeling Language (UML)

Easy for humans to understand

* Ref: J.P. Britton and A.N. deVos, “CIM-based standards and CIM evolution,” IEEE Trans. Power Syst., vol. 20, no. 2, pp.758-764, May 2005

Common Information Model Information exchange among computers using XML documents Profiles specify subset of CIM classes & attributes for specific business context Implementation technologies, such as XML to create serialized files & messages

Standards for power system models Standards for information message payloads

CIM UML can be extended Standard extensions for new functional areas Private extensions for specific utility requirements

Data encapsulated inside CIM XML tags. CIM XML tags standardize the way data to be exchanged. Sample CIM XML File ‐

CIM XML Creation

Steps to create CIM XML – Identify CIM classes and attributes Generate CIM Profile Develop CIM XML schema Agreeing upon the XML schema by all the

stakeholders Develop plug‐ins for creating and parsing

CIM XML file

Core: : Identif iedObject

+ mRID :String [0..1]

StateVariables: :CoVariance

+ cov Angle :Float+ cov Voltage :Float

Topology: :TopologicalNode

StateVariables: : SvVoltage

+ angle :AngleRadians [0..1]+ v :Voltage [0..1]

StateVariables: :S tateVariable

{root}

0..1

1

0..11

App CIMY.1 X.1Y.2 X.2Y.3 X.3Y.4 X.4Y.5 X.5

Publisher

Publishers:One Application Connector:Obtains Data From Application And/Or DatabaseTransforms Data (if necessary) to the “CommonLanguage” (a Canonical Data Model)Puts Data Into Message TemplatePublishes The Message (Fires & Forgets)

DataWarehouse

SubstationAutomation

OMS

DistWiresModel

GridWiresModel

DAC

CIS

VRU

GIS

DistributionAutomation

HumanResources

OutageReporting

Event History WorkManagement

EMS

...

CIMX.1 X.2 X.3 X.4 X.5

Subscriber

CIM AppX.1 B.1X.2 B.2X.3 X.4 X.5

Subscriber

CIM AppX.1 A.1X.2 X.3 X.4 A.4X.5 A.5

Subscriber

CIM AppX.1 C.1X.2 X.3 C.3X.4 C.4X.5

Subscriber

Subscribers:Several Application Adapters Receive The Same MessageEach Adapter:Parses Message, Pulling Out Data Needed By ApplicationTransforms Data (if necessary) to Local Application FormatPasses Data To Local Application And/Or Database Through Most Appropriate Means

Decoupled InformationExchange

CIM UML

Information and Semantic Models

Context

Message Syntax

Profile

MessageXML Schema

Contextual layer restricts information modelConstrain or modify data typesCardinality (may make mandatory)Cannot add to information model

Message syntax describes format for instance dataCan re-label elementsChange associations to define single structure for

message payloadsMappings to various technologies can be defined

Information ModelGeneralized model of all utility objects and their

relationshipsApplication independent

Message Syntax

CIM UML


Context

Profile

MessageXML Schema

CIM/XMLRDF Schema

RelationalDatabase

CIM ModelRules

CIM/XMLRules

ProjectRules

Message Assembly

class M ain

EnergySchedulingFinancialM arketOperations

CombinedVersion{root}

+ date: AbsoluteDateTime [0..1] = 2008-12-17-see-... {readOnly }+ v ersion: String [0..1] = iec61970CIM13v 1... {readOnly }

Reservation

IEC61970

IEC61968

WG13

WG14

WG16

class M ain

Equivalents

Protection

SCADA

Generation

OutageLoadM odel

TopologyM eas

Wires

«Global»Domain

Core

OperationalLimits

ControlArea

GenerationDynamics

(from Generat ion)

Production

(from Generat ion)

«WorkInProgress»StateVariables

«WorkInProgress»Contingency

CIM UML


Context

Message Syntax

Power SystemModel Profile

Group

CIM/RDFSchema

Information ModelDefines all concepts needed for exchange of

operational load flow models– Reused parts– New extensions

Contextual layer restricts information modelSpecifies which part of CIM is used for

static/dynamic model exchangeMandatory and optionalRestrictionsBut cannot add to information model

File syntaxCan re-label elementsChange associations to define single structure

for message payloadsMappings to various technologies can be

defined

Conforms to IEC 61970-301 CIM

Conforms to IEC 61970-452, 453,

456, othersModel Exchange

Profile

Conforms to IEC 61970-501 and -552

CIM XML Model Exchange Format

IEC 61970‐4xx series of Component Interface Standards (CIS) Specifies the functional requirements for interfaces that a

component (or application) implements to exchange information with other components (or applications) and/or to access publicly available data in a standard way

Component interfaces describe the specific message contents and services that can be used by applications for this purpose

Implementation of these messages in a particular technology is described in Part 5 of the standard

Equipment Model

Common Objects

Topology

State Variables

Schedules

Schematic Layouts

Measurement Set

Measurement Specifications

Boundary Objects

DynamicModels

IEC 61970-452 specifies the specific profile (or subset) of the CIM for exchange of static power system data between utilities, security coordinators and other entities participating in a interconnected power system

All parties have access to the modeling of their neighbor’s systems that is necessary to execute state estimation or power flow applications

A companion standard, IEC 61970-552, defines the CIM XML Model Exchange Format based on the Resource Description Framework (RDF) Schema specification language which can be used to transfer power system model data for a particular profile

pkg M ain

AssetsPointOriented

Customers

Common

Operations

Work

Assets

M etering PaymentM etering

Domain2Locations

TypeAssetAssetM odelsAssetsLinear

Planning

LoadControl

Parts 3, 4 (and 5?)

Part 4

Parts (5 and 7)?

Part 6

Part 8

Part 9

IEC 61968 Compliant Middleware Services

(NE)Network

ExtensionPlanning

(CS)CustomerSupport

(MR)Meter

Reading &Control

(AM)Records &

AssetManagement

(MC)Maintenance

&Construction

InterfaceStandard: Part 4





(ACT)CustomerAccount

Management

(FIN)Financial

(PRM)Premises

(HR)Human

Resources

(EMS)Energy

Management &Energy Trading

(RET)Retail


(SC)Supply

Chain andLogistics

(NO)Network

Operation


(OP)OperationalPlanning &

Optimization








Electric Distribution NetworkPlanning, Constructing,

Maintaining, and Operating

Generation and Transmission Management,Enterprise Resource Planning, Supply Chain, and

General Corporate Services

Business FunctionsExternal To Distribution

Management

Distribution ManagementBusiness Functions

Provides Framework For Identifying Information Exchange Requirements Among Utility Business Functions

15 May 2019 |

A power transformer is not mapped to a single CIM class Represented by a number of components with a single PowerTransformer container class

Two‐winding power transformer becomes two TransformerWinding objects within a PowerTransformercontainer

If a tap changer is present to control one of the windings An instance of the TapChanger class is associated with that particular winding

Also contained within the PowerTransformer instance

Inherits from Equipment, since does not conduct

electricity

Physically connected to network and conducts

electricity, so inherits from ConductingEquipment

Part of TransformerWinding, not separate piece of

equipment

Shell of transformer, containing windings,

insulation, magnetic core, etc.

Example to show how voltage levels, current transformers, power transformers and generators are modelled

Circuit contains a single generating source, load, line, and busbar. The circuit also contains two power transformers resulting in three voltage levels of 17kV, 33kV and 132kV

Ref: Book – Common Information Model, Mathias Uslar (Springer)

Smart Grid HandbookDoc: McMorran, “An Introduction to IEC 61970‐301 & 61968‐11: The Common Information Model”,

University of Strathclyde, Glasgow, UK

EnergyConsumer

Breaker

SynchronousMachine

GeneratingUnit

Breaker

BusbarSection

Breaker

ACLineSegment

Current measurement represented by

Measurement connected to Terminal

29

Maps to 17 CIM classes 45 CIM objects

Could be extended further with addition of objects for control areas equipment owners measurement units generation and load curves

asset data

EMS Native Interface attributes: TRANS_NAME – The Transformer’s name WINDINGA_R – The Transformer’s primary winding resistance WINDINGA_X – The Transformer’s primary winding reactance WINDINGB_R – The Transformer’s secondary winding resistance WINDINGB_X – The Transformer’s secondary winding reactance WINDINGA_V – The Transformer’s primary winding voltage WINDINGB_V – The Transformer’s secondary winding voltage

Two different interface attributes (WINDINGA_R and

WINDINGB_R) map to same CIM attribute

Aggregation changed from 0..n to 2

Multiplicity changed from

0..1 to 1

Multiplicity changed from

0..1 to 1

Note:• Associations changed to aggregations• Parent classes removed

• Not required in actual message content• Parent classes already known by both sender and receiver

• Corollary: Only those parts of the CIM used in message exchange which need to be supported by interface applications

• End result – modified class structure• Example of application of business context to information model

<cim:PowerTransformer> <cim:Naming.name>Transformer SGT1</cim:Naming.name> <cim:PowerTransformer.Contains_TransformerWindings> <cim:TransformerWinding.r>0.23</cim:TransformerWinding.r> <cim:TransformerWinding.x>0.78</cim:TransformerWinding.x> <cim:TransformerWinding.windingType>WindingType.primary </cim:TransformerWinding.windingType> <cim:Equipment.MemberOf_EquipmentContainer> <cim:VoltageLevel.BaseVoltage> <cim:BaseVoltage.nominaVoltage>400 </cim:BaseVoltage.nominalVoltage> </cim:VoltageLevel.BaseVoltage> </cim:Equipment.MemberOf_EquipmenContainer> </cim:PowerTransformer.Contains_TransformerWindings> <cim:PowerTransformer.Contains_TransformerWindings> <cim:TransformerWinding.r>0.46</cim:TransformerWinding.r> <cim:TransformerWinding.x>0.87</cim:TransformerWinding.x> <cim:TransformerWinding.windingType>WindingType.secondary </cim:TransformerWinding.windingType> <cim:Equipment.MemberOf_EquipmentContainer> <cim:VoltageLevel.BaseVoltage> <cim:BaseVoltage.nominaVoltage>275 </cim:BaseVoltage.nominalVoltage> </cim:VoltageLevel.BaseVoltage> </cim:Equipment.MemberOf_EquipmenContainer> </cim:PowerTransformer.Contains_TransformerWindings>

</cim:PowerTransformer>

XML Schema Used for generation of message payloads for system interfaces in

system integration use cases RDF Schema Resource Description Framework (RDF) is given by W3C. Used for exchange of power system models Resolves issues related to XML Schema – To provide the meaning

for the XML documents

RDF Schema is a means of expressing simple statements about the relationship between resources

RDF Schema mechanism is a set of RDF resources (including properties) and constraints on their relationships

Defines application‐specific RDF vocabularies

RDF Schema URI unambiguously identifies a single version of a schema

provides means of showing relations between elements beyond parent‐child relation

The schema contains additional elements that go beyond the simple ID and resource attribute

UML. RDF Relational Model

Object Resource Tuple (i.e. row)Attribute or association

Property Attribute (i.e. column) or foreign key

Class Class Relation (i.e. table)

Resource Description

Tuple value

URI Key value Value Field value

[Courtesy Of Leila Schneburger]

Siemens 100 bus model - RDF schema

<?xml version="1.0" encoding="UTF-8"?><rdf:RDF xml:base="siemens" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cim="http://iec.ch/TC57/2001/CIM-schema-cim10#">

<cim:ACLineSegment rdf:ID="_6B1DD5C2CB934E86AC53FFD886E2D1B3"><cim:Naming.name>BBD-RSK2</cim:Naming.name><cim:Conductor.bch>2.79</cim:Conductor.bch><cim:Conductor.x>4.3378</cim:Conductor.x><cim:Conductor.r>0.4761</cim:Conductor.r>

</cim:ACLineSegment>

<cim:Terminal rdf:ID="_EB6085D9DF364DA78A884D4D0A571371"><cim:Naming.name>T2</cim:Naming.name><cim:Terminal.ConnectivityNode rdf:resource="#_CC312D30C85C4236948A4129AEE3B5F7"/><cim:Terminal.ConductingEquipment rdf:resource="#_6B1DD5C2CB934E86AC53FFD886E2D1B3"/>

</cim:Terminal>

<cim:Terminal rdf:ID="_7C8354E0DA247DBB3611E2E8BF8A86D"><cim:Naming.name>T1</cim:Naming.name><cim:Terminal.ConnectivityNode rdf:resource="#_D16FD63501444AECBF8157D1E4764E38"/><cim:Terminal.ConductingEquipment rdf:resource="#_6B1DD5C2CB934E86AC53FFD886E2D1B3"/>

</cim:Terminal>

Many EMS vendors support power system model exchange using CIM/RDF/XML, some with CIM‐based databases behind the scenes

Utilities have used the CIM as the basis for developing common messages for integration

Asset and work management vendors as well as GIS application vendors are supporting CIM/XSD standards

AMI (Smart Meter) projects use IEC 61968 Part 9 for meter related information exchange

CIM has been extended into the power market, planning, and dynamic model exchange

CIM provides a foundation for Service‐Oriented Architecture (SOA) and Web service implementations

Developed by National Rural Electric Cooperative Association (NRECA) in collaboration with key industry vendors

Covers applications of interest to distribution utilities Standard is mature, but scope is continuing to grow In use at hundreds of utilities Mature interoperability testing program Applies to all interfaces Implemented using XML; web services and batch transport profiles

defined More information and specification available at ‐

www.MultiSpeak.org

Where CIM covers transmission, generation and distribution, MultiSpeak is distribution focused

Best point of comparison is between IEC 61968 and MultiSpeak, where the common focus is information exchanges related to distribution systems

MultiSpeak is focused to meet needs of electric cooperatives in the US, while IEC 61968 is focused towards all utilities and the international marketplace

IEC 61968 is transport independent while MultiSpeak is transport specific and uses SOAP (Simple Object Access Protocol, an XML‐based messaging protocol), sockets, and files

Both focus on interfaces between applications, as opposed to data structures internal to applications

Supporting models which define classes, simple types and complex types

Use of XML Schema for definition of messages Messages have a control area and a payload Use of nouns and verbs for definition of messages (although actual

nouns and verbs are different between the two)

Separate standards continue to be a stumbling block for utility implementations

Utilities want to implement the best of both standards Vendors want to avoid the need to develop and maintain dual

interfaces Implementations in process trying to bridge the standards and look

for best of both worlds. At some utilities both CIM‐compatible and MultiSpeak compatible

products will need to co‐exist and interoperate MultiSpeak V4.0 and future releases will move towards IEC CIM

wherever appropriate. V4.0 is internationalized and supports an IEC CIM compatible power

system model. IEC and MultiSpeak jointly will develop international standards

leading to harmonized profiles.

Common‐sense idea that electricity customers should be able to download their energy usage information in consumer‐ and computer‐friendly format

Helps and empower Consumers and Spur Innovation Entrepreneur‐created web portals analyse energy usage and provide

actionable tips A single third party interface encourages value added services that

don’t depend on continuous utility innovation on this interface Adoption of demand side management schemes will require

consumer feedback and engagement to enable them to benefit A single interface developed by implementers allows robust

applications to be developed

Usage Profile

Overall Usage

Cost of Usage

Hourly load profile for past billing period plus current period to date Fifteen minute load profile for most recent 15 days Daily load profile for past month or year Summary only data Energy usage and energy demand readings Gas, Water usage profiles Yearly summary data with monthly parts

UsagePoint ServiceCategory

MeterReading IntervalBlock

IntervalReading

ReadingQuality

ReadingTypeElectricPowerSummary

ElectricPowerQualitySummary

EUI comes from and to residences and businesses

Single Data Format: all at once

Single Data Format: as sequence

Sources of EUI Uses of EUI

Via

: ESP

I, SE

P2, W

eb P

orta

l

Power Utility

Energy Services Provider Interface (ESPI) standard is to create a standardized process and interface for the exchange of a retail customer’s energy usage information between their designated data custodians

“colored text”

“grid view”

“graphic view” <xs:complexType name="IntervalBlock"> <xs:annotation> <xs:documentation>Time sequence of Readings of the same ReadingType.</xs:documentation> </xs:annotation> <xs:complexContent> <xs:extension base="IdentifiedObject"> <xs:sequence> <xs:element name="interval" type="DateTimeInterval" minOccurs="0"> <xs:annotation> <xs:documentation>Specifies the time period during which the contained readings were taken.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IntervalReading" type="IntervalReading" minOccurs="0" maxOccurs="unbounde </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

IntervalBlock

MeterReading

UsagePoint

ReadingType

IntervalBlock

ElectricPowerUsageSummary

IntervalBlock has an Interval time definition

The IntervalReadings have values, cost, and reading

quality, as well as optional time period

Note: most parts of schema can be

extended

The integration of consumer devices into the smart grid An addition to existing consumer HANs Serves two general purposes: Inform the consumer (e.g., energy usage, pricing) Request actions to assist the grid (e.g., thermostat changes, PV

inverter controls, plug‐in electrical vehicle charging) Focus on communications related to efficiency, usage, price, demand

response and load control, and service provider messages An IoT “profile” Supports range of backhaul technologies Optimized for embedded and battery‐powered devices

A widely deployed standard for the Smart Grid HAN Provides most of the needing application information (more on that

in a moment) IP enabled architecture using Zigbee stack Communication – In‐home only Via smart meter Via Internet Combinations of the above

Any device can be a server and/or client for a function set – servers provide the data, clients use the data

Can have multiple servers for a function set

Price Communication Demand Response and Load Control Energy Usage Information (e.g., meter data) Distributed Energy Resources (Generation & Storage) Service Provider Messaging Prepayment Metering Electric Vehicle Billing Communication Communications between utility and DER aggregator, as well as utility

and individual smart inverters File Download / Update

IEEE 2030.5 named as “default protocol” for smart inverter communications

Interoperability Specifications describe information models, data exchange formats and communication protocols used in distributed energy resource systems

Communication between data loggers of a solar plant with inverters, meter etc. happens using RS‐232/RS‐485 protocol with SunSpec as information model

SunSpec information model is defined using SunSpec model definition XML (SMDX)

Supported device categories include: Inverters Meters Panels Environmental Sensors String Combiners Trackers Energy Storage Charge Controllers

SunSpec models are communication protocol agnostic

Each SunSpec compliant device definition includes at least three SunSpec Information Models: The SunSpec Common Model (i.e. SunSpec model 1) ‐ Provides

identification information (e.g. manufacturer, model, serial no.) associated with physical device

Standard Model – specify common data points implemented by the device of a given category

Vendor Models – specify data points that only apply to vendor implementation

An End Model that marks the end of the SunSpec device definition

ankush sharmaiitk.ac.in/smartcity/qip/download/ppt/day-5/smart_grid... · 2019-05-15 · circuit...

Documents