UCAIug Issue Tracking System: Issueshttps://redmine.ucaiug.org/https://redmine.ucaiug.org/favicon.ico?15861924492024-03-28T13:34:58ZUCAIug Issue Tracking System
Redmine WG16 Issues - CIM Issues #6745 (New): Need for consistent approach for Market Productshttps://redmine.ucaiug.org/issues/67452024-03-28T13:34:58ZScott Coe
<p>Market Products are not used consistently in the CIM because market products are not really consistent across markets...</p>
<p>Energy is the universal commodity; however, even when considering universal grid support products the names vary. In the North America, they call the load frequency control the Regulation product, but in Europe is is Secondary Reserve. Standby/emergency reserve products are more varied. Tertiary Reserve in Europe is split into Synchronous and Non-Synchronous Reserve in the North America. But in even in North America, there is inconsistent usage. PJM calls it Synchronized/Non-Synchronized, MISO and SPP have Spinning and Supplemental, NYISO/ISO-NE/CAISO use Spinning and Non-Spinning, and finally ERCOT has Responsive and Non-Spinning.</p>
<p>One of the oldest market enumerations, MarketProductType does not follow the typical format. We have: EN, RU, RD, SR, NR, RC, LFU, LFD, REG, RPU, CO2e, RMU, and RMD. Changing to Energy, RegulationUp, RegulationDown, SynchronousReserve or SpinningReserve, NonSynchronousReserve or NonSpinningReserve, ReliabibilityUnitCommitment, LoadFollowingUp, LoadFollowingDown, CarbonDioxideEquivalent, RegulationMileageUp, and RegulationMileageDown would break things.</p>
<p>Then we have a similar enumeration: ResourceCapacityType. RU, RD, SR, NR, MO, FO, RA, RMR which map to RegulationUp, RegulationDown, SynchronousReserve or SpinningReserve, NonSynchronousReserve or NonSpinningReserve, MustOffer, FlexibleOffer, ResourceAdequacy, and ReliabilityMustRun. Clearly a different use, but some of the concepts here overlap.</p>
<p>Finally, the most recent is ResourceCertificationKind which allows us to flag when a resource is certified to provide a service. Here the enumeration is properly formatted (all but one entry, that is) and again have a strong correlation to products: RegulationUp, RegulationDown, SpinningReserve, NonSpinningReserve, ReliabilityMustRun, BLACKSTART, DemandSideResponse, SynchronousCondenser, ReliabilityUnitCommittment, Energy, Capacity.</p> WG13 Issues - CIM Issues #6680 (New): Support time series/schedule for SSHhttps://redmine.ucaiug.org/issues/66802024-01-17T15:43:16ZChavdar Ivanovchavdar.ivanov@griddigit.eu
<p>We have the ability to exchange multiple SSH but we do not have capability exchange irregular schedule for SSH classes. It will be good to have a generic model of 2-3 classes that provide this possibility<br />There are use cases that require exchange of multiple SSH information where exchange of multiple files is less attractive.<br />Some of the use cases are<br />- TSO-DSO exchange for planning code in UK<br />- ENTSO-E exchanges where SSH can contain all situations for a day <br />- setting up year round calculations with time series SSH (e.g. when some information is coming from market simulations)<br />... etc</p>
<p>It will be good to have this model added to CIM18 and a small profile (SSH-Schedule, or some other name) included in 456</p> WG13 Issues - CIM Issues #6663 (Open): The SSH profile needs to be revisited and updated for cons...https://redmine.ucaiug.org/issues/66632024-01-04T21:30:37ZTodd Viegut
<p>In reviewing the existing SSH profile we observe inconsistency the approach for what devices are being "generalized". Specifically, most devices are reified in the instanced data as cim:Equipment. For example:</p>
<p><cim:Equipment rdf:about="#_c5aa8f57-82a4-4242-b093-2183cc6732b5"><br /> <cim:Equipment.inService>true</cim:Equipment.inService><br /></cim:Equipment></p>
<p>However, in the case of Switches we have the specific specializations defined in the profile (Jumper, Breaker, etc). This should be changed such that these are removed and that all specialized of cim:Switch appear in the profile as:</p>
<p><cim:Switch rdf:about="#_c5aa8f57-82a4-4242-b093-2183cc6732b5"><br /> <cim:Equipment.inService>true</cim:Equipment.inService><br /> ...<br /></cim:Switch></p> WG14 Issues - CIM Issues #6621 (Review): Add the Design sub-package to the Enterprise packagehttps://redmine.ucaiug.org/issues/66212023-12-05T19:18:02ZHenry Dotson
<p>Sufficient work has been completed by the Part 7 working group to add the "Design" sub-package to the "Enterprise" package and indicate its dependencies on other "Enterprise" sub-packages.</p> WG14 Issues - CIM Issues #6620 (New): Enterprise Package Name Related Model Updateshttps://redmine.ucaiug.org/issues/66202023-12-05T19:07:35ZHenry Dotson
<p>The CIM UML model package name change from "IEC61968" to "Enterprise" has created the need to update some model element names for consistency.</p> CIM Joint Issues - CIM Issues #6619 (New): Renaming the CIM UML Model Packageshttps://redmine.ucaiug.org/issues/66192023-12-05T18:37:57ZHenry Dotson
<p>There is a need to explicitly distinguish the CIM UML model from IEC TC57 CIM-based standards for the purpose of unambiguously identifying ownership of intellectual property.</p>
<p>The current CIM UML model top-level packages have names containing IEC terms related to IEC TC57 CIM-based standards. Specifically, the root-level model package name is "TC57CIM," and the three top-level sub-packages under the root-level model package are named "IEC61970," "IEC61968," and "IEC62325." These names introduce ambiguity regarding ownership of the CIM UML model.</p>
<p>The CIM UML model is open source and owned by UCA, the Electric Power Research Institute and various other organization and is reproduced permission of the UCA User Group, Inc (UCAIug). The CIM UML model open source file is managed by UCAIug under their Open Source sites. The IEC TC57 CIM-based standards are owned and copyrighted by the IEC. The IEC TC57 CIM-based standards are derived from the CIM UML model.</p>
<p>The aforementioned packages need to be renamed to remove the ambiguity regarding ownership of the CIM UML model.</p> WG13 Issues - CIM Issues #6610 (New): Multiple issue Measurement and Controlhttps://redmine.ucaiug.org/issues/66102023-11-27T15:55:48ZSvein Olsen
<p>This is a collection of issues on CIM17 Measurement, SCADA and Control information model with the focus on what is relevant for the Operation profile.</p> CIM Joint Issues - CIM Issues #6584 (New): Handling unit multiplier needs joint WG concensus on a...https://redmine.ucaiug.org/issues/65842023-11-08T12:55:38ZTodd Viegut
<p>Handling unit multiplier</p>
<p>WG13 needed a policy with respect to how unit multpliers are to be exchanged. For example CDPSM has need for Length to be in <strong>km</strong> for line length, but in <strong>meters</strong> for conductor spacing. IEC 61970-552 does not provide for the exchange of unit symbols or unit multpliers. Therefore, manual documentation is required in profiles. Possibly different model parts assembled together may have different unit multipliers such as combining a distribution and transmission model together. With current work in progress for the upcoming IEC 61970-301 Ed 8.0 (i.e. CIM18) and the accompanying editions of IEC 61970-452, IEC 61970-456, etc. there is the planned introduction of the new unbalanced profiles which will require concensus on an approach.</p>
<p>WG13 has issue: <a class="external" href="https://redmine.ucaiug.org/issues/5014">https://redmine.ucaiug.org/issues/5014</a> for addressing this cross-cutting concern within the context of WG13. This CIM Joint issue is to raise visibility across WG14, WG16, WG21 so that we have a common understanding/policy for how we will address this.</p> IEC TC57 WG10 Future Work - WG10 Future Work #6448 (New): GOOSE treatment as a commandhttps://redmine.ucaiug.org/issues/64482023-06-21T09:46:02ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/724220">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/724220</a></p> IEC TC57 WG10 Future Work - WG10 Future Work #6428 (New): Next Steps with IEC 61850-90-11 (Publis...https://redmine.ucaiug.org/issues/64282023-06-21T09:26:50ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/719278">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/719278</a></p>
<p>Comment: Check about starting the TF</p> IEC TC57 WG10 Future Work - WG10 Future Work #6422 (New): Consistent Handling of Abbreviations fo...https://redmine.ucaiug.org/issues/64222023-06-21T09:18:46ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/720322">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/720322</a></p>
<p>Comment: Laurent will initiate</p> IEC TC57 WG10 Future Work - WG10 Future Work #6420 (In Progress): Validation of SCL Files Using O...https://redmine.ucaiug.org/issues/64202023-06-21T09:12:42ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/723864">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/723864</a></p>
<p>Comment: New TF</p> IEC TC57 WG10 Future Work - WG10 Future Work #6414 (In Progress): Golden Single Line Diagram For ...https://redmine.ucaiug.org/issues/64142023-06-21T08:42:41ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/722608">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/722608</a></p>
<p>Notes from Morning session (in addition to the summary on the collab tool):<br />"At least for the primary part"</p> IEC TC57 WG10 Future Work - WG10 Future Work #6411 (New): Update the Model of Circuit Breaker/Dis...https://redmine.ucaiug.org/issues/64112023-06-21T08:33:57ZVladan Cvejic
<p>Link to Collaboration tool discussion:<br /><a class="external" href="https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/724224">https://collaborate.iec.ch/#/pages/workspaces/137211/documents/145326/details/539706/discussions/724224</a></p>
<p>Notes from Morning session (in addition to the summary on the collab tool):<br />"as well 7-500, 90-3, 62271-3; initially create TF to prepare a PWI maybe for a TR"</p> WG13 Issues - CIM Issues #5375 (In Progress): Clean up transformer documentation - Margaret remov...https://redmine.ucaiug.org/issues/53752022-06-02T20:54:18ZYang Feng
<p>Margaret has decided to remove the some of the paragraphs describing distribution network models (e.g., distribution transformer, tap changer... more can be found in the attached document) from Part-11 documents.<br />These paragraphs should be reviewed and re-applied to where they fit, either in 301 or Part-13 document.</p>
<p>Pat Brown wrote<br />This Redmine issue is focused on cleaning up transformer documentation that currently exists in multiple locations: 61970-301 template, 61968-11 template, 61970-452 template, 61968-13 template and UML. <br />Other Redmine issues focus on transformer modelling improvements (esp. for transformers modelled with tanks):<br /> - Redmine 5302: association from TransformerTank to TransformerTankInfo<br /> - Redmine 6147 [GMDM #1]: streamlining of tank-based transformer modelling<br /> - Redmine 6148 [GMDM #2]: TapChanger and TapChangerInfo .ctRatio, .ptRatio attributes<br /> - Redmine 6341 [GMDM #4]: support for transformer type description / derivation</p>