Skip to main content
CIMug
Login | Join | Help (new window)

Modify settings and columns

CIMug > Model Issues  

Model Issues

Online repository of CIM technical issues, with oversight of the CIM Model Manager.

CIM User Group members can enter modeling issues here. Click New to insert a new issue.  Enter the required Title and Description.  The Created By and Date Created date will be automatically be filled in.  Enter a priority and category which will indicate the part of the model or the subject of the issue.

To receive updates, you can create a general Alert for the entire list (see the drop-down Actions menu in the list header), or create specific Alerts associated with each item (see the drop-down menu associated with each item Title). Click here to view My Alerts and review your settings (for the CIMug parent site only, not subsites). Add an Alert for the Model Issues list.

Suggestions for improving this page should be submitted through the Help Desk.

  
View: 
Sort by AttachmentsUse SHIFT+ENTER to open the menu (new window).
DescriptionFilterProposed ResolutionFilterCommentsFilter
12
TransformerCoolingTypeUse SHIFT+ENTER to open the menu (new window).
In IEC-61970-301 the enumeration TransformerCoolingType and the attribute PowerTransformer.transfCoolingType need to have documentation added, and enumerated values need to be added. Otherwise both should be removed.
Closed1/12/2009randy.rhodes61970View Entries...(2) Normal
13
TieFlow directionUse SHIFT+ENTER to open the menu (new window).
The new class TieFlow does not clearly state that it is part of a control area in its class documentation.   Nore does it clearly specify the direction of the positive flow.    The flow direction on SvPowerFlow class should also be clarified in similar manner.   The direction can be described as as "from the connection point (either ConnectivityNode or TopologicalNode)into the Terminal and conducting equipement".   I think the previous text simply says "into the terminal" which could be confusing if thinking of the terminal connecting into the device internally.
Active2/19/2009kendall.demaree61970View Entries...(2) Normal
14
SvPowerFlow flow direction.Use SHIFT+ENTER to open the menu (new window).
Clarify the description of flow as positive into the terminal from the connection point, which is either a ConnectivityNode or TopologicalNode.   Similarly the one could say the flow is "load convention" or into the conducting equipment.
Active2/19/2009kendall.demaree61970View Entries...(2) Normal
15
Documenation of LoadResponseCharacteristic exponentsUse SHIFT+ENTER to open the menu (new window).
Suggest improvement to documenation of LoadResponseCharacteristic.pVoltageExpoent on its intended usage and mathematical equation.

Voltage exponents are only used if the LoadResponseCharacteristic.exponentModel is "true".   If so, then the voltage exponents are specified and used to compute load as  cim:SvFlow.p = Pnominal * (cim:SvVoltage.v/cim:BaseVoltage.nominalVoltage)**cim:LoadResponseCharacteristic.voltageExponent

where:

* is "multiply"
/ is divide
** is "raised to power of"
cim:SvFlow object is the flow at the terminal of the EnergyConsumer (See CIM definition)
cim:LoadResponseCharacterisitic is from EnergyConsumer.LoadResponseCharacteristic
cim:SvVoltage is from the connected TopologicicalNode

I think that Pnominal should correspond to an EnergyConsumer attribute, but I don't know which one, possible pFixed?  Note UCTE profile does not exchange the nominal value, just the solved value.

Simlar description needed for qVoltageExponent, pFrequencyExponent, and qFrequencyExponent

SvFlow.p = pNominal * (frequency/(nominal frequency))**pFrequencyExponent

Note that both voltage and frequency exponents could be used together so the full equation would be:

SvFlow.p = Pnominal * (voltage/(base voltage))**pVoltageExponent * (frequency/(base frequency))**pFrequencyExponent

