From e44fcb97d0d86753795ba9abe64a2c2d15e65867 Mon Sep 17 00:00:00 2001 From: Admin CIMug Date: Wed, 1 May 2024 20:24:58 +0000 Subject: [PATCH] Deployed dc09839 to 1.1 with MkDocs 1.5.3 and mike 2.0.0 --- 1.1/index.html | 2 +- 1.1/search/search_index.json | 2 +- 1.1/sitemap.xml.gz | Bin 127 -> 127 bytes 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/1.1/index.html b/1.1/index.html index 84a4408..bbf923f 100644 --- a/1.1/index.html +++ b/1.1/index.html @@ -669,7 +669,7 @@

Home

CIM Modeling Guide

Version 1.1

13-February-2021

-

Click here to download the PDF release pf this version of the CIM Modeling Guide.

+

Click here to download the PDF release of this version of the CIM Modeling Guide.

Note

When referencing an offline PDF version of this guide note that it may not correspond to the latest publicly available guide. To reference the latest online see https://cim-mg.ucaiug.io.

diff --git a/1.1/search/search_index.json b/1.1/search/search_index.json index 86c05d5..975e221 100644 --- a/1.1/search/search_index.json +++ b/1.1/search/search_index.json @@ -1 +1 @@ -{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":"

UCAIug

CIM Modeling Guide

Version 1.1

13-February-2021

Click here to download the PDF release pf this version of the CIM Modeling Guide.

Note

When referencing an offline PDF version of this guide note that it may not correspond to the latest publicly available guide. To reference the latest online see https://cim-mg.ucaiug.io.

UCA International Users Group

"},{"location":"#right-to-distribute-and-credit-notice","title":"RIGHT TO DISTRIBUTE AND CREDIT NOTICE","text":"

This material was created by the UCA International Users Group CIM Model Managers and is available for public use and distribution. Please include credit in the following manner, \u201cUCAIug CIM Modeling Guide, Version 1.1, \u00a9 February 2021. All rights reserved by the UCA International Users Group\u201d.

"},{"location":"#disclaimer-of-warranties-and-limitation-of-liabilities","title":"DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES","text":"

THIS DOCUMENT is a work product of THE UCA International Users Group. it was prepared by the CIM Model Managers and approved by the UCA International Users Group leadership. NEITHER the CIM Model Managers, the UCA International Users Group leadership, the CIM users group, NOR ANY PERSON ACTING ON BEHALF OF ANY OF THEM:

(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I) WITH RESPECT TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED RIGHTS, INCLUDING ANY PARTY'S INTELLECTUAL PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S CIRCUMSTANCE; OR

(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY CONSEQUENTIAL DAMAGES, EVEN IF the UCA International Users Group OR ANY UCA International Users Group REPRESENTATIVE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR SELECTION OR USE OF THIS DOCUMENT OR ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT.

(C) Reference herein to any specific commercial process, or service by its trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the UCA International Users Group.

"},{"location":"#third-party-intellectual-property","title":"THIRD PARTY INTELLECTUAL PROPERTY","text":"

The CIM standards are a set of International Electrotechnical Committee (IEC) standards and are the Intellectual Property of the IEC. The UCA International Users Group has a Liaison D relationship with the IEC that provides access rights to the CIM standards for software development. The Common Information Model (CIM) is Open Source and is rendered in the Unified Modeling Language.

"},{"location":"#acknowledgements","title":"Acknowledgements","text":"

In preparing this specification, the UCAIug recognizes the special contributions of the following CIM Subcommittee and their organizations.

"},{"location":"#abstract","title":"Abstract","text":"

This document specifies the rules and recommendations on how to use the UML to create and maintain a standardized Common Information Model (CIM) of the electric grid and other related business domains. Such models are called Domain Models. The primary goal of this document is to facilitate communication and understanding among people working with the CIM domain models. The primary goal of the rules is to specify the structure and modeling constraints applied to the CIM. The primary goal of the recommendations is to provide guidelines on how to extend the CIM as more of the model is elaborated by working groups within the International Electrotechnical Commission (IEC) and by the CIM user community. The intent of the recommendations is to facilitate the incorporation of new model elements into the CIM.

"},{"location":"#foreword","title":"Foreword","text":"

Exchanging power systems data between utility companies is always problematic when proprietary formats are used. In the past a company would traditionally use a single software system, whether it is a custom in-house solution, or purchased from a large software company, and there would be a single proprietary data standard and format used. With the deregulation of the power industry and the emergence of smarter grids, there is now a greater need to be able to share such power system data between companies and systems.

The increase in choice provided by the number of power system software vendors and the different software packages and architectures available add to the challenge of data exchange. These issues point to a requirement for a single, open standard for describing power system data and to aid the interoperability between software packages and exchange of information both within one company and between companies.

The Common Information Model (CIM) is an open standard for representing power system components originally developed by the Electric Power Research Institute (EPRI) in North America. The CIM provides the basis of a series of standards developed under the auspices of the International Electrotechnical Commission (IEC). The CIM standard was started as part of the Control Centre Application Programming Interface (CCAPI) project at EPRI with the aim of defining a common definition for the components in power systems for use the Energy Management System (EMS) Application Programming Interface (API). The EMS API is now maintained by IEC Technical Committee 57 Working Group 13 as IEC 61970-301. The format has been adopted by the major EMS vendors to allow the exchange of data between their applications, independent of their internal software architecture or operating platform.1

"},{"location":"#about-the-uca-international-cim-users-group","title":"About the UCA International CIM Users Group","text":"

The UCA International Users Group (UCAIug) is a not-for-profit corporation focused on assisting users and vendors in the deployment of standards for real-time applications for several industries with related requirements. The UCAIug does not write standards, however it works closely with those bodies that have primary responsibility for the completion of standards (notably IEC TC 57: Power Systems Management and Associated Information Exchange).

The UCAIug as well as its member groups (the CIM Users Group (CIMug), Open Smart Grid, and IEC61850) draws its membership from utility user and supplier companies. The mission of the UCAIug is to enable integration through the deployment of open standards by providing a forum in which the various stakeholders in the energy and utility industry can work cooperatively together as members of a common organization to:

This document is a work product produced by the CIM Subcommittee with the intent to help accomplish the UCAIug mission.

  1. \"Common Information Model Primer: Eighth Edition\u201d; EPRI, Palo Alto, CA: 2022 EPRI 3002001040 \u21a9

"},{"location":"revision-history/","title":"Revision History","text":"Rev. # Rev Date Author Description 1.0 25-Nov-2019 H. Dotson, et al. Initial Release 1.1 13-Feb-2021 H. Dotson, et al. Update to Rule 197"},{"location":"section1-introduction/","title":"Introduction","text":""},{"location":"section1-introduction/#document-overview","title":"Document Overview","text":"

The CIM has been growing and more groups are extending it with new functionality. Currently the following IEC TC57 working groups are working with the CIM:

Initially only WG13 and WG14 were working with the CIM. Each group worked with a local copy of the UML model file and the two copies were synchronised as needed. With three working groups the synchronisation process becomes more complex. This document describes how to manage CIM across multiple working groups and provides best practices for applications wanting to extend the CIM.

"},{"location":"section1-introduction/#document-purpose","title":"Document Purpose","text":"

The purpose of this document is to provide guidance to individuals working with the CIM UML on how to modify the CIM in accordance with the CIM modeling rules and CIM change management. The rules and process are maintained and enforced by the CIM model managers.

The goals of this document are to: 1) facilitate communication and understanding among individuals working with CIM domain models; and 2) streamline the incorporation of new content into the CIM UML.

"},{"location":"section1-introduction/#document-scope","title":"Document Scope","text":"

