Cim U T1 S2 Saxton-cim Standards And Architecture Part 1 (1).pdf

  • Uploaded by: Fernando Rojas
  • 0
  • 0
  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Cim U T1 S2 Saxton-cim Standards And Architecture Part 1 (1).pdf as PDF for free.

More details

  • Words: 5,327
  • Pages: 64
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

Related Documents


More Documents from ""