UCAIug Issue Tracking System: Issueshttps://redmine.ucaiug.org/https://redmine.ucaiug.org/favicon.ico?15861924492024-03-12T21:05:03ZUCAIug Issue Tracking System
Redmine 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> CIM Joint Issues - CIM Issues #6677 (New): Document Class Generalization Refinementhttps://redmine.ucaiug.org/issues/66772024-01-16T17:35:38ZHenry Dotson
<p>There is a desire to modify the Document class by removing the Document.type string attribute and replacing it with the Document.documentKind enumeration attribute and the Document.documentKindOther string attribute. This would apply best practices to the model and maintain model consistency with the Document.documentKindOther being used when the DocumentKind enumeration class includes "other" as one of the literals in its list of enumerations.</p>
<p>However, the Document.type string attribute is used in IEC62325 profiles, so removing it would break existing IEC62325 profiles.</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> 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> WG14 Part 9 Issues - CIM Issues #6543 (New): AccuracyClass for sensorshttps://redmine.ucaiug.org/issues/65432023-10-19T14:43:23ZDavid Haynes
<p>CurrentTransformer and PotentialTransform inherit from Sensor, and each have "accuracyClass" as attributes. It seems that "accuracyClass" should be promoted up to the Sensor parent, and inherited by everything sensor related.</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 #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 #6267 (New): Person and Organization Relationshipshttps://redmine.ucaiug.org/issues/62672023-02-15T15:31:47ZHenry Dotson
<p>The Person and Organisation relationship modeling is inadequate.</p> CIM Issues - CIM Issues #6266 (New): Person and Person Role Modelinghttps://redmine.ucaiug.org/issues/62662023-02-15T15:21:41ZHenry Dotson
<p>The current modeling of Person and Person Role is insufficient.</p> IEC TC57 WG10 Future Work - WG10 Future Work #6143 (New): Update the Switchgear / Breaker Modelhttps://redmine.ucaiug.org/issues/61432022-09-29T14:19:16ZChristoph Brunner
<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> WG14 Part 9 Issues - CIM Issues #5979 (New): Meter to UsagePoint relationship should be many-to-manyhttps://redmine.ucaiug.org/issues/59792022-09-21T16:40:54ZDavid Haynes
<p>The relationship between a meter and a UsagePoint models the fact that a UsagePoint could have multiple meters associated with it, but there is a metering product which supports multiple ports. Generally speaking, in North America, pulse initiators might be located anywhere on-premises of a particular site, and (sub)meter electricity or some other commodity. The meter has pulse counters in it, in addition to the normal functioning conventional ANSI meter. The utility collects these counts as well as the readings generated within the meter on a monthly/daily/hourly/quarter-hourly basis.</p>
<p>In South America, there is the notion of a "meter bank" which is actually a collection of metrology cards. Each metrology card meters one service. The meter's display is in the home. These metrology cards are usually located in a metal cabinet and mounted up on a pole. So, the meter is actually not located on-premises for the usage being measured. Wires fan out from the meter bank to individual locations that use electricity. This design is for security reasons. The pole-mounted meter bank has considerable physical security around it compared to the on-premises meter. The meter bank is located among the high voltage wires and is physically inaccessible to the average person.</p> CIM Issues - CIM Issues #5885 (New): Consider CIM measurement classes that can hold multiple meas...https://redmine.ucaiug.org/issues/58852022-07-13T15:50:43ZTom Berry
<p>IEC TS 62361-102 Recommendation R17</p>
<p>These classes would be similar to the SvPowerFlow or SvVoltage classes for state variables.<br />For example:<br />• MeasurementVector would have attributes “magnitude” and “angle” and would correspond<br />to the CMV common data class.<br />• MeasurementComplexValue would have attributes “real” and “imaginary” and would<br />typically be used to hold values for real and reactive power.</p>
<p>• MeasurementWyeValue would have attributes "valueA", "valueB", "valueC"</p> CIM Issues - CIM Issues #5883 (New): Define a standard way to define IEC 61850 data object names ...https://redmine.ucaiug.org/issues/58832022-07-13T15:31:10ZTom Berry
<p>IEC TS 62361-102 Recommendation R13 / R14:</p>
<p>Recommendation R13: CIM based standards should use selected IEC 61850 data object<br />names as MeasurementType names.</p>
<p>Recommendation R14: [Alternative to R13] add a new attribute in the CIM Measurement<br />class called IEC 61850 DataObject, which is an enumeration and the value will be any data<br />object that is defined in IEC 61850.</p>
<p>Recommendation R19: CIM based standards should use selected IEC 61850 data object<br />names as ControlType names or add a specific attribute as recommended for Measurements</p> CIM Issues - CIM Issues #5882 (New): Model fans, motors, battery systems and similar auxiliary eq...https://redmine.ucaiug.org/issues/58822022-07-13T15:24:08ZTom Berry
<p>IEC TS 62361-102 Recommendation R5</p>
<p>The business needs for modelling fans, motors and battery systems<br />and similar types of auxiliary equipment in control centre applications should be considered.</p>
<p>The IEC 61850 SCL allows fans, motors and battery systems to be defined either as types of<br />general equipment or as types of conducting equipment. When defined as conducting<br />equipment they will have terminals to allow modelling of their electrical supplies. There is no<br />corresponding CIM class for these types of equipment within the connectivity model except<br />the generic EnergyConsumer class.</p>
<p>Auxiliary equipment may be relevant for asset management purposes.<br />Possible use cases<br />- Switching auxiliary equipment in and out for maintenance.<br />- Derating the primary equipment as function of the state of the auxiliary equipment</p> CIM Joint Issues - CIM Issues #5316 (Open): How to best associate the CIM with other related info...https://redmine.ucaiug.org/issues/53162022-02-15T13:24:35ZGreg Robinson
<p>While there may be better ways to consider now, the ErpSupport package is an example of one method for loosely coupling the CIM with other information model standards (Open Application Group was used in this case). There were two important ideas behind this approach:<br />1. Provide lightweight classes that could be used for common situations within the scope of CIM contexts. <br />2. Provide interface classes within the CIM that individual utility implementations could easily associate or replace with like classes of the utility’s ERP model. In this way, important relationships of both the CIM and the particular ERP model could be retained while enabling linkages to be made between the loosely coupled models.</p>
<p>Examples of ERP functions that often need to be referenced from a CIM point-of-view include bill of materials, invoices, ledgers, inventory, issues from inventory, purchase orders, chart of accounts, requisitions, and time sheets. A similar approach had been used for GML support in earlier CIM releases, but that informative package was removed.</p>