The scope of this document includes providing:

1) A description of the items under CIM Management;

2) A description of the CIM Management processes;

3) Rules and recommendations for CIM UML modeling

4) Rules and recommendations for CIM UML extension;

5) Rules and recommendations for transforming CIM UML into a canonical model in preparation to create CIM Profiles;

6) A description of the process for submitting CIM UML extensions, UML used in the user-defined profiles for incorporation into the CIM UML and the IEC CIM standards, respectively;

7) A description of the UML tool (Sparx EA) used for CIM Management.

"},{"location":"section1-introduction/#what-this-document-does-not-cover","title":"What this Document Does Not Cover","text":"

This Document Does Not Cover All UML Concepts

The CIM UML uses a subset of the UML concepts. This document only covers the UML concepts relevant to the CIM UML.

This Document Does Not Cover How the CIM UML Rules Evolved

The CIM UML rules have evolved over time and it is not the intent of this document to discuss the history of their evolution. The intent of this document is to specify the CIM UML rules in clear unambiguous language. It is the goal of this document to communicate the rules in such a way that the rationale for each rule is self-evident. The exception is the discussion of CIM UML version control in section 8.

This Document Does Not Cover How Each Working Group Develops Additional CIM UML Content

The methodologies and practices used by each IEC working group to develop additional CIM UML content is not in the purview of CIM Management. The output of the working groups do trigger some of the CIM Management processes, and these triggers are identified in this document.

This Document Does Not Cover Detailed Tool Procedures Used To Accomplish CIM Management Tasks

The detailed tool procedures used to accomplish CIM Management tasks are not in the purview of CIM modeling. This document does identify what tool is used to accomplish each CIM Management process activity. This document does provide the step by step procedures for exporting and importing the CIM model in XMI format. CIM Management tasks are discussed in the CIM Management Process and Procedures document.

This Document Does Not Cover Tools Used To Create CIM Profiles

The tools used to create CIM Profiles are not in the purview of CIM Management. This document does provide rules and recommendations for transforming the CIM UML (a semantic information model) into a canonical data model that can then be used as input to a tool to create CIM Profiles.

"},{"location":"section1-introduction/#who-this-document-is-for","title":"Who this Document Is For","text":"

This document has the following intended audience:

Target Audience

Secondary Audience

"},{"location":"section1-introduction/#how-this-document-is-organized","title":"How this Document Is Organized","text":"

This document begins with Sections 1, 2, and 3 providing introductory content, references, and definitions, respectively.

Section 4 is an overview of CIM Management. This section provides the business context for CIM Management within the UCAIug organizational structure (the \u201cWhere\u201d of CIM Management), and the roles and responsibilities (the \u201cWho\u201d and \u201cWhat\u201d) of CIM Management. The section also provides an overview of the CIM Management processes (the \u201cHow\u201d of CIM Management) performed by CIM model managers, and how the CIM Management processes integrate with the IEC standards development process.

Section 5 specifies CIM UML modeling rules and recommendations. This section covers rules and recommendations for the model structure, packages, classes, attributes, associations, enumerations, inheritance, diagrams, element descriptions, stereotypes, namespaces, and documentation (the \u201cHow To\u201d of CIM UML development within the working groups).

Section 6 specifies CIM extension rules and recommendations. This section contains general extension rules and covers rules and recommendations for package extension, class extension, attribute extension, association extension, and enumeration extension (the \u201cHow To\u201d of CIM extension).

Section 7 specifies CIM UML transformation rules. This section contains general schema profiling rules and rules for RDFS and XSD profiling.

Section 8 describes CIM UML version control. This section provides an overview of version control and the CIM UML version control strategy.

Section 9 identifies and describes the artifacts under CIM Management. This includes CIM UML artifacts, CIM Profiles, draft standards, CIM Management process artifacts, and CIM Management tool customizations.

Section 10 discusses the tools used for CIM UML model management. Tools include Enterprise Architect, jCleanCIM, and the CIMug Website.

"},{"location":"section1-introduction/#symbols-figures-and-style-conventions","title":"Symbols, Figures, and Style Conventions","text":"

Conventions

This document uses the following conventions.

Symbol Legend

This document contains a series of diagrams that are referred to as figures. The primary symbols used throughout all figures are individually described in the following symbol legend:

UML Notation

The Unified Modeling Language is used

Text Formats

  1. Bold text is used to identify a term that can be found in the glossary. The term will be in bold text the first time it is used in the document. All subsequent uses of the term will be in normal text.

  2. Square brackets ([ ]) are used as delimiters for referenced works cited in this document.

"},{"location":"section1-introduction/#document-control","title":"Document Control","text":"

This document will be reviewed periodically by the CIM Model Managers and updated as needed. Lessons learned will be captured with each CIM UML update and used to improve this document. If the document is written in an older format, the document should be revised into the latest CIM Users Group template format.

This document contains a revision history log. When changes occur, the version number will be updated to the next increment and the date, author making the change, and change description will be recorded in the revision history log of the document.

"},{"location":"section10-cim-management-tools/","title":"CIM Management Tools","text":"

This section gives a brief description of the software tools used to help carry out the responsibilities of CIM Management.

"},{"location":"section10-cim-management-tools/#sparx-enterprise-architect","title":"Sparx Enterprise Architect","text":"

Sparx Systems Enterprise Architect modeling tool is the tool used to maintain the CIM UML. CIM Management leverages the tool support for partitioning a model into several model files, which allows working groups to develop top-level package model content separately, and then merge the model changes into a complete version of the CIM UML.

Enterprise Architect can also be used to generate CIM Profiles with its Schema Composer tool.

"},{"location":"section10-cim-management-tools/#cimtool","title":"CIMTool","text":"

CIMTool is an open source tool for working with the CIM to produce design artifacts such as database schemas, RDF Schema, XSD Schema, JSON Schema, source code classes, reference documentation, etc. from a contextual profile.

"},{"location":"section10-cim-management-tools/#jcleancim","title":"jCleanCim","text":"

jCleanCim is a Java application that is used to auto generate draft model standards from the CIM UML. It uses a Word document template, a configuration file, and a CIM UML project file to create the 61970-301, 61968-11, and 62325-301 model documents.

"},{"location":"section10-cim-management-tools/#cimug-website","title":"CIMug Website","text":"

The CIMug website serves as the tool that provides online access to artifacts under CIM Management. The CIMug website provides unrestricted access to the CIM UML and controlled access (security credentials required) to artifacts that fall under the Liason D relationship UCA has with the IEC.

"},{"location":"section2-references/","title":"References","text":""},{"location":"section2-references/#normative-references","title":"Normative References","text":"

The following IEC documents, and the other identified references herein contain information which, through reference in this text, constitute normative provisions of this document. At the time of publication, the editions indicated were valid. All IEC documents, and other normative references are subject to revision. All users of this document are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below.

Document ID Document Description IEC61968-2 IEC61968 Part 2: Glossary IEC62357-1 TC 57 Architecture Part 1: Reference Architecture for Power System Information Exchange IETF001 Internet Engineering Task Force Request for Comments 2119 (RFC2119). March 1997. TC57-Glossary IEC TC57 Glossary UML-2.5.1 Unified Modeling Language Specification Version 2.5.1. Object Management Group December 2017"},{"location":"section2-references/#informative-references","title":"Informative References","text":"

The following documents referenced herein contain information which is not binding and does not constitute provisions of this document. The information referenced in this text is informative and supportive information intended to enhance the comprehension of this document.

