By Mark Hatfield
Users of advanced metering infrastructure (AMI) and meter data management systems (MDMS) naturally fall into a daily rhythm. Meter data are received each day. Validations and estimations are performed; business analysts review individual meter issues and broader trends. After the data processing is complete, the daily framing of billing determinants to support the on- and off-cycle billing requests is performed. This is the daily rhythm of the MDMS and the paradigm of time MDMS is designed to support. The MDMS takes and prepares the previous day’s data for the various business processes that use the data—Web presentment, customer calls and inquiries, revenue protection, proactive customer communications or pre-pay calculations.
But, does the MDMS provide equivalent value to support other paradigms of time? What functionality could a MDMS provide to warrant supporting other paradigms of time? What architectural choices can impact MDMS’ ability to support other paradigms of time?
The Paradigm of the Month
During the deployment of an AMI system, the utility straddles the daily paradigm of the AMI system, the legacy monthly paradigm of manual reads and drive-by meter reading. The question is asked in every AMI project: Should monthly meter reads be loaded into the MDMS? There are two camps on this issue.
Figure 1 shows a representation of an MDMS that does not receive monthly reads. The basic approach states that conventional meter reads will be processed as they are today. Monthly reads will not have to go to the MDMS; they will be stored and billed via the customer information system (CIS). AMI meters that must be read manually for billing—during field acceptance and commissioning, for example—will be processed just as conventional meters are today. When the decision is made that the AMI meter reads are accurate and the meters will no longer be manually read, the MDMS will become the source of billing determinants that support the CIS billing process. The primary advantage of this approach is that, early in the AMI project, the utility can continue to use existing processes to bill the vast majority of meters. The utility will have enough CIS changes and testing to complete without having to redo all billing processes.
Figure 2 shows a representation of an MDMS that receives and bills monthly meter reads. In this approach, the MDMS will be the repository for all meter reads; all meters will be billed through the MDMS and existing billing interfaces will be abandoned—with the possible exception of large commercial and industrial meters. The primary advantage of this approach is the presence of a single integration path to bill all meters and a single repository for all read data. The risk of this approach entails abandoning established billing processes early in the project. All meters will be billed through the new MDMS billing integrations in the first month.
Another potential advantage of loading manual reads into the MDMS involves the ability of the MDMS to provide functionality that compares monthly manual reads with the delivered AMI data to verify parallel read accuracy of the AMI data. This analysis can help ensure the meter is configured correctly—correct meter multipliers, for example—and it might help identify a meter that is installed at the wrong premise (switched meters). The utility does not have to bill the meters via the MDMS integrations to use this functionality.
|Figure 1. AMI and monthly reads are billed separately.|
The Paradigm of “as Soon as Possible”
What to call this paradigm is a struggle. If it is called “real time” or “near real-time,” someone argues with the strict definition of each term. We will, therefore, stay away from these terms and agree there are utility business processes that want an AMI action or AMI data to be delivered as soon as possible (ASAP). Each user and process will have a unique definition of the acceptable time frame.
An on-demand read (ODR) is an ASAP request for the latest register read from a specific AMI meter. A customer service representative, for example, might initiate an ODR to help answer a customer billing question. To minimize call duration, the AMI system must respond quickly for the ODR function to have value in this process. A billing analyst might also use an ODR to verify an extremely high or low bill. Because the customer is not waiting on the phone, ASAP can take longer than the previous example.
Will ODR requests and responses need to go through the MDMS? This depends on whether the MDMS will provide value-add functionality in processing the ODR flow. For customer service representatives using the MDMS user interface to view AMI meter data, processing the ODR through the MDMS will be necessary to support the business process. The utility might also be able to leverage product integrations from the MDMS to the AMI, which will be simpler than going directly to the AMI.
If the utility plans to have multiple AMI systems, the MDMS can broker the ODR flow to the correct AMI system. These are generally not complex integrations, so the utility will have to weigh the value of the product MDMS-AMI integrations. Each of these factors will impact whether the ODR flows should go through the MDMS or go directly to the AMI head-end.
Outage Management and Distribution Automation
When using AMI data to support outage analysis, an important functional goal is to filter outage and power restoration events to reduce false outages sent to the outage management system (OMS). Some MDMS solutions have the ability to filter momentary outages and known service orders.
A momentary filter will hold the outage event for a configurable time period while waiting for a power restoration event from the same meter. If the restoration event is not received, the outage event is sent to OMS. A service order filter will not send the outage event to the OMS if the MDMS is aware of service work at the premise that might result in disconnecting the meter.
If the MDMS does not provide filtering or other OMS-light functionality, the MDMS should not be involved in the outage management process. Some AMI systems filter for momentaries. The utility can also build momentary, service order and known outage filters in the integration layer.
For distribution automation (DA) and distribution management systems (DMS), the focus is on understanding how the electric network is immediately performing. The metering device at the end of every feeder can support this.
The DMS will probably want a 24-hour load profile for every customer. This data fits with the daily paradigm of the MDMS and will be provided via a database extract procedure or daily data delivery.
|Figure 2. AMI and monthly meter reads are billed via the same process.|
To support the high value volt and volt-ampere reactive optimization for voltage conservation calculations in the DMS, the requirement will be similar to the ODR previously discussed. Instead of a register read, however, the DA and DMS will want a voltage reading from a meter. This data is not required for every meter on a feeder, but for specific bellwether meters. External systems will need to track the specific bellwether meters that will be used in the analysis.
For self-healing fault location, isolation and supply restoration (FLISR) applications, the DMS will want device open and close status information and fault indicator status from specific line DA devices—smart reclosers, fault circuit indicators, etc.—on the system. Since these new DA devices are being deployed with supervisory control and data acquisition (SCADA) (distributed network protocol 3 or DNP3) to AMI—vendor specific—protocol converters, there is no need to go through the MDMS for this type of ASAP information. SCADA will typically be interfaced with the AMI head-end for the communication requirements down a distribution feeder.
If the DA integrations are bypassing the MDMS, then the logical flow will have the ODR voltage requests for bellwether meters also bypass the MDMS. There might, however, be advantages for the MDMS to store the voltage data to support long-term power quality analysis.
The MDMS can have a role in the different paradigms of time. The real answer is not whether the MDMS should support these time paradigms but whether operational benefits require these features in a utility’s MDMS. The costs and benefits of using the MDMS must be weighed for each case and integration data flow. The importance of the MDMS role in the other paradigms of time depends on priorities, the functionality of the legacy systems and the capabilities needed to achieve the smart grid vision.
About the author: Mark Hatfield is a principal consultant with Enspiria Solutions Inc., A Black & Veatch Co. He specializes in smart grid and MDMS for electric and gas utility operation. He holds an MA in geography from the University of Illinois and a BS in geography from the U.S. Air Force Academy.