5.3 Smart Meter Reading
5.3.1 Description
This clause provides selected Smart Meter Reading use cases
5.3.2 Source
oneM2M-REQ-2013-0217R02 Smart Meter Reading Use Case
Note
use case information extracted from SGIP/OpenSG
REQ-2015-0563 pCR on smart meter reading
5.3.3 Actors
- Smart Meters (SM), Data Aggregation Points (DAPs),
- Advanced Metering Infrastructure (AMI) Head-end,
- Meter Data Management System (MDMS),
- Customer Information System (CIS)
5.3.4 Pre-conditions
Availability of meter data.
Smart Meters which are deployed in a block (e.g. same house, building, community, etc.) with the same behavior based on default configuration or charging policy could be assigned as a group.
5.3.5 Triggers
Smart meter on-demand or bulk interval meter read request events
5.3.6 Normal Flow
Smart Grid Interoperability Panel (SGIP) (http://www.sgip.org) and OpenSG users group (http://osgug.ucaiug.org/default.aspx) have been leading this effort in North America. An informative document has been submitted to OneM2M based on the SGIP activity. In general, a number of external organizations such as the SGIP or the SGCG (Smart Grid Coordination Group) in Europe have been working to define use cases for Smart Grid (SG). Portals such as the Smart Grid Information Clearing House (http://www.sgiclearinghouse.org) to assist with distributing information about smart grid initiatives in the US. The use-cases presented are derived in part from the above publicly available information.
Figure 5.3.6-1 shows the conceptual actors/data flow diagram based on a more detailed diagram developed by SG-Net. The more detailed diagram developed by SG-Net can be seen in the associated submission related to SGIP-based Smart Grid Use Cases.
In Figure 5.3.6-2 each element is an "actor" that is communicating with another actor using the shown data flows. As an example, consider "Smart Meter" in the "Customer" quadrant (lower right). Smart Meter (SM) communicates with a number of other actors, such as a Data Aggregation Point (DAP) located in the AMI Network. The DAP can then transmit the aggregated data to the Utility Service Provider using the Wide Area Network. The meter reading information can reach the data centre for the Utility Service Provider via the AMI Headend which can forward the information to the MDMS which can coordinate with the CIS to store/retrieve meter data and to determine customer billing information. In certain variations such as cellular-based smart metering systems, a DAP entity may be bypassed, or merely serve as a pass-through for the information flow between the utility data centre and the smart meter.
Figure 5.3.6-1 Conceptual Actors/Data Flow Diagram
Figure 5.3.6-2 Typical Smart Meter Reading Flows A (on left) and B (on right)
Typically, a utility data centre processing application communicates end-to-end via the AMI Headend with a smart meter data application at the edge. Figure 5.3.6-2 shows two possible flows A and B depending on whether there is a DAP entity along the path from the Utility Data Centre / AMI Headend and the Smart Meter.
In flow A, the Utility Data Centre / AMI Headend can make a request to the Smart Meter directly. Typically there may be 3 to 6 such requests per day (typically < 10 times per day). The request could indicate that the current meter reading is desired. Alternatively, multiple meter readings over a period of time such as for a few hours (e.g. from 2 p.m. to 8 p.m.) for a given day or across days could be requested. The Smart Meter completes the request and communicates it back to the Utility Data Centre / AMI HeadEnd. Typical in such on-demand or bulk-interval read requests, a reasonably immediate response is desired of the order of a few seconds, so that there is not necessarily any significant delay tolerance allowed for the response. However, it is possible that, in current systems or in future systems, such requests could optionally carry a delay tolerance associated with the request depending on the urgency of the request. The size of the meter reading response can be of the order of a few tens to hundreds of bytes, and is also implementation dependent.
In flow B, the Utility Data Centre / AMI Headend can make a request to the Smart Meter that can be received via the DAP. Typically there may be 3 to 6 such requests per day (typically < 10 times per day). The request could indicate that the current meter reading is desired or that multiple meter readings over a period of time are desired. The Smart Meter completes the request and sends its response to the DAP. This response from the Smart Meter to the DAP is typically desired in the order of 15 to 30 seconds, as suggested in the submitted informative document related to SGIP-based Smart Grid Use Cases. However the actual delay in processing can be implementation dependent across smart metering systems across the world. The size of the meter reading response can be of the order of a few tens to hundreds of bytes, and is also implementation dependent.
In case that the Smart Meters belong to a group, there are two ways to distribute the request from the Utility Data Centre / AMI Headend to Smart Meters: the Utility Data Centre / AMI Headend sends a request to DAP then DAP distributes it to all Smart Meters, or the Utility Data Centre / AMI Headend sends same requests to all Smart Meters via DAP which acts as a router. There are several ways to submit the data from Smart Meters to the Utility Data Centre / AMI Headend: The DAP entity can buffer the data for some time, receive data from many meters, and then submit the aggregated data across meters to the Utility Data Centre / AMI Head End. The duration for which the DAP may buffer data can be implementation dependent, and could last for several seconds or minutes. In some variants, the DAP may serve merely as a router, so that it directly forwards the smart meter response to the Utility Data Centre / AMI HeadEnd without performing any aggregation tasks. In further variants, the DAP entity could be merely a virtual processing entity and not a physical one, where such a virtual entity could even potentially reside on the other side (not shown) of the wide area network associated with the Utility Data Centre / AMI Head End. For instance, the Utility Data Centre / AMI Headend could send a request to DAP for distributing it to all Smart Meters in a group, and if the DAP belongs to the third party, the DAP shall serve as a router to directly forward the smart meter response to the Utility Data Centre / AMI HeadEnd without performing any aggregation tasks.
Summary
To summarize, meter reading requests could request a single meter reading or a set of meter readings. Such requests may occur a few times (typically < 10) per day and can be of the order of a few tens of bytes. Meter reading responses can be of the order of a few 10s to 100s of bytes typically. Meter reading responses are typically expected in the order of a few seconds after reception of the request at the meter. Any delay tolerance associated with such requests can be optional or implementation dependent. In some system variants, a DAP entity may not exist at all so that the Utility Data Centre / AMI Head End communicates directly with the smart meter. In other end-to-end system variants, a DAP entity may serve as an intermediate processing or forwarding entity between the Smart Meter and the Utility Data Centre / AMI Head End. In such cases, the DAP entity may be either a physical or virtual processing entity in the end-to-end system and can assist with buffering and aggregating meter reading responses. The duration of buffering or aggregation at the DAP entity can be implementation dependent and could be of the order of a few seconds or minutes typically.
5.3.7 Alternative Flow
None
5.3.8 Post-conditions
None
5.3.9 High Level Illustration
None
5.3.10 Potential Requirements
- The M2M System shall be able to provide identity verification between the M2M device and the M2M server.
- The M2M System shall be able to protect confidentiality of data (i.e. Smart Meter Response), even when DAP is deployed by the third party.