Document ID Document Description CIM_Primer Common Information Model (CIM) Primer: Eighth Edition, EPRI 3002024188, April 2022 ERL001 Web Service Contract Design and Versioning for SOA, Prentice Hall, 2009 IEC61968-1 IEC 61968-1:2020 - Interface Reference Model UML001 The Unified Modeling Language Reference Manual, Addison-Wesley, 1999"},{"location":"section3-definitions/","title":"Definitions","text":"

For the purposes of this document the following definitions apply:

Term Definition Artifact Distribution Process The process used to ensure comprehensive distribution of artifacts under CIM management to CIMug repositories and other subscribers of those artifacts. Backwards Compatibility The capability of a new version of the CIM UML to continue to support CIM Profiles designed to work with the old version of the CIM UML. Canonical Data Model See \u201cContextual Data Model\u201d CIM Model Manager An individual that has overall responsibility for an IEC CIM Working Group\u2019s artifacts under CIM management. A CIM Model Manager is a member of both the CIMug and an IEC Working Group CIM Profile A subset of the full CIM UML that is derived to define data exchanges required between systems. CIM Users Group (CIMug) A subgroup of the UCA International Users Group established to provide a forum in which users, consultants, and suppliers can cooperate and leverage the IEC CIM international standards to advance interoperability between utility enterprise systems. Committee Draft (CD) The first working draft of an IEC standard that is available for circulation to the members of the IEC TC57. Committee Draft for Vote (CDV) The draft of an IEC standard that has incorporated changes to the CD after addressing comments received from national committees about the CD. Common Information Model (CIM, CIM UML) An open source semantic information model expressed in the Unified Modeling Language (CIM UML) representing real-world electric utility objects and information entities, and the relationships between them (sometimes called a \u201cdomain model\u201d). The CIM UML also represents the properties of the concepts as UML class attributes. Compatible Change When the changes incorporated in a new version of the CIM UML do not negatively affect existing CIM Profiles, then the change itself is considered a compatible change. Conceptual Data Model See \u201cSemantic Information Model\u201d Configuration Management (CM) The function of managing changes to the CIM UML and other work products performed by CIM Model Managers. Configuration Management Plan (CMP) A plan developed to define, document, control, implement, account for, and audit changes to the various CIM configuration items. The CMP provides information on the requirements and procedures necessary for CM activities and establishes the methodology for configuration identification and control of released and changes to configuration items. The CMP also describes the process for maintaining status accounting and verifying the completeness and correctness of configuration items throughout the CIM UML development life cycle. Contextual Data Model A subset of CIM elements constrained for a specific business context for use in a data exchange between systems. Continuous Process Improvement (CPI) The ongoing process of improving the CIM management process through incremental and breakthrough improvements. The goal of CPI is to improve the quality of the CIM UML or the efficiency of the CIM management process. DER Distributed Energy Resource DERMS Distributed Energy Resource Management System Document Generation (DG) The function performed by CIM Model Managers in which CIM UML based draft IEC standards are auto generated using jCleanCIM and a document template. eap The filename extension given to a Sparx Enterprise Architect project file stored in a proprietary file format in a computer file system. eapx The filename extension given to a Sparx Enterprise Architect project file stored as an XML document in a computer file system. Electric Power Research Institute (EPRI) An independent, nonprofit organization for public interest energy and environmental research. EPRI conducts research, development, and demonstration projects for the benefit of the public in the United States and internationally. EPRI focuses on electricity generation, delivery, and use in collaboration with the electricity sector, its stakeholders and others to enhance the quality of life by making electric power safe, reliable, affordable, and environmentally responsible. Energy Management System (EMS) A software application used by operators of electric utility grids to monitor, control, and optimize the performance of a transmission network. eXtensible Markup Language (XML) A universal format for structured documents and data. XML documents are used to exchange structured data between utility systems. Final Draft International Standard (FDIS) The draft of an IEC standard that has incorporated changes to the CDV after addressing comments received from national committees about the CDV. The FDIS documents the completed version of the new standard to be circulated for approval by the national committees. Forwards Compatibility The capability of a new version of the CIM UML to support a range of future CIM Profiles. The extent of forwards compatibility is defined by the number of new use case interactions that can be supported with the new CIM UML. Governance The organizational structure, processes and policies by which the CIM UML is developed, deployed, and maintained. CIM model managers are responsible for governance of the CIM UML. Incompatible Changes Changes to the CIM UML that results in the new CIM UML no longer being compatible with existing CIM Profiles. International Electrotechnical Commission (IEC) A global organization that publishes consensus-based International Standards and manages conformity assessment systems for electric and electronic products, systems and services, collectively known as electrotechnology.The IEC\u2019s role is to facilitate the complicated process of reaching agreement (consensus) among the many experts from countries all over the world who volunteer to prepare the rules, specifications and terminology that allow manufacturers to build devices that work together, safely and as expected. International Standard (IS) The published version of an IEC international standard. IETF Internet Engineering Task Force. The Internet Engineering Task Force is an open standards organization, which develops and promotes voluntary Internet standards, in particular the standards that comprise the Internet protocol suite. jCleanCIM A java application that is used to auto generate draft model standards from the CIM UML. Model Change Implementation (MCI) The function of making changes to an existing CIM UML baseline to create a new CIM UML baseline performed by CIM Model Managers. Model Change Management (MCM) The function of identifying and managing CIM UML change requests performed by CIM Model Managers. Model Change Management Plan (MCMP) A documented plan to define, document, and track the information required to effectively manage change requests throughout the CIM UML development life cycle. Model Change Validation (MCV) The function of ensuring proposed CIM UML changes are in compliance with CIM modeling rules performed by CIM Model Managers. Model Development (MD) The function of developing new model elements and updating existing model elements performed by IEC Working Group members. Model Distribution (MD) The function of distributing CIM UML baselines to official repositories and authorized consumers of the CIM UML performed by CIM Model Managers. Namespace Prefix (nsprefix) A proxy for a namespace. Namespace prefixes are mapped to a namespace in the XML declaration of the namespace using a special attribute that starts with the letters xmlns. New Work Item Proposal (NWIP) A proposal for new IEC standard development work. The NWIP is the first work product created in the development of a new IEC standard. Preliminary Work Item (PWI) The work item produced during the Preliminary Stage of the IEC standard development process. The Preliminary Stage is applied for work items where no target dates can be established. This stage can be used for the elaboration of a New Work Item Proposal and the development of an initial draft. Release A release is the distribution of a baseline version of the CIM UML. A release may be either public or private (sent only to IEC Working Groups) and generally constitutes the initial generation of a new or upgraded model elements. Resource Description Framework (RDF) An XML schema used to provide a framework to create peer-to-peer relationships between data elements in an XML format (XML nodes). Resource Description Framework Schema (RDFS) A vocabulary for describing properties and classes of RDF resources and how those resources are linked in peer-to-peer relationships. Semantic Information Model A method of structuring information in order to represent it in a specific logical way. It is a conceptual data model that includes semantic information that adds a basic meaning to the data and the relationships between data concepts. The CIM UML is a semantic information model. Sparx Enterprise Architect (Sparx EA) The brand name for modeling tool used to host the CIM UML. Sparx Systems in the company that developed, maintains, and sells the tool. Technical Committee 57 (TC57) The technical committee of the IEC whose purpose is to prepare international standards for power systems control equipment and systems, and associated information exchange for real-time and non-real-time information used in the planning, operation and maintenance of power systems. UCA Utility Communications Association (see UCAIug) UCA International Users Group (UCAIug) A not-for-profit corporation focused on enabling utility domain system integration through the deployment of open standards, by providing a forum in which the various stakeholders in the energy and utility industry can work cooperatively together as members of a common organization. UML Association The semantic relationship between two or more classes. UML Attribute A named property of a class that describes a range of values that instances of that property may hold. UML Class A description of a set of objects that share the same attributes, relationships, and semantics. UML Class Diagram A diagram that shows a set of classes and their relationships; class diagrams address the static design view of a system. UML Enumeration Literal A named value that is part of a list of named values used as the range of a particular type. UML Inheritance The mechanism by which more-specific elements incorporate the structure of more-general elements. UML Multiplicity A specification of the range of allowable cardinalities that a set may assume; multiplicity is specified for attributes and associations. UML Namespace A scope in which names may be defined and used; within a namespace, each name denotes a unique element. UML Stereotype An extension of the vocabulary of the UML, which allows you to create new kinds of building blocks (classes) that are derived from existing ones but that are specific to your problem. Unified Modeling Language (UML) A graphical modeling language for visualizing, specifying, constructing, and documenting the artifacts of a software intensive system. The UML provides a collection of graphical model elements that have semantic meaning, and the rules for combining model elements for the purpose of communicating the conceptual and physical representation of a system. Universal Resource Identifier (URI) A sequence of characters that identifies the name and location of a file or resource in a uniform format. URIs provide a standard way for resources to be accessed by other computers across a network or over the World Wide Web. Version Control Strategy A specification of how versioning is implemented and communicated. Web Ontology Language (OWL) A language used to explicitly represent the meaning of terms in vocabularies and the relationships between those terms in machine interpretable content on the Web. Working Draft (WD) A draft version of an IEC standard that documents work in progress being performed by a working group project team. Working drafts by definition are incomplete and not available for circulation to the members of TC57. Working Group A group of individuals that collectively work to further develop the CIM UML and CIM based standards. Working Group 13 (WG13) The IEC TC57 working group responsible for developing standards for information exchange among systems supporting business functions directly involved with operation and planning of the overall interconnected electric grid. Working Group 14 (WG14) The IEC TC57 working group responsible for developing standards for information exchange among systems supporting business functions that support power system operations, maintenance and customer support. Working Group 16 (WG16) The IEC TC57 working group responsible for developing standards which facilitate the integration of electricity market application software developed independently by different vendors into a market management system, between market management systems and market participant systems. Working Group 21 (WG21) The IEC TC57 working group responsible for developing standards for system interfaces, communication protocols and profiles for industrial, home and building automation; and for retail markets, real time pricing, and traditional non-market load management. XML Metadata Interchange (XMI) An Object Management Group (OMG) standard for exchanging metadata information via Extensible Markup Language (XML). XML Schema Definition (XSD) An XML document that uses the XML Schema Definition Language to define the structure of CIM message payloads and CIM message headers."},{"location":"section4-cim-overview/","title":"CIM Overview","text":"