I think all these calculations flow from the basic definitions, but documenting how they work together make is much clearer.   We could even do this in a diagram instead of as documentation on the attributes themselves.
Active3/5/2009kendall.demaree61970View Entries...(2) Normal
16
comment on RegulatingControl associationUse SHIFT+ENTER to open the menu (new window).
Put in comment on RegulatingCondEq.RegulatingControl associaiton end.   Now says "copy from...".   Should say something like "The regulating control scheme in which this equipment participates."
Active3/11/2009kendall.demareecombinedView Entries...(2) Normal
17
CurveStyle semanticsUse SHIFT+ENTER to open the menu (new window).
We need description of the meaning of CurveStyle enumerations.   Documenation is missing and it is not completely clear how straight line and ramp might differ.   Every enum should have a non-blank description.   If the enum name is the same as the semantic description, then formally declare that by copying the enum name to the semantic description, otherwise we do not know the difference between incompleteness and what may be obvious to some.
Active4/2/2009kendall.demaree61970View Entries...(3) Low
18
Symbols in enumerated valuesUse SHIFT+ENTER to open the menu (new window).
Only certain characters are valid in many implementation languages, such as Java, and enumerations may become identifiers in those languages, so CIM should contain no symbols that are likely to be invalid. Specifically, 61970:Domain:UnitSymbol value for celsius has the degree symbol before "C".
The degree symbol character should be removed from 61970:Domain:UnitSymbol "°C", leaving just "C".
Active6/11/2009steve.van ausdall61970View Entries...(2) Normal
19
LandBase and DocumentUse SHIFT+ENTER to open the menu (new window).

The Class LandBase in IEC61968 has two associations. One to ChangeSet and one to NetworkDataSet. In addition LandBase inherits from the Class document which also has an association to ChangeSet and to NetworkDataSet. So LandBase has now two associations to ChangeSet and two to NetworkDataSet. Perhaps one is enough.

Remove the two mentioned associations from LandBase.

Active8/28/2009Heiner Feislachen61968View Entries...(3) Low
20
Inconsistent attribute naming conventionUse SHIFT+ENTER to open the menu (new window).

Inconsistent naming convention for attributes with data type of AbsoluteDate or AbsoluteDateTime

 

It seems the attribute naming convention follows …<Date> for AbsoluteDate data type and …<DateTime> for AbsoluteDateTime data type, but it is not consistent. Here are some examples:

 

expirationDate & expirationDateTime:

Assignment.expirationDate                    – type of AbsoluteDateTime

AccessPermit.expirationDate                – type of AbsoluteDate

            Skill.expirationDateTime                       – type of AbsoluteDateTime

 

effectiveDate & effectiveDateTime:

            Assignment.effectiveDate                      – type of AbsoluteDateTime

            PassThroughBill.effectiveDate   – type of AbsoluteDateTime

            Skill.effectiveDateTime             – type of AbsoluteDateTime

 

dueDate:

            WorkBillingInfo.dueDate                      – type of AbsoluteDateTime

            CustomerBillingInfo.dueDate                 – type of AbsoluteDate

            ErpInvoice.dueDate                              – type of AbsoluteDate

 

endDate & endDateTime:

            Season.endDate                                   – type of AbsoluteDateTime

            ServiceGuarantee.endDate                    – type of AbsoluteDateTime

            Tariff.endDate                                      – type of AbsoluteDate

            IncidentRecord.endDateTime                – type of AbsoluteDateTime

            OperationalRestriction.endDateTime     – type of AbsoluteDateTime

            Outagerecord.endDateTime                  – type of AbsoluteDateTime

            SwitchingSchedule.endDateTime           – type of AbsoluteDateTime

 

startDate & startDateTime:

            Season.startDate                                  – type of AbsoluteDateTime

            ServiceGuarantee.startDate                   – type of AbsoluteDateTime

            Tariff.startDate                         – type of AbsoluteDate

            IncidentRecord.startDateTime   – type of AbsoluteDateTime

            OperationalRestriction.startDateTime    – type of AbsoluteDateTime

            ProfileData.startDateTime                     – type of AbsoluteDateTime

            SwitchingSchedule.startDateTime          – type of AbsoluteDateTime

            TimeTariffInterval.startDateTime           – type of AbsoluteDateTime

            TroubleTicket.startDateTime                 – type of AbsoluteDateTime

 

To follow one naming convention

Closed9/10/2009shawn.hucombinedView Entries...(2) Normal
21
Enhancement of ReadingKind<enum> from Metering PackageUse SHIFT+ENTER to open the menu (new window).

A value for frequency is missing when passing metering data using classes in the Metering package (61968).Otherwise the enum attribute “other” has to be used which is too unspecific.

Add the enumeration attribute frequency to the enumeration ReadingKind<enum>

Closed9/16/2009josé.gonzález61968View Entries...(2) Normal
22
Relationship between ConsumptionTariffInterval and TimeTariffIntervalUse SHIFT+ENTER to open the menu (new window).

