Program on Technology Innovation:
Distribution Common Information Model (CIM)
Modeling of Two North American Feeders
Effective May 4, 2009, this report has been made publicly available in accordance
with Section 734.3(b)(3) and published in accordance with Section 734.7 of the U.S.
Export Administration Regulations. As a result of this publication, this report is subject
to only copyright protection and does not require any license agreement from EPRI.
This notice supersedes the export control restrictions and any proprietary licensed
material notices embedded in the document prior to publication
Program on Technology Innovation:
Distribution Common Information Model (CIM) Modeling
of Two North American Feeders
1018281
Final Report, March 2009
EPRI Project Manager
L. King
ELECTRIC POWER RESEARCH INSTITUTE
3420 Hillview Avenue, Palo Alto, California 94304-1338 ▪ PO Box 10412, Palo Alto, California 94303-0813 ▪ USA
800.313.3774 ▪ 650.855.2121 ▪ askepri@epri.com ▪ www.epri.com
DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES
THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION NAMED BELOW AS AN ACCOUNT OF WORK
SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH INSTITUTE, INC. (EPRI).
NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE ORGANIZATION BELOW, 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 EPRI OR ANY EPRI 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.
ORGANIZATION THAT PREPARED THIS DOCUMENT
EnerNex Corporation
NOTE
For further information about EPRI, call the EPRI Customer Assistance Center at 800.313.3774 or
e-mail askepri@epri.com.
Electric Power Research Institute, EPRI, and TOGETHER…SHAPING THE FUTURE OF ELECTRICITY
are registered service marks of the Electric Power Research Institute, Inc.
Copyright © 2009 Electric Power Research Institute, Inc. All rights reserved.
CITATIONS
This document was prepared by
EnerNex Corporation
620 Mabry Hood Road, Suite 300
Knoxville, TN 37932
Principal Investigator
T. McDermott
This document describes research sponsored by the Electric Power Research Institute (EPRI).
This publication is a corporate document that should be cited in the literature in the following
manner:
Program on Technology Innovation: Distribution Common Information Model (CIM) Modeling
of Two North American Feeders. EPRI, Palo Alto, CA: 2009. 1018281.
iii
PRODUCT DESCRIPTION
North American distribution feeders differ from the transmission systems that the Common
Information Model (CIM) was originally developed to represent, and they also differ from
distribution systems in most other parts of the world. For example, North American lines
and loads are typically unbalanced; many lines and transformers are single-phase or two-phase;
and grounding practices vary.
Results and Findings
This report presents the results of modeling two North American feeders along with a gap
analysis identifying new modeling needed in the CIM—specifically the Common Distribution
Power System Model (CDPSM)—to better support North American feeders.
Challenges and Objectives
This project modeled two different North American distribution feeders in the CIM to the
extent possible. A gap analysis is provided, including preliminary suggestions of methods to
close these gaps. The scope includes electrical, asset, geographic, and load modeling issues.
Applications, Values, and Use
This project was undertaken to address the concerns raised by utility industry stakeholders that
the CIM was not adequate to completely and accurately model North American distribution
systems. The results of this research will be used by the IEC TC 57 WG 14 to improve the
CIM to resolve these issues.
EPRI Perspective
EPRI has been at the forefront of the development of the CIM from its beginning. EPRI
continues to identify industry needs that the CIM can help meet, in this case with an accurate
and complete distribution model that will not only aid system interoperability but also enable
applications that can lead to a smarter grid.
Approach
The project team identified two participating utilities to supply feeder data: Alabama Power
and PacifiCorp. The criterion for a good candidate feeder was one that would present sufficient
variety in the equipment employed. The initial project task was to gather appropriate data and
information from the utilities for the modeling work.
Each participating utility provided the following:
1. Feeder electrical model data, in a text format. These data included, where possible, any
referenced equipment or line data from a library, along with overcurrent protection and
voltage control device settings.
2. Geographic Information System (GIS) data corresponding to the feeder, in a text format.
These data included the geographic routing and connectivity.
3. Load data corresponding to the feeder, in a text format. These data included customer
numbers, sizes, or classes; load profile or survey data; monthly energy usage; and peak
kW and power factor.
v
4. A one-line diagram of the substation serving the feeder, including the transformer
MVA, kV, impedance, winding connections, and neutral impedances, if any.
5. Documentation of the data formats provided, subject to vendor disclosure requirements.
Items 1-3 were provided in an electronic format, so that automated processing tools could be
applied.
Identifying feeder data was obfuscated in the resulting models and in this report.
Keywords
Common Information Model
CIM
Distribution
vi
ACKNOWLEDGMENTS
We would like to thank PacifiCorp and Alabama Power Company, a subsidiary of Southern
Company, for providing example feeder models. The following people were helpful answering
questions and providing feedback on the interim reports:
•
•
•
Nathan Wilson, PacifiCorp
G. Larry Clark, Alabama Power Company
J. Mark Swindall, Alabama Power Company
Roger Dugan of EPRI helped with OpenDSS software enhancements during the project.
vii
CONTENTS
1 INTRODUCTION ....................................................................................................................1-1
Problem Statement ..............................................................................................................1-1
Technical Approach .............................................................................................................1-1
2 OPENDSS MODEL DEVELOPMENT ....................................................................................2-1
PacifiCorp’s Feeder..............................................................................................................2-1
Alabama Power Company’s Feeder ....................................................................................2-2
Simulation Results ...............................................................................................................2-3
3 CIM MODEL DEVELOPMENT ...............................................................................................3-1
OpenDSS to CIM Export and Validation Tools ....................................................................3-1
Example: Voltage Level and Base Voltage ..........................................................................3-2
Example: Connectivity Node ................................................................................................3-2
Example: Substation or Source............................................................................................3-3
Example: Line ......................................................................................................................3-3
Example: Load .....................................................................................................................3-4
Example: Capacitor..............................................................................................................3-4
Example: Transformer..........................................................................................................3-5
Example: Voltage Regulator ................................................................................................3-6
Example: Switching Devices ................................................................................................3-8
Example: Line Code (Possible CIM Extension) ...................................................................3-8
Example: Line Geometry......................................................................................................3-9
4 GAP ANALYSIS .....................................................................................................................4-1
CIM Issues ...........................................................................................................................4-1
OpenDSS Issues..................................................................................................................4-3
5 CONCLUSIONS AND RECOMMENDATIONS ......................................................................5-1
6 REFERENCES .......................................................................................................................6-1
A FEEDER ELECTRICAL MODELING IN CIM ....................................................................... A-1
B FEEDER ELECTRICAL MODELING IN CIM ....................................................................... B-1
ix
1
INTRODUCTION
This chapter describes the project objective and our approach to attain that objective. A recent
EPRI report [1] provides a comprehensive introduction to the IEC Common Information Model
(CIM) for Distribution, including different parts of the IEC standards, and software tools for
working with the CIM. The reader should have access to [1], and should periodically check the
CIM Users Group web site [2] for updates to the draft standards. There has been previous work
attempting to apply the CIM to North American distribution feeders [3-6], but no interoperability
testing has occurred and the CIM has not yet evolved to support North American feeders. In
contrast, the National Rural Electric Cooperative Association’s MultiSpeak Specification has
evolved specifically to support North American feeders [7-8]. This project was undertaken to
help ensure that CIM offers good support for North American feeders.
Problem Statement
North American distribution feeders differ from the transmission systems that CIM was
originally developed to represent, and they also differ from distribution systems in most other
parts of the world. For example, both lines and loads are typically unbalanced. Many lines and
transformers are single-phase or two-phase. Grounding practices vary. Two different North
American distribution feeders will be represented, to the extent possible, in the CIM. A gap
analysis will be provided, including at least preliminary suggestions of methods to close these
gaps. The scope includes electrical, asset, geographic, and load modeling.
Technical Approach
Two participating utilities were identified: PacifiCorp and Alabama Power Company. These two
utilities use Areva DMS, CYME International CYMDIST, and ABB FeederAll for engineering
analysis software. Their input files were translated from the original formats into netlists for
EPRI’s OpenDSS software, recently released as open source [9]. This provides a means to
validate the model translation, by comparing power flow solutions in OpenDSS to the original
software outputs. The next step was to translate the models from OpenDSS into CIM-compatible
formats; this step cannot be validated yet because the CIM has not been finalized for distribution
power flow models.
Figure 1-1 shows how OpenDSS plays an important role in the model translation efforts. The
translation path shown in black, from MultiSpeak version 2 to OpenDSS, was completed earlier
in a different project [10], partially funded by EPRI. The paths shown in red, from Areva or
FeederAll into OpenDSS, and from OpenDSS into CIM, were accomplished in this project. The
paths shown in blue, an import from CIM and two-way transfers with MultiSpeak v4, may be
implemented in future projects. When completed, this suite of software tools and translators will
support the Common Distribution Power System Model (CDPSM) interoperability testing, which
is tentatively planned for November 2009. Previous experience shows that CIM interoperability
testing is a critical step in making the CIM ready for actual use. That is why we implemented the
project results with components that can be used in future interoperability testing.
1-1
Results of a previous modeling effort and gap analysis [4] were not fully adopted into the CIM.
This current EPRI research project has technology transfer and advocacy components that cannot
be short-changed. In addition to this report, a presentation was delivered at the TC 57 / WG 14
meeting on October 16, 2008 in Melbourne, Florida (see Appendix A). A similar presentation
was made in EPRI’s CIM for Distribution Webcast on December 11, 2008 (see Appendix B).
Regular conference calls are on-going to address CIM issues with the IEC TC 57 / WG 14
Part 11 “modeling team”.
OpenDSS
MultiSpeak
v4 XML/XSD
CIM
XML/RDF
XSLT
FeederAll
MDB
Excel
VBA
DSS
Netlist
XSLT
Figure 1-1
Model translation for CIM, OpenDSS, and other software
1-2
XSLT
MultiSpeak
v2 XML
(Milsoft/UWIG)
Areva DMS
XML
2
OPENDSS MODEL DEVELOPMENT
This chapter describes the process of translating the two example feeder models into OpenDSS,
and the results of power flow simulation in OpenDSS.
PacifiCorp’s Feeder
The data was provided in a MS Access file from ABB’s FeederAll program. The data was copied
to an Excel spreadsheet, and then exported to OpenDSS using Visual Basic for Applications
(VBA) code. With the original data provided in a Microsoft application, it was most convenient
to use Microsoft tools for the model translation to OpenDSS.
In general, it was possible to determine the parameter units and proper usage from the FeederAll
database. The switching devices are incorporated into line sections; this matches the OpenDSS
model. Transformers are also incorporated into line sections, which required the generation of
some internal nodes. The model comprises:
•
•
•
•
•
•
•
•
•
1 Feeder
12.5 MVA substation transformer
1209 line sections
870 loads, most of them unbalanced
2 shunt capacitors, fixed
21 switches
4 sectionalizers
4 reclosers
3 voltage regulators
The FeederAll data includes conductor and spacing data in metric units. However, the conductor
data is not shared among line types (i.e., there are usually 3 separate entries of the same data for
3 phase positions). Also, the FeederAll schema stores pair-wise distances between conductors
and heights, instead of horizontal positions and heights. These were not all consistent. Many of
the cable charging values did not match available typical data. A small number of loads were
missing power factors, and a small number of lines referenced invalid library entries.
In response to follow-up questions, PacifiCorp provided feeder load current levels, and line
voltage regulator settings. In many instances, single-phase loads and lines appeared to be miswired. We obtained a sample sketch from PacifiCorp’s FeederAll program to help resolve these
situations. That example showed a single-phase lateral on phase C, serving a load on phase C
connected at an interior point. In the database, the load was defined on phase C, but one lateral
segment carried “conductor 2” and the other carried “conductor 1”. None of the three match.
Further investigation showed many instances like that, producing isolated loads and subnetworks
that prevented a valid power flow solution. All nodes in the system are defined as three-phase,
which does not help to resolve these ambiguities.
2-1
There are at least three ways that FeederAll might be handling this situation to produce valid
power flow results on single-phase or two-phase laterals:
1. Tracing from loads with defined phases, adjust the wire assignments to ensure
connectivity. (An unofficial source indicates this is the most likely explanation.)
2. If using a symmetrical component approach, the single-phase loads may be distributed on
all three phases, with equivalent Z1 and Z0 line parameters. (However, this would not
explain how “C” appears on the screen shot from PacifiCorp.)
3. There may be another table that defines the phase assignments.
Further investigation is expected to resolve this issue in the near future, as EnerNex assists
PacifiCorp with translation of another FeederAll model, and as EPRI assists other clients with
FeederAll translation.
Alabama Power Company’s Feeder
The original data was provided in an XML (with XSD) file compatible with Areva’s DMS.
This XML file was translated to OpenDSS using an XSLT 2.0 stylesheet. It was found that the
Saxon-B parser [11] offers the best support for XSLT-based conversion, and it’s free. This parser
requires Java. There is a .Net version that has been cross-compiled from the Java version, so it
offers no real advantage over the Java version. Microsoft’s XML parsers have some version
incompatibilities that become difficult to work with. For any model provided in XML, such as
Areva DMS or MultiSpeak, the use of XSLT becomes attractive because it can “pull” data as
needed from the source XML file, using relatively simple XPATH expressions.
The tap changer and line regulator parameters, which are optional in Areva’s schema, were not
included in the XML. Switching devices are separate from the line sections, so these were
modeled separately in OpenDSS. The customer load is all defined on ServicePoints, which are
fed from service transformers having their own kVA rating. The loads were allocated for
OpenDSS using 400 amperes in each feeder. The system model comprises:
•
•
•
•
•
•
•
•
•
•
•
1 substation source
2 feeders, Fdr2 and Fdr6
1175 transformers (some associated to 79 banks, not used in the OpenDSS model)
1037 service points
2351 line segments, including both overhead and underground
5 shunt capacitors that are SCADA-controlled
57 switches
10 reclosers
1 sectionalizer
136 fuses
4 voltage regulators
2-2
In response to follow-up questions, Alabama Power provided the Areva line construction data
in CSV files, and a CYMDIST file for several feeders. The CYMDIST file included substation
source impedance, and line voltage regulator settings. Three of the regulators are “autoboosters”, with a reduced number of taps and only in the boost direction, but otherwise like
a standard regulator. The CYMDIST data was manually added to the OpenDSS netlists.
The feeders also include line post sensors for capacitor bank control and other monitoring
functions. There was not specific reference to these in either the Areva XML or the CymDist file.
They represent assets. In OpenDSS they might correspond to an energy meter or sensor, or they
could be incorporated into capacitor and switch controls.
For this example, the capacitor controls were implemented as local voltage control, sensing
the primary voltage directly (i.e., a PT ratio of 1). Neither OpenDSS nor the CIM presently
models capacitor control via SCADA. (In operating practice, the capacitors are switched for
VAR requirement at point of application with voltage override with the switching performed on
a per phase basis as required.)
Most of the transformers in this model were service transformers, feeding service points. Loads
were automatically added at the service points, based on the transformer kVA rating and a
nominal power factor. The CIM does not represent loads this way, but OpenDSS can allocate
loads (as can most distribution analysis software) and calculate nominal power levels before the
CIM export occurs.
Simulation Results
Figure 2-1 shows the layout of line segments in OpenDSS for the PacifiCorp feeder. Some of the
isolated sections can be seen. There is no valid power flow solution for this circuit in OpenDSS,
due to the mis-wired single-phase loads discussed above. This may be resolved in subsequent
work already funded for 2009.
Figure 2-1
PacifiCorp feeder in OpenDSS graph
2-3
Figure 2-2 shows the layout of line segments for the two Alabama Power feeders. The segment
widths are weighted by current flow, and the substation is located near the left end of the thickest
blue lines. With loading set at 30% of the connected transformer kVA, the total power delivered
was 6.85721 MW, with losses of 3.926%.
Figure 2-2
Alabama power feeders in OpenDSS graph
2-4
3
CIM MODEL DEVELOPMENT
This chapter describes the CIM RDF model files produced in the project. There were three
examples used:
1. PacifiCorp’s model was 3.5 MB as a FeederAll database (Microsoft Access MDB file),
translated to a 220 KB OpenDSS netlist, and then to a 2.87 MB CIM RDF file.
2. Alabama Power’s model (two feeders) was 3.25 MB as an Areva XML file, translated
to a 510 KB OpenDSS netlist, and then to a 8.88 MB CIM RDF file.
3. A smaller distribution model, used to illustrate line geometry input, was translated from
a 30 KB OpenDSS netlist, to a 307 KB CIM RDF file.
On average, the CIM RDF model is around 10 to 15 times larger than the OpenDSS netlist,
which is fairly terse.
OpenDSS to CIM Export and Validation Tools
Initially, an attempt was made at using XSLT for the translation from OpenDSS netlist to
CIM RDF, but that offers no advantage over code-based translation. XSLT 2.0 has text-parsing
support, but offers no real benefit for an unstructured text file. The translation was finally
implemented in Delphi code, from the OpenDSS program. A new “export cdpsm” command
was added, and is now part of the open source software distribution. There are apparently no
RDF-specific tool sets, but even if available, they might not offer any advantage because the
CIM RDF has a very flat structure.
CIMSpy [12] was used to validate some of the exported CIM RDF syntax, which led to some
corrections. However, a complete and updated set of validation rules for CDPSM is not yet
available. The examples provided in this chapter contain a mixture of:
1. Classes and attributes defined in the latest published IEC 61968-13, although the
CIM has deleted some of the referenced classes (e.g., EquivalentLoad) since then.
2. Classes and attributes defined in the current CIM version 14.
3. Proposed new or modified classes and attributes.
By the end of 2009, it should be possible to resolve all such inconsistencies with further work
on IEC 61968 Part 11 (modeling), Part 13 (CDPSM), and the interoperability testing.
The examples in this chapter use unique IDs within the model, but in practice globally unique
identifiers (GUIDS) will be required to guarantee uniqueness within the problem domain
(i.e. across models and power systems).
3-1
It is apparent that CIM RDF objects are written in a flat structure, with no hierarchy and no order
dependence. However, an object will often contain references to other objects. This makes the
file simple to write, but probably more complicated to read. One method would be to read the
entire file into memory, building data structures along the way. Then in a second pass, the
references between data structures would be resolved using the unique identifiers. Finally,
the CIM-derived data structures can be translated into the native file format.
Example: Voltage Level and Base Voltage
This listing shows the XML header and the Voltage Level and Base Voltage, written first. Base
Voltages pertain to transformer windings and AC line segments. Voltage Levels pertain to
substations, connectivity nodes, and most kinds of equipment; they are similar to Base Voltages,
with the addition of minimum and maximum operating levels.
<?xml version="1.0" encoding="utf-8"?>
<!-- un-comment this line to enable validation
-->
<rdf:RDF xmlns:cim="http://iec.ch/TC57/2008/CIM-schema-cim13#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!--->
<cim:BaseVoltage rdf:ID="BaseVoltage_0.120">
<cim:IdentifiedObject.name>BaseVoltage_0.120</cim:IdentifiedObject.name>
<cim:BaseVoltage.nominalVoltage>0.12</cim:BaseVoltage.nominalVoltage>
</cim:BaseVoltage>
<cim:VoltageLevel rdf:ID="VoltageLevel_0.120">
<cim:IdentifiedObject.name>VoltageLevel_0.120</cim:IdentifiedObject.name>
<cim:VoltageLevel.BaseVoltage rdf:resource="#BaseVoltage_0.120"/>
<cim:VoltageLevel.lowVoltageLimit>0.114</cim:VoltageLevel.lowVoltageLimit>
<cim:VoltageLevel.highVoltageLimit>0.126</cim:VoltageLevel.highVoltageLimit>
</cim:VoltageLevel>
This listing shows the required tag closing the XML file:
</rdf:RDF>
Example: Connectivity Node
This listing is for a connectivity node with X and Y coordinates as a shortcut. The OpenDSS
stores X and Y positions for each bus, which makes it simple to write a section of connectivity
nodes in one block. In the CIM, positions are actually associated to equipment and not to nodes,
but this has not yet been exercised in a test. For distribution systems, it is common for the feeder
map to be defined by geographic positions, even for power flow calculations. OpenDSS could be
enhanced to write equipment positions based on the terminal bus positions.
<cim:ConnectivityNode rdf:ID="CN_420">
<cim:IdentifiedObject.name>420</cim:IdentifiedObject.name>
<cim:ConnectivityNode.MemberOf_EquipmentContainer rdf:resource="#VoltageLevel_7.200"/>
<cim:PositionPoint.xPosition>2062394</cim:PositionPoint.xPosition>
<cim:PositionPoint.yPosition>865573</cim:PositionPoint.yPosition>
</cim:ConnectivityNode>
3-2
Example: Substation or Source
This listing describes a substation, connected to connectivity node 420, with a terminal
mediating the connection between substation and connectivity node. The Energy Source
class was used to define the substation source impedance, but this should be clarified in the
CDPSM profile.
<cim:Substation rdf:ID="Sub_source">
<cim:IdentifiedObject.name>source</cim:IdentifiedObject.name>
</cim:Substation>
<cim:EnergySource rdf:ID="Eq_source">
<cim:IdentifiedObject.name>source</cim:IdentifiedObject.name>
<cim:Equipment.MemberOf_EquipmentContainer rdf:resource="#VoltageLevel_12.470"/>
<cim:ConductingEquipment.phases>ABC</cim:ConductingEquipment.phases>
<cim:EnergySource.nominalVoltage>12.47</cim:EnergySource.nominalVoltage>
<cim:EnergySource.voltageMagnitude>12.47</cim:EnergySource.voltageMagnitude>
<cim:EnergySource.voltageAngle>0</cim:EnergySource.voltageAngle>
<cim:EnergySource.r>0.16987</cim:EnergySource.r>
<cim:EnergySource.x>1.02971333333333</cim:EnergySource.x>
<cim:EnergySource.r0>0.07153</cim:EnergySource.r0>
<cim:EnergySource.x0>0.715303333333333</cim:EnergySource.x0>
</cim:EnergySource>
<cim:Terminal rdf:ID="Trm_Eq_source_T1">
<cim:IdentifiedObject.name>Eq_source_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Eq_source"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_420"/>
</cim:Terminal>
Example: Line
This listing describes a single-phase line segment, with two terminals mediating the connection
to connectivity nodes at each end, and one internal AC line segment. The sequence impedance
parameters should not be used directly in a power flow calculation for single-phase lines.
Instead, one of the following three alternatives could apply:
1. The CondCode attribute of 8 could be referenced to the Line Code, a possible CIM
extension described later in this section. The Line Code extension can model either
sequence impedances or phase impedance matrices per unit length.
2. Adjust the sequence impedance outputs so that correct self and mutual impedances
can be derived from them.
3. Use the existing Conductor Type modeling capability in CIM. If the actual conductor
types and wire arrangements are not available, an exporting software package might
reverse-engineer the physical data so that correct impedances are obtained.
<cim:Line rdf:ID="Line_1919631">
<cim:IdentifiedObject.name>1919631</cim:IdentifiedObject.name>
</cim:Line>
<cim:Terminal rdf:ID="Trm_Line_1919631_T1">
<cim:IdentifiedObject.name>Line_1919631_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Line_1919631"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_1919620"/>
</cim:Terminal>
<cim:Terminal rdf:ID="Trm_Line_1919631_T2">
<cim:IdentifiedObject.name>Line_1919631_T2</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Line_1919631"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_1919621"/>
</cim:Terminal>
3-3
<cim:ACLineSegment rdf:ID="Seg_1919631">
<cim:IdentifiedObject.name>1919631</cim:IdentifiedObject.name>
<cim:ACLineSegment.MemberOf_Line rdf:resource="#Line_1919631"/>
<cim:ConductingEquipment.BaseVoltage rdf:resource="#BaseVoltage_12.470"/>
<cim:Conductor.length>203.8837</cim:Conductor.length>
<cim:ConductingEquipment.phases>A</cim:ConductingEquipment.phases>
<cim:Conductor.r>0.058</cim:Conductor.r>
<cim:Conductor.x>0.1206</cim:Conductor.x>
<cim:Conductor.bch>3.4E-009</cim:Conductor.bch>
<cim:Conductor.r0>0.058</cim:Conductor.r0>
<cim:Conductor.x0>0.1206</cim:Conductor.x0>
<cim:Conductor.bch0>3.4E-009</cim:Conductor.bch0>
<cim:CondCode>8</cim:CondCode>
</cim:ACLineSegment>
Example: Load
The following is a single-phase load with its terminal. The voltage level is phase-neutral.
<cim:EquivalentLoad rdf:ID="Load_1721234a">
<cim:IdentifiedObject.name>1721234a</cim:IdentifiedObject.name>
<cim:EquivalentLoad.MemberOf_EquipmentContainer rdf:resource="#VoltageLevel_7.200"/>
<cim:ConductingEquipment.phases>A</cim:ConductingEquipment.phases>
<cim:EnergyConsumer.qfixed>10.8972473588517</cim:EnergyConsumer.qfixed>
<cim:EnergyConsumer.pfixed>22.5</cim:EnergyConsumer.pfixed>
<cim:EnergyConsumer.customerCount>1</cim:EnergyConsumer.customerCount>
</cim:EquivalentLoad>
<cim:Terminal rdf:ID="Trm_Load_1721234a_T1">
<cim:IdentifiedObject.name>Load_1721234a_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Load_1721234a"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_1721287"/>
</cim:Terminal>
This listing is for a three-phase load, with its terminal. The voltage level is phase-phase.
<cim:EquivalentLoad rdf:ID="Load_1853488">
<cim:IdentifiedObject.name>1853488</cim:IdentifiedObject.name>
<cim:EquivalentLoad.MemberOf_EquipmentContainer rdf:resource="#VoltageLevel_12.470"/>
<cim:ConductingEquipment.phases>ABC</cim:ConductingEquipment.phases>
<cim:EnergyConsumer.qfixed>65.3834841531101</cim:EnergyConsumer.qfixed>
<cim:EnergyConsumer.pfixed>135</cim:EnergyConsumer.pfixed>
<cim:EnergyConsumer.customerCount>1</cim:EnergyConsumer.customerCount>
</cim:EquivalentLoad>
<cim:Terminal rdf:ID="Trm_Load_1853488_T1">
<cim:IdentifiedObject.name>Load_1853488_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Load_1853488"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_1853491"/>
</cim:Terminal>
Example: Capacitor
This example is a three-phase capacitor bank with local voltage control. The available control
modes in CIM are voltage, current, and reactive power. In addition, time, temperature, and power
factor control modes often appear on distribution systems. The PT ratio was defined as 1, so that
the set points are feeder primary volts to ground, rather than per-unit or on the more typical base
of 120 volts.
<cim:ShuntCompensator rdf:ID="Cap_c81">
<cim:IdentifiedObject.name>c81</cim:IdentifiedObject.name>
<cim:Equipment.MemberOf_EquipmentContainer rdf:resource="#VoltageLevel_12.470"/>
<cim:ConductingEquipment.phases>ABC</cim:ConductingEquipment.phases>
<cim:ShuntCompensator.reactivePerSection>600</cim:ShuntCompensator.reactivePerSection>
<cim:ShuntCompensator.normalSections>1</cim:ShuntCompensator.normalSections>
<cim:ShuntCompensator.maximumSections>1</cim:ShuntCompensator.maximumSections>
3-4
</cim:ShuntCompensator>
<cim:Terminal rdf:ID="Trm_Cap_c81_T1">
<cim:IdentifiedObject.name>Cap_c81_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Cap_c81"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_202_20955"/>
</cim:Terminal>
<cim:RegulatingControl rdf:ID="CapC_c81">
<cim:IdentifiedObject.name>c81</cim:IdentifiedObject.name>
<cim:RegulatingControl.regulatingCondEq rdf:resource="#Cap_c81"/>
<cim:RegulatingControl.terminal rdf:resource="#Cap_capacitor.c81"/>
<cim:RegulatingControl.mode>voltage</cim:RegulatingControl.mode>
<cim:RegulatingControl.discrete>1</cim:RegulatingControl.discrete>
<cim:RegulatingControl.targetValue>6840</cim:RegulatingControl.targetValue>
<cim:RegulatingControl.targetRange>7560</cim:RegulatingControl.targetRange>
</cim:RegulatingControl>
Example: Transformer
This listing describes a single-phase service transformer, with two windings and a terminal for
each winding. The containing power transformer allows for up to 4 windings, because they are
named (up to “quaternary”) not numbered. There appears to be no way of explicitly modeling the
center-tapped secondary, which is very common on distribution systems, so this example shows
only a single 120-volt secondary. The primary winding base voltage is 7.2 kV, because it’s
connected phase-to-neutral.
<cim:PowerTransformer rdf:ID="Xf_2002000006813885">
<cim:IdentifiedObject.name>2002000006813885</cim:IdentifiedObject.name>
<cim:PowerTransformer.phases>C</cim:PowerTransformer.phases>
</cim:PowerTransformer>
<cim:TransformerWinding rdf:ID="Wdg_2002000006813885_1">
<cim:IdentifiedObject.name>2002000006813885_1</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_2002000006813885"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_7.200"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.025</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>7.2</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>0.025</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>primary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>Y</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:TransformerWinding rdf:ID="Wdg_2002000006813885_2">
<cim:IdentifiedObject.name>2002000006813885_2</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_2002000006813885"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_0.120"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.025</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>0.12</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>0.025</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>secondary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>Y</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:Terminal rdf:ID="Trm_Wdg_2002000006813885_1_T1">
<cim:IdentifiedObject.name>Wdg_2002000006813885_1_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_2002000006813885_1"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_195_2759950"/>
</cim:Terminal>
<cim:Terminal rdf:ID="Trm_Wdg_2002000006813885_2_T1">
<cim:IdentifiedObject.name>Wdg_2002000006813885_2_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_2002000006813885_2"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_195_2759950_1"/>
</cim:Terminal>
3-5
The next listing is a three-phase, two-winding substation transformer with line-to-line voltage
bases. All of the transformer impedances have been written per winding for a star equivalent.
Winding Tests should be used for three-winding and four-winding transformers, but none of
those occurred in the example feeders. This usage should be defined and tested in the CDPSM.
<cim:PowerTransformer rdf:ID="Xf_ewym1">
<cim:IdentifiedObject.name>ewym1</cim:IdentifiedObject.name>
<cim:PowerTransformer.phases>ABC</cim:PowerTransformer.phases>
</cim:PowerTransformer>
<cim:TransformerWinding rdf:ID="Wdg_ewym1_1">
<cim:IdentifiedObject.name>ewym1_1</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_ewym1"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_115.000"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.2065</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>115</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>100</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>primary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>D</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:TransformerWinding rdf:ID="Wdg_ewym1_2">
<cim:IdentifiedObject.name>ewym1_2</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_ewym1"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_13.279"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.2065</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>13.27905</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>100</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>secondary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>Y</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:Terminal rdf:ID="Trm_Wdg_ewym1_1_T1">
<cim:IdentifiedObject.name>Wdg_ewym1_1_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_ewym1_1"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_ewym8115"/>
</cim:Terminal>
<cim:Terminal rdf:ID="Trm_Wdg_ewym1_2_T1">
<cim:IdentifiedObject.name>Wdg_ewym1_2_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_ewym1_2"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_ewym23b1"/>
</cim:Terminal>
Example: Voltage Regulator
This listing is for a line voltage regulator, single-phase line-to-neutral, and part of a three-phase
bank of regulators. First, a two-winding power transformer is defined with 1:1 voltage
transformation ratio, and a terminal for each winding. Next comes a ratio transformer for the
taps on winding 2. This is an auto-booster with only 4 tap steps. The neutral position is always
written as the center tap position from OpenDSS, but for an auto-booster the neutral would
probably be 0. The OpenDSS power flow solution actually determines the tap position. As with
capacitor control, the lack of a PT ratio in the CIM requires that voltage be specified on the
feeder primary. It’s not clear whether the target range attribute can adequately describe a
regulator’s bandwidth setting. The line drop compensator R and X values, which are not
actually used in this example, are written to the Regulation Schedule object. The CT ratio
should be accounted for, along with possibly different R and X values for reverse power flow.
3-6
<cim:PowerTransformer rdf:ID="Xf_2002000006838485">
<cim:IdentifiedObject.name>2002000006838485</cim:IdentifiedObject.name>
<cim:PowerTransformer.phases>A</cim:PowerTransformer.phases>
</cim:PowerTransformer>
<cim:TransformerWinding rdf:ID="Wdg_2002000006838485_1">
<cim:IdentifiedObject.name>2002000006838485_1</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_2002000006838485"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_7.600"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.005</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>7.6</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>0.76</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>primary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>Y</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:TransformerWinding rdf:ID="Wdg_2002000006838485_2">
<cim:IdentifiedObject.name>2002000006838485_2</cim:IdentifiedObject.name>
<cim:Transformer.MemberOf_PowerTransformer rdf:resource="#Xf_2002000006838485"/>
<cim:ConductingEquipment.BaseVoltage.BaseVoltage rdf:resource="#BaseVoltage_7.600"/>
<cim:TransformerWinding.r>0.002</cim:TransformerWinding.r>
<cim:TransformerWinding.x>0.005</cim:TransformerWinding.x>
<cim:TransformerWinding.ratedKV>7.6</cim:TransformerWinding.ratedKV>
<cim:TransformerWinding.ratedMVA>0.76</cim:TransformerWinding.ratedMVA>
<cim:TransformerWinding.windingType>secondary</cim:TransformerWinding.windingType>
<cim:TransformerWinding.connectionType>Y</cim:TransformerWinding.connectionType>
</cim:TransformerWinding>
<cim:Terminal rdf:ID="Trm_Wdg_2002000006838485_1_T1">
<cim:IdentifiedObject.name>Wdg_2002000006838485_1_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_2002000006838485_1"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_190_7900"/>
</cim:Terminal>
<cim:Terminal rdf:ID="Trm_Wdg_2002000006838485_2_T1">
<cim:IdentifiedObject.name>Wdg_2002000006838485_2_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Wdg_2002000006838485_2"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_190_7900_1"/>
</cim:Terminal>
<cim:RatioTapChanger rdf:ID="Tap_r88a">
<cim:IdentifiedObject.name>r88a</cim:IdentifiedObject.name>
<cim:RatioTapChanger.transformerWinding rdf:resource="#Wdg_2002000006838485_2"/>
<cim:TapChanger.highStep>4</cim:TapChanger.highStep>
<cim:TapChanger.lowStep>0</cim:TapChanger.lowStep>
<cim:TapChanger.neutralStep>2</cim:TapChanger.neutralStep>
<cim:TapChanger.normalStep>2</cim:TapChanger.normalStep>
<cim:TapChanger.neutralU>7620</cim:TapChanger.neutralU>
<cim:TapChanger.stepVoltageIncrement>2.5</cim:TapChanger.stepVoltageIncrement>
<cim:TapChanger.initialDelay>30</cim:TapChanger.initialDelay>
<cim:TapChanger.subsequentDelay>2</cim:TapChanger.subsequentDelay>
<cim:TapChanger.tculControlMode>volt</cim:TapChanger.tculControlMode>
<cim:TapChanger.type>voltageControl</cim:TapChanger.type>
</cim:RatioTapChanger>
<cim:RegulatingControl rdf:ID="RegCtrl_r88a">
<cim:IdentifiedObject.name>r88a</cim:IdentifiedObject.name>
<cim:RegulatingControl.ratioTapChanger rdf:resource="#Tap_r88a"/>
<cim:RegulatingControl.discrete>1</cim:RegulatingControl.discrete>
<cim:RegulatingControl.mode>voltage</cim:RegulatingControl.mode>
<cim:RegulatingControl.targetValue>7937.5</cim:RegulatingControl.targetValue>
<cim:RegulatingControl.targetRange>317.5</cim:RegulatingControl.targetRange>
</cim:RegulatingControl>
<cim:RegulationSchedule rdf:ID="RegSched_r88a">
<cim:IdentifiedObject.name>r88a</cim:IdentifiedObject.name>
<cim:RegulationSchedule.regulatingControl rdf:resource="#RegCtrl_r88a"/>
<cim:RegulationSchedule.lineDropCompensation>0</cim:RegulationSchedule.lineDropCompensation>
<cim:RegulationSchedule.lineDropR>0</cim:RegulationSchedule.lineDropR>
<cim:RegulationSchedule.lineDropX>0</cim:RegulationSchedule.lineDropX>
</cim:RegulationSchedule>
3-7
Example: Switching Devices
The CIM defines concrete Breaker, Fuse, and LoadBreakSwitch classes, with few attributes.
In the OpenDSS model, there is an implicit switch at each end of a line section, which may be
opened or closed on command. Relays and reclosers may also be attached to the implicit switch
at either end of any line section. FeederAll uses a similar model, as the switching and overcurrent
protection devices are attached to the end of a line section.
In the OpenDSS model, it’s also possible to define a line segment as a “switch” having
negligible impedance, still opened or closed on command, and it may also have overcurrent
protection controls attached. Several of these line switches appear in the exported CIM RDF
for Alabama Power’s example. These were all exported as Load Break Switches; the following
example is actually a recloser, for which there is no existing CIM class.
<cim:LoadBreakSwitch rdf:ID="Swt_recloserx7168">
<cim:IdentifiedObject.name>recloserx7168</cim:IdentifiedObject.name>
<cim:ConductingEquipment.phases>ABC</cim:ConductingEquipment.phases>
<cim:Switch.normalOpen>false</cim:Switch.normalOpen>
</cim:LoadBreakSwitch>
<cim:Terminal rdf:ID="Trm_Swt_recloserx7168_T1">
<cim:IdentifiedObject.name>Swt_recloserx7168_T1</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Swt_recloserx7168"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_196_32599"/>
</cim:Terminal>
<cim:Terminal rdf:ID="Trm_Swt_recloserx7168_T2">
<cim:IdentifiedObject.name>Swt_recloserx7168_T2</cim:IdentifiedObject.name>
<cim:Terminal.ConductingEquipment rdf:resource="#Swt_recloserx7168"/>
<cim:Terminal.ConnectivityNode rdf:resource="#CN_196_32599_1"/>
</cim:Terminal>
Example: Line Code (Possible CIM Extension)
“Line codes” are not presently in the CIM, but are used by OpenDSS and many other software
packages to describe a library of line impedances per unit length, when there is no longer any
underlying physical model. Here is a single-phase “Line Code” object, with new attributes
rMatrix, xMatrix, and cMatrix to define the parameters per phase. In this case, the sequence
parameters should not be used, even if they are written to the CIM RDF. The number of phases
must also be specified. At a later time, OpenDSS should have a feature to generate approximate
physical line data to match the library electrical data. Or, a CIM extension could be specified for
just the transfer of power flow models.
<cim:LineCode rdf:ID="Code_cu1/0x1ph">
<cim:IdentifiedObject.name>cu1/0x1ph</cim:IdentifiedObject.name>
<cim:numPhases>1</cim:numPhases>
<cim:baseFreq>60</cim:baseFreq>
<cim:r>0.058</cim:r>
<cim:x>0.1206</cim:x>
<cim:c>3.4</cim:c>
<cim:r0>0.1784</cim:r0>
<cim:x0>0.4047</cim:x0>
<cim:c0>1.6</cim:c0>
<cim:rMatrix>0.14720000</cim:rMatrix>
<cim:xMatrix>0.22430000</cim:xMatrix>
<cim:cMatrix>2.80000000</cim:cMatrix>
</cim:LineCode>
3-8
This is a three-phase line code, for which the sequence parameters are valid, but the phase
parameter matrices may be more accurate. The matrix attributes are written in the OpenDSS
triangular format for symmetrical matrices, using a bar (‘|’) to separate the rows, and a comma
(‘,’) to separate elements in each row. The matrix dimensions are defined by the numPhases
attribute. In the general case, it is not appropriate to name each matrix element (e.g., raa, rab, rac,
etc.) because the number of phases could vary, and could even be larger than 3 for lines sharing a
right of way, underbuild, etc.
<cim:LineCode rdf:ID="Code_acsr795">
<cim:IdentifiedObject.name>acsr795</cim:IdentifiedObject.name>
<cim:numPhases>3</cim:numPhases>
<cim:baseFreq>60</cim:baseFreq>
<cim:r>0.0261</cim:r>
<cim:x>0.1171</cim:x>
<cim:c>3.4</cim:c>
<cim:r0>0.0938</cim:r0>
<cim:x0>0.4468</cim:x0>
<cim:c0>1.6</cim:c0>
<cim:rMatrix>0.04866667|0.02256667,0.04866667|0.02256667,0.02256667,0.04866667</cim:rMatrix>
<cim:xMatrix>0.22700000|0.10990000,0.22700000|0.10990000,0.10990000,0.22700000</cim:xMatrix>
<cim:cMatrix>2.80000000|-0.60000000,2.80000000|-0.60000000,-0.60000000,2.80000000</cim:cMatrix>
</cim:LineCode>
Example: Line Geometry
This example shows a OpenDSS line geometry, exported as a CIM Conductor Type with
supporting WireType objects and WireArrangement objects. These can all serve as part of a
conductor type library. The example line geometry is a three-phase line with neutral, on a pole
with horizontal crossarm. The phase conductors are 336 ACSR, and the neutral is 1/0 ACSR.
The four conductor positions are specified in four WireArrangement objects, using the pole as
horizontal reference (X=0 m), and ground as the vertical reference (Y=0 m).
<cim:WireType rdf:ID="Wire_acsr336">
<cim:IdentifiedObject.name>acsr336</cim:IdentifiedObject.name>
<cim:WireType.gMR>0.0255</cim:WireType.gMR>
<cim:WireType.radius>0.3705</cim:WireType.radius>
<cim:WireType.resistance>0.306</cim:WireType.resistance>
<cim:WireType.ratedCurrent>530</cim:WireType.ratedCurrent>
<cim:WireType.phaseConductorCount>1</cim:WireType.phaseConductorCount>
</cim:WireType>
<cim:WireType rdf:ID="Wire_acsr1/0">
<cim:IdentifiedObject.name>acsr1/0</cim:IdentifiedObject.name>
<cim:WireType.gMR>0.00446</cim:WireType.gMR>
<cim:WireType.radius>0.199</cim:WireType.radius>
<cim:WireType.resistance>1.12</cim:WireType.resistance>
<cim:WireType.ratedCurrent>230</cim:WireType.ratedCurrent>
<cim:WireType.phaseConductorCount>1</cim:WireType.phaseConductorCount>
</cim:WireType>
<cim:ConductorType rdf:ID="Cond_hc2_336_1neut_0mess">
<cim:IdentifiedObject.name>hc2_336_1neut_0mess</cim:IdentifiedObject.name>
</cim:ConductorType>
<cim:WireArrangement rdf:ID="Arr_hc2_336_1neut_0mess_1">
<cim:IdentifiedObject.name>hc2_336_1neut_0mess_1</cim:IdentifiedObject.name>
<cim:WireArrangement.sequence>1</cim:WireArrangement.sequence>
<cim:WireArrangement.MemberOf_ConductorType rdf:resource="#Cond_hc2_336_1neut_0mess"/>
<cim:WireArrangement.WireType rdf:resource="#Wire_acsr336"/>
<cim:WireArrangement.mountingPointX>-1.2909</cim:WireArrangement.mountingPointX>
<cim:WireArrangement.mountingPointY>13.716</cim:WireArrangement.mountingPointY>
</cim:WireArrangement>
<cim:WireArrangement rdf:ID="Arr_hc2_336_1neut_0mess_2">
<cim:IdentifiedObject.name>hc2_336_1neut_0mess_2</cim:IdentifiedObject.name>
<cim:WireArrangement.sequence>2</cim:WireArrangement.sequence>
3-9
<cim:WireArrangement.MemberOf_ConductorType rdf:resource="#Cond_hc2_336_1neut_0mess"/>
<cim:WireArrangement.WireType rdf:resource="#Wire_acsr336"/>
<cim:WireArrangement.mountingPointX>-0.502</cim:WireArrangement.mountingPointX>
<cim:WireArrangement.mountingPointY>13.716</cim:WireArrangement.mountingPointY>
</cim:WireArrangement>
<cim:WireArrangement rdf:ID="Arr_hc2_336_1neut_0mess_3">
<cim:IdentifiedObject.name>hc2_336_1neut_0mess_3</cim:IdentifiedObject.name>
<cim:WireArrangement.sequence>3</cim:WireArrangement.sequence>
<cim:WireArrangement.MemberOf_ConductorType rdf:resource="#Cond_hc2_336_1neut_0mess"/>
<cim:WireArrangement.WireType rdf:resource="#Wire_acsr336"/>
<cim:WireArrangement.mountingPointX>0.5737</cim:WireArrangement.mountingPointX>
<cim:WireArrangement.mountingPointY>13.716</cim:WireArrangement.mountingPointY>
</cim:WireArrangement>
<cim:WireArrangement rdf:ID="Arr_hc2_336_1neut_0mess_4">
<cim:IdentifiedObject.name>hc2_336_1neut_0mess_4</cim:IdentifiedObject.name>
<cim:WireArrangement.sequence>4</cim:WireArrangement.sequence>
<cim:WireArrangement.MemberOf_ConductorType rdf:resource="#Cond_hc2_336_1neut_0mess"/>
<cim:WireArrangement.WireType rdf:resource="#Wire_ACSR1/0"/>
<cim:WireArrangement.mountingPointX>0</cim:WireArrangement.mountingPointX>
<cim:WireArrangement.mountingPointY>14.648</cim:WireArrangement.mountingPointY>
</cim:WireArrangement>
3-10
4
GAP ANALYSIS
This chapter summarizes the new features needed in both CIM (specifically the CDPSM)
and in OpenDSS to better support North American feeders.
CIM Issues
The following issues will be submitted through the IEC TC 57 / WG 14 Part 11 Modeling team.
They are divided into priority groups. Most important are the issues affecting outage analysis for
interoperability testing, followed by the power flow issues and then the asset modeling issues.
For example, the CIM needs Recloser and Sectionalizer classes to represent North American
feeders, but this gap will not affect power flow testing.
These issues impact outage analysis:
1. Clarify the use of geographic coordinates. This is important for a graphical
representation of power flow results on distribution systems. It appears that Location
and GmlPosition may be defined for any PowerSystemResource. That could lead to
inconsistent or redundant locations. Also, in the 61968 portion of CIM, the Location
class seems oriented toward service locations and addresses. It would be helpful to work
out some examples and preferred methods through testing for power flow models.
2. Bring back the EquivalentLoad class. This is probably the preferred method of
representing customer loads, and has been referenced in the latest published Part 13
(CDPSM) standard.
3. Assign phase codes to windings, so that line-to-line single-phase transformers can be
represented.
4. Everything outside the substation should be in a feeder container, not a bay or
substation. In general, substations and bays are thought of as being “inside the fence”.
On a North American distribution feeder, there is a lot of pole-mounted and pad-mounted
equipment, including transformers, switches, capacitor banks, reclosers, fuses,
sectionalizers, and voltage regulators that should be associated with a feeder. Feeders
are considered to have a voltage level. Equipment inside the fence should still use the
Substation and Bay objects.
5. Clarify the appearance of phases on Terminals and Connectivity Nodes. The CIM
phase assignments occur on Conducting Equipment, which indirectly defines the phases
on attached Terminals and Connectivity Nodes. Some distribution analysis software
operates this way, but it also maintains the phases actually appearing at each node
or bus. The CDPSM profiles and interoperability tests should cover a variety of phasing
arrangements, to ensure support for the transfer of topologically correct models. One of
the example databases included topologically incorrect data for single-phase sections,
and this situation may be widespread among North American utilities.
4-1
These additional issues affect power flow testing:
1. Add the full complement of control parameters for voltage regulators, including
CT and PT ratios, voltage bandwidth, reverse R, and reverse X.
2. For capacitor controls, add the modes for power factor, var control, time, and
temperature.
3. Add a new line code class, possibly as a CIM extension, to facilitate transfer of power
flow models. It’s possible to transfer the actual impedances per line segment, but then
information about common line construction types will be lost in the transfer.
4. Define a structured matrix format, for the phase impedance matrices of a general
number of conductors and other applications. This could be another CIM extension
supporting the transfer of power flow models.
These additional issues affect asset modeling and fault analysis:
1. Add a Recloser class. The recloser (Figure 4-1) is a pole-mounted fault interrupter with
built-in phase and ground relays, current transformer (CT), and supplemental controls. It
could possibly be represented as equipment aggregated into a CIM Substation or Bay, but
then it loses identity as a Recloser asset. The PacifiCorp and Alabama Power examples
both have reclosers.
2. Add a Sectionalizer class. This device is an automatic switch that will lock open to
isolate a faulted section. It may, or may not, have load breaking capability. Its primary
purpose is to provide fault sectionalizing at locations where the fault current is either too
high, or too low, for proper coordination of fuses. The Alabama Power and PacifiCorp
examples both have sectionalizers.
3. Add a Sensor class. Alabama Power is interested in having line post sensors (or in
general, any type of sensor out on the feeder) explicitly modeled. Attributes will have
to be defined with the Part 11 modeling team. Distribution systems are not heavily
instrumented, and with recently growing interest in “smart grid” concepts it will be
more important to model and evaluate the limited available sensing, control, and
communication devices.
4-2
Figure 4-1
Example of a pole-top recloser
OpenDSS Issues
The following OpenDSS features are also suggested:
1. A true model library should be implemented, for transformers and other non-line classes.
The existing “like” parameter was used to mimic this feature, but it has the side effect of
creating phantom buses for all of the library entries, which then appear in text reports.
2. A non-unique display name should be added for each class and bus. Both ABB and
Areva implement an ID, which must be unique, and a name, which need not be unique.
3. Expanding on item 2, the CDPSM will require that IDs be unique and persistent across
models (e.g., unique even among different utilities). This is necessary for incremental
updates to work. To meet this requirement, the OpenDSS will need to manage GUIDs for
each component, either reading them from a netlist, or creating and maintaining them on
command.
4-3
4. The LineGeometry class should be refactored so that the WireData is associated
separately to the line. For example, a Line could reference either a LineCode having
impedance data, or it could reference a LineGeometry plus the necessary number
of WireData instances. This would match how MultiSpeak, ABB, and Areva handle
spacings and conductors, as separate choices. At present the OpenDSS handles this
in a way similar to the CIM, but that should be changed.
5. The DSSgraph component cuts off the circuit plot for both of these examples. This
is a bug that should be fixed. Only EPRI has the source code for DSSgraph, because it
references a licensed commercial software component. EPRI might consider replacing
this with an open-source component for DSSgraph.
6. The Feeder object is only associated with energy meters, and it is not always instantiated.
The OpenDSS should have a feature that makes semi-permanent feeder assignments to
components, based on tracing back to the source. As in real life, these assignments can
change due to switching, but they would help with the CIM export.
7. The OpenDSS should have an algorithm to automatically change wire and/or load phase
assignments to assure connectivity. This would help ensure valid power flow solutions
for models that don’t have consistent data.
8. CIM RDF import should be implemented in time for interoperability testing.
9. An outage analysis feature should also be implemented in time for interoperability
testing, because some vendors plan to participate in the outage analysis test, but not
power flow testing.
10. CIM RDF import and export should both be implemented in optional compressed
format, such as uuencoded zip files.
11. Import and export of the CIM RDF incremental update should also be implemented
for interoperability testing.
4-4
5
CONCLUSIONS AND RECOMMENDATIONS
The conclusions are:
1. The latest CIM UML model has evolved away from the latest published CDPSM in
IEC Std. 61968-13. This lack of stability makes it difficult to produce a valid CIM RDF
model for North American feeders.
2. Reclosers, sectionalizers, and sensors need to be added to the CIM as assets; and the
electrical model needs adequate representation of these devices. The first two classes are
unique to North American distribution systems, but they are very widespread. The third
class would be important for all distribution systems.
3. The open-source distribution of OpenDSS provides an example that some vendors
might find helpful in starting their CIM interface developments.
The recommended next steps are:
1. Complete the preparation of OpenDSS for interoperability testing. The proper handling
of globally unique identifiers is especially important. EPRI can then provide a test partner
for any vendor wishing to test model exchange for analytical functions.
2. Recruit vendors to participate in power flow model exchange for November 2009. The
completion of CDPSM power flow testing would help stabilize the CIM for distribution
systems, just like the several rounds of CPSM power flow testing have stabilized the
CIM for transmission systems.
3. Recruit vendors to participate in testing for outage analysis, which can be viewed as a
simplified kind of power flow. Some vendors may not be ready for complete power
flow testing in 2009, but they could still test some critical aspects of model exchange,
including geographic, connectivity, phasing, switching, and load information. This
implies a two-level CDPSM profile, one for outage analysis, and the second for power
flow.
5-1
6
REFERENCES
1. The Common Information Model for Distribution: An Introduction to the CIM for
Integrating Distribution Applications and Systems. EPRI, Palo Alto, CA: 2008.
1016058. Available: http://mydocs.epri.com/docs/public/000000000001016058.pdf.
2. CIM Users Group [Online]. Available: http://www.cimug.org.
3. S. Neumann, “CIM Extensions for Electrical Distribution”, IEEE/PES 2001 Winter
Meeting Proceedings, pp. 904–907.
4. X. Wang, N. N. Schulz, and S. Neumann, “CIM Extensions to Electrical Distribution and
CIM XML for the IEEE Radial Test Feeders,” IEEE Trans. Power Systems, vol. 18, no.
3, pp. 1021-1028, Aug. 2003.
5. T. E. McDermott, “Distribution System Data Exchanges to Support Line and Cable
Parameter Calculations”, IEEE/PES 2007 General Meeting Proceedings, June 24-28,
2007, Tampa, FL.
6. T. E. McDermott, “Open Source Data Translation for Distribution System and Transient
Modeling”, IEEE/PES 2008 T & D Conference Proceedings, April 20-23, 2008,
Chicago, IL.
7. MultiSpeak [Online]. Available: http://www.multispeak.org.
8. G. McNaughton, R. Saint, “Comparison of the MultiSpeak Distribution Connectivity
Model and the IEC Common Information Model Network Data Set”, Distributech 2008,
Tampa, FL.
9. OpenDSS [Online]. Available: http://sourceforge.net/projects/electricdss/.
10. UWIG Distributed Wind Impacts Project [Online]. Available:
http://www.uwig.org/distiwind.
11. Saxon-B, the XSLT and XQuery Processor [Online]. Available:
http://saxon.sourceforge.net.
12. CIMSpy [Online]. Available: http://www.powerinfo.us/WebPages/opensource.html.
6-1
A
FEEDER ELECTRICAL MODELING IN CIM
A-1
A-2
A-3
A-4
A-5
A-6
A-7
A-8
A-9
A-10
A-11
A-12
A-13
A-14
A-15
A-16
A-17
A-18
A-19
A-20
A-21
A-22
A-23
B
FEEDER ELECTRICAL MODELING IN CIM
B-1
B-2
B-3
B-4
B-5
B-6
B-7
B-8
B-9
B-10
B-11
B-12
Export Control Restrictions
The
Access to and use of EPRI Intellectual Property is granted with the
(EPRI, www.epri.com) conducts research and development relating
specific understanding and requirement that responsibility for ensur-
to the generation, delivery and use of electricity for the benefit of
ing full compliance with all applicable U.S. and foreign export laws
the public. An independent, nonprofit organization, EPRI brings
and regulations is being undertaken by you and your company. This
together its scientists and engineers as well as experts from academia
includes an obligation to ensure that any individual receiving access
and industry to help address challenges in electricity, including
hereunder who is not a U.S. citizen or permanent U.S. resident is
reliability, efficiency, health, safety and the environment. EPRI also
permitted access under applicable U.S. and foreign export laws and
provides technology, policy and economic analyses to drive long-
regulations. In the event you are uncertain whether you or your com-
range research and development planning, and supports research
pany may lawfully obtain access to this EPRI Intellectual Property, you
in emerging technologies. EPRI’s members represent more than 90
acknowledge that it is your obligation to consult with your company’s
percent of the electricity generated and delivered in the United
legal counsel to determine whether this access is lawful. Although
States, and international participation extends to 40 countries.
EPRI may make available on a case-by-case basis an informal as-
EPRI’s principal offices and laboratories are located in Palo
sessment of the applicable U.S. export classification for specific EPRI
Alto, Calif.; Charlotte, N.C.; Knoxville, Tenn.; and Lenox, Mass.
Intellectual Property, you and your company acknowledge that this
assessment is solely for informational purposes and not for reliance
Electric
Power
Research
Institute,
Inc.
Together…Shaping the Future of Electricity
purposes. You and your company acknowledge that it is still the obligation of you and your company to make your own assessment
of the applicable U.S. export classification and ensure compliance
accordingly. You and your company understand and acknowledge
your obligations to make a prompt report to EPRI and the appropriate
authorities regarding any access to or use of EPRI Intellectual Property hereunder that may be in violation of applicable U.S. or foreign
export laws or regulations.
Program:
Technology Innovation
© 2009 Electric Power Research Institute (EPRI), Inc. All rights reserved. Electric Power
Research Institute, EPRI, and TOGETHER...SHAPING THE FUTURE OF ELECTRICITY are
registered service marks of the Electric Power Research Institute, Inc.
Printed on recycled paper in the United States of America
1018281
Electric Power Research Institute
3420 Hillview Avenue, Palo Alto, California 94304-1338 • PO Box 10412, Palo Alto, California 94303-0813 USA
800.313.3774 • 650.855.2121 • askepri@epri.com • www.epri.com