CIM Issues #5979
Meter to UsagePoint relationship should be many-to-many
IEC 61968-9 and others
Description
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.
Decision
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.