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> WG13 Issues - CIM Issues #6553 (New): Removal of InfGrid package InfSIPShttps://redmine.ucaiug.org/issues/65532023-10-25T19:55:45ZBecky Iverson
<p>CIM17 included a proposed set of modeling to support SIPS in the InfGrid package. In CIM18, this package has been removed. It is understood that there is a new Inf package for ENTSO-E extensions that may have some of the similar modeling support for SIPS, but without the existing InfSIPS package that existed in CIM17, there is no way to harmonize or compare the SIPS support between the different modeling suggestions. Please return the InfSIPS package to the InfGrid package for use in the upcoming modeling sessions for review of SIPS support to be included in the Grid->Base package.</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> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6377 (New): Update the Switchgear / Breaker Modelhttps://redmine.ucaiug.org/issues/63772023-06-14T13:17:15ZVladan Cvejic
<p>There exist the LNs XCBR/XSWI ("operative model") and the "supervision" LNs SCBR and SOPM. In addition, there are trip and control circuits. The number of instances needed depends on the switchgear technology (single phase switching/tripping and three phase control/tripping). The DOs in the LNs are not always in line with allocated tasks of the LNs. Therefore, a careful consistent and comprehensive remodeling is needed.</p> CIM Joint Issues - CIM Issues #6372 (New): Inconsistencies in Nameplate data for DERshttps://redmine.ucaiug.org/issues/63722023-06-12T13:18:19ZScott Coe
<p>Perhaps an issue for other equipment as well, but at least for DERs there is confusing modelling of DER nameplate data in the Dynamics sub-package of the Grid Package. DERNameplateData includes fields such as "acVmax" and "reactiveSusceptance" which seem to be not exclusive to dynamic response. Furthermore, this data appears to me to be more related to the asset world, and perhaps should be modelled as DER Datasheet info, rather than in Grid.</p>
<p>A related issue is that similar data appears in "DERNameplateDataApplied", also in dynamics. This represents the settings information which are bounded by the manufacturer limits, but can be configured (presumable at install but perhaps also via software controls) as protection settings are re-evaluated by the utility.</p> WG14 Part 9 Issues - CIM Issues #6368 (New): The interplay between events and status measurements...https://redmine.ucaiug.org/issues/63682023-06-01T14:14:20ZDavid Haynes
<p>Part 9 Annex C offers an 18 part field to describe a measurement. Annex E offers a 4 part field to describe a status. However the first of the four parts indicates the source, and the last of the four indicates the new status. Quite often a subscriber will want to monitor the status of a condition that an event announces. If it an important condition, the subscriber will want to receive periodic status updates for fear it may have missed a published event. There are many many events and the coverage of measurements doesn't always correspond to it.<br />It is unnecessarily awkward to relate a measurement status to an event. A change to the design of the standard could make it easier.</p> WG13 Issues - CIM Issues #6329 (New): VsConverter required and optional attributes in SSH and SV ...https://redmine.ucaiug.org/issues/63292023-05-02T17:13:42ZTodd Viegut
<p>We have encountered use cases between exchanges between vendors that must be addressed.</p>
<p>Example use cases for consideration:</p>
<p>- System A export (only supports AC side) --> imported into System B (which supports both AC & DC)</p>
<p>- For SSH Inputs: System B export (which supports both AC & DC) --> imported into System A (only supports AC side) (Here equivalence can be done on the DC side when imported into System A)</p>
<p>- The dependency between SSH attributes and controls and subsequently required SV output.</p>
<p>What solution is needed? May need a more immediate fix for.</p>
<p>What is the minimum requirement for the VsConverter to exist (and included in the export)?</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>