61970-301©1EC:2003 11- 1 Scope The Common Information Model(CIM)is an abstract model that represents all the major objects in an electric utility enterprise typically involved in utility operations.By providing a standard way of representing power system resources as object classes and attributes,along with their relationships,the CIM facilitates the integration of Energy Management System (EMS) applications developed independently by different vendors,between entire EMS systems developed independently,or between an EMS system and other systems concerned with different aspects of power system operations,such as generation or distribution management.This is accomplished by defining a common language (i.e.,semantics and syntax)based on the CIM to enable these applications or systems to access public data and exchange information independent of how such information is represented internally. The object classes represented in the CIM are abstract in nature and may be used in a wide variety of applications.The use of the CIM goes far beyond its application in an EMS.This standard should be understood as a tool to enable integration in any domain where a common power system model is needed to facilitate interoperability and plug compatibility between applications and systems independent of any particular implementation. Due to the size of the complete CIM,the object classes contained in the CIM are grouped into a number of logical Packages,each of which represents a certain part of the overall power system being modeled.Collections of these Packages are progressed as separate International Standards.This particular International Standard specifies a Base set of packages which provide a logical view of the physical aspects of Energy Management System (EMS)information within the electric utility enterprise that is shared between all applications.Other standards specify more specific parts of the model that are needed by only certain applications.Section 4.2 below provides the current grouping of packages into standards documents. 2 Normative References The following normative documents contain provisions which,through reference in this text, constitute provisions of this International Standard.At the time of publication,the editions indicated were valid.All normative documents are subject to revision,and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below.Members of IEC and ISO maintain registers of currently valid International Standards. [No normative references are defined at this time] 3 Definitions and Abbreviations Refer to International Electrotechnical Vocabulary,IEC 60050,for general glossary definitions. For the purposes of this International Standard,the terms and definitions given in Annex A and the following apply. 3.1 Energy Management System(EMS) A computer system comprising a software platform providing basic support services and a set of applications providing the functionality needed for the effective operation of electrical generation and transmission facilities so as to assure adequate security of energy supply at minimum cost
61970-301 IEC:2003 – 11 – 1 Scope The Common Information Model (CIM) is an abstract model that represents all the major objects in an electric utility enterprise typically involved in utility operations. By providing a standard way of representing power system resources as object classes and attributes, along with their relationships, the CIM facilitates the integration of Energy Management System (EMS) applications developed independently by different vendors, between entire EMS systems developed independently, or between an EMS system and other systems concerned with different aspects of power system operations, such as generation or distribution management. This is accomplished by defining a common language (i.e., semantics and syntax) based on the CIM to enable these applications or systems to access public data and exchange information independent of how such information is represented internally. The object classes represented in the CIM are abstract in nature and may be used in a wide variety of applications. The use of the CIM goes far beyond its application in an EMS. This standard should be understood as a tool to enable integration in any domain where a common power system model is needed to facilitate interoperability and plug compatibility between applications and systems independent of any particular implementation. Due to the size of the complete CIM, the object classes contained in the CIM are grouped into a number of logical Packages, each of which represents a certain part of the overall power system being modeled. Collections of these Packages are progressed as separate International Standards. This particular International Standard specifies a Base set of packages which provide a logical view of the physical aspects of Energy Management System (EMS) information within the electric utility enterprise that is shared between all applications. Other standards specify more specific parts of the model that are needed by only certain applications. Section 4.2 below provides the current grouping of packages into standards documents. 2 Normative References The following normative documents contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All normative documents are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. [No normative references are defined at this time] 3 Definitions and Abbreviations Refer to International Electrotechnical Vocabulary, IEC 60050, for general glossary definitions. For the purposes of this International Standard, the terms and definitions given in Annex A and the following apply. 3.1 Energy Management System (EMS) A computer system comprising a software platform providing basic support services and a set of applications providing the functionality needed for the effective operation of electrical generation and transmission facilities so as to assure adequate security of energy supply at minimum cost
61970-301©1EC:2003 -12- 3.2 Application Program Interface (API) The set of public functions provided by an executable application component for use by other executable application components. 4 CIM Specification 4.1 CIM Modeling Notation The CIM is defined using object-oriented modeling techniques.Specifically,the CIM specification uses the Unified Modeling Language (UML)notation,which defines the CIM as a group of packages Each package in the CIM contains one or more class diagrams showing graphically all the classes in that package and their relationships.Each class is then defined in text in terms of its attributes and relationships to other classes. The UML notation is described in Object Management Group (OMG)documents and several published textbooks. 4.2 CIM Packages The CIM is partitioned into a set of packages.A package is a general purpose means of grouping related model elements.There is no specific semantic meaning.The packages have been chosen to make the model easier to design,understand and review.The Common Information Model consists of the complete set of packages.Entities may have associations that cross many package boundaries.Each application will use information represented in several packages The comprehensive CIM is partitioned into the following packages for convenience,where packagages are grouped to be handled as a single standard document as shown: IEC 61970 Part 301(this document) ·Core ●Domain Generation Generation Dynamics ·LoadMode ·Meas ·Outage 。Production 。Protection ·Topology ·Vires IEC 61970 Part 302 ·Energy Scheduling 。Financial ●Reservation 1EC61970Part303 ·SCADA
61970-301 IEC:2003 – 12 – 3.2 Application Program Interface (API) The set of public functions provided by an executable application component for use by other executable application components. 4 CIM Specification 4.1 CIM Modeling Notation The CIM is defined using object-oriented modeling techniques. Specifically, the CIM specification uses the Unified Modeling Language (UML) notation, which defines the CIM as a group of packages. Each package in the CIM contains one or more class diagrams showing graphically all the classes in that package and their relationships. Each class is then defined in text in terms of its attributes and relationships to other classes. The UML notation is described in Object Management Group (OMG) documents and several published textbooks. 4.2 CIM Packages The CIM is partitioned into a set of packages. A package is a general purpose means of grouping related model elements. There is no specific semantic meaning. The packages have been chosen to make the model easier to design, understand and review. The Common Information Model consists of the complete set of packages. Entities may have associations that cross many package boundaries. Each application will use information represented in several packages. The comprehensive CIM is partitioned into the following packages for convenience, where packagages are grouped to be handled as a single standard document as shown: IEC 61970 Part 301 (this document) Core Domain Generation Generation Dynamics LoadModel Meas Outage Production Protection Topology Wires IEC 61970 Part 302 Energy Scheduling Financial Reservation IEC 61970 Part 303 SCADA
61970-301©1EC:2003 -13- IEC61968 ●Assets ● Consumer Core2 Distribution ● Documentation Note that the package boundaries do not imply application boundaries.An application may use CIM entities from several packages. Figure 1 shows the packages defined for IEC 61970-301 CIM Base and their dependency relationships.The dashed line indicates a dependency relationship,with the arrowhead pointing from the dependent package to the package on which it has a dependency. Generation LoadModel Outage Protection Wires Meas Topology Core <<Global>> Domain Figure 1-CIM Part 301 Package Diagram The paragraphs below summarize the contents of each CIM package.Normative Annex A contains the specification for each of the CIM packages
61970-301 IEC:2003 – 13 – IEC 61968 Assets Consumer Core2 Distribution Documentation Note that the package boundaries do not imply application boundaries. An application may use CIM entities from several packages. Figure 1 shows the packages defined for IEC 61970-301 CIM Base and their dependency relationships. The dashed line indicates a dependency relationship, with the arrowhead pointing from the dependent package to the package on which it has a dependency. Generation Domain <<Global>> Wires LoadModel Core Meas Topology Outage Protection Figure 1 – CIM Part 301 Package Diagram The paragraphs below summarize the contents of each CIM package. Normative Annex A contains the specification for each of the CIM packages
61970-301©1EC:2003 -14- NOTE 1-The package definitions are loosely based on the "Conformance Blocks"that were defined for the CIM specification version 7 defined in the EPRI CCAPI project. NOTE 2-The contents of the CIM defined in this specification were obtained from a straight conversion of the CCAPI CIM static information model defined in the CCAPI CIM Version 10. NOTE 3-Informative Annex B contains a mapping of the information modeling notation used in the CCAPI CIM Version 7 to the UML used in this standard specification.This Annex is intended to assist those readers who have previously worked with the CCAPI CIM and who now need to adopt the new UML notation.Those readers not acquainted with the previous CCAPI CIM notation may choose to not read Annex B. 4.2.1 Core This package contains the core Naming,PowerSystemResource,EquipmentContainer,and ConductingEquipment entities shared by all applications plus common collections of those entities.Not all applications require all the Core entities.This package does not depend on any other package,but most of the other packages have associations and generalizations that depend on it. 4.2.2 Topology This package is an extension to the Core Package that in association with the Terminal class models Connectivity,that is the physical definition of how equipment is connected together.In addition it models Topology,that is the logical definition of how equipment is connected via closed switches.The Topology definition is independent of the other electrical characteristics. 4.2.3 Wires The Wires package is an extension to the Core and Topology package that models information on the electrical characteristics of Transmission and Distribution networks.This package is used by network applications such as State Estimation,Load Flow and Optimal Power Flow. 4.2.4 Outage This package is an extension to the Core and Wires packages that models information on the current and planned network configuration.These entities are optional within typical network applications 4.2.5 Protection This package is an extension to the Core and Wires packages that models information for protection equipment such as relays.These entities are used within training simulators and distribution network fault location applications. 4.2.6 Meas The Meas package contains entities that describe dynamic measurement data exchanged between applications 4.2.7 LoadModel This package provides models for the energy consumers and the system load as curves and associated curve data.Special circumstances that may affect the load,such as seasons and daytypes,are also included here
61970-301 IEC:2003 – 14 – NOTE 1 – The package definitions are loosely based on the “Conformance Blocks” that were defined for the CIM specification version 7 defined in the EPRI CCAPI project. NOTE 2 – The contents of the CIM defined in this specification were obtained from a straight conversion of the CCAPI CIM static information model defined in the CCAPI CIM Version 10. NOTE 3 – Informative Annex B contains a mapping of the information modeling notation used in the CCAPI CIM Version 7 to the UML used in this standard specification. This Annex is intended to assist those readers who have previously worked with the CCAPI CIM and who now need to adopt the new UML notation. Those readers not acquainted with the previous CCAPI CIM notation may choose to not read Annex B. 4.2.1 Core This package contains the core Naming, PowerSystemResource, EquipmentContainer, and ConductingEquipment entities shared by all applications plus common collections of those entities. Not all applications require all the Core entities. This package does not depend on any other package, but most of the other packages have associations and generalizations that depend on it. 4.2.2 Topology This package is an extension to the Core Package that in association with the Terminal class models Connectivity, that is the physical definition of how equipment is connected together. In addition it models Topology, that is the logical definition of how equipment is connected via closed switches. The Topology definition is independent of the other electrical characteristics. 4.2.3 Wires The Wires package is an extension to the Core and Topology package that models information on the electrical characteristics of Transmission and Distribution networks. This package is used by network applications such as State Estimation, Load Flow and Optimal Power Flow. 4.2.4 Outage This package is an extension to the Core and Wires packages that models information on the current and planned network configuration. These entities are optional within typical network applications. 4.2.5 Protection This package is an extension to the Core and Wires packages that models information for protection equipment such as relays. These entities are used within training simulators and distribution network fault location applications. 4.2.6 Meas The Meas package contains entities that describe dynamic measurement data exchanged between applications. 4.2.7 LoadModel This package provides models for the energy consumers and the system load as curves and associated curve data. Special circumstances that may affect the load, such as seasons and daytypes, are also included here
61970-301©1EC:2003 -15- This information is used by Load Forecasting and Load Management. 4.2.8 Generation The Generation package is divided into two subpackages:Production and GenerationDynamics. 4.2.8.1 Production This package provides models for various kinds of generators.It also models production costing information which is used to economically allocate demand among committed units and calculate reserve quantities. This information is used by Unit Commitment and Economic Dispatch of Hydro and Thermal Generating Units,Load Forecasting.and Automatic Generation Control applications. 4.2.8.2 Generation Dynamics This package provides models for prime movers,such as turbines and boilers,which are needed for simulation and educational purposes This information is used by the Unit Modeling for Dynamic Training Simulator applications 4.2.9 Domain The Domain package is a data dictionary of quantities and units that define datatypes for attributes(properties)that may be used by any class in any other package. This package contains the definition of primitive datatypes,including units of measure and permissible values.Each datatype contains a value attribute and an optional unit of measure, which is specified as a static variable initialized to the textual description of the unit of measure Permissible values for enumerations are listed in the documentation for the attribute using UML constraint syntax inside curly braces.String lengths are listed in the documentation and are also specified as a length property. 4.3 CIM Classes and Relationships The class diagram(s)for each CIM package shows all the classes in the package and their relationships.Where relationships exist with classes in other packages,those classes are also shown with a note identifying the package which owns the class. Classes and objects model what is in a power system that needs to be represented in a common way to EMS applications.A class is a description of an object found in the real world,such as a power transformer,generator,or load that needs to be represented as part of the overall power system model in an EMS.Other types of objects include things such as schedules and measurements that EMS applications also need to process,analyze,and store.Such objects need a common representation to achieve the purposes of the EMS-API standard for plug- compatability and interoperability.A particular object in a power system with a unique identity is modeled as an instance of the class to which it belongs. It should also be noted that the CIM is defined to facilitate data exchange.As defined in this document,CIM entities have no behavior other than default create,delete,update and read.In order to make the CIM as generic as possible it is highly desirable to make it easy to configure for specific implementations.In general it is easier to change the value or domain of an attribute than to change a class definition.These principles imply that the CIM should avoid defining too many specific sub-types of classes.Instead the CIM defines generic classes with attributes giving the
61970-301 IEC:2003 – 15 – This information is used by Load Forecasting and Load Management. 4.2.8 Generation The Generation package is divided into two subpackages: Production and GenerationDynamics. 4.2.8.1 Production This package provides models for various kinds of generators. It also models production costing information which is used to economically allocate demand among committed units and calculate reserve quantities. This information is used by Unit Commitment and Economic Dispatch of Hydro and Thermal Generating Units, Load Forecasting, and Automatic Generation Control applications. 4.2.8.2 Generation Dynamics This package provides models for prime movers, such as turbines and boilers, which are needed for simulation and educational purposes. This information is used by the Unit Modeling for Dynamic Training Simulator applications. 4.2.9 Domain The Domain package is a data dictionary of quantities and units that define datatypes for attributes (properties) that may be used by any class in any other package. This package contains the definition of primitive datatypes, including units of measure and permissible values. Each datatype contains a value attribute and an optional unit of measure, which is specified as a static variable initialized to the textual description of the unit of measure. Permissible values for enumerations are listed in the documentation for the attribute using UML constraint syntax inside curly braces. String lengths are listed in the documentation and are also specified as a length property. 4.3 CIM Classes and Relationships The class diagram(s) for each CIM package shows all the classes in the package and their relationships. Where relationships exist with classes in other packages, those classes are also shown with a note identifying the package which owns the class. Classes and objects model what is in a power system that needs to be represented in a common way to EMS applications. A class is a description of an object found in the real world, such as a power transformer, generator, or load that needs to be represented as part of the overall power system model in an EMS. Other types of objects include things such as schedules and measurements that EMS applications also need to process, analyze, and store. Such objects need a common representation to achieve the purposes of the EMS-API standard for plug- compatability and interoperability. A particular object in a power system with a unique identity is modeled as an instance of the class to which it belongs. It should also be noted that the CIM is defined to facilitate data exchange. As defined in this document, CIM entities have no behavior other than default create, delete, update and read. In order to make the CIM as generic as possible it is highly desirable to make it easy to configure for specific implementations. In general it is easier to change the value or domain of an attribute than to change a class definition. These principles imply that the CIM should avoid defining too many specific sub-types of classes. Instead the CIM defines generic classes with attributes giving the