Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
CIM as a Frameworkfor Smart Grid Interoperability
Part 1
CIM Users GroupColumbus, Ohio, USATerry Saxton
2
Presentation Contents for Morning Session
Part 1• What is the CIM?• Role of CIM in achieving
interoperability in the Smart Grid• Key architectural concepts – three
layer architecture/framework• Design time modeling approach • Work flow from semantic model to
message/file assembly using CIM• Layer 1 - CIM UML information
model and contents– Who Manages the CIM UML Model?
- TC 57 Organization and Formal Liaisons
– Example: Substation model using CIM– Demo of UML modelling Tool – Sparx
EA
Break
Part 2• Layer 2 - Profiles for defining system
interfaces– IEC 61970 network model exchange and
how models are used in network analysis– IEC 61968 message payloads for system
integration
• Layer 3 - Implementation syntax of instance data
– CIM expressed in XML and RDF Schema
• Value of an Enterprise Semantic Model (ESM) based on the CIM
• Case studies• Where to get more CIM information
3
What is the Problem that created the need for Interoperability in the Smart Grid?
– Deregulation of the power industry, and– Increasing difficulty in building new capacity, complicating
today’s power grid and pushing the grid nearer to operating limits
Consequence: Power grid operations have become dramatically more dependent on complex computer-based analytically-intensive operating practices
– Smart Grid is a transformative movement• expanding the number and variety of active participants• expanding the types of energy sources• expanding the kinds of active business processes
– Result: significant increase in the operational complexity of the system
4
The NIST Smart Grid Conceptual Model
5
Smart Grid Conceptual Model – Diving Deeper
CIM
ZigBee SEP
NAESB ESPI (Green Button)
MultiSpeak
CIMCIMCIM
CIM
CIM
OpenADR
System Interoperability is the Goal
NAESB OpenFMB
CIMCGMES
6
Role of CIM in Smart Grid Architecture• Here’s where the CIM comes into the solution• CIM standards aim to simplify integration of
components and expand options for supply of components by standardizing information exchanges– Reduce complexity with clear consistent semantic modeling
across the enterprise– Data sources: achieve a clear picture of data mastership in the
enterprise – Data consumers: make ‘data of record’ available on demand to
qualified users• CIM employs a canonical data model (CDM) strategy
for standardizing interfaces in the power system operations and planning domain
7
What is a Canonical Data Model?
A common language, likeuse of English in InternationalIEC standards
A common vocabulary or set of semantics for creatingunderstanding
8
The Common Language Should Provide Relevant Information To A User Regardless of Source
EngineeringConcerns
MaterialsManagement
ConcernsConstruction
Concerns
OperationsConcerns
ProtectionConcerns
MaintenanceConcerns
9
The Common Language Should Provide Relevant Information To A User Regardless of Source
Engineering Concerns The logical view of how the type of equipment fits (will fit) in the electrical network. Nominal configuration of “as-built” and “future” states. • Field Name • Spatial Location • Version • Physical Connectivity • Load Projections • Capacity Requirements • Compatible Unit • Equipment Ratings
Construction Concerns Lifecycle information regarding when and how to install equipment: • Field Name • Location • Equipment Manufacturer/Model • Compatible Unit • Equipment Ratings • Work Order • Work Design • Installation Schedule &Budget • Permits • Manufacturer Specifications • Safety Requirements
Materials Management Concerns Planning and tracking material requirements for construction and maintenance. Information about physical pieces of equipment. • Asset Identifier • Compatible Unit • Equipment Component Type • Equipment Manufacturer/Model • Serial Number • Location • Equipment Location History • Manufacturer Specifications
10
The Needs of Various Users –Some Same, Some Different (continued)
Operations Concerns Real-time condition of equipment and electrical network necessary to maintain reliable network operation: • Field Name • Schematics & Spatial Location • Electrical Connectivity • Operational Limits (dynamic) • Equipment Status • Clearances • Network Measurements (voltage,
current, frequency) • Equipment Faults • Weather Measurements • Operational Restrictions
Maintenance Concerns Lifecycle information regarding when and how equipment is maintained: • Field Name • Location • Equipment Manufacturer/Model • Equipment Ratings • Routine Maintenance • Testing & Diagnostics
Procedures • Equipment Condition • Inspection Schedule • Equipment Repair Records • Site Service Records • Maintenance Budget • Safety Requirements
Protection Concerns Setting and configuring relays based on equipment and network protection requirements: • Field Name • Schematics • Electrical Connectivity • Maximum Capacity • Zones Of Protection • Equipment Status • Clearances • Network Measurements
(voltage, current, frequency, transients)
• Equipment Faults
11
Exchanging Common Language Messages Among Systems Should Provide Relevant Information To Each System That Is Harmonious With All Other Systems’ Information
WorkBlah, Blah, Blah,
Organization,Blah, Blah, Blah
MaintenanceBlah, Blah, Blah,
Organization,Blah, Blah, Blah Switching Schedule
Blah, Blah, Blah, Organization,
Blah, Blah, Blah
Load Data SetBlah, Blah, Blah,
Organization,Blah, Blah, Blah
Meter ReadingBlah, Blah, Blah,
Organization,Blah, Blah, Blah
Load ControlBlah, Blah, Blah,
Organization,Blah, Blah, Blah
Asset CatalogBlah, Blah, Blah,
Organization,Blah, Blah, Blah
CrewBlah, Blah, Blah,
Organization,Blah, Blah, Blah
Service ConnectionRequest
Blah, Blah, Blah, Organization,
Blah, Blah, Blah
Planned OutageBlah, Blah, Blah,
Organization,Blah, Blah, Blah
For example, in each of the message exchanges depicted above, the same Organization is referenced for different reasons. There should be NO inconsistencies about this Organization
12
For example, a common language-based logical infrastructure facilitates collaboration among the many applications involved in Asset Management
Asset Strategy
Asset Portfolios
Risk Management
RegulatoryReporting
Financial Management
ResourceScheduling &
Planning
Equip./FleetManagement
Supply Chain Management
ContractManagement
Mobile Workforce
Mgmt.
Work Collaboration & Reporting
Work Design
Asset Owner Asset Manager Service Provider
Asset Investment Planning Asset Program Management
Customer Management Asset Operations
CIS
CRM
IVR eBusiness EMS DMS
SCADA
OMS
Asset Planning Tool
Budget Load Forecast
ReliabilityAnalysis
NetworkAnalysis
Asset Repository
ExecutiveDashboard
Program Mgmt.
Work Mgmt.
Mobile & Dispatching
Contract Mgmt.
GISRevenue
Facility I&M
Portal
SA/DA
Metering
SRCM
13
Application To Common Language Mapping –The Typical Field to Field Process Is Cumbersome
• Individual fields of data models from data sources are mapped to each other
• Approach does not scale well as the number of maps grows exponentially with each new data source
• Mapping is a challenge as ‘mappers’ must have an in depth understanding of all relevant data sources – a tall order!
14
The CIM is the Basis for a Common Systems Language for Utilities
One DictionarySupports Many Forms of Communication
• The same dictionary is used for multiple forms of human communication:– Letters– Phone calls– Conversations– Emails– Etc.
• In similar manner, the same CIM is used for multiple forms of computer communication:
– XML– RDF– OWL – DDL– Etc.
14
15
Using A Semantic Model Simplifies & Scales Up The Mapping Process
• What is a Semantic Model?– The key ingredients that make up a semantic model are a vocabulary of
basic terms, a precise specification of what those terms mean and how they relate to each other.
• How does one define a Semantic Model?– Before making mappings, a model (or an ontology) of a given business
domain is defined. • The model is expressed in a knowledge representation language –
CIM uses UML• The model contains business concepts, relationships between them
and a set of rules• The Semantic Model is then used to provide a common language for
exchanging information between systems that have different ways of representing data internally
• This is some times referred to as Canonical Data Model which is mapped to by each system
– Compared to one-to-one mappings, mapping data sources to a common semantic model offers a much more scaleable and maintainable way to manage and integrate enterprise data
16
How is a Semantic Model used in practice?
• By organizing the mapping in a discrete layer for use by adapters (i.e., data converters/mappers)
• In this way, semantic models enable communication between computer systems that is independent of the individual system technologies, information architectures and applications
17
ETLIntegration BusWeb Services
Apps.
GenericServices
Composite Applications
DW
Business Intelligence
CIM-based CommonLanguageAdapters
SemanticModel
Metadata
The CIM Semantic Model Provides a Semantic Layer in an Enterprise Architecture
18
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
AM/FM/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
Message Type Instance: ChangedNetworkDataSet (Expressed In Common Language)
Decoupled InformationExchange
19
Now let’s look under the hood of the CIM standards
20
The IEC Common Information Model (CIM) - What Is It?
• A set of standards to enable system integration and information exchange based on a common information model
– Provides a general information model and message/file schemas for messages/files exchanged between systems
• A key differentiator: The CIM standards are based on a Unified Modeling Language (UML) based electronic information model representing real-world objects and information entities exchanged within the value chain of the electric power industry
– Provides common semantics for all information exchanges• Referred to as Model-Driven Integration (MDI)
– Not tied to a particular application’s view of the world• But permits same model to be used by all applications to facilitate information sharing
between applications– Maintained by IEC in Sparx Enterprise Architect (EA) modeling tools– Many tools available
• Generating design artifacts and documentation• Validation
– Enable data access to enterprise data warehouse in a standard way
21
Once again – What is the CIM?
• It’s more than a set of standards – it’s a solution!• UML model can be customized or tailored to fit specific utility data
requirements– Private extensions– Merging and harmonizing with other standard models– Subset can be published as a standard from a different SDO
• Example: NAESB Open Field Message Bus (OpenFMB) based on combined CIM and 61850 object models
• New interface profiles can defined for information exchange• New design artifacts (e.g., XSDs) can be generated with same
tools used to develop the CIM standards
22
We Need An Organizing Framework
• Let’s break it down• The CIM standards include an information model expressed in UML• Profiles for specifying a subset of the CIM classes and attributes for a
specific business context at a specific system interface or system interaction
• Implementation models– Use of XML to create serialized files and messages
• RDF Schema-based standards for power system model exchange
• XML Schema-based standards for information message payloads
– Could include ETL based on CIM for data base access• DDLs for data tables
• But how do we organize these pieces?
23
GWAC* Stack and the CIM Standards
Organizational
Technical
Informational
8: Economic/Regulatory Policy
7: Business Objectives
6: Business Procedures
3: Syntactic Interoperability
5: Business Context
2: Network Interoperability
4: Semantic Understanding
1: Basic Connectivity
Interoperability Categories
Political and Economic Objectives as Embodied in Policy and Regulation
Strategic and Tactical Objectives Shared between Businesses
Alignment between Operational Business Processes and Procedures
Awareness of the Business Knowledge Related to a Specific Interaction
Understanding of the Concepts Contained in the Message Data Structures
Understanding of Data Structure in Messages Exchanged between Systems
Mechanism to Exchange Messages between Multiple Systems across a Variety of Networks
Mechanism to Establish Physical and Logical Connections between Systems
CIM
*GWAC – GridWise Architecture Council
24
CIM Layered Architecture*
CIM UML
Information and Semantic Models
Context
Message Syntax
Profiles
Message/FileFormat
(XSD, RDFSchema, OWL)
Contextual layer restricts information model• Specifies which part of CIM is used for given profile• Mandatory and optional• Restrictions• But cannot add to information model
Message syntax describes format for instance data• Serialization of instance data• Can re-label elements• Change associations to define single structure for
message payloads• Mappings to various technologies can be defined
Information Model• Generalized model of all utility objects and their
relationships• Application independent, but defines all concepts
needed for any application
* Based on UN/CEFACT CCTS (Core Component Technical Specification)
26
CIM Design Time Methodology
• Let’s consider how these layered CIM standards are applied to solve the system integration problem
• First step is to link business process data exchanges discovered by creating activity diagrams and sequence diagrams and linking with a common semantic model (such as the CIM model)– Example sequence diagram
2727
Global methodological framework inspired from UN/Cefact CCTS (Core Component Technical Specification) standard
DMS OMS
Exchanged Dataanalysis
1
Message ConceptualModel
orMessageAssembly
(Exchanged at app interfaces)
4
Business Process Study:
Ex: outage Management
Contextual Modelor Business
Information Entity
3(Sub-Set, Constraints, restrictions)
5 Implementation Message Modelor
Syntax Binding
Technological derivation XSD, OWL,RDFS, SQL …etc
XML Exchanged Data
Validation
Information Modelor Core
Components( CIM)
2
CIM extensions
28
CIM Design Time Methodology
• Another Example– Need to exchange an Energy Transaction between Transmission
Operator (TO) and an Independent System Operator (ISO)– Illustrates in more detail the design artifacts generated at each
step– Important to note all design is done in UML using Sparx
Enterprise Architect with choice of CIM Tools– Final step is to automatically generate XML or RDF schemas from
the UML
29
FromInformation
Model to Syntactic Model
Ex: Energy Transaction
AbstractModel
Syntactic Model
<?xml version="1.0" encoding="UTF-8"?><xsd:elementname=« MT_EnergyTransaction"><xsd:sequence>
<xsd:elementname=« EnergyTransaction"/>
<xsd:sequence><xsd:element name=« Name"/>
<xsd:element name=« Type"/></xsd:sequence>
</xsd:element>
UML World
XML Syntactic World
Information/SemanticModel
Context/Profiles
MessageAssembly
MessageSyntax
30
Information/Semantic Model Expressed in UML (Unified Modeling Language) Notation
Class Name usually describes things in the real world
Class Attributes describesignificant aspects about the thing
This Specialization indicates that an “EnergyTransaction” is a type of“Document.” “EnergyTransaction” inherits all of the attributes from Document
Aggregation is a variant of Association and indicates a class is a collection or container of other classes, but if the container is destroyed, its contents are not.
Associationsconnect classes and areassigned a role that describes the relationship
31
FromInformation Model
to Syntactic Model
AbstractModel
Syntactic Model
UML World
XML Syntactic World
Information/SemanticModel
Context/Profiles
32
Context/ProfilesString Length
changed to exactly 6
String Length
changed to max of 4
Only “code” attribute retained
Association inherited from
parent Document class, cardinalities
changed to “1”
Various tools available to create Profiles
33
FromInformation Model
to Syntactic Model
AbstractModel
Syntactic Model
UML World
XML Syntactic World
Information/SemanticModel
Context/Profiles
MessageAssembly
34
Message Assembly
35
FromInformation Model
to Syntactic Model
AbstractModel
Syntactic Model
<?xml version="1.0" encoding="UTF-8"?><xsd:elementname=« MT_EnergyTransaction"><xsd:sequence>
<xsd:elementname=« EnergyTransaction"/>
<xsd:sequence><xsd:element name=« Name"/>
<xsd:element name=« Type"/></xsd:sequence>
</xsd:element>
UML World
XML Syntactic World
Information/SemanticModel
Context/Profiles
MessageAssembly
MessageSyntax
36
To Summarize• The CIM information model standard expressed in UML is used is
the source of the semantics needed for a particular exchange • A Profile specifies the restricted subset of the CIM classes and
attributes for specific business context– This is the CDM (Canonical Data Model) for a particular information
exchange • An Implementation Technology, such as XML, is used to create the
schema for serializing the instance data as files or messages, resulting in– Standards for power system models– Standards for information message payloads
• The good news --- most of the power system models and message schemas needed by a utility are already defined as IEC standards– 61970 series: Power system models for operations and planning (T&D)– 61968 series: Message schemas for enterprise integration (T&D)– 62325 series: Deregulated Market Communications
37
Let’s look at each layer of the CIM standards
CIM UML
Information and Semantic Models
Context
Message Syntax
Profiles
Message/FileFormat
(XSD, RDFSchema, OWL)
Contextual layer restricts information model• Specifies which part of CIM is used for given profile• Mandatory and optional• Restrictions• But cannot add to information model
Message syntax describes format for instance data• Can re-label elements• Change associations to define single structure for
message payloads• Mappings to various technologies can be defined
Information Model• Generalized model of all utility objects and their
relationships• Application independent, but defines all concepts
needed for any application
38
Foundational Relationships Of The CIM
PowerSystemResourceElectrical Network Role Used For
Planning, Operations, etc.
AssetPhysical Plant Filling A Role
Such As A Transformer, Pole, etc.
LocationWhere To Find Something By
GPS, Address, Electronically, etc.
OrganisationEntities Performing Roles Such
As Operations, Tax Authority
PersonPeople Performing Roles SuchDispatcher, Field Operator, etc.
DocumentInformation Containers Such AsTrouble Ticket, Work Orders, etc.
CustomerIndustrial, Commercial, & Residential
Which Can Have Multiple Accounts
39
UCA InternationalUser groups
Who Manages the CIM UML Model?- TC 57 Organization and Formal Liaisons
IEEEPES PSCC
SecuritySubComm
WG14SIDMS
WG19Architecture
WG13EMS-API
WG 10SubstationAutomation
CIGRESC D2-24SC B5-38
TC57
CIM/61850Harmonization
WG17DER
WG16EnergyMarkets
WG18Hydro
WG15Security Legend
CIM-based
61850-based
WG3TelecontrolProtocols
WG20Power Line
Carrier
ConvenersAdvisory Group
CAG
WG21Grid SystemInterfaces
40
IEC TC57 CIM Packages
WG13Operations/Planning Network Models
WG14Operations/PlanningAssets and Back OfficeSystem Integration
WG16DeregulatedMarketCommunications
cla ss PackageDependencies
TC57CIM::CombinedVer sion
+ date: Date [0..1] = 2011-09-09 {readOnly}+ version: String [0..1] = iec61970CIM15v3... {readOnly}
IEC61970
(from TC57CIM)
PackageDependenciesCIMVer sion
+ date: Date [0..1] = 2011-05-07 {readOnly}+ version: String [0..1] = 6 {readOnly}
IEC61968
(from TC57CIM)
IEC62325
(from TC57CIM)
PackageDependencies
(from TC57CIM)
IEC62325::IEC62325CIMVer sion
+ date: Date [0..1] = 2011-04-28 {readOnly}+ version: String [0..1] = IEC62325CIM01v07 {readOnly}
IEC61968::IEC61968CIMVer sion
+ date: Date [0..1] = 2011-08-10 {readOnly}+ version: String [0..1] = IEC61968CIM11v13 {readOnly}
IEC61970::IEC61970CIMVer sion
+ date: Date [0..1] = 2011-09-09 {readOnly}+ version: String [0..1] = IEC61970CIM15v33 {readOnly}
41
WG13 CIM Packages - 61970cla ss IEC61970Dependencies
Equiv a lents
P r otect ion
SCADA
Gener a t ion
OutageLoadModel
TopologyMeas
Wir es
Doma in
Cor e
IEC61970CIMVer sion
+ date: Date [0..1] = 2011-09-09 {readOnly}+ version: String [0..1] = IEC61970CIM15v33 {readOnly}
Oper a t iona lLimits
Contr olAr ea
Gener a t ionDy namics
(from Generation)
P r oduct ion
(from Generation)
Cont ingency
Auxil ia r y Equipment
Sta teVa r iables
Diagr amLay out
42
Concepts: Generalization/Inheritance
• Equipment: Specialization of PowerSystem Resource
• ConductingEquipment: Specialization of Equipment
• Switch: Specialization of Conducting Equipment
• ProtectedSwitch: Specialization of Switch
• Breaker: Specialization of ProtectedSwitch
Release 14
Release 15
cla ss Documenta t ionExampleInher itance
IdentifiedObjectCor e::Power Sy stemResour ce
Cor e::Equipment
Cor e::Conduct ingEquipment
Wir es::Br eaker
W ir es::P r otectedSwitch
Wir es::Switch
Wir es::Power Tr ansfor mer
43
Naming and ContainerHierarchy Part 1
cla ss NamingHier a r chy Pa r t1
Cor e::Substa t ion
Cor e::Bay
Cor e::VoltageLev el
Cor e::SubGeogr aphica lRegion
Line
Cor e::Geogr aphica lRegion
Cor e::Ident if iedObject
+ aliasName: String [0..1]+ mRID: String [0..1]+ name: String [0..1]
Cor e::Equipment
Cor e::EquipmentConta iner
Cor e::Power Sy stemResour ce
P lant
Cor e::Connect iv ity NodeConta iner
+Substation 1
+VoltageLevels 0..*
+Region 0..1
+Regions 0..*
+VoltageLevel0..1
+Bays0..*
+Region0..1
+Lines 0..*
+Region 0..1
+Substations 0..*
+Bays 0..*
+Substation
0..1
+EquipmentContainer0..1
+Equipments0..*
44
Naming and EquipmentHierarchyPart 2
cla ss NamingHier a r chy Pa r t2
Fuse
Ener gy Consumer
ShuntCompensa tor
Connector
Busba r Sect ion
Br eaker
ACLineSegment
Disconnector
Jumper
Fr equency Conv er ter
Ener gy Sour ce
Sta t icVa r Compensa tor
Rect i f ier Inv er ter
Conductor
Cor e::Conduct ingEquipment
Cor e::Equipment
DCLineSegment
Sy nchr onousMachine
CompositeSwitch
Switch
Meas::Measur ement
Cor e::Power Sy stemResour ce TapChanger
Gr ound
Regula t ingCondEq
Gr oundDisconnector
P r oduct ion::Gener a t ingUnit
Cor e::Ident if iedObject
+ aliasName: String [0..1]+ mRID: String [0..1]+ name: String [0..1]
Ser iesCompensa tor
P r otectedSwitch
LoadBr eakSwitch
Junct ion
Rota t ingMachine
+CompositeSwitch0..1
+Switches 0..*
+GeneratingUnit 0..1+SynchronousMachines 1..*
+PowerSystemResource0..1
+Measurements
0..*
45
Names
cla ss Names
Ident if iedObject
+ aliasName: String [0..1]+ mRID: String [0..1]+ name: String [0..1]
Name
+ name: String [0..1]
NameTy pe
+ description: String [0..1]+ name: String [0..1]
NameTy peAuthor ity
+ description: String [0..1]+ name: String [0..1]
+Names
0..* +NameType1
+Names 0..*
+IdentifiedObject 1
+NameTypes
0..* +NameTypeAuthority
0..1
46
ConnectivityandTopology Model
cla ss Ma in
Cor e::EquipmentConta iner
Switch/Node static Model
Cor e::Connect iv ity Node
Cor e::Connect iv ity NodeConta iner
Cor e::Ter mina l
Bus/Branch calculated Model
Topologica lNode
Meas::Measur ement
Cor e::Conduct ingEquipment
Topologica l Island
Cor e::Power Sy stemResour ce
Cor e::Ident if iedObject
BusNameMar ker
Cor e::Equipment
Bus/Branch bus naming specificaiton static model.
Contr olAr ea ::Contr olAr ea
+ netInterchange: ActivePower [0..1]+ pTolerance: ActivePower [0..1]+ type: ControlAreaTypeKind [0..1]
+ConnectivityNodes 0..*
+TopologicalNode 0..1
+AngleRef_TopologicalIsland0..1
+AngleRef_TopologicalNode0..1
+Terminal0..*
+TopologicalNode0..1
+BusNameMarker
0..1
+Terminal1..*
+ConnectivityNodes 0..*
+ConnectivityNodeContainer
1
+Measurements 0..*
+Terminal0..1
+Terminals0..*
+ConnectivityNode 0..1
+TopologicalNodes 1..*
+TopologicalIsland 1
+Terminals
0..*+ConductingEquipment 1
+TopologicalNode0..*+ConnectivityNodeContainer
0..1
47
Converting a Circuit to CIM Objects
• 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
Taken from Alan McMorran, Common Information Model Primer: First Edition., EPRI, Palo Alto, CA: 2011, 1024449. Third Edition now available.
48
Example Circuit as a Single Line Diagram
EnergyConsumer
Breaker
SynchronousMachine
GeneratingUnit
Breaker
BusbarSection
Breaker
ACLineSegment
Current measurement represented by
Measurement connected to Terminal
49
Transformer Class DiagramCIM Release 15
Winding terminal for balanced transformer model
network connection
Winding terminal for unbalanced transformer
model network connection
ConductingEquipment with associations to types of
TransformerEnds for electrical connectivity
TransformerTank added for distribution transformer windings so each phase
winding could be modeled
Previously included in Winding class
50
Balanced Transformer Model
Contains legacy attributes for resistance, reactance,
conductance, susceptance,
For backward compatibility, can consider as optional
51
Balanced Transformer Instance for Transformer 17-33 - Release 15 and later
Transformer 17-33 is represented as four CIM objects plus optional objects
Connections from the transformer to the network are made directly from the PowerTransformer via association to PowerTransformerEnd
52
Unbalanced Distribution Transformer with Multiple Tanks Instance Example
53
Example Circuit with Full CIM Mappings
• 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
54
WG14 CIM Packages - 61968pkg IEC61968Dependencies
Meter ing
Pay mentMeter ing
Cor e
(from IEC61970)
Doma in
(from IEC61970)
Meas
(from IEC61970)
LoadContr ol
Common
Customer s
Asset Info
Assets
Wor k
IEC61968CIMVer sion
+ date: Date [0..1] = 2011-08-10+ version: String [0..1] = IEC61968CIM11v13
55
Common Concepts in 61968 CIM
cla ss CommonOv er v iew
IdentifiedObjectAct iv ity Recor d
+ createdDateTime: DateTime [0..1]+ reason: String [0..1]+ severity: String [0..1]+ status: Status [0..1]+ type: String [0..1]
Agr eement
+ signDate: Date [0..1]+ validityInterval: DateTimeInterval [0..1]
IdentifiedObjectDocument
+ createdDateTime: DateTime [0..1]+ docStatus: Status [0..1]+ electronicAddress: ElectronicAddress [0..1]+ lastModifiedDateTime: DateTime [0..1]+ revisionNumber: String [0..1]+ status: Status [0..1]+ subject: String [0..1]+ title: String [0..1]+ type: String [0..1]
IdentifiedObjectOr ganisa t ion
+ electronicAddress: ElectronicAddress [0..1]+ phone1: TelephoneNumber [0..1]+ phone2: TelephoneNumber [0..1]+ postalAddress: PostalAddress [0..1]+ streetAddress: StreetAddress [0..1]
Posit ionPoint
+ sequenceNumber: Integer [0..1]+ xPosition: String [0..1]+ yPosition: String [0..1]+ zPosition: String [0..1]
IdentifiedObjectTimePoint
+ dateTime: DateTime [0..1]+ relativeTimeInterval: Seconds [0..1]+ sequenceNumber: Integer [0..1]+ status: Status [0..1]+ window: DateTimeInterval [0..1]
TimeSchedule
+ disabled: Boolean [0..1]+ offset: Seconds [0..1]+ recurrencePattern: String [0..1]+ recurrencePeriod: Seconds [0..1]+ scheduleInterval: DateTimeInterval [0..1]
IdentifiedObjectLoca t ion
+ direction: String [0..1]+ electronicAddress: ElectronicAddress [0..1]+ geoInfoReference: String [0..1]+ mainAddress: StreetAddress [0..1]+ phone1: TelephoneNumber [0..1]+ phone2: TelephoneNumber [0..1]+ secondaryAddress: StreetAddress [0..1]+ status: Status [0..1]+ type: String [0..1]
IdentifiedObjectCoor dina teSy stem
+ crsUrn: String [0..1]
IdentifiedObjectOr ganisa t ionRole
Conf igur a t ionEv ent
+ effectiveDateTime: DateTime [0..1]+ modifiedBy: String [0..1]+ remark: String [0..1]
+Documents
0..*
«informative»
+ActivityRecords
0..*
+ChangedDocument0..1
+ConfigurationEvents0..*
+Organisations
0..*«informative»
+ActivityRecords
0..*
+TimeSchedule
1 +TimePoints
0..*
+Location
1
+PositionPoints
0..*
+ChangedLocation
0..1
+ConfigurationEvents0..*
+Location
0..* +CoordinateSystem
0..1
+Roles
0..*
+Organisation
0..1
+ChangedOrganisationRole
0..1
+ConfigurationEvents
0..*
56
How The CIM Handles Location For Logical Devices And/OrThe Physical Asset Performing The Device’s Rolecla ss AssetsOv er v iew
IdentifiedObjectAsset
+ acceptanceTest: AcceptanceTest [0..1]+ critical: Boolean [0..1]+ electronicAddress: ElectronicAddress [0..1]+ initialCondition: String [0..1]+ initialLossOfLife: PerCent [0..1]+ lifecycle: LifecycleDate [0..1]+ lotNumber: String [0..1]+ purchasePrice: Money [0..1]+ serialNumber: String [0..1]+ status: Status [0..1]+ type: String [0..1]+ utcNumber: String [0..1]
AssetConta iner
IdentifiedObjectAssetFunct ion
+ configID: String [0..1]+ firmwareID: String [0..1]+ hardwareID: String [0..1]+ password: String [0..1]+ programID: String [0..1]
ComMedia
IdentifiedObjectAssetModel
IdentifiedObjectAsset Info
P r oductAssetModel
+ corporateStandardKind: CorporateStandardKind [0..1]+ modelNumber: String [0..1]+ modelVersion: String [0..1]+ usageKind: AssetModelUsageKind [0..1]+ weightTotal: Weight [0..1]
OrganisationRoleAssetOr ganisa t ionRole
OrganisationRoleManufactur er
AssetOwner
IdentifiedObjectCor e::
Power Sy stemResour ce
IdentifiedObjectCommon::Loca t ion
+ direction: String [0..1]+ electronicAddress: ElectronicAddress [0..1]+ geoInfoReference: String [0..1]+ mainAddress: StreetAddress [0..1]+ phone1: TelephoneNumber [0..1]+ phone2: TelephoneNumber [0..1]+ secondaryAddress: StreetAddress [0..1]+ status: Status [0..1]+ type: String [0..1]
+Location 0..1
+PowerSystemResources 0..*
+Assets
0..*
+Location
0..1
+Assets 0..*
+AssetInfo 0..1
+Assets
0..*
+AssetContainer0..1
+Assets
0..*
+PowerSystemResources 0..*
+Assets
0..*
+OrganisationRoles
0..*
+AssetModel
0..1
+AssetInfo
0..1+AssetDatasheet
0..1
+PowerSystemResource
0..*
+ProductAssetModel
0..*
+Manufacturer
0..1
57
Types Of Document Relationship InheritedBy All Assets
58
Activity Recordscla ss tmpAct iv ity Recor d
IdentifiedObjectInfCommon::
Per son
IdentifiedObjectCommon::Document
IdentifiedObjectCommon::Act iv ity Recor d
+ createdDateTime: DateTime [0..1]+ reason: String [0..1]+ severity: String [0..1]+ status: Status [0..1]+ type: String [0..1]
IdentifiedObjectAssets::Asset
IdentifiedObjectInfCommon::
ScheduledEv ent
InfWor k::Wor kSta tusEntr y
InfCustomer s::ComplianceEv ent
InfAssets::Fa i lur eEv ent
Meter ing::EndDev iceEv ent
InfOper a t ions::PSREv ent
IdentifiedObjectCommon::
Or ganisa t ion
+ErpPersons 0..*
«informative»+ActivityRecords
0..*
+Documents0..*
«informative»
+ActivityRecords
0..*
+Assets 0..*
+ActivityRecords 0..*+ScheduledEvents 0..*
«informative»
+Assets 0..*
+Organisations 0..*
«informative»
+ActivityRecords 0..*
59
WG16 CIM Market Extensionscla ss Ma in
Mar ketCommon
Mar ketManagementMar ketOper a t ions
IEC62325CIMVer sion
+ date: Date [0..1] = 2011-04-28 {readOnly}+ version: String [0..1] = IEC62325CIM01v07 {readOnly}
60
CIM UML Release Cycles
• 61970 CIM UML tries for annual release cycle• Basis for IEC 61970-301 CIM Base Fifth Edition
• Word document auto-generated from the UML electronic model• Information system and Profile documents are synchronized with
UML model release• 61968 CIM UML different update cycles
• Basis for IEC 61968-11 CIM Distribution Information Exchange Model
• 62325 CIM UML on another update cycle• Basis for IEC 62325-301 CIM for Deregulated Markets
• Complete CIM UML available as a combined model on CIMugSharepoint site:
– Title: draft CIM16 + DCIM12 + MCIM02
– Name: iec61970cim16v13_iec61968cim12v05_iec62325cim02v05
61
CIM UML in Enterprise Architect
• The CIM UML model is maintained in Sparx Enterprise Architect (EA)
• Current Official CIM Releases of UML Model – iec61970cim16v29a_iec61968cim12v08_iec62325cim03v01a
(official release 16 WG13)– iec61970cim17v04_iec61968cim12v09_iec62325cim03v01a
(updated by WG14)– iec61970cim17v07_iec61968cim12v10_iec62325cim03v02
(current model release)
• Go to UML model in EA
62
Break