Background

Since international deregulation of energy markets began in the 1990\u2019s, the need for electric utility companies to exchange data externally on a regular basis, and internally between software applications, has steadily increased. The exponential growth in integration complexity due to the large number of proprietary application interfaces created a significant risk to the reliable operation of an interconnected electric power grid owned and operated by different electric utility companies. This business concern was the driver for a common format for all data exchanges in the electrical power domain.

This business driver led to the need for:

  1. a semantic information model that represents all of the real-world and information entities (concepts) in the electric power domain and the relationships between them; and
  2. a canonical data model to provide a non-proprietary way to exchange data between utility domain systems and databases.

The Common Information Model (CIM) is an open source semantic information model expressed in the Unified Modeling Language (CIM UML) representing real-world electric utility objects and information entities, and the relationships between them (sometimes called a \u201cdomain model\u201d). The CIM UML also represents the properties of the concepts as UML class attributes. The CIM UML model is hosted and maintained in a Sparx Systems Enterprise Architect Project by the UCAIug.

The IEC Technical Committee 57 (IEC TC57) CIM working groups develop a set of standards to enable electric power systems integration and information exchange based on the CIM UML. New model content provided by members of either the IEC TC57 CIM working groups or the UCAIug is formally incorporated into the CIM UML. These members volunteer their time and subject matter expertise to accomplish the goals of each organization.

The IEC publishes international standards derived directly from the CIM UML for each IEC TC57 CIM working group. The IEC also publishes international standards derived from canonical data models that constrain fragments of the CIM UML for specific data exchanges between utility domain systems and databases. These international standards for data exchange are called \u201cCIM Profiles\u201d.

In recent years, the IEC TC57 has come under increasing pressure from utility companies and vendors to release new versions of the CIM-based standards more quickly in order to respond to the transformative changes occurring in the industry. UCAIug leadership has determined that in order to reduce the time to market of new standards, updates to the CIM must occur often enough to support the release of new versions of the IEC TC57 standards once a year while simultaneously expanding the organization\u2019s ability to effectively manage a higher volume of content change to the CIM UML.

In order to achieve these two goals, the UCAIug leadership has decided that the UCAIug can best improve its effectiveness in these areas by:

  1. aligning CIM UML Management processes with the IEC fast track International Standard release process;
  2. facilitating communication and understanding among individuals working with CIM UML domain models; and
  3. facilitating the incorporation of new content into the CIM UML.

For the past two years the IEC TC57 CIM working groups have emphasized the importance (to their productivity) of having access to documented rules and recommendations for creating new CIM content. Up until the release of this document, CIM management guidelines resided in draft documents owned by CIM Model Managers.

"},{"location":"section4-cim-overview/#cim-uml-scope","title":"CIM UML Scope","text":"

The CIM UML is semantic information model that represents real-world physical electric grid objects and information entities. The CIM UML is the basis for data that is exchanged between systems to:

  1. enable grid operation and planning;
  2. support grid operations, grid maintenance, and customer support;
  3. support wholesale electricity market activity between market participants; and
  4. support interfaces with non-utility owned systems connected on the other side of the meter to the grid. The CIM UML is used by IEC TC57 CIM working groups as the foundation for creating CIM profiles. The mission statement for each IEC TC57 CIM working group is provided in Table 4\u20111.

Table 4\u20111. IEC TC57 CIM Working Group Mission Statements

Group ID Mission Statement WG13 Define standards for information exchange among systems supporting business functions directly involved with operation and planning of the overall interconnected electric grid. These functions rely on power system network models to analyse the behaviour of the grid. These business functions cover the entire interconnected grid at all voltage levels, and they often involve interactions between systems at various different participants in the grid (e.g. RTO, TSO, DSO, microgrid, generator, consumer). WG14 Define standards for information exchange among systems supporting business functions that support power system operations, maintenance and customer support. This includes major business functions such as asset management, work management, meter data management, customer information, geographic information systems and engineering design. Also included is interoperating with assets and business capabilities governed by interconnection agreements with customers. WG16 Define standards which facilitate the integration of electricity market application software developed independently by different vendors into a market management system, between market management systems and market participant systems. This is accomplished by defining message exchanges to enable these applications or systems access to public data and exchange information independent of how such information is represented internally. WG21

Define standards for system interfaces, communication protocols and profiles in consideration of:

"},{"location":"section4-cim-overview/#cim-management-business-context","title":"CIM Management Business Context","text":"

CIM Management is a business function performed by the CIM Subcommittee of the UCAIug Technical Oversight Committee (see Figure 4\u20111).

Figure 4\u20111. UCA International Users Group Organization Chart

