CIM Issues #6368
The interplay between events and status measurements should be supported more cleanly
61968-9
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.
Updated by David Haynes 11 months ago
Updated by David Haynes 11 months ago
Updated by David Haynes 11 months 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.)