CIM Issues #6508
Support the means to identify the accuracy of the measurement in <MeterReadings>
61968-9
Description
Different revenue meters offer different accuracy classes. The meter's accuracy is treated as an attribute of the asset. However, it is a lot of work for a consumer of the data to research the accuracy of the source device. Furthermore, not all measurements within an instrument are necessarily held to the same accuracy. Sometimes exceptions are provided to measurements which are outside the scope of the ANSI C12.1 certification. An electric meter might provide a temperature reading for example which is not 0.2% accurate, while the kWh measurement is 0.2% accurate.
Sensors are typically not tested to this standard, and will have different accuracies.
SCADA equipment also supplies voltage and current measurement with various accuracies.
All of these measurements may be available to a user who is trying to compare data from different sources.
It would be good to indicate exceptions to the rule, and where possible, supply the actual accuracy of the measurement.
Proposed Solution
The MEAS class in 61970 has a sensorAccuracy attribute in MeasurementValue. sensorAccuracy has a typecast of "percent." It is an optional element.
Proposal: Add this same element to MeterReading. Logically, it should be located near the <value> and <ReadingQualities> elements within <Readings>.
Instructions should be provided in the standard on how to use this field (and many other fields.)
If calibration is temporarily lost due to a voltage event, a quality code can simply be used by the communication module to mark data provided at that time with a quality code exception. But if the user collects a reading that is not within the scope of the instrument's calibration, a quality code should indicate that as well.
When the measurement is published, <MeterReadings> should carry these quality codes, but also, at some level, the sensorAccuracy should be provided to users so that they don't make assumptions about the data that aren't true. This would be a good job for the MDMS.
Decision
On the Aug 17, 2023 Part 9 team call, the small group felt that the addition of a quality code was a logical proposal we should accept, and that the addition of the <sensorAccuracy> element sounded reasonable too, but needed more discussion. Could it be added at a higher level near the <meter> element, or is it better to add it at a lower level near the <value>? It seems that the answer depends on the use case we are trying to address. If all of the readings are consistently accurate from the same device, then it can be up near the <meter> element, and it is an attribute of the meter. (We may even want to argue the need to create a "meter" class based on EndDeviceAsset.) But, like 61970, it may be best to keep it an attribute of MEAS and inherit the element down in the <value> area -- because different measurements from the same device can have different accuracies. More discussion is perhaps needed in a larger group at a subsequent meeting.
Release Notes
Related to issue #6544.
It seems that we can simply add "sensorAccuracy" as an element to the BaseReading, place it next to "value", in the MeterReadings XSD, and not have to change the CIM model whatsoever.
Updated by David Haynes 7 months ago
It seems that an accuracy class should be published as part of the EndDeviceConfig class or the MeterConfig class. By listing every reading type supported and pairing it with an indication of accuracy, it would be possible to publish the device's capabilities (in terms of what could potentially be measured) as well as how accurately it would be measured if collected and reported.
There is also the desire to have a fully self-describing message, so it would also make sense to add an (optional) accuracy indication next to the meter readings value.