Top 5 Foundational Activities in Using Smart Meter Data for Grid Operations

by David G. Kreiss, AMI Operations Consulting LLC

Smart meter data offers utilities opportunities to improve the reliability and performance of their distribution systems. Volt-VAR, conservation voltage reduction, load balancing, outage management, transformer overload detection and even high impedance fault detection could benefit significantly from smart meter data. Utilities, however, are finding it is more difficult to use smart meter data than anticipated.

Utilities should perform the following foundational activities to use smart meter data for grid operations:

No. 1 Get an Accurate M-T-P Map of the Circuit

Most grid applications require the electrical connectivity of the meter to be known to use the data from smart meters. The expectation is that the accuracy of the mapping of meter to transformer to phase (M-T-P map) be 90 percent or greater to use meter data for load balancing or transformer overload identification applications.

Most utilities, however, do not have accurate M-T-P maps. Some utilities have found that their connectivity mapping is only 60 to 80 percent accurate. Until now, the creation of an accurate M-T-P map could require extensive fieldwork that might include visually tracking each premise wire to the connected transformer. Two studies in development will result in a software application that will use smart meter data to provide an M-T-P map with an expected accuracy of greater than 90 percent. Another issue is that a utility’s GIS system might be based on a circuit model and not a single-phase model. A secondary activity ensures the underlying connectivity model used by the geospatial application to display the AMI system and its connectivity to the distribution system is a single-phase model.

No. 2 Determine Required Meter Data for the Application

A collection of smart grid operational projects have been delayed because they were not getting the correct meter data in a timely manor. It is important to identify up front the precise data required from the smart meter and the acceptable latency for delivering that data to the grid application.

Smart meters can store a broad range of data: average voltage over an interval, the high and low voltage that occurred during the interval, and multiple instantaneous high or low voltages during the interval. They also can deliver the present voltage when requested. In addition, the meter can store the described data and proactively send the information as an alert or exception when a user settable threshold is exceeded. The personality of a meter—what it records, stores and alerts upon—generally is determined by its configuration file. Most utilities upload the same configuration file to meters of the same form (single-phase 120 or single-phase 240); otherwise, it would be difficult to manage the population of meters, to include replacements.

It is generally prudent to minimize the amount of data a meter collects and the alerts it sends. Excessive data can overload communications, negatively affect data storage and retrieval and affect meter reliability, all of which can affect billing reads. It must be determined up front which data the meter will collect, communicate and alert. This configuration must be well-tested.

Consider the data needed for a hypothetical real-time volt-VAR control application. The volt-VAR logic might want the following smart meter data:

  1. Average voltage during past X hours;
  2. Minimum and maximum values for any Y-minute interval during the past X hours;
  3. Present voltage; and
  4. An exception (real-time alert) if the average voltage over a Z-minute period drops below or goes above user-defined thresholds.

Given that most of today’s smart meters can record and alert on this data, it would seem that such a project would be feasible. The next step would be to create and upload the appropriate meter configuration file. An issue, however, arises: How often would this data be used by the volt-VAR application? It would be unreasonable to obtain that data hourly from all meters. It would burden the communications system, especially during billing reads, and the cost of an information technology (IT) system to process the data for near-time use would be excessive. The solution is to select a collection of circuit monitors, also called bell weathers, to represent the voltage characteristics of each section of the circuit. Care must be taken in selecting these circuit monitors because they must represent all phases on a particular section. Also, special meter replacement and management processes must be developed for the circuit monitors. Given the selection of these circuit monitors, the volt-VAR application would launch a point-to-point read job only when it would be considering a control function and be the consumer of the alerts to address transient issues.

foundational activities

No. 3 Have a Time-of-Day Communications Load Profile

Most utilities are uncertain of their over-the-air load profiles over the course of a day. They are reluctant to perform major ad hoc reads for fear of overloading the system and possibly affecting billing reads.

Read requests by the head-end system, the network management system provided by the advanced metering infrastructure (AMI) vendor, can be invoked as a broadcast read or point-to-point read. Most daily scheduled large-scale reads are of the broadcast variety. This is where the head-end system sends a single read request to a predetermined large group of meters: the application group. Point-to-point reads, where individual read requests are sent to individual meters, generally are used to read data from a smaller group of meters. Billing reads usually are broadcast reads followed by point-to-point reads to meters that did not respond to the broadcast read.

To support selected grid applications, smart meter data will be needed on an ad hoc basis. The communications load profile will determine the amount of data that can be requested, given the time of day. Having a load profile will allow grid application ad hoc read activities to be managed without affecting daily activities.

No. 4 Ensure Near-time Access of Collected Smart Meter Data

Data collected from smart meters does not mean that the required data is immediately available for grid applications. There might be a significant delay associated with storing the data collected by the head-end system and exposing that data to the grid application typically via a database query or interface. This foundational activity ensures collected data is available to the applications in a timely manor. This activity is especially important where the utility has employed an extract-transfer-load (ETL) architecture to serve smart meter data from a data warehouse. ETL services have delays that can be amplified during a high load event such as an outage. Also, a data warehouse could have blackout periods during which new smart meter data cannot be loaded and is unavailable for grid applications.

No. 5 Use Transform Application for Power Outage, Restoration Alert

The expectation has been that the AMI system would deliver most power outage and restoration alerts reliably. This has not been the case for most utilities, even given small outage events. This suggests that raw power outage and restoration alerts should not be used directly by the grid application but rather intelligently transformed to provide answers regarding the outage.

Smart meters will send an alert or notification when power is lost and has been restored. Utilities have been frustrated by the reliability of these alerts to support their outage management and storm restoration activities. In many cases, the percentage of outage and restoration alerts have fallen far short of expectation and can vary widely based on the size or geospatial footprint of the outage. Without consistency, it has been hard for utilities to construct actionable plans based on this data.

The foundational activity is to create an application that transforms the data into actionable information. Reasonably accurate algorithms have been developed that sidestep the frustration of using outage alert data directly. These algorithms can be built into an application that delivers answers to the grid application. The benefit of a single transform application is that a single set of logic can serve multiple grid applications, and changing of the logic need only occur in a single location.

Conclusion

Many utilities have addressed issues associated with collecting and processing smart meter billing data, but most are just beginning to address the challenges of using smart meter data for grid applications.

It behooves utilities to create road maps of grid applications to use smart meter data and then perform most or all of the foundational activities in this article for each application.

Smart meter data offers great potential to enable the smart grid. Performing these foundational activities should reduce the time to take advantage of this huge, untapped resource.

David G. Kreiss is the managing director of AMI Operations Consulting LLC. He has worked as general manager of Southern California Edison’s AMI operations center, SCE project manager of the SmartConnect monitoring and analysis system, and founder of Kreiss Johnson Technologies, a utility smart grid software development company. Reach him at david.kreiss@amioperations.com.

Go to www.pgi.hotims.com for more information.

More PowerGrid International Issue Articles
PowerGrid International Articles Archives
View Power Generation Articles on PennEnergy.com
Previous articleEye on the World
Next articleDuke Energy’s Data Modeling & Analytics Initiative

No posts to display