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> WG14 Part 3 Issues - CIM Issues #6744 (New): CrewStatusKind enumeration is missing values for dea...https://redmine.ucaiug.org/issues/67442024-03-26T16:56:48ZMartin Millermartin.miller@glires.com
<p>The current CrewStatusKind enumeration only contains entries for assignment of crews and the only value (fieldComplete) that represents the deassignment of a crew also represents the completion of work. It is missing any entries that represent the deassignment of a crew without completement of work.</p>
<p>At a minimum the enumeration needs an additional value to represent the concept of "Deassigned" which means that "the crew is no longer working on the outage in the field, without the outage being corrected". <br />Ideally, there would also be a second additional value to represent the concept of "Rejected" which means that "the crew has refused an assignment."</p> IEC 61850 User Feedback Task Force - Feature #6739 (New): How to deal with 'Beh' and 'Health' of ...https://redmine.ucaiug.org/issues/67392024-03-18T10:37:35ZMichael Haecker
<p>For site testing, users shall use the test mode to isolate devices/functions to prevent from flooding control centres with test data.</p>
<p>Whereas data marked "test" can be filtered out, changes of 'Beh' cannot be filtered out. When, for example, changing the active parameter set, the user will create data towards the control centre for LN instances which are activated/inactivated through this change.<br />[Part 7-4 Annex A: "Regardless of the status of LN.Beh, the quality test attribute of Mod, Beh and Health shall be q.test=false."]</p>
<p>In an automation system where a gateway is used to interface the control centre, this gateway could implement a feature to block the information flow of a device in test. Where a direct link via IEC 61850 is used, such blocking is not possible.</p> IEC 61850 User Feedback Task Force - Improvement #6738 (New): Amending TGSN LN class with setting...https://redmine.ucaiug.org/issues/67382024-03-18T10:14:44ZMichael Haecker
<p>The LN classes TCTR and TVTR inherit from 'InstrumentTransformerLN' some settings which can be used for adapting the output signal.</p>
<p>TGSN LN class is missing the settings for scaling, linerarization, wideing of a focussed range.</p> IEC 61850 User Feedback Task Force - Bug #6737 (New): Amending TGSN LN class with signal characte...https://redmine.ucaiug.org/issues/67372024-03-18T09:57:10ZMichael Haecker
<p>The model of a generic sensor does not provide characteristics about the analogue signal type which is used to receive the sensor value.</p>
<p>TC57/WG18 are proposing to amend the model with a setting to state the analogue signal type.</p> WG13 Issues - CIM Issues #6736 (New): Quality61850 Class does not match the definition of Quality...https://redmine.ucaiug.org/issues/67362024-03-12T21:05:03ZTom Berry
<p>CIM definition is missing Inconsistent, Inaccurate Boolean<br />IEC 61850 does not define Source = DEFAULTED</p>
<p>Encoding is now<br />/*
* Bit(s) Name Value<br /> 0-1 Validity Good 0 0<br /> Invalid 0 1<br /> Reserved 1 0<br /> Questionable 1 1<br /> 2 Overflow<br /> 3 OutofRange<br /> 4 BadReference<br /> 5 Oscillatory<br /> 6 Failure<br /> 7 OldData<br /> 8 Inconsistent<br /> 9 Inaccurate<br /> 10 Source Process 0<br /> Substituted 1<br /> 11 Test<br /> 12 OperatorBlocked<br /> */</p> WG16 Issues - CIM Issues #6735 (New): new disclaimer note on every Inf* UML diagram indicating to...https://redmine.ucaiug.org/issues/67352024-03-11T19:54:31ZBecky Iverson
<p>We need to indicate the usage of Inf in a more explicit way to avoid confusions.</p> WG16 Issues - CIM Issues #6734 (New): Review use/inheritance of Document by UCA TF 16 classes, pr...https://redmine.ucaiug.org/issues/67342024-03-11T14:58:20ZBecky Iverson
<p>UTF 14 is reviewing all classes that are inheriting from Document and has request UTF 16 to review the use of Document class.</p> CIM Joint Issues - CIM Issues #6730 (New): Evaluation of the Pipeline Open Data Standard (PODS)https://redmine.ucaiug.org/issues/67302024-03-07T17:09:26ZDavid Haynes
<p>An organization that has a "pipes model" has been located. All of the WGs interested in Redmine issue <a class="issue tracker-9 status-1 priority-2 priority-default" title="CIM Issues: Multi-commodity Support (New)" href="https://redmine.ucaiug.org/issues/6729">#6729</a> should consider [[<a class="external" href="https://pods.org/">https://pods.org/</a>]] . <br />The PODS organization was funded by oil and gas companies in an effort to make an "open" pipeline standard, suitable to carry GIS data.<br />They use Enterprise Architect to maintain their model. They also can provide the model in the form of a data base.<br />Descriptions of their model and organization are attached.<br />Their IP rules are different than the UCAIug. It is copyrighted and only joined members (of the PODS association) may use the model. <br />It doesn't appear that they publish written documents with an SDO like the CIM UG does with the IEC. Nevertheless, according to their website, there are over 200 implementations in 36 countries.</p>
<p>Is there an interest in a liaison between the CIM UG and PODS? If so, what would we like to share?</p> CIM Joint Issues - CIM Issues #6729 (New): Multi-commodity Supporthttps://redmine.ucaiug.org/issues/67292024-03-07T16:57:20ZDavid Haynes
Many utilities sell multiple commodities (electricity, gas, water, and more). Many vendors make products that support more than one commodity. <br />The issue has been batted around for years within WG14 and the issue raised at a CAG meeting. The IEC managers would like usecase information around this subject.<br />We think there is potentially some common use cases to be found in the areas of:
<ul>
<li>Meter Reading and Control</li>
<li>Asset Management</li>
<li>Work Management</li>
<li>Energy Planning (EMS/DMS)</li>
<li>SCADA</li>
<li>Energy markets</li>
</ul>
<p>In addition to potential usecase capture, we should think about how much energy should be expended within the CIM to support multiple commodities, or should another WG with another model be sought to become a partner, and merely map the two models at some prescribed interface?</p> Client - Issues #6728 (New): cSg13 refers to PIXIT entry Sg5/Sg6 but not clarified in the expecte...https://redmine.ucaiug.org/issues/67282024-03-05T12:34:33ZRichard Schimmel
<p>The expected result requires the client to read the SGCB.resvTms but that is optional according to PIXIT Sg6! The PIXIT entry Sg6 has no Edition indication. So when PIXIT says No the client will fail the expected result.</p>
<p>Propose: update the expected result to allow PIXIT Sg6=No behavior. Update the PIXIT Entry Sg6 edition.</p> Client - Issues #6727 (New): cDsN1bc, cFtN2 have no non-Ed2 specific error codehttps://redmine.ucaiug.org/issues/67272024-03-05T12:26:20ZRichard Schimmel
<p>Same as for cSrvN10 also cDsN1b/cDsN1c (MMS GetNameList) and cFtN2 (MMS fileDirectory) have no Ed1 specific error code.<br />I propose to deprecate these test cases just like cSrvN10.</p> Server - Issues #6724 (New): GOOSE Subscriber sGos12 test expects DUT to _send_ a GOOSE message https://redmine.ucaiug.org/issues/67242024-02-28T12:52:13ZUrsula Kramarczyk
<p>The expected result of mandatory sGos12 demands that DUT sends (so, it publishes) a GOOSE message. What if DUT does not have Publisher services, or its GoCB do not refer dataset with the subscribed state change?</p> Test Procedure Issues - Issues #6723 (New): GOOSE destination MAC address according Amd1: PIXIT G...https://redmine.ucaiug.org/issues/67232024-02-27T13:54:50ZUrsula Kramarczyk
<p>The edition 2 amendment 1 in 61850-8-1 25.3.2 and Annex B results in changes in validation of destination MAC address in GOOSE multicast (compare TISSUE 1890). In edition <= 2.0 there was MAC-address range, in amd1 it became “only” a recommendation.</p>
<ul>
<li>The sGos5 references to -8-1 subclause 18.1, but the Layer 2 Addressing is the subclause 25.3.2; and in Annex B.</li>
<li>In PIXIT Gs1, in Notes - add bullet for Ed2.1 destination MAC address. In ed.2.1 the value Y is not valid anymore (all data accepted by any MAC multicast address; and sGos5 is mandatory).</li>
</ul>
<blockquote>
<p>Or does "Y" mean that DUT only checks if it is multicast, and not the range (check of first and second bits in the first octet)?</p>
</blockquote>
<ul>
<li>In 'GOOSE Subscribe' the table 'Abstract test cases': the sGos5 entry does not match the sGos5 title (missing … “and destination MAC-address outside recommended range”).</li>
</ul> Server - Issues #6722 (New): sGop10 PIXIT reference needed ?https://redmine.ucaiug.org/issues/67222024-02-26T11:13:39Zchristian zehnder
<p>In TPCL Ed2.1 v1p2 sGop10 detail was missing as reported in Issue 5954. It was agreed to add the one from V1p1. sGop10 is mandatory and contains 2 steps to test FCDA and/or FCD according to PIXIT. There is no PIXIT reference.<br />If dataset are configurable both steps are "applicable" <del>>mandatory. If fixed one seems ok.<br /></del> PIXIT Gp8 is for edition 1 only. Shall we reference to this or create new one?<br />- If DS are fixed it seems only one step needs to be tested. Whatever is implemented. So FCDA is not mandatory (as its was in ED1)<br />- Do we need a PIXIT entry at all? If fixed tester cannot modify he can check what exists. If its configurable both steps are applicable. Is configurable IED allowed to support only FCDA or FCD? Then we need Pixit.</p>
<p>Background: Discussion what needs to be supported in a fixed server. Only FCDA seems ok. If not fixed they would be forced to implement FCD too.</p>