The CIM Technical Subcommittee is responsible for handling all technical and maintenance issues concerning the CIM and related standards. Responsibilities of the CIM Subcommittee related to CIM Management include:

  1. Chair Modeling Meetings

    • Review model updates submitted by working groups with working group representative(s)

  2. Manage the CIM Issues Process

    • Compile and categorize issues

    • Develop proposed resolutions

    • Obtain agreement on resolutions from CIM Technical Subcommittee and IEC TC57 WG13, WG14, WG16 and WG21.

  3. Manage Versions of CIM Artifacts

    • Provide version management of the CIM UML model

    • Provide version management of derived files in other formats (e.g., XML, RDF, etc.)

  4. Maintain Oversight of CIM Support Tools

    • Maintain oversight of which version of Sparx Enterprise Architect is used to maintain the CIM UML.

    • Maintain oversight of the jCleanCIM tool used for validation of the CIM UML model.

  5. Maintain CIM Repositories

    • Maintain repositories for artifacts produced by individual projects implementing the CIM and related standards, such as:

    • submitted CIM extensions;

    • message payload definitions;

    • tools, and;

    • training materials.

    • Maintain repositories for sample CIM/XML/RDF power system model files

"},{"location":"section4-cim-overview/#cim-management-functions","title":"CIM Management Functions","text":""},{"location":"section4-cim-overview/#model-change-management","title":"Model Change Management","text":"

Model change management (MCM) is the ongoing process of identifying and managing CIM UML change requests. A model change management plan (MCMP) is developed to define, document and track the information required to effectively manage change requests throughout the CIM UML development life cycle.

"},{"location":"section4-cim-overview/#model-change-validation","title":"Model Change Validation","text":"

Model change validation (MCV) is the ongoing process of ensuring proposed CIM UML changes are in compliance with CIM modeling rules.

"},{"location":"section4-cim-overview/#model-change-implementation","title":"Model Change Implementation","text":"

Model change implementation (MCI) is the ongoing process of making changes to an existing CIM UML baseline to create a new CIM UML baseline.

"},{"location":"section4-cim-overview/#configuration-management","title":"Configuration Management","text":"

Configuration management (CM) is the ongoing process of identifying and managing changes to the CIM UML and other work products. A configuration management plan (CM Plan) is developed to define, document, control, implement, account for, and audit changes to the various CIM configuration items. The CM Plan provides information on the requirements and procedures necessary for CMP activities and establishes the methodology for configuration identification and control of releases and changes to configuration items. It also describes the process for maintaining status accounting and verifying the completeness and correctness of configuration items throughout the CIM UML development life cycle.

"},{"location":"section4-cim-overview/#model-distribution","title":"Model Distribution","text":"

Model distribution (MD) is the ongoing process of distributing CIM UML baselines to official repositories and authorized consumers of the CIM UML.

"},{"location":"section4-cim-overview/#continuous-process-improvement","title":"Continuous Process Improvement","text":"

Continuous process improvement (CPI) is the ongoing process of improving the CIM management processes through incremental and breakthrough improvements. The goal of CPI is to improve the quality of the CIM UML or the efficiency of the CIM management processes.

"},{"location":"section4-cim-overview/#cim-management-function-mappings","title":"CIM Management Function Mappings","text":"

Mapping of the CIM management functions includes two (2) mappings of the CIM management functions. The first shows the mapping between CIM management functions and CIM management responsibilities assigned to the CIM Subcommittee with the UCAIug. The second shows the mapping between CIM management functions and the CIM management processes that realize those functions. The first mapping is shown in Figure 4\u20112. The second mapping is discussed in Section 4.4 and shown in Figure 4\u20119

Figure 4\u20112. CIM Management Functions-to-UCA CIM Responsibilities Mapping

"},{"location":"section4-cim-overview/#cim-management-processes","title":"CIM Management Processes","text":"

CIM management processes are the realization of CIM management functions. There are five (5) CIM management processes. The CIM management processes are shown in Figure 4\u20113. A list of the processes and their descriptions are provided in Table 4\u20112.

Figure 4\u20113. CIM Management Processes

Table 4\u20112. CIM Management Processes

Process Process Description Model Development The model development process is the core CIM UML process. It is executed to extend the CIM UML and create a new baseline of the CIM UML. This process is triggered by any one of the roles that is responsible for model development. The model development process flow is shown in Figure 4\u20114. CIM Management is performed as part of the \u201cVerify Extended Model\u201d subprocess. Change Management The Change Management Process establishes an orderly and effective procedure for tracking the submission, coordination, review, evaluation, categorization of change requests, and approval for release of changes to CIM UML baselines. The Change Management Process is shown in Figure 4\u20115. Changes can either be modifications to existing model elements or the creation of new model elements. Document Generation The document generation process involves the creation of the document artifacts associated with the CIM. The CIM UML is used to create these documents as exemplified in Figure 4\u20116. CIM Profiles (including RDF and XML schemas) are generated by the IEC working groups. CIM Model Managers may assist working groups in creating RDF and XML schemas. All other artifacts under CIM Management are generated by CIM Model Managers. Artifact Distribution The artifact distribution process ensures comprehensive distribution of artifacts under CIM management (see Section 8 for details) to CIMug repositories and other subscribers of those artifacts. The artifact distribution process flow is shown in Figure 4\u20117. Continuous Process Improvement The continuous process improvement process establishes a sequence of activities for incremental improvement of the change request and model distribution processes with the goal of improving the quality of the CIM UML or the efficiency of the CIM management processes. The continuous process improvement process is shown in Figure 4\u20118.

Figure 4\u20114. Model Development Process Flow

Figure 4\u20115. Change Management Process

Figure 4\u20116. Document generation from CIM UML

Figure 4\u20117. Artifacts Distribution Process Flow

Figure 4\u20118. Continuous Process Improvement Process Flow

"},{"location":"section4-cim-overview/#cim-management-process-mappings","title":"CIM Management Process Mappings","text":"

The mapping between CIM management functions and the CIM management processes are shown in Figure 4\u20119.

Figure 4\u20119. CIM Management Process-to-CIM Management Functions Mapping

The CIM Model Managers perform most of the tasks within the CIM management processes. There are however, other roles within the CIMug and IEC working groups that also perform CIM management tasks. The following table provides a description of each role and its mapping to CIM management processes.

Role Role Description MDP CMP DGP ADP CPIP CIMug Focus Community This group role consists of individual CIMug members and IEC CIM Working Group members dedicated to developing CIM extensions that deal with a specific area of focus. X CIMug Project Team This group role consists of individual CIMug members and IEC CIM Working Group members working on projects that are jointly funded by participating utilities or vendor companies. X CIMug Working Group This group role consists of individual CIMug members working on issues of common interest to CIM Users. X IEC CIM Working Group This group role consists of individuals appointed by their respective IEC National Committee (technical experts) that take part in the drafting of IEC standard working documents. X X IEC Working Group Project Leader This individual role performed by an IEC Working Group member has overall responsibility for leading the development of a new edition of an international standard from the IEC proposal stage through to the IEC publication stage. X X IEC Working Group Convener This individual role performed by an IEC Working Group member is responsible for arranging and leading face-to-face IEC Working Group meetings and providing working group oversight. X X Model Manager This individual role performed by an individual that is a member of both the CIMug and an IEC Working Group has overall responsibility for artifacts under CIM management. X X X X X

Table 4\u20113. Role-to-CIM Management Process Mapping

"},{"location":"section4-cim-overview/#cim-management-process-integration-with-the-iec-standards-process","title":"CIM Management Process Integration with the IEC Standards Process","text":""},{"location":"section4-cim-overview/#iec-standards-development-process","title":"IEC Standards Development Process","text":"

As IEC standards, the CIM standards must go through the IEC international standards development process to be published. An IEC International Standard is the result of an agreement between the National Committees of the IEC. The IEC standard development process and the documents created in the process are shown in Figure 4\u201110. A description of the IEC stages is provided in Table 4\u20114.

Figure 4\u201110. IEC International Standard Development Process

Table 4\u20114. Description of IEC Standard Development Stages.

