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
Information and Semantic Models
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
Information and Semantic Models
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
InterfaceStandard: Part 6
InterfaceStandard: Part 7
InterfaceStandard: Part 8
InterfaceStandard: Part 9
(ACT)CustomerAccount
Management
(FIN)Financial
(PRM)Premises
(HR)Human
Resources
(EMS)Energy
Management &Energy Trading
(RET)Retail
InterfaceStandard: Part 10
(SC)Supply
Chain andLogistics
(NO)Network
Operation
InterfaceStandard: Part 3
(OP)OperationalPlanning &
Optimization
InterfaceStandard: Part 5
InterfaceStandard: Part 10
InterfaceStandard: Part 10
InterfaceStandard: Part 10
InterfaceStandard: Part 10
InterfaceStandard: Part 10
InterfaceStandard: Part 10
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 | Page 21
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