This is a case that a TOU tariff can vary based on consumption block. In other words, peak hour prices can be different with different consumption blocks. It seems there should be a relationship between TimeTariffInterval and ConsumptionTariffInterval which does not exist in the current CIM UML.

 

 

Also a CPP (critical peak pricing) can suspend all previous pricing (TOU and/or block consumption) for certain duration. Should this be treated as a TOU case?

 

See sample data from SE (Smart Energy) TRD below:

 

 

Block1Price1 $ 0.11531 Block1Price-OffPeak

 

Block2Price1 $ 0.13109 Block2Price-OffPeak

 

Block3Price1 $ 0.25974 Block3Price-OffPeak

 

Block4Price1 $ 0.37866 Block4Price-OffPeak

 

Block5Price1 $ 0.44098 Block5Price-OffPeak

 

Block1Price2 $0.1453  Block1Price-Peak

 

Block2Price2 $0.1711  Block2Price-Peak

 

Block3Price2 $0.2997  Block3Price-Peak

 

Block4Price2 $0.4287  Block4Price-Peak

 

Block5Price2 $0.4960  Block5Price-Peak

 

Block1Price4 $0.99  Block1Price-CPP

 

Block2Price4 $0.99 Block2Price-CPP

 

Block3Price4 $0.99 Block3Price-CPP

 

Block4Price4 $1.25 Block4Price-CPP

 

Block5Price4 $1.99 Block5Price-CPP

 

To make ConsumptionTariffInterval contain TimeTariffInterval or vice verse. Not sure about how to deal with CPP. Thoughts?
Closed10/26/2009shawn.hucombinedView Entries...(2) Normal
23
Part-9 XSDs issues/questionsUse SHIFT+ENTER to open the menu (new window).

CustomerMeterDataSet.xsd:    

SDPLocation/occupancyDate is a type of AbsoluteDate in UML but presented in XSD as xs:string (should it be xs:date?)

<xs:simpleType name="AbsoluteDate" sawsdl:modelReference="http://iec.ch/TC57/CIM-generic#AbsoluteDate">

                        <xs:restriction base="xs:string"/>

            </xs:simpleType>

 

MeterSystemEvent.xsd:

MeterSystemEvents/EndDeviceEvent/Assets has a multiplicity of 1 so should it be named “Asset” instead of “Assets” to follow the naming convention?

 

EndDeviceAsset.xsd

Attributes formNumber, kH, and kR do not belong to EndDeviceAsset class in UML but showed up in the XSD. They are native to MeterAsset class.

 

The following elements are complex data type containing multiplier, unit and value in CIM UML but presented in Part-9 XSDs as simple data type xs:float.

·        Conductance

·        ApparentPower

·        Money

·        Reactance

·        Frequency

·        Susceptance

·        ActivePower

·        Voltage

·        CurrentFlow

·        Resistance

·        Minutes

·        RealEnergy

·        PerCent

·        Seconds

·        ReactivePower

·        Weight

 

This is about profile, not about CIM UML.
Closed10/29/2009shawn.hucombinedView Entries...(2) Normal
24
IEC62325 - association between Organisation and DocumentUse SHIFT+ENTER to open the menu (new window).
IEC62325 needs this associations for MMS.
Organisation 0..* ---------------0..* Document
(2010-08-10, WG14/16 modelling call) Close issue without model change.
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
25
IEC62325 - association between Document and MarketRoleUse SHIFT+ENTER to open the menu (new window).
IEC62325 needs this association to return in NOT INFORMATIVE cause MMS needs it.

MMS need Document 0..*------------------0..* MarketRole
Subclass, then draw associations among subclasses.
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
26
IEC62325 - association between Document and DocumentUse SHIFT+ENTER to open the menu (new window).
IEC62325 needs an association between Document and itself.

Document 0..*----------------0..* Document
(2010-08-10, WG14/16 modelling call) Close issue without model change.
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
27
IEC62325 - association between Document and EnergyAreaUse SHIFT+ENTER to open the menu (new window).
MMS needs an association between Document and EnergyArea

Document 0..*-------------------0..* EnergyArea
Active4/16/2010cyril.effantincombinedView Entries...(2) Normal
28
IEC62325 - association between Document and ActivityRecordUse SHIFT+ENTER to open the menu (new window).
MMS needs an association between Document and ActivityRecord to be not informative

