61970-301©1EC:2003 -16- type name.Applications may then use this information to instantiate specific object types as required.Applications may need additional information to define the set of valid types and relationships. Classes have attributes that describe the characteristics of the objects.Each class in the CIM contains the attributes that describe and identify a specific instance of the class.Only the attributes that are of public interest to EMS applications are included in the class descriptions. Each attribute has a type,which identifies what kind of attribute it is.Typical attributes are of type integer,float,boolean,string,and enumeration,which are called primitive types.However, many additional types are defined as part of the CIM specification.For example,Compensator has a MaximumkV attribute of type Voltage.The definition of data types is contained in the Domain Package described in Section 4.2.9. Relationships between classes reveal how they are structured in terms of each other.CIM classes are related in a variety of ways,as described in the clauses below. 4.3.1 Generalization A generalization is a relationship between a more general and a more specific class.The more specific class can contain only additional information.For example,a Power Transformer is a specific type of Power System Resource.Generalization provides for the specific class to inherit attributes and relationships from all the more general classes above it. Figure 2 is an example of generalization.In this example taken from the Wires package,a Breaker is a more specific type of Switch,which in turn is a more specific type of ConductingEquipment,which is itself a more specific type of PowerSystemResource. A PowerTransformer is another more specific type of PowerSystemResource. PowerSystemResource (from Core) ConductingEquipment PowerTransformer (from Core) Switch Breaker Figure 2-Example of generalization
61970-301 IEC:2003 – 16 – type name. Applications may then use this information to instantiate specific object types as required. Applications may need additional information to define the set of valid types and relationships. Classes have attributes that describe the characteristics of the objects. Each class in the CIM contains the attributes that describe and identify a specific instance of the class. Only the attributes that are of public interest to EMS applications are included in the class descriptions. Each attribute has a type, which identifies what kind of attribute it is. Typical attributes are of type integer, float, boolean, string, and enumeration, which are called primitive types. However, many additional types are defined as part of the CIM specification. For example, Compensator has a MaximumkV attribute of type Voltage. The definition of data types is contained in the Domain Package described in Section 4.2.9. Relationships between classes reveal how they are structured in terms of each other. CIM classes are related in a variety of ways, as described in the clauses below. 4.3.1 Generalization A generalization is a relationship between a more general and a more specific class. The more specific class can contain only additional information. For example, a Power Transformer is a specific type of Power System Resource. Generalization provides for the specific class to inherit attributes and relationships from all the more general classes above it. Figure 2 is an example of generalization. In this example taken from the Wires package, a Breaker is a more specific type of Switch, which in turn is a more specific type of ConductingEquipment, which is itself a more specific type of PowerSystemResource. A PowerTransformer is another more specific type of PowerSystemResource. Figure 2 – Example of generalization Breaker ConductingEquipment (from Core) PowerSystemResource (from Core) Switch PowerTransformer
61970-301©1EC:2003 -17- 4.3.2 Simple Association An association is a conceptual connection between classes.Each association has two roles. Each role is a direction on the association that describes the role the target class(i.e.,the class the role goes to)has in relation to the source class (i.e..the class the role goes from).Roles are given the name of the target class with or without a verb phrase.Each role also has multiplicity/cardinality,which is an indication of how many objects may participate in the given relationship.In the CIM,associations are not named. For example,in the CIM there is an association between a TapChanger and a RegulationSchedule (See Figure 3 which is taken from the Wires package). Multiplicity is shown at both ends of the association.In this example,a TapChanger object may have 0 or 1 RegulationSchedules,and a RegulationSchedule may belong to 0,1,or more TapChanger objects. TapChanger RegulationSchedule 0.n 0.1 Tapchangers RegulationSchedule Figure 3-Example of Simple Association 4.3.3 Aggregation Aggregation is a special case of association.Aggregation indicates that the relationship between the classes is some sort of whole-part relationship,where the whole class "consists of" or "contains"the part class,and the part class is "part of"the whole class.The part class does not inherit from the whole class as in generalization. Figure 4 illustrates an aggregation between the Topologicallsland class and the TopologicalNode class,which is taken from the Topology package.As shown,a TopologicalNode can be a member of exactly one Topologicallsland,but a Topologicallsland can contain any number(but at least one)of TopologicalNodes. Topologicallsland TopologicalNode 1 1.n Topologicallsland TopologicalNodes Figure 4-Example of Aggregation 4.4 CIM Model Concepts and Examples The CIM classes,attributes,types,and relationships are specified in the normative Annex A. Annex A comprises a complete description of the CIM. To help understand how to interpret the CIM,four examples are given in the following paragraphs.The first is a portion of the Wires package class diagram illustrating how a PowerTransformer is modeled.The second illustrates how the important concept of Connectivity
61970-301 IEC:2003 – 17 – 4.3.2 Simple Association An association is a conceptual connection between classes. Each association has two roles. Each role is a direction on the association that describes the role the target class (i.e., the class the role goes to) has in relation to the source class (i.e., the class the role goes from). Roles are given the name of the target class with or without a verb phrase. Each role also has multiplicity/cardinality, which is an indication of how many objects may participate in the given relationship. In the CIM, associations are not named. For example, in the CIM there is an association between a TapChanger and a RegulationSchedule (See Figure 3 which is taken from the Wires package). Multiplicity is shown at both ends of the association. In this example, a TapChanger object may have 0 or 1 RegulationSchedules, and a RegulationSchedule may belong to 0, 1, or more TapChanger objects. Figure 3 – Example of Simple Association 4.3.3 Aggregation Aggregation is a special case of association. Aggregation indicates that the relationship between the classes is some sort of whole-part relationship, where the whole class “consists of” or “contains” the part class, and the part class is “part of” the whole class. The part class does not inherit from the whole class as in generalization. Figure 4 illustrates an aggregation between the TopologicalIsland class and the TopologicalNode class, which is taken from the Topology package. As shown, a TopologicalNode can be a member of exactly one TopologicalIsland, but a TopologicalIsland can contain any number (but at least one) of TopologicalNodes. Figure 4 – Example of Aggregation 4.4 CIM Model Concepts and Examples The CIM classes, attributes, types, and relationships are specified in the normative Annex A. Annex A comprises a complete description of the CIM. To help understand how to interpret the CIM, four examples are given in the following paragraphs. The first is a portion of the Wires package class diagram illustrating how a PowerTransformer is modeled. The second illustrates how the important concept of Connectivity TapChanger RegulationSchedule Tapchangers RegulationSchedule 0..n 0..1 TopologicalIsland TopologicalNode TopologicalIsland TopologicalNodes 1 1..n
61970-301©1EC:2003 -18- is modeled in the CIM.The third shows the inheritance hierarchy of devices modeled in the CIM.The fourth illustrates the important concept of equipment containers. 4.4.1 Transformer Model Figure 5 shows a portion of the Wires class diagram which models a PowerTransformer device. As shown,a PowerTransformer is a specialized class of Equipment,which is a specialized class of a PowerSystemResource,as is ConductingEquipment and TapChanger.This is shown by the use of the generalization-type of relationship,which uses an arrow to point to the general class, and permits the PowerTransformer to inherit attributes from both Equipment and PowerSystemResource. A PowerTransformer also has a TransformerWinding,which is modeled with an aggregation-type of relationship using a diamond symbol to point from the part class to the whole class.As shown,a PowerTransformer may have (or contain)one or more TransformerWindings,but a TransformerWinding may belong to(or be a member of)only one PowerTransformer. The TransformerWinding has other relationships as well: A generalization relationship with ConductingEquipment An association relationship with the WindingTest class,such that a TransformerWinding object may be TestedFrom from 0,1,or more WindingTest objects. An aggregation relationship with the TapChanger class,such that a TransformerWinding object may have 0,1,or more TapChanger objects associated with it. Annex A contains a complete description of each class in Figure 5 along with the definition of all the attributes and relationships supported in each class
61970-301 IEC:2003 – 18 – is modeled in the CIM. The third shows the inheritance hierarchy of devices modeled in the CIM. The fourth illustrates the important concept of equipment containers. 4.4.1 Transformer Model Figure 5 shows a portion of the Wires class diagram which models a PowerTransformer device. As shown, a PowerTransformer is a specialized class of Equipment, which is a specialized class of a PowerSystemResource, as is ConductingEquipment and TapChanger. This is shown by the use of the generalization-type of relationship, which uses an arrow to point to the general class, and permits the PowerTransformer to inherit attributes from both Equipment and PowerSystemResource. A PowerTransformer also has a TransformerWinding, which is modeled with an aggregation-type of relationship using a diamond symbol to point from the part class to the whole class. As shown, a PowerTransformer may have (or contain) one or more TransformerWindings, but a TransformerWinding may belong to (or be a member of) only one PowerTransformer. The TransformerWinding has other relationships as well: A generalization relationship with ConductingEquipment An association relationship with the WindingTest class, such that a TransformerWinding object may be TestedFrom from 0, 1, or more WindingTest objects. An aggregation relationship with the TapChanger class, such that a TransformerWinding object may have 0, 1, or more TapChanger objects associated with it. Annex A contains a complete description of each class in Figure 5 along with the definition of all the attributes and relationships supported in each class
61970-301©1EC:2003 -19- PowerSystemResource (from Core) Equipment PowerTransformer TapChanger (from Core) +PowerTransformer 1 0.n 0.n +TapChangers TapChangers +MemberOf PowerTransformer +HeatExchanger 0.1 HeatExchanger +Contains_TransformerWindings +RegulationSchedule 1.n 0.1 ConductingEquipment TransformerWinding RegulationSchedule (from Core) +TransformerWinding 0.n +To_TransformeWindings +From_TransformerWinding +To_WindingTest +From_WindingTests /0.n WindingTest Figure 5-Transformer Model 4.4.2 Connectivity Model Figure 6 shows the Topology class diagram which models connectivity between different types of ConductingEquipment.Also included is a portion of the Meas package class diagram dealing with measurements to illustrate how measurements are associated with conducting equipment
61970-301 IEC:2003 – 19 – ConductingEquipment (from Core) Equipment (from Core) PowerSystemResource (from Core) RegulationSchedule TapChanger 0..1 0..n +RegulationSchedule 0..1 +TapChangers 0..n WindingTest HeatExchanger TransformerWinding 0..n 1 +TapChangers 0..n +TransformerWinding 1 1 0..n +From_TransformerWinding 1 +From_WindingTests 1 0..n 0..n +To_WindingTest 1 +To_TransformeWindings0..n PowerTransformer 0..1 1 +HeatExchanger 0..1 +PowerTransformer 1 1..n 1 +Contains_TransformerWindings 1..n +MemberOf_PowerTransformer 1 Figure 5 – Transformer Model 4.4.2 Connectivity Model Figure 6 shows the Topology class diagram which models connectivity between different types of ConductingEquipment. Also included is a portion of the Meas package class diagram dealing with measurements to illustrate how measurements are associated with conducting equipment
61970-301©1EC:2003 -20- Naming (from Core) PowerSystemResource (from Core) +ConductingEquipment +Terminals ConductingEquipment 0.1 0..nTerminal (from Core) (from Core) 0.n +Terminals 0.1 +Terminal EquipmentContainer +MemberOf EquipmentContainer (from Core) 1 +ConnectivityNodes +ConnectivityNode 0.n 0.1 ConnectivityNode +Measurements 0.n 0..n +ConnectivityNodes Measurement (from Meas) +TopologicalNode Switch/Node ◇0.1 Model TopologicalNode +TopologicalNodes 1.n Bus/Branch Model +Topologicallsland 10 Topologicallsland Figure 6-Connectivity Model To model connectivity,Terminal and Connectivity classes are defined.A Terminal belongs to one ConductingEquipment,although ConductingEquipment may have any number of Terminals.Each Terminal may be connected to a ConnectivityNode,which is a point where terminals of conducting equipment are connected together with zero impedance.A ConnectivityNode may have any number of terminals connected,and may be a member of a TopologicalNode (i.e.,a bus),which is in turn a member of a Topologicallsland.TopologicalNodes and Topologicallslands are created as a result of a topology processor evaluating the"as built"topology and the actual Switch positions. EquipmentContainers,which are a specialization of a PowerSystemResource,may contain zero or more ConnectivityNodes.The associations,ConductingEquipment-Terminal and Terminal ConnectivityNode,capture the as built topology of an actual power system network.For each
61970-301 IEC:2003 – 20 – Bus/Branch Model Switch/Node Model Naming (from Core) PowerSystemResource (from Core) TopologicalIsland ConductingEquipment (from Core) Measurement (from Meas) TopologicalNode 1 1..n +TopologicalIsland 1 +TopologicalNodes 1..n Terminal (from Core) 0..1 0..n +Terminals 0..n +ConductingEquipment 0..1 0..n 0..1 +Measurements 0..n +Terminal 0..1 EquipmentContainer (from Core) ConnectivityNode 0..n 0..1 +ConnectivityNodes 0..n +TopologicalNode 0..1 0..n 0..1 +Terminals 0..n +ConnectivityNode 0..1 1 0..n +MemberOf_EquipmentContainer 1 +ConnectivityNodes 0..n Figure 6 – Connectivity Model To model connectivity, Terminal and Connectivity classes are defined. A Terminal belongs to one ConductingEquipment, although ConductingEquipment may have any number of Terminals. Each Terminal may be connected to a ConnectivityNode, which is a point where terminals of conducting equipment are connected together with zero impedance. A ConnectivityNode may have any number of terminals connected, and may be a member of a TopologicalNode (i.e., a bus), which is in turn a member of a TopologicalIsland. TopologicalNodes and TopologicalIslands are created as a result of a topology processor evaluating the “as built” topology and the actual Switch positions. EquipmentContainers, which are a specialization of a PowerSystemResource, may contain zero or more ConnectivityNodes. The associations, ConductingEquipment – Terminal and Terminal – ConnectivityNode, capture the as built topology of an actual power system network. For each