| 12 | | 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. | | Closed | 1/12/2009 | randy.rhodes | 61970 | View Entries... | (2) Normal |
| 13 | | 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. | | Active | 2/19/2009 | kendall.demaree | 61970 | View Entries... | (2) Normal |
| 14 | | 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. | | Active | 2/19/2009 | kendall.demaree | 61970 | View Entries... | (2) Normal |
| 15 | | 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.
| | Active | 3/5/2009 | kendall.demaree | 61970 | View Entries... | (2) Normal |
| 16 | | 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." | | Active | 3/11/2009 | kendall.demaree | combined | View Entries... | (2) Normal |
| 17 | | 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. | | Active | 4/2/2009 | kendall.demaree | 61970 | View Entries... | (3) Low |
| 18 | |
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". | Active | 6/11/2009 | steve.van ausdall | 61970 | View Entries... | (2) Normal |
| 19 | |
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. | Active | 8/28/2009 | Heiner Feislachen | 61968 | View Entries... | (3) Low |
| 20 | |
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
| Closed | 9/10/2009 | shawn.hu | combined | View Entries... | (2) Normal |
| 21 | |
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>
| Closed | 9/16/2009 | josé.gonzález | 61968 | View Entries... | (2) Normal |
| 22 | |
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? | Closed | 10/26/2009 | shawn.hu | combined | View Entries... | (2) Normal |
| 23 | |
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. | Closed | 10/29/2009 | shawn.hu | combined | View Entries... | (2) Normal |
| 24 | | IEC62325 needs this associations for MMS.
Organisation 0..* ---------------0..* Document
| (2010-08-10, WG14/16 modelling call) Close issue without model change. | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 25 | | 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. | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 26 | | IEC62325 needs an association between Document and itself.
Document 0..*----------------0..* Document
| (2010-08-10, WG14/16 modelling call) Close issue without model change. | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 27 | | MMS needs an association between Document and EnergyArea
Document 0..*-------------------0..* EnergyArea
| | Active | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 28 | | 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. | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 29 | | MMS needs the following association
ActivityRecord 0..* ---------------------0..* RegularTimePoint
| Subclass, then draw associations among subclasses. | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 30 | | MMS need the return of the Class Unit in the Core package
This Unit class needs to inherit from IdentifiedObject
| | Active | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 31 | | 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). | Closed | 4/16/2010 | cyril.effantin | combined | View Entries... | (2) Normal |
| 32 | | 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.
| Active | 6/1/2010 | herb.falk | combined | View Entries... | (2) Normal |
| 33 | | 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.
| Active | 6/1/2010 | herb.falk | combined | View Entries... | (2) Normal |
| 34 | | 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. | Active | 9/11/2010 | Margaret.Goodrich | 61970 | View Entries... | (2) Normal |
 | 35 | | 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 | Active | 5/3/2011 | gerard.hoogenraad | 61970 | View Entries... | (2) Normal |
| 36 | | 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.
| Active | 5/18/2011 | gerard.hoogenraad | 61968 | View Entries... | (2) Normal |
| 37 | | 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 | Active | 7/6/2011 | devon.merritt | 61970 | View Entries... | (2) Normal |