Document 0..*-----------------0..* ActivityRecord
(2010-08-10, WG14/16 modelling call) Close issue without model change.
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
29
IEC62325 - association between ActivityRecord and RegularTimePointUse SHIFT+ENTER to open the menu (new window).
MMS needs the following association

ActivityRecord 0..* ---------------------0..* RegularTimePoint
Subclass, then draw associations among subclasses.
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
30
IEC62325 - return the Class Unit in Core packageUse SHIFT+ENTER to open the menu (new window).
MMS need the return of the Class Unit in the Core package

This Unit class needs to inherit from IdentifiedObject
Active4/16/2010cyril.effantincombinedView Entries...(2) Normal
31
IEC62325 - request of change on the datatype of the attribute kind in MarketRole ClassUse SHIFT+ENTER to open the menu (new window).
At the moment the kind attribute is typed with an enumeration MarketRoleKind.
The problem is that when using this attribute in MMS we need other enumerated literal in the list of the Enumerations.
The proposition and is to reopen the door and put a String datatype instead of an enumeration at CIM level.
Then the Enumeration should be set when profiling the CIM model into a specific profile.
If the CIM model is already restricting the use of this attribute then we can't use it in MMS.

(2010-08-10, WG14/16 modelling call) WG16 CMM to:
a) Move MarketRole and MarketRoleKind into IEC62325
b) create subclass of Organisation (e.g., MarketParticipant), and then
c) move association with MarketRole from Organisation to MarketParticipant, and finally,
d) remove ‘informative’ stereotype from association MarketParticipant-MarketRole.

2010-09-28, WG14 modelling call: Agreed by all CMMs. Applied (TK).
Closed4/16/2010cyril.effantincombinedView Entries...(2) Normal
32
Units and Unit Multipliers are not sufficientUse SHIFT+ENTER to open the menu (new window).
There are no units that allow PV and other DER related measurements (e.g. Lumens, etc) as Unit enumerated values.  Additionally, the range of unit multipliers may not be sufficient.
It is recommended that both the unit and unit multiplier enumerations embrace the full SI Units as specified in ISO 1000.  It is further recommended that the actual enumerated values be aligned with IEC 61850-7-3.
Active6/1/2010herb.falkcombinedView Entries...(2) Normal
33
Not all Async and Synchronous Machines are Rotating EquipmentUse SHIFT+ENTER to open the menu (new window).
A change to the dynamics package causes all synchronous and asynchronous machines to be rotating equipment.


Update the UML so that there are asynchronous machines and rotating asynchronous machines.  Do the same for synchronous machines.

However, care must be taken so that generators can be either.

Active6/1/2010herb.falkcombinedView Entries...(2) Normal
34
Currency EnumerationsUse SHIFT+ENTER to open the menu (new window).
The Currency Enumeration needs to be expanded to include other currency denominations for the NIST PAP10 work that is currently underway.
Use ISO 4217 for the complete list of currency codes and add these to the enumeration.  I will email an excerpt that contains the full list to Lars-Ola (the current model manager) for his review and possible use.
(TK 2010-10-14) I'll need to do that for 61850 UML, so we can reuse in CIM? Each literal will also have an integer value, this should not bother in CIM.

(TK 2012-02-09) Official UML of 61850 currently contains the full enumeration of currencies, according to ISO 4217. This could be reused? Or, do we refer to external standard as discussed in Nuernberg?
Active9/11/2010Margaret.GoodrichcombinedView Entries...(2) Normal
Attachment35
Enhance the SCADA PackageUse SHIFT+ENTER to open the menu (new window).
Enhance the SCADA package with calculation and data exchange.

In order to be able to maintain calculations within the SCADA system using CIM and to maintain the exchange of MeasurementValues to other RTOs/TSOs.
See attached powerpoint and EA, XMI or HTML files
Active5/3/2011gerard.hoogenraad61970View Entries...(2) Normal
36
61968 – 9 Meter Reading and Control - EndDeviceEventUse SHIFT+ENTER to open the menu (new window).
On CIMug Prag Margaret Goodrich presented on the CIM University "03-61968-9 Meter Reading and Control.pdf". On Page 13 an example of an EndDeviceEvent (<ns1:EndDeviceEventType ref=“3.26.0.85”/>).
This is no good xml modelling.
<ns1:EndDeviceEventType EndDeviceType="3" EndDeviceDomain="26" EndDeviceSubdomain="0" EndDeviceEventorAction="85"/> would be much better and more xml conform.
Active5/18/2011gerard.hoogenraad61968View Entries...(2) Normal
37
Section 4.7.2 Number of Terminals for ConductingEquipment objects appears to be incompleteUse SHIFT+ENTER to open the menu (new window).
Section 4.7.2 Number of Terminals for ConductingEquipment objects in IEC 61970-301 appears to be incomplete.