Stage Stage Description Preliminary Stage The preliminary stage is applied for work items where no target dates can be established. This stage can be used for the elaboration of a new work item proposal and the development of an initial draft. These work items are subject to approval in accordance with the normal procedures before progressing to the preparatory stage. Proposal Stage The proposal stage is the first step in creating a new standard. During this stage a working group generates a proposal for new work. The output of this stage is a New Work Item Proposal (NWIP). The NWIP is submitted via a National Committee to the IEC and communicated to the members of the appropriate IEC CIM working group. Preparatory Stage

During this stage a Working Draft (WD) is prepared, generally by a project leader within a project team. The availability of working draft (if not supplied with the proposal) is 6 months.

The preparatory stage ends when a working draft is available for circulation to the members of the technical committee or subcommittee as a first committee draft (CD) and is registered by the office of the CEO.

Committee Stage The committee stage is the principal stage at which comments from National Committees are taken into consideration, with a view to reaching consensus on the technical content. Enquiry Stage After addressing the comments received from national committees about the CD the working group then prepares an updated version of the standard that is issued as a Committee Draft for Vote (CDV). This is circulated to member countries for a five-month voting period and is considered approved if two thirds of the votes cast are in favor and the number of negative votes does not exceed 25% of the votes cast. At this stage countries may still submit comments along with their vote. Approval Stage

The working group, once again, addresses any comments that have been received and prepares a Final Draft International Standard (FDIS). This is submitted to the IEC Central Office and circulated to the national committees for a two-month voting period. At this stage a country may only make an explicit vote: positive, negative or abstention.

The FDIS is approved if two thirds of the votes cast are in favor and the number of negative votes cast does not exceed 25% of the votes cast. If approved, the document is published however if the conditions are not met it is referred back to the working group to be revised. Final publication is the responsibility of the IEC Central Office and leads to the publication of an international standard. This normally takes place within two months of the approval of the FDIS.

Publication Stage

This stage is entirely the responsibility of the Central Office and leads to publication of the International Standard, normally within 6 weeks of approval of the FDIS.

Once a final draft International Standard has been approved, only minor editorial changes are introduced into the final text. The International Standard is published within 6 weeks of approval of the FDIS.

"},{"location":"section4-cim-overview/#process-integration-points","title":"Process Integration Points","text":"

The CIM management processes integrate with the IEC standards development process because the CIM UML provides the basis for IEC CIM standards. There are two types of integration points between the two processes: 1) draft standards preparation; and 2) draft standards submission.

A mapping between the applicable IEC standards development stages and the CIM Management processes are provided in Table 4\u20115.

Table 4\u20115. CIM Management Processes-to-IEC Standard Development Stage Mappings

Proposal Stage Preparatory Stage Committee Stage Enquiry Stage Approval Stage Publication Stage Model Development Process X X X X X Change Management Process X X X X X Document Generation Process X X X Artifact Distribution Process X X X X X"},{"location":"section4-cim-overview/#draft-standards-preparation","title":"Draft Standards Preparation","text":"

The intermediate draft standards submitted to the IEC are produced during the execution of the Model Development process and the Document Generation process. CIM UML changes are incorporated to form the basis of the draft standards. Therefore, the Change Management process is also part of draft standards preparation.

"},{"location":"section4-cim-overview/#draft-standards-submission","title":"Draft Standards Submission","text":"

The submission of the draft standards to the IEC takes place during the Artifact Distribution process. The IEC is considered one of the subscribers for the draft standards in the process.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/","title":"CIM UML Modeling Rules and Recommendations","text":""},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#overview","title":"Overview","text":"

This section describes rules and recommendations on how to use the UML to model electric utility domain information. The UML does not include a step-by-step model development process. It is a general-purpose modeling language that all modelers can use. The primary goal behind CIM UML modeling rules and recommendations is to ensure a well-formed, consistent semantic information model is maintained in order to facilitate communication and understanding among people working with the CIM.

Due to the evolving nature of the CIM, there are notable rule exceptions throughout the CIM UML. The rationale for retaining exceptions include:

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#uml-concepts-used-in-the-cim","title":"UML Concepts Used in the CIM","text":"

The CIM uses a very small subset of UML concepts. UML concepts and models can be grouped into the following concept areas: 1) static structure; 2) dynamic behavior; 3) implementation constructs; 4) model organization; and 5) extensibility mechanisms. The CIM only uses UML concepts in the static structure and model organization concept areas.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#uml-static-structure-concepts","title":"UML Static Structure Concepts","text":"

The CIM uses UML concepts that model utility domain concepts, their internal properties, and their relationships to each other. Utility domain concepts are modeled as classes, each of which describes a set of discrete objects that hold information. Utility domain concept properties are modeled as class attributes. The relationships between utility domain concepts are modeled as class associations or generalisations. Many classes share common structure using generalisation. Static structure concepts are viewed using class diagrams.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#uml-model-organization-concepts","title":"UML Model Organization Concepts","text":"

The CIM uses UML packages to organize modeling information. Packages are general-purpose hierarchical organizational units of UML models. The purpose of packages in the CIM is mainly for controlling working group ownership, with sub-packages mainly representing conceptual organization. This usage of the package structure allows for relatively easy movement of classes among packages without impacting concrete implementations. It also defines the area of responsibility for model managers.

The CIM also uses UML dependencies among packages to impose an overall model architecture. The contents of the packages must conform to the package dependencies and to the imposed model structure.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#model-structure-rules","title":"Model Structure Rules","text":"

Model structure rules address UML metamodel rules, and the structure, dependencies, and assembly of CIM packages.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#uml-metamodel-rules","title":"UML Metamodel Rules","text":"RuleID Description Rule001

The CIM shall be limited to the following UML metamodel elements:

  1. Packages;

  2. Classes

  3. Attributes;

  4. Associations;

  5. Enumerated Literals;

  6. Multiplicities;

  7. Inheritance;

  8. Diagrams;

  9. Description of UML elements;

  10. Namespaces;

  11. Specified package stereotypes and

  12. Specified class stereotypes.

Rule002 The UML element unique identifier shall be the internally generated Enterprise Architect GUID."},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#package-structure-rules","title":"Package Structure Rules","text":"

Overview

The CIM is wholly contained in one top-level package named TC57CIM. TC57CIM contains all of the utility domain model elements.

TC57CIM Package Structure

The top-level \"CIM\" (formerly TC57CIM) package is partitioned into sub-packages corresponding to the IEC TC57 working groups and an additional package that describes the dependencies between the top-level IEC TC57 working group packages. The working groups are mapped to the corresponding UML top-level packages as follows:

Both the legacy and new top-level package structure are shown in Figure 5\u20111 and Figure 5-2 respectively.

Figure 5\u20111 - TC57CIM Package Structure

Figure 5\u20112 - CIM Package Structure (New)

RuleID Description Rule003 There shall be one and only one package in the root model that contains all of the TC57 CIM information. Rule004

For each of the following TC57 working groups, there shall be one and only one package that contains all of its CIM information:

Each package is also referred to as a \u201ctop-level\u201d package.

Rule005 The TC57 working group top-level packages and the package that describes their dependencies shall be the only sub-packages within the TC57 CIM information package. Rule006 There shall be a diagram within the TC57 CIM information package that depicts the top-level TC57 CIM package structure that includes the TC57 working group packages and the package that describes their dependencies. Rule007 There shall be a diagram within the TC57 CIM information package that contains a note as its only UML element and that note shall include the CIM UML copyright notice verbiage. Rule008 Each package should typically include at least one diagram that contains all the classes in a package, and an arbitrary number of other diagrams."},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#package-dependency-rules","title":"Package Dependency Rules","text":"

