By Mark Hatfield, Enspiria Solutions Inc.
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-cycle 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 business processes that use the data: Web presentment, customer calls and inquiries, revenue protection, proactive customer communications or prepay calculations.
But does the MDMS provide equivalent value to support other paradigms of time? What functionality could an 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 and the legacy monthly paradigm of manual reads, drive-by meter reading or both. 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—for example, during field acceptance and commissioning—will be processed as conventional meters are today. At the time the decision is made that the AMI meter reads are accurate and the meters no longer will be read manually, 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, you can continue to use existing processes to bill most of your meters. You 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 well-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 that the meter is configured correctly (for example, correct meter multipliers), and it also might help identify a meter that is installed at the wrong premise (switched meters). You do not have to bill the meters via the MDMS integrations to use this functionality.
The Paradigm of ASAP
We struggle with what to call this paradigm. If we call it real time or near real-time, someone argues with the strict definition of each term. Therefore, we will 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 an acceptable time frame.
An on-demand read is an ASAP request for the latest register read from a specific AMI meter. For example, a customer service representative might initiate an on-demand read to help answer a customer billing question. To minimize call duration, the AMI system must respond quickly for the on-demand read function to have value in this process. Or a billing analyst might use an on-demand read to verify an extremely high or low bill. Because a customer is not waiting on the phone, ASAP can take longer than the previous example.
Will on-demand read requests and responses need to go through the MDMS? This depends on whether the MDMS will provide value-add functionality in processing the on-demand read flow. For customer service representatives using the MDMS user interface to view AMI meter data, processing the on-demand read through the MDMS will be necessary to support the business process. You may also be able to leverage product integrations from the MDMS to the AMI, which will be simpler than going directly to the AMI.
If you plan to have multiple AMI systems, the MDMS might broker the on-demand read flow to the correct AMI system. Generally these are not complex integrations, so you must weigh the value of the product MDMS-AMI integrations. Each factor will affect whether the on-demand read flows should go through the MDMS or go directly to the AMI headend.
Outage Management and DA
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 can 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 the 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 may result in disconnecting the meter.
If the MDMS does not provide filtering or other OMS-like functionality, the MDMS should not be involved in the outage management process. Some AMI systems filter for momentaries. You also can build momentary, service order and known outage filters in the integration layer.
For distribution automation and distribution management systems, the focus is on understanding how the electric network is performing right now. The metering device at the end of every feeder can support this.
The distribution management system likely will want a 24-hour load profile for every customer. This data fits well with the daily paradigm of the MDMS and will be provided via a database extract procedure or daily data delivery.
To support the high value volt/VAR optimization for voltage conservation calculations in the distribution management system, the requirement will be similar to that of the on-demand read discussed. Instead of a register read, however, the distribution automation or distribution management system will want a voltage reading from a meter. This data is not required for every meter on a feeder, but, rather, 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 applications, the distribution management system will want device open and close status information and fault indicator status from specific line distribution automation devices (smart reclosers, fault circuit indicators, etc.) on the system. Because these new distribution automation devices are being deployed with supervisory control and data acquisition (SCADA)—distributed network protocol 3 (DNP3)—to AMI (vendor-specific) protocol converters, there is no need to go through the MDMS for this type of ASAP information. Typically SCADA is interfaced with the AMI headend for the communication requirements down a distribution feeder.
If the distribution automation integrations are bypassing the MDMS, then the logical flow will have the on-demand read voltage requests for bellwether meters also bypass the MDMS. There may be advantages, however, for the MDMS to store the voltage data to support long-term power-quality analysis.
The MDMS can have a role in the paradigms of time. The 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 use case and integration data flow. The importance of the MDMS role in the other paradigms of time depends on your priorities, the functionality of your legacy systems and the capabilities you need to add to achieve your smart grid vision.
Mark Hatfield is a principal consultant with Enspiria Solutions Inc., a Black & Veatch Company. He specializes in smart grid and MDMS for electric and gas utility operation. He has a Master of Arts in geography from the University of Illinois and a Bachelor of Science in geography from the U.S. Air Force Academy.
Power Engineerng Issue Archives
View Power Generation Articles on PennEnergy.com