CIM Issues #5011: The 61970 452 profile and 456 profile both contain the same - WG13 Issues - UCAIug Issue Tracking System

CIM Issues #5011

The 61970 452 profile and 456 profile both contain the same

Added by Herbert Falk about 2 years ago. Updated 7 months ago.

Status:

Closed

Priority:

High

Author/Contact Info:

Martin E. Miller

Base Release:

CIM16

Solution to be Applied To:

CIM18v02

Solution Version:

CIM18v04

Solution Applied By:

Chavdar Ivanov

Completion Date:

02/27/2023

CIM Keywords:

Breaking Change:

Breaking Change Description:

CIM Impacted Groups:

WG13

Requestor:

Standard(s):

Version:

CIM18v04

Clause:

Sub-Clause:

Paragraph:

Table:

Originally Closed in Version:

Origination Date:

08/31/2016

Origination ID:

13_265

Originally Assigned To:

Description

The 61970 452 profile and 456 profile both contain the same attributes with different contextual usage.

Proposed Solution

In the same manner that the OperationalLimit value was split into value and normalValue to resolve the same problem in that class, the following attributes should be split into normal and active values:

RegulatingControl.discrete --> discrete (SSH) and normalDiscrete (EQ)
RegulatingControl.targetValue --> targetValue (SSH) and normalTargetValue (EQ)
GeneratingUnit.normalPF --> participationFactor (SSH) and normalPF (EQ)
SynchronousMachine.operatingMode --> operatingMode (SSH) and normalOperatingMode (EQ)

Assign to Physical Devices Subgroup
SynchronousMachine.referencePriority --> referencePriority (SSH) and normalReferencePriority (EQ)

Decision

Discussion from September 9, 2016
Add description of normalization (divide by sum) so that factors work with generators out of service. Not canonical UML related, but plan is to change profile so normalPF is not exchanged in SSH profile. The participationFactor may not be needed if global option of which set is available.

This was approved in the 15-Feb-2023 in-person meeting in Richland with the additional action item that all variables needed for SSH are covered by the proposal. If any are missed they should be added.

Decision(s):
Discussion led to the following directive on what to consider when determining if there’s a need to add an additional “normal” attribute for a particular power system resource:

If there’s a normal quantity that changes and is different for each scenario, then we don’t really have a “normal” quantity. Only when in all scenarios is “normal” quantity the same do we want to have an attribute.

Discussed further on 22-Feb-2023. Decisions follow:

Additionally, adding a “normal” attribute in addition to the SSH attribute to provide a state for power flow is not desirable. This can be done through the use of a default SSH or a pattern.

Action Items (Chavdar): For normal attributes if we need an additional attribute for normal then we need to add a legitimate explanation in the description for each of these as to why it is necessary (how/when used?). This would be specified on the EQ side.

The proposed solution (above) was actually already implemented in CIM17. The above comments are additional actions/decisions that need to be executed to close out this issue. Chavdar, please update the release notes accordingly to document final changes associated with this issue before closing.

Release Notes

CIM16 issues were already closed in CIM17.

Existing attributes that have "normal" are well described.

Moving forward, the following principle will be applied. It is not desirable to add a “normal” attribute in addition to an attribute added in the SSH profile to provide a state for power flow. This can be done through the use of a default SSH or a pattern. For instance, if there’s a normal quantity that changes and is different for each scenario, then we don’t really have a “normal” quantity. Only when in all scenarios we have “normal” quantity, it makes sense to have "normal" attribute.