61970-301©1EC:2003 -21- Terminal connected to a ConnectivityNode,the associations of the other Terminal(s)connected to the same ConectivityNode identify the ConductingEqupment object(s)that are electrically connected To model the analog values such as voltage and power,each Terminal has an association with a Measurement class from the Meas package.Although not shown in Figure 6,a Measurement object is associated with at least one MeasurementValue object.Each MeasurementValue object is an instance of a measurement from a specific source,for example,a telemetered measurement.In a study context the measurement values would have a calculation source instead. Annex A contains a complete description of each class in Figure 6 along with the definition of all the attributes and relationships supported in each class. 4.4.2.1 Connectivity and Containment Example To illustrate how the connectivity model and containment model would appear as objects,a small example is presented in Figure 7.The example shows a transmission line with a T-junction spanning two substations and a substation having two voltage levels with a transformer between them.The transmission line consists of two different cables.One of the voltage levels is shown with a busbar section having a single busbar and two very simple switchgear bays connecting to the busbar. SS2 400KV SSI-SS2 i SS1 Cablel Cable2 12345MW Cable3 12345KV BBI 12345MW SS4 110KV Figure 7-Simple Network Example Figure 8 shows how connectivity is modeled in the CIM as well as one way (but not necessarily the only way)containment is modeled for the diagram in Figure 6.The shaded square boxes represent EquipmentContainers,and the white square boxes represent ConductingEquipment. Darker shading indicates the EquipmentContainer is higher up in the containment hierarchy (i.e., Substation is highest.VoltageLevel next,etc.).White circles represent ConnectivityNodes,and black small circles represent Terminals.A Terminal belongs to a ConductingEquipment,and a ConnectivityNode belongs to an EquipmentContainer.This means that the borders (or contact points)between ConductingEquipment are their Terminals interconnected via ConnectivityNodes
61970-301 IEC:2003 – 21 – Terminal connected to a ConnectivityNode, the associations of the other Terminal(s) connected to the same ConectivityNode identify the ConductingEqupment object(s) that are electrically connected. To model the analog values such as voltage and power, each Terminal has an association with a Measurement class from the Meas package. Although not shown in Figure 6, a Measurement object is associated with at least one MeasurementValue object. Each MeasurementValue object is an instance of a measurement from a specific source, for example, a telemetered measurement. In a study context the measurement values would have a calculation source instead. Annex A contains a complete description of each class in Figure 6 along with the definition of all the attributes and relationships supported in each class. 4.4.2.1 Connectivity and Containment Example To illustrate how the connectivity model and containment model would appear as objects, a small example is presented in Figure 7. The example shows a transmission line with a T-junction spanning two substations and a substation having two voltage levels with a transformer between them. The transmission line consists of two different cables. One of the voltage levels is shown with a busbar section having a single busbar and two very simple switchgear bays connecting to the busbar. SS1 SS2 400KV 110KV 12345 MW 12345 KV 12345 MW Cable1 Cable2 SS1-SS2 T1 BB1 SS4 Cable3 Figure 7 - Simple Network Example Figure 8 shows how connectivity is modeled in the CIM as well as one way (but not necessarily the only way) containment is modeled for the diagram in Figure 6. The shaded square boxes represent EquipmentContainers, and the white square boxes represent ConductingEquipment. Darker shading indicates the EquipmentContainer is higher up in the containment hierarchy (i.e., Substation is highest, VoltageLevel next, etc.). White circles represent ConnectivityNodes, and black small circles represent Terminals. A Terminal belongs to a ConductingEquipment, and a ConnectivityNode belongs to an EquipmentContainer. This means that the borders (or contact points) between ConductingEquipment are their Terminals interconnected via ConnectivityNodes
61970-301©1EC:2003 -22- SS2 400KV Volts SS1-SS2 (KV) SS I (W) CN5 DC2 Cablel CN2 BRI Cable2 CNI BR3 P2 (MW) CN6 CN8 1w2 SS4 CN7 110KV Figure 8-Simple Network Connectivity Modeled with CIM Topology The Line SS1-SS2 has two ACLineSegments-Cable1 and Cable2.A collapsed Substation SS3 with ConnectivityNode CN2 models the connection point between the ACLineSegments as well as a T-junction to Cable3,which provides a connection to Substation 4.Each ACLineSegment has two Terminals.Cable1 is connected to CN3 and CN2 via these Terminals.CN3 is contained by the VoltageLevel 400KV.The breaker BR1 has two terminals of which one is connected to CN3. The rest is left to the interested reader to trace. Measurements are represented by square callouts where the arrow points to a Terminal.P1 is connected to the right Terminal belonging to Breaker BR1.Note that P1 is drawn inside the box representing BR1.This is because a Measurement may belong to a PowerSystemResource (PSR),as is the case with BR1.P2 is drawn inside the VoltageLevel 400KV,which means it belongs to the 400KV VoltageLevel instead of BR3. 4.4.3 Inheritance Hierarchy Figure 9 shows an overview of the inheritance hierarchy modeled in the CIM.This overview, which is included as one of the Wires package diagrams,actually spans most of the CIM packages
61970-301 IEC:2003 – 22 – SS3 SS 1 Cable2 SS 2 110KV 400KV CN3 Cable1 CN2 BR1 DC2 CN4 P1 (MW) CN5 BB1 T 1 TW 1 TW 2 CN7 CN6 Volts (KV) BR3 P2 (MW) CN1 SS1-SS2 Cable3 SS 4 CN8 Figure 8 - Simple Network Connectivity Modeled with CIM Topology The Line SS1-SS2 has two ACLineSegments - Cable1 and Cable2. A collapsed Substation SS3 with ConnectivityNode CN2 models the connection point between the ACLineSegments as well as a T-junction to Cable3, which provides a connection to Substation 4. Each ACLineSegment has two Terminals. Cable1 is connected to CN3 and CN2 via these Terminals. CN3 is contained by the VoltageLevel 400KV. The breaker BR1 has two terminals of which one is connected to CN3. The rest is left to the interested reader to trace. Measurements are represented by square callouts where the arrow points to a Terminal. P1 is connected to the right Terminal belonging to Breaker BR1. Note that P1 is drawn inside the box representing BR1. This is because a Measurement may belong to a PowerSystemResource (PSR), as is the case with BR1. P2 is drawn inside the VoltageLevel 400KV, which means it belongs to the 400KV VoltageLevel instead of BR3. 4.4.3 Inheritance Hierarchy Figure 9 shows an overview of the inheritance hierarchy modeled in the CIM. This overview, which is included as one of the Wires package diagrams, actually spans most of the CIM packages
61970-301©1EC:2003 -23- PowerSystemResource VoltageControlZone (from Core) TapChanger LoadArea (from LoadModel) Line CompositeSwitch Equipment EquipmentContainer Substation (from Core) (from Core) (from Core) VoltageLevel HeatExchanger (from Core) PowerTransformer Bay GeneratingUnit (from Core) (from Production) ProtectionEquipment (from Protection) ConductingEquipment DCLineSegment (from Core) Conductor ACLineSegment TransformerWinding CustomerMeter (from LoadModel) StationSupply (from LoadModel) EnergyConsumer EquivalentLoad EquivalentSource (from LoadModel) Rectifierinverter InductionMotorLoad Ground (from LoadModel) Connector BusbarSection RegulatingCondEq Junction StaticVarCompensator SynchronousMachine Switch Compensator Jumper Fuse Breaker Disconnecto LoadBreakSwitch GroundDisconnector Figure 9-Equipment Inheritance Hierarchy
61970-301 IEC:2003 – 23 – PowerSystemResource (from Core) Connector Conductor EquivalentSource Ground Jumper Junction RectifierInverter RegulatingCondEq StaticVarCompensator Switch Fuse TransformerWinding TapChanger Disconnector LoadBreakSwitch DCLineSegment ACLineSegment Line Compensator VoltageControlZone BusbarSection LoadArea (from LoadModel) EquivalentLoad (from LoadModel) InductionMotorLoad (from LoadModel) EnergyConsumer StationSupply (from LoadModel) CustomerMeter (from LoadModel) HeatExchanger Bay (from Core) VoltageLevel (from Core) PowerTransformer Substation (from Core) EquipmentContainer (from Core) Equipment (from Core) SynchronousMachine GeneratingUnit (from Production) Breaker ConductingEquipment (from Core) ProtectionEquipment (from Protection) GroundDisconnector CompositeSwitch Figure 9 – Equipment Inheritance Hierarchy
61970-301©IEC:2003 -24- 4.4.4 Equipment Containers Figure 10 shows the concept of equipment containers modeled in the CIM.Equipment containers represent ways of organizing and naming equipment typically found within a substation.As may be seen,there is some flexibility provided in which containers are used in a specific application of the CIM in order to accommodate different international practices as well as differences typically found between transmission and distribution substations.Each container represents an aggregation of other containers and/or equipment objects. +MemberOf_EquipmentContainer EquipmentContainer 0.1 0.n Equipment ConductingEquipment (from Core) (from Core) (from Core) +Contains_Equipments PowerTransformer Substation 0.十 (from Core） 1◇ +MemberOf_Substation 01 +MemberOf_PowerTrapsformer +MemberOf_Substation +Contains TransformerWindings +MemberOf Substation T..n TransformerWinding +Contains VoltageLevels 0.n +VoltageLevel VoltageLevel 1 BaseVoltage (from Core) (from Core) 0.n 0.1◇ +BaseVoltage +MemberOf VoltageLevel +Contains_Bays +Contains_Bays 0.n 0.n Bay (from Core) Contains_CompositeSwitches 0.n 0.1 0.n CompositeSwitch Switch +CompositeSwitch +Switches Figure 10-Equipment Containers 4.5 Modeling Tools The CIM was constructed and is maintained using Rational ROSE from Rational Software Corporation.The entire CIM exists as a.mdl file viewable with Rational ROSE,including the class diagrams and descriptions of classes,attributes,types,and relationships.Viewing the CIM in this fashion provides a graphical navigation interface that permits all CIM specification data to be viewed via point-and-click from the class diagram in each package.Each top level package is also distributed as a.cat file,allowing new models to be constructed from the CIM packages
61970-301 IEC:2003 – 24 – 4.4.4 Equipment Containers Figure 10 shows the concept of equipment containers modeled in the CIM. Equipment containers represent ways of organizing and naming equipment typically found within a substation. As may be seen, there is some flexibility provided in which containers are used in a specific application of the CIM in order to accommodate different international practices as well as differences typically found between transmission and distribution substations. Each container represents an aggregation of other containers and/or equipment objects. Equipment (from Core) EquipmentContainer (from Core) 0..n 0..1 +Contains_Equipments 0..n +MemberOf_EquipmentContainer 0..1 ConductingEquipment (from Core) TransformerWinding PowerTransformer 1..n 1 +Contains_TransformerWindings 1..n +MemberOf_PowerTransformer 1 BaseVoltage (from Core) VoltageLevel (from Core) 1 0..n +BaseVoltage 1 +VoltageLevel 0..n Bay (from Core) 0..1 0..n +MemberOf_VoltageLevel 0..1 +Contains_Bays 0..n Switch Substation (from Core) 1 0..n +MemberOf_Substation 1 +Contains_VoltageLevels 0..n 0..1 0..n +MemberOf_Substation 0..1 +Contains_Bays 0..n CompositeSwitch 0..n 0..1 +Switches 0..n +CompositeSwitch 0..1 0..1 0..n +MemberOf_Substation 0..1 +Contains_CompositeSwitches 0..n Figure 10 – Equipment Containers 4.5 Modeling Tools The CIM was constructed and is maintained using Rational ROSE from Rational Software Corporation. The entire CIM exists as a .mdl file viewable with Rational ROSE, including the class diagrams and descriptions of classes, attributes, types, and relationships. Viewing the CIM in this fashion provides a graphical navigation interface that permits all CIM specification data to be viewed via point-and-click from the class diagram in each package. Each top level package is also distributed as a .cat file, allowing new models to be constructed from the CIM packages
61970-301©1EC:2003 -25- All future changes to the CIM specification,resulting in new versions of this standard,will be incorporated first into the Rational ROSE model description to ensure a single source for the CIM model data. Annex A of this document was auto-generated using Rational SoDA,another modeling tool from Rational Software Corporation.SoDA generates Word documents from the ROSE model file based on a custom template created in Word that incorporates the IEC format and styles. 4.6 Modeling Guidelines This section provides guidelines on how to maintain and extend the CIM. The CIM is meant to contain classes and attributes that will be exchanged over public interfaces between major appications.The goal is to keep,as much as possible,only the generic features from which a detailed implementation may be derived.In general,it is easier to change the value or domain of an attribute than to change a class definition.This makes the model more robust because it is able to support a broader class of requirements,and more stable because new requirements may be able to be handled without requiring changes to the model. 4.6.1 Amendments to the CIM From time to time it may be desirable to amend the CIM to either revise the existing model or to extend the CIM to model additional elements of an electric utility power system.The recommended process for such amendments is as follows: 1.Prepare a Use Case(s)to describe the desired changes.This should include proposed changes to the appropriate class diagrams showing new/revised classes,attributes,and associations 2.The Use Case(s)is then reviewed by the appropriate IEC Working Group to decide if the requested changes should be treated as revisions to the current CIM standard,or if they should be treated as private amendments,not requiring a change to the standard itself. 3.Proposed amendments accepted by the working group will be added to a list of outstanding issues,and at the appropriate time,a new version of the CIM model will be prepared and an update made to the appropriate IEC CIM specification. 4.6.1.1 Changes to the CIM UML ROSE Model From a modeling perspective,when the CIM is extended,the approach is to start with the existing CIM UML model in Rational ROSE format.The extensions may be added in any of several ways that are available in UML,but in all cases the approach is to inspect the current model and determine the best way to build off of the existing class diagrams.The extensions may take the form of any of the following,starting from the simplest to the most complex: Adding additional values to existing attributes in a class Adding additional attributes to existing classes Adding new classes that are specializations of existing classes Adding new classes via associations with existing classes The main objective is to reuse the existing CIM to the maximum extent possible.From a packaging point of view,extensions should be made to existing Packages where possible.If the extensions comprise a new domain of application,then consideration should be given to creating a new Package for the additions,but still creating the necessary associations to the existing package,keeping in mind that even though a new Package is being created,the CIM is still a single ROSE model file
61970-301 IEC:2003 – 25 – All future changes to the CIM specification, resulting in new versions of this standard, will be incorporated first into the Rational ROSE model description to ensure a single source for the CIM model data. Annex A of this document was auto-generated using Rational SoDA, another modeling tool from Rational Software Corporation. SoDA generates Word documents from the ROSE model file based on a custom template created in Word that incorporates the IEC format and styles. 4.6 Modeling Guidelines This section provides guidelines on how to maintain and extend the CIM. The CIM is meant to contain classes and attributes that will be exchanged over public interfaces between major appications. The goal is to keep, as much as possible, only the generic features from which a detailed implementation may be derived. In general, it is easier to change the value or domain of an attribute than to change a class definition.This makes the model more robust because it is able to support a broader class of requirements, and more stable because new requirements may be able to be handled without requiring changes to the model. 4.6.1 Amendments to the CIM From time to time it may be desirable to amend the CIM to either revise the existing model or to extend the CIM to model additional elements of an electric utility power system. The recommended process for such amendments is as follows: 1. Prepare a Use Case(s) to describe the desired changes. This should include proposed changes to the appropriate class diagrams showing new/revised classes, attributes, and associations. 2. The Use Case(s) is then reviewed by the appropriate IEC Working Group to decide if the requested changes should be treated as revisions to the current CIM standard, or if they should be treated as private amendments, not requiring a change to the standard itself. 3. Proposed amendments accepted by the working group will be added to a list of outstanding issues, and at the appropriate time, a new version of the CIM model will be prepared and an update made to the appropriate IEC CIM specification. 4.6.1.1 Changes to the CIM UML ROSE Model From a modeling perspective, when the CIM is extended, the approach is to start with the existing CIM UML model in Rational ROSE format. The extensions may be added in any of several ways that are available in UML, but in all cases the approach is to inspect the current model and determine the best way to build off of the existing class diagrams. The extensions may take the form of any of the following, starting from the simplest to the most complex: Adding additional values to existing attributes in a class Adding additional attributes to existing classes Adding new classes that are specializations of existing classes Adding new classes via associations with existing classes The main objective is to reuse the existing CIM to the maximum extent possible. From a packaging point of view, extensions should be made to existing Packages where possible. If the extensions comprise a new domain of application, then consideration should be given to creating a new Package for the additions, but still creating the necessary associations to the existing package, keeping in mind that even though a new Package is being created, the CIM is still a single ROSE model file