The concept of package dependencies is critical to both the understanding of model ownership among working groups and the practical integration or assembly of packages from different owners. An additional package is maintained outside of the IEC working group packages to describe the dependencies among the packages of each working group. This package, named \u201cPackageDependencies\u201d contains a figure illustrating these dependencies as shown in Figure 5-3 UML package dependencies (for illustration, not official CIM standard). As such the PackageDependencies package is itself dependent upon all the other major packages

The package dependencies should rarely change and therefore it makes sense for the CIM model manager role to maintain this diagram through the normal model issues submittal process. There is no need for each package owner to edit this package. By design there are no circular dependencies among the major packages. Issues are resolved through the CMM board.

The rule of CIM ownership is that any model linkages between packages are owned by the depending package. Thus any linkage (generalisation, association, dependency relationship, attribute type reference, or diagram reference) between e.g. IEC61968 and IEC61970 is owned by the IEC61968 package since it depends upon IEC61970. In CIM, we model associations as implicitly bi-directional, and this rule of package ownership applies to both ends of an association (i.e., for an association between e.g. IEC61968 and IEC61970, both association ends are owned by the IEC61968 package). This is the convention applicable to CIM model management regardless of UML association end ownership, which standard UML does not explicitly specify.

Further we expect that derived classes (specialisations) are within the dependent package (e.g. cross package specialisations would be modelled within IEC61968 packages since IEC61968 depends upon IEC61970). Classes in a given package are allowed to specialise classes owned by packages upon which the given package depends.

Additionally we prefer to have the source end of associations in the dependent package. This is not strictly required, but is a good practice and can be validated by the CIM validation tools used to generate the CIM documentation. Following this convention may allow shortcuts in reassembling combined models, but this is not a formally documented feature of Enterprise Architect.

Diagrams should only include links to anything from packages upon which the containing package depends. Not following this practice will cause such linked elements to disappear when reassembling the combined model. This is the main reason for having the separate \u201cPackageDependencies\u201d package with its overview diagram from Figure 5-4. Importing this package last ensures that all the dependencies appear on the diagram when assembling the combined model from its partitions.

When a model linkage spans working group packages, both parties should be aware of the linkage once models are combined. Such linkages should normally be discussed among working groups so that inappropriate linkages are not established. At this point any change that impacts that linkage should be agreed among the affected working groups.

This coordination extends to any potentially inherited attributes and associations when the linkage is generalization. Namely, the class inheriting attributes and associations from its base class that is in another working group package depends on types used for attributes and association ends of the base class. Therefore, any change in the base class will impact all those that inherit from that base class.

Types used for attributes in a class introduce dependencies that must be coordinated among the working groups as well.

RuleID Description Rule009 There shall be one and only one package in the CIM that describes the dependencies between the TC57 working group packages. Rule010 The package that describes the dependencies between the TC57 working group packages shall be maintained outside of the IEC working group packages. Rule011 The package used to contain IEC working group package dependencies shall be named \u201cPackageDependencies\u201d Rule012 There shall be no circular dependencies among IEC working group packages Rule013 The \u201cPackageDependencies\u201d package shall contain a figure illustrating package dependencies as shown in Figure 5\u20113. Rule014 Dependencies between packages shall be owned by the dependent package. Rule015

The source end of associations between classes in different working group sub-packages shall be owned by the dependent package.

NOTE: Following this convention may allow shortcuts in reassembling combined models, but this is not a formally documented feature of Enterprise Architect.

Rule016 Class inheritances between classes in different packages (specialisations) shall be owned by the dependent package Rule017 Associations between classes in different IEC working group packages shall be owned by the source (dependent) working group package e.g. for an association between an Enterprise (formerly IEC61968) class and a Grid (formerly IEC61970) class, both association ends are owned by the Enterprise (formerly IEC61968) package.

Figure 5\u20113. Top-level CIM (formerly TC57CIM) Package Dependencies

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#package-assembly-rules","title":"Package Assembly Rules","text":"

Each working group edits what it owns and merges what others own. With three working groups this results in six possible ways to exchange portioned model files between the groups as shown in Figure 5-4.

Figure 5-4 - Possible partition file exchanges between WG13, WG14 and WG16

A box in Figure 5-4 represents a complete UML model while the rows under the working group name correspond to package numbers in CIM.

With four working groups the number of possible exchanges increases to twelve and with five it becomes twenty and so on.

The procedure to update a package with a partition file corresponds to an arrow in Figure 5-4 and consists of the following steps:

To properly obtain the correct UML package versions in a synchronized model, one can follow the steps in Figure 5-5. Complete synchronisation can be achieved by copying whole models as shown in Figure 5-5.

Figure 5-5 Complete synchronisation example

In Figure 5-5 a complete synchronisation of all model files is made in the following steps:

  1. Synchronise the WG14 model with Grid (61970) from WG13,

  2. Synchronise the WG16 model with Grid (61970) from WG13 and Enterprise (61968) from WG14,

  3. Copy the complete and synchronised WG16 model to WG13 and WG14.

This procedure minimizes the number of steps.

The whole process can be summarized as simply merging packages from the owner of that package. The package can be either obtained directly from the owner or indirectly from the owner. The additional rules are that we merge packages via the procedure in clause 2.2.2 and we must follow the guidance for model ownership of cross package linkages as defined in clause 2.2.4. We stamp each major package with a version revision stamp which is representative of the package (as defined by our ownership rules) in any combined model which has followed this process.

The merging process can inadvertently change dependent models so care must be taken to not make changes that invalidate dependent models. For example if WG13 were to delete a class from which WG14 generalizes, that generalization owned by WG14 would be lost in any merge where the class was deleted. This is why it is important to track the dependencies and make or break such dependencies only when agreed on both sides.

It is vital when using Enterprise Architect tool to start with an empty model and import packages in dependency order as defined in the PackageDependendencies diagram shown in Figure 4. This assembly process will ensure that combined models are created properly. For example import the Grid (formerly IEC61970) package before Enerprise (formerly IEC61968), and import PackageDependencies package last. At any point when assembling packages, the model will be complete in regards to anything owned by the imported packages according to the definition of ownership in clause 2.2.4.

UML element Identity in Enterprise Architect UML is by internally generated GUID\u2019s. Thus it is not equivalent to delete something and then enter the same data again. Such an operation will break linkages in the model, though the source model appears identical from the user interface. In Enterprise Architect you can change the names without breaking linkages. Some tools rely upon the name of the class or attribute not the Enterprise Architect GUID values for reference matching and will break linkages if names are changed. Modelling actions should be aware of both implications.

The best practice is to always import and work with the standard packages upon which your package depends so you get the proper GUID based linkages.

RuleID Description Rule018 Working group package assembly must start with an empty Enterprise Architect project containing a single empty model. Rule019 Packages must be first exported from a properly combined model and then imported into an empty Enterprise Architect project containing a single empty model in order to perform proper package assembly. Rule020 Packages may be exported in any order. Rule021 Package exportation must follow the procedure specified in Appendix TBD. Rule022

The integrity of internally generated GUIDs for Enterprise Architect model elements must be preserved between model versions to ensure model integrity.

NOTE:: Some tools rely upon the name of the class or attribute not the Enterprise Architect GUID values for reference matching and will break linkages if names are changed.

Rule023 Package assembly must be performed by importing packages in dependency order as defined in the PackageDependencies diagram shown in Figure 5\u20113. Specifically, the package import order is:
  1. Grid (formerly IEC61970);
  2. Enterprise (formerly IEC61968);
  3. Market (formerly IEC6235);
  4. PackageDependencies.
Rule024

After each package import, the package dependency rules specified in Section 5.2.3 must be satisfied.

NOTE: Any cross-working group package associations to packages not yet imported will be discarded in the combined model as they are by definition not owned by the thus far imported packages.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#package-rules","title":"Package Rules","text":"

