CIM Issues #5979

Meter to UsagePoint relationship should be many-to-many

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

Author/Contact Info:
Base Release:
Observed in iec61970cim17v40_iec61968cim13v13b_iec62325com03v17v_CIM100.1.1.1
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
WG13, WG14, WG16

IEC 61968-9 and others

Originally Closed in Version:
Origination Date:
Origination ID:
Originally Assigned To:


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.

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.

Proposed Solution

Change the multiplicity between UsagePoint and EndDevice to be many-to-many.


This issue was briefly raised at meeting #80 in Oslo. And while the following was not brought up, the author of the issue is willing for it to be withdrawn.
It seems on how "usage point" is used by the implementation. It seems that there are work-arounds. 1.) Multiple usage points could be created at the same location on the occasion where multiple meters feed into the same "socket." 2.) Pulse generators that feed data into a revenue meter should have their own "usage point" even though the data is collected and reported by a meter at a different "usage point."
These recommendations can be placed in the narrative of Part 9 edition 4.


Updated by David Haynes over 1 year ago

The Part 9 payload must also be able to identify which UsagePoint is being reported with the reading.
The Part 9 MasterDataManagement must be updated to reflect the meter-to-UsagePoint relationship.
The introduction of the Terminal class should be factored into the message schema as another identifier.


Updated by David Haynes about 1 year ago

  • Decision updated (diff)

Also available in: Atom PDF