CIM as a Framework for Smart Grid Interoperability Part 1 CIM Users Group Erlangen, Germany Terry Saxton
Presentation Contents for Morning Session Part 1
Part 2
•
•
• • • • •
What is the interoperability problem? 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
Layer 2 - Profiles for defining system interfaces – –
•
Layer 3 - Implementation syntax of instance data –
• • •
IEC 61970 network model exchange IEC 61968 message payloads for system integration
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
Break 2
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
3
Interoperability is about Data Exchange – Lots of Data! • Exchanged between systems/applications from many different suppliers within an enterprise (horizontal) • Let’s look at where we are today and where we are headed
4
The NIST Smart Grid Conceptual Model
5
Sample of Systems/Communications Paths Comprising the Smart Grid Illustrates Complexity and Need for Interoperability
6
Interoperability is about Data Exchange – Lots of Data! • Exchanged between systems/applications from many different suppliers within an enterprise (horizontal) • Received from the field from many different sources (vertical/hierarchical)
7
Asset Health - Data Aggregation Challenge Data
Systems
TOA Field Service Management
Doble Database
Maximo Cascade
Asset Health Data
Asset Catalog Data
Asset Engineer
Owner/ User
Review Replacement Planning Maintenance Planning Long term planning
SCADA Historian
The OT Divide
Operations Manager
Alarms Customers Short Term planning
Challenging to bring the data together 8
8
Interoperability is about Data Exchange – Lots of Data! • Exchanged between systems/applications from many different suppliers within an enterprise (horizontal) • Received from the field from many different sources (vertical/hierarchical) • Exchanged between utilities (DSO-DSO and DSO-TSO) • Distributed Energy Resources (DER) and MicroGrids • Distributed Intelligence in Field Devices and the Internet of Things (IoT) – Sheer numbers of interconnections
• The list goes on and on
9
That’s the Problem – What’s the Solution? • Solution requirements – Requires information transfer between systems that were designed independently – More important: The hundreds of transfers involved in complex processes must all be informationally compatible with one another in order to achieve the required end result – All of this is only practical with intensive computer-based automation dependent on • Multiple systems at multiple locations owned and operated by multiple parties cooperating within defined business scenarios • Requires information produced by System A and System B to be consumable by System C in order to produce information for System D in time frames that may not tolerate errors or human intervention
10
Example - Let’s focus on distribution ops and outage management
11
Example: Non-Smart System Integration – Results in Multiple Unique Point-Point Data Exchanges and Mappings GIS OMS
CIS
OR
TT
AMR
WMS WO
DMS CIS – Customer Information System OMS – Outage Management System DMS – Distribution Management System WMS – Work Management System GIS – Geographic Information System
OMS
CIS
CR
Trouble Ticket TT – Trouble Ticket OR – Outage Report WO – Work Order CR – Customer Report
Information Flow Design
Outage Record
TT
DMS
OR
WO
CR
12
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
13
What is a Canonical Data Model?
A common language, like use of English in International IEC standards A common vocabulary or set of semantics for creating understanding 14
The CIM is the Basis for a Common Systems Language for Utilities • 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: – – – – –
One Dictionary Supports Many Forms of Communication
XML RDF OWL DDL Etc.
15
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 each have a different ways of representing data internally • This is some times referred to as Canonical Data Model which is mapped to by each system
16
Using A Semantic Model Simplifies & Scales Up The Mapping Process • How is a Semantic Model used in practice?
– By organizing the knowledge 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
The CIM Semantic Model Provides a Semantic Layer in an Enterprise Architecture Composite Applications
CIM-based Common Language Adapters Generic Services
Web Services
Business Intelligence
Integration Bus
ETL
DW
Semantic Model Metadata
Apps.
18
Example: System Integration with the CIM - in Step With Business Needs GIS OMS
IEC 61968 IRM Interface
CIS
OR
TT
CIM Adapters
Semantically Consistent ESB
AMR
WMS DMS
Information Flow Design
Trouble Ticket CIS – Customer Information System OMS – Outage Management System DMS – Distribution Management System WMS – Work Management System GIS – Geographic Information System
TT – Trouble Ticket OR – Outage Report WO – Work Order CR – Customer Report
Outage Record
DMS
OMS
CIS TT
OR
19
Warning: Don’t be fooled by external appearances You need the CIM ingredient to avoid adding to ‘Integration Anarchy’
OMS
GIS
CIS
DMS
AMR
Integration Infrastructure
WMS Integration anarchy is a chaos of:
Without common (1) duplicated logic, semantics, Data Integration Anarchy! Point-to-Point (2) duplicated data, Integration will (3) duplicated effort, continue at the (4) newly acquired integration difficulties, data level (5) lack of ability to easily create new application functionality from services, and (6) lack of ability to support business processes with applications
Integration anarchy will result in higher costs and an inflexible, brittle Smart Grid System of Systems
20
Decoupled Information Exchange CIM X.1 X.2 X.3 X.4 X.5
CIM X.1 X.2 X.3 X.4 X.5
App B.1 B.2
Subscriber
Subscribers: Several Application Adapters Receive The Same Message Each Adapter: Parses Message, Pulling Out Data Needed By Application Transforms Data (if necessary) to Local Application Format Passes Data To Local Application And/Or Database Through Most Appropriate Means
App A.1
A.4 A.5
Subscriber
Outage Reporting
Grid Wires Model
DAC
Dist Wires Model
EMS
OMS
CIM X.1 X.2 X.3 X.4 X.5
App C.1 C.3 C.4
Subscriber VRU
Distribution Automation
CIS
Message Type Instance: ChangedNetworkDataSet (Expressed In Common Language)
Event History
CIM X.1 X.2 X.3 X.4 X.5
AM/FM/GIS
Subscriber
Human Resources
App Y.1 Y.2 Y.3 Y.4 Y.5
CIM X.1 X.2 X.3 X.4 X.5
Publisher
Work Management
Substation Automation
...
Data Warehouse
Publishers: One Application Connector: Obtains Data From Application And/Or Database Transforms Data (if necessary) to the “Common Language” (a Canonical Data Model) Puts Data Into Message Template Publishes The Message (Fires & Forgets)
21
Now let’s look under the hood of the CIM standards as applied to smart distribution application integration
22
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 • Enables integration of applications/systems – Provides a common information model (semantics) – Basis for defining CDMs (profiles) for each information exchange and associated message/file schemas for all messages/files exchanged between systems
• Enables data access to enterprise data warehouse in a standard way
•
– Common language to navigate and access complex data structures in any database – Inspiration for logical data schemas (e.g., for an operational data store Enables exchange of power system network models between utilities
23
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 other standard 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 A key differentiator: The CIM standards are based on a Unified Modeling Language (UML) based information model representing real-world objects and information entities exchanged within the value chain of the electric power industry – 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
– Developed and standardized by IEC using Sparx Enterprise Architect modeling tools 24
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? 25
GWAC* Stack and the CIM Standards Interoperability Categories 8: Economic/Regulatory Policy
Organizational
CIM
7: Business Objectives
Strategic and Tactical Objectives Shared between Businesses
6: Business Procedures
Alignment between Operational Business Processes and Procedures
5: Business Context
Informational
Technical
Political and Economic Objectives as Embodied in Policy and Regulation
Awareness of the Business Knowledge Related to a Specific Interaction
4: Semantic Understanding
Understanding of the Concepts Contained in the Message Data Structures
3: Syntactic Interoperability
Understanding of Data Structure in Messages Exchanged between Systems
2: Network Interoperability
Mechanism to Exchange Messages between Multiple Systems across a Variety of Networks
1: Basic Connectivity
Mechanism to Establish Physical and Logical Connections between Systems
*GWAC – GridWise Architecture Council 26
CIM Layered Architecture* Information and Semantic Models Information Model
CIM UML
• Generalized model of all utility objects and their relationships • Application independent, but defines all concepts needed for any application
Context
Profiles
Message Syntax
Message/File Format (XSD, RDF Schema, 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
* Based on UN/CEFACT CCTS (Core Component Technical Specification) 27
CIM Design Time Methodology • Let’s consider how these layered CIM standards are applied to solve the system interoperability 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
29
Global methodological framework inspired from UN/Cefact CCTS (Core Component Technical Specification) standard
3
(Sub-Set, Constraints, restrictions)
2
Contextual Model or Business Information Entity
Information Model or Core Components ( CIM)
4 Message Conceptual Model or Message Assembly (Exchanged at app interfaces)
CIM extensions Technological derivation XSD, OWL,RDFS, SQL …etc
Business Process Study:
1 Exchanged Data analysis
Ex: outage Management
5 Validation
Implementation Message Model or Syntax Binding
XML Exchanged Data
DMS
OMS
30
30
CIM Design Time Methodology • Another Example – Need to exchange an Energy Transaction between System A and System B – 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
31
From Information Model to Syntactic Model Ex: Energy Transaction
UML World
Abstract Model
Information/ Semantic Model
Context/ Profiles
Message Assembly
XML Syntactic World Message Syntax
<xsd:element name=« MT_EnergyTransaction"> <xsd:sequence> <xsd:element name=« EnergyTransaction"/> <xsd:sequence> <xsd:element name=« Name"/> <xsd:element name=« Type"/>
Syntactic Model 32
Information/Semantic Model Expressed in UML (Unified Modeling Language) Notation Class Name usually describes things in the real world
Class Attributes describe significant 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.
Associations connect classes and are assigned a role that describes the relationship
33
Information/ From Semantic Information Model Model
to Syntactic Model
Abstract Model
Context/ Profiles
UML World
XML Syntactic World
Syntactic Model 34
Context/Profiles
Various tools available to create Profiles
String Length changed to exactly 6
Only “code” attribute retained
String Length changed to max of 4
Association inherited from parent Document class, cardinalities changed to “1”
35
Information/ From Semantic Information Model Model
to Syntactic Model
UML World
Abstract Model
Context/ Profiles
Message Assembly
XML Syntactic World
Syntactic Model 36
Message Assembly
37
Information/ From Semantic Information Model Model
to Syntactic Model
UML World
Abstract Model
Context/ Profiles
Message Assembly
XML Syntactic World
Message Syntax
<xsd:element name=« MT_EnergyTransaction"> <xsd:sequence> <xsd:element name=« EnergyTransaction"/> <xsd:sequence> <xsd:element name=« Name"/> <xsd:element name=« Type"/>
Syntactic Model 38
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)
39
Let’s look at each layer of the CIM standards Information and Semantic Models Information Model
CIM UML
• Generalized model of all utility objects and their relationships • Application independent, but defines all concepts needed for any application
Context
Profiles
Message Syntax
Message/File Format (XSD, RDF Schema, 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
40
Foundational Relationships Of The CIM
PowerSystemResource
Organisation
Electrical Network Role Used For Planning, Operations, etc.
Entities Performing Roles Such As Operations, Tax Authority
Asset
Person
Physical Plant Filling A Role Such As A Transformer, Pole, etc.
People Performing Roles Such Dispatcher, Field Operator, etc.
Location
Customer
Where To Find Something By GPS, Address, Electronically, etc.
Industrial, Commercial, & Residential Which Can Have Multiple Accounts
Document Information Containers Such As Trouble Ticket, Work Orders, etc.
41
Who Manages the CIM UML Model? - TC 57 Organization and Formal Liaisons UCA International User groups
WG19 Architecture
WG13 EMS-API CIM/61850 Harmonization
WG 10 Substation Automation
WG14 SIDMS
CIGRE SC D2-24 SC B5-38
WG17 DER
TC57 WG16 Energy Markets WG3 Telecontrol Protocols
Conveners Advisory Group CAG
WG15 Security
WG21 Grid System Interfaces
WG18 Hydro
IEEE PES PSCC Security SubComm
WG20 Power Line Carrier
Legend CIM-based 61850-based 42
IEC TC57 CIM Packages cl a ss P a ck a geDependenci es
WG13
Operations/Planning Network Models
I EC 61970
TC 57C I M ::C ombi nedV er si on + +
(from TC57CIM)
date: Date [0..1] = 2011-09-09 {readOnly} version: String [0..1] = iec61970CIM15v3... {readOnly}
I EC 61970::I EC 61970C I M V er si on + +
WG14
I EC 61968::I EC 61968C I M V er si on
I EC 61968
Operations/Planning Assets and Back Office System Integration
(from TC57CIM)
date: Date [0..1] = 2011-09-09 {readOnly} version: String [0..1] = IEC61970CIM15v33 {readOnly}
+ +
date: Date [0..1] = 2011-08-10 {readOnly} version: String [0..1] = IEC61968CIM11v13 {readOnly}
I EC 62325::I EC 62325C I M V er si on
WG16
Deregulated Market Communications
I EC 62325
+ +
date: Date [0..1] = 2011-04-28 {readOnly} version: String [0..1] = IEC62325CIM01v07 {readOnly}
+ +
date: Date [0..1] = 2011-05-07 {readOnly} version: String [0..1] = 6 {readOnly}
P a ck a geDependenci esC I M V er si on
(from TC57CIM)
P a ck a geDependenci es
(from TC57CIM)
43
WG13 CIM Packages - 61970 cl a ss I EC 61970Dependenci es I EC 61970C I M V er si on + +
date: Date [0..1] = 2011-09-09 {readOnly} version: String [0..1] = IEC61970CIM15v33 {readOnly}
Loa dM odel
O ut a ge
P r ot ect i on
Gener a t i on
Gener a t i onDy na mi cs
(from Generation)
P r oduct i on
(from Generation)
W i r es
Equi v a l ent s
C ont r ol A r ea St a t eV a r i a bl es
SC A DA
O per a t i ona l Li mi t s
Topol ogy M ea s
C or e A uxi l i a r y Equi pment Doma i n C ont i ngency
Di a gr a mLa y out
44
Concepts: Generalization/Inheritance cl a ss Document a t i onExa mpl eI nher i t a nce
IdentifiedObject C or e::P ow er Sy st emResour ce
C or e::Equi pment
Release 14
• Equipment: Specialization of PowerSystem Resource
W i r es::P ow er Tr a nsf or mer
C or e:: C onduct i ngEqui pment
W i r es::Sw i t ch
W i r es::P r ot ect edSw i t ch
W i r es::B r ea k er
Release 15
• ConductingEquipment: Specialization of Equipment
• Switch: Specialization of Conducting Equipment • ProtectedSwitch: Specialization of Switch • Breaker: Specialization of ProtectedSwitch
45
Naming and Container Hierarchy Part 1
cl a ss Na mi ngHi er a r chy P a r t 1 C or e::I dent i f i edO bject + + +
aliasName: String [0..1] mRID: String [0..1] name: String [0..1]
+Regions
0..* C or e:: +EquipmentContainer Equi pment C ont a i ner 0..1
C or e:: SubGeogr a phi ca l Regi on
+Region
C or e:: P ow er Sy st emResour ce
C or e:: C onnect i v i t y NodeC ont a i ner
C or e:: Geogr a phi ca l Regi on +Region 0..1
+Region 0..1 0..1 +Equipments 0..* +Lines
C or e:: Equi pment
0..* P l a nt Li ne
+Substations +Substation 0..1
0..*
C or e:: Subst a t i on
+Substation
+VoltageLevels
1
0..*
C or e:: V ol t a geLev el 0..1
0..*
+Bays 0..*
+VoltageLevel
+Bays
C or e:: Bay
46
cl a ss Na mi ngHi er a r chy P a r t 2 C or e::I dent i f i edO bject
Naming and Equipment Hierarchy Part 2
+ + +
+Measurements
M ea s:: M ea sur ement
aliasName: String [0..1] mRID: String [0..1] name: String [0..1]
C or e:: 0..1 P ow er Sy st emResour ce
0..*
Ta pC ha nger
+PowerSystemResource
C or e:: Equi pment
C omposi t eSw i t ch 0..1 +CompositeSwitch
P r oduct i on::Gener a t i ngU ni t
Rot a t i ngM a chi ne +Switches
+GeneratingUnit
0..1
+SynchronousMachines
1..*
Sy nchr onousM a chi ne
0..* C or e:: C onduct i ngEqui pment
Sw i t ch
Fuse Regul a t i ngC ondEq
C onduct or
Jumper DC Li neSegment
Di sconnect or
Gr oundDi sconnect or
P r ot ect edSw i t ch
Loa dB r ea k Sw i t ch
A C Li neSegment
St a t i cV a r C ompensa t or C onnect or
Fr equency C onv er t er
B usba r Sect i on
Shunt C ompensa t or
Ener gy C onsumer B r ea k er
Junct i on
Ser i esC ompensa t or
Rect i f i er I nv er t er
Gr ound Ener gy Sour ce
47
Names cl a ss Na mes
I dent i f i edO bject + + +
aliasName: String [0..1] mRID: String [0..1] name: String [0..1]
+IdentifiedObject
1
+Names 0..* Na me +
name: String [0..1]
+Names 0..*
1 +NameType + +
Na meTy pe
+NameTypes
description: String [0..1] 0..* name: String [0..1]
Na meTy peA ut hor i t y
0..1
+NameTypeAuthority
+ +
description: String [0..1] name: String [0..1]
48
Connectivity and Topology Model
cl a ss M a i n C or e:: I dent i f i edO bject
C or e:: P ow er Sy st emResour ce
M ea s:: M ea sur ement +Measurements 0..1 C or e:: Equi pment
+Terminals
+ConductingEquipment 1
C or e:: Ter mi na l
0..* +Terminals
0..*
+Terminal 1..* +Terminal
+Terminal 0..*
+BusNameMarker 0..1
0..* C or e:: C onduct i ngEqui pment +ConnectivityNode
B usNa meM a r k er 0..1
C or e:: +ConnectivityNodes 0..* C onnect i v i t y Node
Bus/Branch bus naming specificaiton static model.
+ConnectivityNodeContainer +ConnectivityNodes
1 C or e:: C onnect i v i t y NodeC ont a i ner
0..*
0..1 +TopologicalNode 0..1 0..1 +TopologicalNode +ConnectivityNodeContainer 0..* +TopologicalNode Topol ogi ca l Node C or e:: Equi pment C ont a i ner
+TopologicalNodes
1..*
+TopologicalIsland
1
Switch/Node static Model
0..1 +AngleRef_TopologicalNode
Bus/Branch calculated Model
0..1 +AngleRef_TopologicalIsland
Topol ogi ca l I sl a nd
C ont r ol A r ea ::C ont r ol A r ea + + +
netInterchange: ActivePower [0..1] pTolerance: ActivePower [0..1] type: ControlAreaTypeKind [0..1]
49
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. Second Edition now available.
50
Example Circuit as a Single Line Diagram EnergyConsumer
ACLineSegment
Breaker Breaker
BusbarSection Breaker
GeneratingUnit
SynchronousMachine
Current measurement represented by Measurement connected to Terminal 51
Transformer Class Diagram CIM Release 15 ConductingEquipment with associations to types of TransformerEnds for electrical connectivity
Winding terminal for balanced transformer model network connection
TransformerTank added for distribution transformer windings so each phase winding could be modeled
Winding terminal for unbalanced transformer model network connection
Previously included in Winding class
52
Balanced Transformer Model
Contains legacy attributes for resistance, reactance, conductance, susceptance,
For backward compatibility, can consider as optional
53
Balanced Transformer Instance for Transformer 17-33 - Release 15 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
54
Unbalanced Distribution Transformer with Multiple Tanks Instance Example
55
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
56
WG14 CIM Packages - 61968 pk g I EC 61968Dependenci es
I EC 61968C I M V er si on + +
Loa dC ont r ol
date: Date [0..1] = 2011-08-10 version: String [0..1] = IEC61968CIM11v13
P a y ment M et er i ng
M et er i ng
A sset I nf o C ommon A sset s
C ust omer s
W or k
M ea s
(from IEC61970)
C or e
(from IEC61970)
Doma i n
(from IEC61970)
57
cl a ss C ommonO v er v i ew
IdentifiedObject
Common Concepts in 61968 CIM
+Location
Loca t i on + + + + + + + + +
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]
0..*
IdentifiedObject
0..1
C oor di na t eSy st em
+CoordinateSystem
+
crsUrn: String [0..1]
+Location
P osi t i onP oi nt
+PositionPoints
1
0..*
+ChangedLocation
+ + + +
sequenceNumber: Integer [0..1] xPosition: String [0..1] yPosition: String [0..1] zPosition: String [0..1]
0..1
IdentifiedObject O r ga ni sa t i on + + + + +
electronicAddress: ElectronicAddress [0..1] phone1: TelephoneNumber [0..1] phone2: TelephoneNumber [0..1] postalAddress: PostalAddress [0..1] streetAddress: StreetAddress [0..1]
+Organisation
+Roles
0..1
0..*
0..*
«informative»
IdentifiedObject
+ + + + + + + + +
IdentifiedObject
+ 0..* + + +ActivityRecords + +
«informative»
createdDateTime: DateTime [0..1] 0..* docStatus: Status [0..1] electronicAddress: ElectronicAddress [0..1] lastModifiedDateTime: DateTime [0..1] revisionNumber: String [0..1] status: Status [0..1] +ChangedDocument subject: String [0..1] 0..1 title: String [0..1] type: String [0..1]
0..* + +ConfigurationEvents + +
signDate: Date [0..1] validityInterval: DateTimeInterval [0..1]
A ct i v i t y Recor d
0..* +Documents
A gr eement + +
0..1
+Organisations
+ActivityRecords
Document
IdentifiedObject +ChangedOrganisationRole
O r ga ni sa t i onRol e
createdDateTime: DateTime [0..1] reason: String [0..1] severity: String [0..1] status: Status [0..1] type: String [0..1]
+ConfigurationEvents C onf i gur a t i onEv ent
0..* effectiveDateTime: DateTime [0..1] modifiedBy: String [0..1] 0..* remark: String [0..1] +ConfigurationEvents
IdentifiedObject
Ti meSchedul e + + + + +
disabled: Boolean [0..1] offset: Seconds [0..1] recurrencePattern: String [0..1] recurrencePeriod: Seconds [0..1] scheduleInterval: DateTimeInterval [0..1]
Ti meP oi nt +TimeSchedule 1
0..*
+TimePoints
+ + + + +
dateTime: DateTime [0..1] relativeTimeInterval: Seconds [0..1] sequenceNumber: Integer [0..1] status: Status [0..1] window: DateTimeInterval [0..1]
58
How The CIM Handles Location For Logical Devices And/Or The Physical Asset Performing The Device’s Role cl a ss A sset sO v er v i ew
IdentifiedObject +AssetInfo +AssetDatasheet
A sset I nf o
0..1 +AssetInfo
0..1
IdentifiedObject
IdentifiedObject
+AssetModel
A sset Funct i on
A sset M odel
0..1
+ + + + +
0..1
+PowerSystemResource
IdentifiedObject 0..*
P r oduct A sset M odel
C or e:: P ow er Sy st emResour ce +PowerSystemResources +PowerSystemResources 0..*
configID: String [0..1] firmwareID: String [0..1] hardwareID: String [0..1] password: String [0..1] programID: String [0..1]
+ + + + +
0..*
corporateStandardKind: CorporateStandardKind [0..1] +ProductAssetModel modelNumber: String [0..1] 0..* modelVersion: String [0..1] usageKind: AssetModelUsageKind [0..1] weightTotal: Weight [0..1]
+Manufacturer OrganisationRole 0..1
M a nuf a ct ur er
+Assets 0..* +Location 0..1
IdentifiedObject C ommon::Loca t i on
+ + + + + + + + +
IdentifiedObject
+Assets A sset
0..*
+ + direction: String [0..1] + electronicAddress: ElectronicAddress [0..1] +Location +Assets + geoInfoReference: String [0..1] + mainAddress: StreetAddress [0..1] 0..1 0..* + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + secondaryAddress: StreetAddress [0..1] + status: Status [0..1] + type: String [0..1] + +
+Assets
+OrganisationRoles
0..*
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] +Assets serialNumber: String [0..1] status: Status [0..1] 0..* type: String [0..1] utcNumber: String [0..1]
OrganisationRole
0..* A sset O r ga ni sa t i onRol e
A sset O w ner
0..1 +AssetContainer C omM edi a
A sset C ont a i ner
59
Types Of Document Relationship Inherited By All Assets
60
Activity Records cl a ss t mpA ct i v i t y Recor d
IdentifiedObject C ommon:: Document
+Documents 0..*
IdentifiedObject C ommon:: O r ga ni sa t i on +Organisations
0..*
IdentifiedObject «informative» A sset s::A sset +Assets +Assets 0..*
«informative»
0..*
I nf C ommon:: P er son
+ActivityRecords «informative» +ScheduledEvents 0..*
+ActivityRecords
0..*
0..* +ActivityRecords
0..*
+ErpPersons
0..*
IdentifiedObject +ActivityRecords
IdentifiedObject
C ommon::A ct i v i t y Recor d
I nf C ommon:: Schedul edEv ent
I nf O per a t i ons:: P SREv ent
IdentifiedObject
+ + + + +
I nf W or k :: W or k St a t usEnt r y
«informative» 0..*
createdDateTime: DateTime [0..1] reason: String [0..1] severity: String [0..1] status: Status [0..1] type: String [0..1]
M et er i ng:: EndDev i ceEv ent
I nf A sset s:: Fa i l ur eEv ent
I nf C ust omer s:: C ompl i a nceEv ent
61
WG16 CIM Market Extensions cl a ss M a i n
I EC 62325C I M V er si on + +
date: Date [0..1] = 2011-04-28 {readOnly} version: String [0..1] = IEC62325CIM01v07 {readOnly}
M a r k et C ommon
M a r k et O per a t i ons
M a r k et M a na gement
62
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 CIMug Sharepoint site: – Title: draft CIM16 + DCIM12 + MCIM02 – Name: iec61970cim16v13_iec61968cim12v05_iec62325cim02v05 63
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
64
Break
65