The purpose of packages in the CIM model is mainly for controlling working group ownership, with sub-packages mainly representing conceptual organization. This usage of the package structure allows for relatively easy movement of classes among packages without impacting concrete implementations.

CIM package names are intended to be unique among all packages without consideration of package hierarchy.

Package ordering is typically specified in dependency order. For example, the Domain and Core packages are ordered first in the UML. The printed documentation will use this package ordering. If no clear dependency relation exists, order packages alphabetically.

To facilitate model management and evolution (and minimise IEC documents generation time), while preserving the means to print official documents at any time in the proper format, we have the following three special kinds of packages

\u201cInf\u201d is the prefix used to denote informative CIM UML sub-packages. This is to avoid name clashes among normative and informative packages (e.g., \u2018Core\u2019 vs. \u2018InfCore\u2019), and to make informative sub-packages obvious through their name. Note that this will apply to all packages that start with this prefix (e.g., 'InfCore' as well as 'Informative').

The content of the informative package, including any sub-packages and its content, recursively, is considered as informative in the sense of IEC documents and is therefore by default excluded from the document generation. However, the CIM UML tool has an option to enable printing the informative content as well, which is useful for e.g., sharing documentation of the current work in an informative sandbox with the working group members, without impact to the stable, normative parts of the model.

An informative package can be defined at any depth in the CIM UML model. The only requirement is the \u201cInf\u201d prefix in the package name. It is recommended to specify \u201cInf\u201d packages as \u201cprivate\u201d packages in Enterprise Architect package properties, so they can be filtered out of diagrams showing the sub packages.

\u201cDoc\u201d is the prefix used to denote those CIM UML sub-packages that contain diagrams used for the IEC document template only, and that should not be printed with the content of the regular model. The sub-package of \"ABC\" with the name \"DocABC\" will be matched, and considered as informative package from the perspective of automatic document generation (i.e., it will be skipped), but it still can be referenced from the IEC document template to include the diagram, for instance in its introductory examples section.

It is recommended to specify \u201cDoc\u201d packages as \u201cprivate\u201d packages in Enterprise Architect package properties, so they can be filtered out of diagrams showing the sub packages.

"},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#531-package-naming-rules","title":"5.3.1 Package Naming Rules","text":"

Package names start with upper case (UpperCamelCase rule). Package names must be unique across the whole CIM.

RuleID Description Rule025 Names for packages shall use the Upper Camel Case naming convention. Rule026 Names for packages shall be British English names. Rule027 All packages containing classes shall have unique names. (i.e., the package containment hierarchy shall not be used in uniquely identifying a package). Rule028 The name of the top-level package at the root of the model shall be CIM (formerly TC57CIM). Rule029

The following names shall be used to identify CIM (formerly TC57CIM) top-level packages:

  1. \"Grid\" (formerly IEC61970) for IEC TC57 WG13 domain information;

  2. \"Enterprise\" (formerly IEC61968) for IEC TC57 WG14 domain information;

  3. \"Markets\" (formerly IEC62325) for IEC TC57 WG16 domain information;

Rule030 The \u201cInf\u201d prefix shall be used in package names to denote informative CIM UML sub-packages. Rule031 An informative package can be defined at any depth in the CIM UML model. The only requirement is the \u201cInf\u201d prefix in the package name. Rule032 The \u201cDoc\u201d prefix shall be used in package names to denote CIM UML sub-packages that contain diagrams used during the generation of IEC documents. Rule033 The package name \u201cDetailedDiagrams\u201d shall be a reserved package name. Rule034 There may be multiple instances of packages named \u201cDetailedDiagrams\u201d in the CIM."},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#package-specification-rules","title":"Package Specification Rules","text":"RuleID Description Rule035 Informative packages should be specified as \u201cprivate\u201d packages in Enterprise Architect package properties, so they can be filtered out of diagrams showing the sub-packages. Rule036 \u201cDoc\u201d packages should be specified as \u201cprivate\u201d packages in Enterprise Architect package properties, so they can be filtered out of diagrams showing the sub-packages. Rule037 \u201cDetailedDiagram\u201d packages should be specified as \u201cprivate\u201d packages in Enterprise Architect package properties, so they can be filtered out of diagrams showing the sub-packages."},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#class-rules","title":"Class Rules","text":"

The following UML class features are used in CIM:

In CIM, a class is used to describe either domain entities or various data types specific to the CIM domain:

CIM classes with a stereotype other than <<deprecated>> are types that never participate in relationships (i.e., no associations, no inheritance), but are used as types for attributes.

CIM does not use abstract classes, because CIM is in itself an abstract model. In contrast, profiles may distinguish between concrete and abstract classes.

CIM does not use association classes, for the sake of keeping the used subset of UML to the minimum that is well supported by tools and well understood by the wide community.

CIM class names are unique among all classes residing within the CIM top-level package without consideration of the package hierarchy.

Classes should be ordered alphabetically or in order of importance or by logical grouping. We do not enforce alphabetically ordering automatically in the UML tool. The order of classes in the UML tool with be the order of classes printed in the IEC document.

RuleID Description Rule038 Names for classes shall use the Upper Camel Case naming convention. Rule039 Names for classes shall be British English names. Rule040 All classes shall have unique names. The package containment hierarchy shall not be used in uniquely identifying a class. Rule041 A CIM class shall be used to describe either an electric utility domain entity or an information entity used in the electric utility domain. Rule042 All class names shall be the singular form of a utility domain concept. Rule043 A CIM class that has the <<CIMDatatype>> stereotype shall have at minimum, the following attributes: 1. value; 2. unit; and 3. multiplier. Rule044 A CIM class shall not be an abstract class. Rule045 A CIM class shall not be an association class. Rule046 CIM classes with a stereotype other than <<deprecated>> shall never participate in relationships with other classes (i.e., no associations, no inheritance). Rule047 CIM classes with a stereotype other than <<deprecated>> shall only be used as datatypes for attributes. Rule048 CIM classes should be ordered alphabetically or in order of importance or by logical grouping within a package."},{"location":"section5-cim-uml-modeling-rules-and-recommendations/#attribute-rules","title":"Attribute Rules","text":"

The following UML attribute features (i.e. available in the \"Properties\" Pane in Sparx EA) are used in CIM:

Attribute names are unique within a classifier and Enterprise Architect will enforce this.

The attribute order should normally be alphabetical unless there is some clear reason to group like attributes together. We do not enforce alphabetic ordering in the UML tool.

RuleID Description Rule049 Names for attributes shall use the Lower Camel Case naming convention Rule050 Names for attributes shall be British English names. Rule051 Attribute names shall be singular form concepts. Rule052 The \"value\" attribute of a CIM class that has the **<<CIMDatatype>>** stereotype shall be a Primitive data type. Rule053 The \"unit\" attribute of a CIM class that has the **<<CIMDatatype>>** stereotype shall be an enumeration data type. Rule054 The \"multiplier\" attribute of a CIM class that has the **<<CIMDatatype>>** stereotype shall be an enumeration data type. Rule055 Attribute data types shall be one of the stereotyped CIM classes (i.e. shall not be one of the Enterprise Architect native data types). Rule056 In instances where an attribute of a CIM class has an initial value, it shall denote a constant for all instance of the class to which the attribute belongs. Rule057 In instances where an attribute of a CIM class has an initial value, it shall be set as both static and constant. Rule058 Attribute multiplicity shall always be \\[0..1\\] (i.e. all CIM attributes are optional). Rule059 For attributes that correspond to power system related measurements as listed below the attribute name must use the symbol, in lower camel case (e.g. ratedU), instead of the name or unit of measurement.