Project

General

Profile

CIM Issues #6368

The interplay between events and status measurements should be supported more cleanly

Added by David Haynes over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
High
Author/Contact Info:
dhaynes@hubbell.com
Base Release:
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
61968-Metering
Breaking Change:
No
Breaking Change Description:
CIM Impacted Groups:
WG14
Requestor:
David Haynes
Standard(s):

61968-9

Version:
4
Clause:
Annex C
Sub-Clause:
Paragraph:
Table:
Originally Closed in Version:
Origination Date:
06/01/2023
Origination ID:
Originally Assigned To:

Description

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.
It is unnecessarily awkward to relate a measurement status to an event. A change to the design of the standard could make it easier.


Proposed Solution

Add a new measurementKind of "EventTypeID". Then to publish a measurement of a status than an event is based on, the commodity field would be used to identify the source of the measurement (meter, sensor, EVSE, etc.). We could supply the EndDeviceDomain enumeration in the numerator field, EndDeviceSubdomain in the denominator field, set uom equal to "status", then supply the EndDeviceEventOrAction code as the value of the measurement. This would allow better interplay between measurements and events.


Release Notes

The business of "breaking change" is a good question. Breaking the CIM? Breaking someone's implementation? There are many other standards that use Annex C. Increasing the length to 20 attribute fields could break all of them.

#1

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
#2

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
  • Release Notes updated (diff)
#3

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
  • Release Notes updated (diff)
#4

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
#5

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
#6

Updated by David Haynes over 1 year ago

  • Proposed Solution updated (diff)
  • Breaking Change changed from Yes to No
  • Breaking Change Description deleted (This creates a change to the 18 part ReadingTypeID field to make it 20 parts.)
#7

Updated by David Haynes over 1 year ago

  • Priority changed from Normal to High

Also available in: Atom PDF