Section text: "The following ConductingEquipment classes have two terminals: ACLineSegment, DCLineSegment, Jumper, Fuse, Breaker, Disconnector, LoadBreakSwitch, SeriesCompensator. All other ConductingEquipment leaf classes have a single terminal."

It seems like the list of conducting equipment objects that have two terminals is incomplete.  For example, I expected that all classes derived from Switch would have two terminals.  If a switch does not have two terminals how does it affect the network connectivity? 
Update the text to match the current objects in the UML model
Active7/6/2011devon.merritt61970View Entries...(2) Normal
38
'DocToDoc' and 'OrgToOrg' 'relation shortageUse SHIFT+ENTER to open the menu (new window).
Reviewing model's draft "iec61970CIM15v32_iec61968CIM11v13_iec62325CIM01v0" I noticed that Document.ToDocumentRoles and Document.FromDocumentRoles was deleted.
It is very sad issues cause it was useful to show "categorized" dependencies between documents. 
Situation with 'OrgToOrg' is the same.

To add property Document.DocumentRoles of type DocDocRole.
To make class DocDocRole with properties From and To of Document type.


To add property ErpOrganisation.OrganisationRoles of type OrgOrgRole.
To make class OrgOrgRole with properties From and To of ErpOrganisation type.
Active2/13/2012andrey.kostyukovcombinedView Entries...(2) Normal
Attachment39
MeterMultiplier: Association to Register missingUse SHIFT+ENTER to open the menu (new window).

In the current CIM version
( iec61970cim16v29_iec61968cim12v08_iec62325cim03v01a ) there seems to be a problem with the MeterMultiplier

because there is no possibility any more to have a direct link between register and meter multipliers.

In order to check this out please just have a closer look at IEC61968, Package Metering, Class: MeteringMultiplier, Class: MeterMultiplier.
--------------------------------------------------------------------------------------------------- 

In some elder  previous CIM version (  IEC61968-11-00v10_iec61970cim14v05_iec61968cim10v23_combined-CDV ) the so-called register factor as well as some

specific electricity related factors like current transformer ratio, potential transformer ratio and transformer ratio could be linked directly to a register.

Explanation: In that elder version the overall model looked a bit different
 ( also with regard to naming a little bit ) .
Most important: There was not any MeterMultiplier yet.

Instead there existed a specialization ElectricMeteringFunction of DeviceFunction in which all the above mentioned electricity factors were included and even some more useful indicators like e.g. transformerRatiosApplied. With ElectricMeteringFunction it was possible to have a direct association to register.

Nowadays however this ElectricMetering has disappeared and the electricity factors have wandered into the MeterMultiplier.

Also the meter itself at that time had two additional attributes like kR and kH but which nowadays also have vanished and wandered into the MeterMultiplier.

------------------------------------------------------------------------------------------------------

At least for the electricity related factors ctRatio, ptRatio and transformerRatio there is a need for a direct linkage to the register where they are applied in order to perform the quantity conversion.
It is not quite clear for me why CIM has changed the former design which seemed to be more appropriate for me.

A solution could be e.g. to introduce a new association register -> MeterMultiplier.
Remark 1:
Maybe a further constraint is needed to make sure that this register should be a register of a meter and not of a more general EndDevice
Remark 2:
I do not expect that CIM will return to the previous design. I can e.g. understand that the multipliers kR and kH can be considered as meter specific.

But for the more electricity specific factors like ctRatio, ptRatio and transformer ratio I do not really understand why this should be considered

only meter related and not also register-related!

Active4/28/2016thomas.weidlich61968View Entries...(1) High
40
Breaker short circuit ratingsUse SHIFT+ENTER to open the menu (new window).
Hi,
The IEC CIM 61970 Breaker Class doesn't have different short circuit rating attributes such as peak make current , peak break current , DC time constant etc.

Could you please let me know how the short circuit ratings of a Breaker are represented by the IEC CIM or any plans to extend it.

Thanks and Regards,
Ramesh
Active9/1/2016ramesh.dolu161970View Entries...(1) High