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> IEC TC57 WG10 Future Work - WG10 Future Work #6579 (New): How to add utility process name to DOshttps://redmine.ucaiug.org/issues/65792023-11-07T14:40:47ZVladan Cvejic
<p>Currently SCL has poor support for handling gateway/RTU-funktions where signal names are translated for remote communication. The specified sigal has a utility process name independent of used protcol. E.g. "start of distance protection". This needs to be associated with its IEC 61850 implementation (xxPDIS1.Str.general, xxPDIS2.Str.general etc.). The 80-1 part describes how 104 addresses can be added to SCL but also other utility fields are important to be able to include in SCL for specification and documentation purposes. Desired solution by Vattenfall is to have vendors use DA description to add utility process name.</p> WG14 Part 9 Issues - CIM Issues #6549 (New): Switch Contention Issuehttps://redmine.ucaiug.org/issues/65492023-10-24T22:26:02ZDavid Haynes
<p>There are many relays controlling many loads. Sometimes these assets can be switched on or off for different reasons. While working on lines, it is a common practice to employ "lock out / tag out" procedures. In this scenario, the workman physically places a padlock on a switch to prevent its movement. Then, at the end of the job the workman physically removes his padlock to restore normal operation of the switch. While the safety issue is nicely handled by the physical locks, an operational issue still remains. What if a CIS declares that a particular RCD switch inside of a revenue meter is to be opened due to non-payment. Then what if this same switch is made available to the DERMS for load control purposes? A DR system might (even as part of a group) ask that the switch participate in a load shed, then upon completion, that the switch be closed in. What is the switch to do? How would it know to revert to an open position? What if that is obsolete information? What are the expectations for the AMI network / load control system? Should there be a "system of record" that is the official keeper of allowable switching activity? Should there be the means for a back office system to effectively place a "lock" on a switch position and prevent other back office systems from operating it? Can multiple systems place locks similar to the physical lockout/tagout mechanism described above? Or rather, should there be a "list"? Should there be a "do not open" list and a "do not close" list? (Someone might be on life support, someone may have moved out, etc.)<br />Meters con not only have a big 200A disconnect, they might have a number of small relays designed to control individual loads like irrigation pumps, or anything else the utility wires them to.<br />There are also specialized switches the AMI network might control -- usually installed beneath a given revenue meter -- to control smaller loads within a home. Should these be lockable too?<br />We can't have multiple systems fighting over the switch position. We need a switch management plan.</p>
<p>This issue is related to Issue <a class="issue tracker-9 status-1 priority-2 priority-default" title="CIM Issues: Group Management (New)" href="https://redmine.ucaiug.org/issues/6542">#6542</a>.</p>
<p>For discussion purposes, we think the scope of this issue is limited to switches that are not on the feeder that a lineman could interact with. These switches are covered by Part 3. But there are switches that are otherwise safe to operate that are in scope.</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 #6328 (New): Required usage of BusbarSectionhttps://redmine.ucaiug.org/issues/63282023-05-01T07:59:15ZChavdar Ivanovchavdar.ivanov@griddigit.eu
<p>Multiple requests received on lack of instructions if BusbarSection is a required class if a ConnectivityNode is a node (just for the connectivity purpose) or a busbar section.</p>
<p>There are multiple options how to solve this gap</p>
<p>- Option 1: state in 301 and/or 452 that "if a ConnectivityNode represents a busbar it is required that there is an instance of BusbarSection which Terminal is associated with this ConnectivityNode." <br />- Option 2: revisit the need of BusbarSection class. If we can make it a bit easier perhaps doing the following is better approach: 1) add a boolean ConnectivityNode.isBusbarSection, this shoudl be required in 452 2) see if if true we require BusbarSection class instantiated or not; if we want to keep it for compatibility we shoudl write a constraint in 452 to require BusbarSection is the boolean is true and we can validate this.</p>
<p>I will put an issue in the IEC on this, but we need to see what the next steps will be within ENTSO-E. The BusbarSection class is in both v2.4 and v3 and it is a matter to say that the usage of it is required in some cases. In a way this is the main purpose of this class anyway. the point we need to state is that it is important to use it.</p> CIM Joint Issues - CIM Issues #5963 (Review): mRID topics [incl GMDM #19]https://redmine.ucaiug.org/issues/59632022-09-12T14:09:24ZYang Feng
<p>The usage of mRID has been brought up during the GMDM IOP and followings are the topics to be covered</p>
<p>• Should the UML be changed to make the mRID a UUID instead of a string?<br />• The omission of mRID in favor of rdf:ID/rdf:about has been inadequately canonized. How can we canonize this in a way that does not retroactively break anyone’s software? <br />• When the mRID is included, what should be done when the mRID value does not exactly match the fully-expanded rdf:ID/rdf:about?<br />• What should be done for mRIDs that are not UUIDs but that do not correctly override the xml:base?<br />• What should be done when a 61968-100 mRID does not conform to the xml:base nor exactly match the fully-expanded rdf:ID/rdf:about?</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> WG14 Issues - CIM Issues #5237 (Review): Eliminate compoundshttps://redmine.ucaiug.org/issues/52372022-01-13T12:39:38ZHerbert Falk
<p>Eliminate use of compound classes street address, street detail, electronic address, telephone number (2)</p>