by Stephen J. Callahan
The evolution from automated meter reading (AMR) to an advanced metering infrastructure (AMI) is firmly under way in the utility industry with a significant degree of the dialog around the required “smartness” of the meter. Indeed, AMI requires smarter, more full-function meters than AMR to progress up the benefits curve. But another element is also required. Both the AMI meters and the systems that process their information need to be architected based on open standards.
AMR implementations collect real-time customer usage data but do not provide the information to the utility in real time. Although single customer on-demand reads and pings are possible, an instantaneous view of all meters in real time is not. Instead, AMR meters store the information locally in the meter itself, and periodically the information is retrieved and sent on to utility billing systems. Yesterday’s data available today is the norm that supports billing applications and yields the associated benefit of reduced meter reading costs. Such is the foundation for most AMR cost justifications.
Outage management is the first step up into the domain of AMI. So called “last gasp” meters provide local residual power for the meter to effectively send out a distress call. Such calls are detected by the AMI network infrastructure and sent on to utility outage management systems (OMS) for processing. This function of an AMI system has significant benefits but requires a meter that is more costly to acquire, operate and maintain than AMR. Additionally, a more extensive network infrastructure is required and the systems to collect this information and process it in near real time are more complex and sophisticated. Yesterday’s data today is just not sufficient. AMR systems are not architected to effectively perform this function.
The next step up to AMI is an even more complex task-the AMI meter as a “gateway” to the customer. With this “smarter” meter, customers can determine their energy usage over time matched with its respective cost; they can also perform “what if” analysis to support energy and cost-efficient behaviors. During an outage, the utility already knows a customer’s power is out and is able to provide a timely and accurate estimate for the time of restoration when a customer calls. To support demand response, the AMI system delivers real time price signals alerting customers of high cost conditions, and allows utilities to send signals directly via the meter connected to a customer premise LAN that is able to control customer energy consuming devices.
Such a customer gateway requires a much more function-rich meter than AMR. It requires a communications infrastructure that is more robust and higher capacity than AMR. And the development of and integration to utility systems (both existing and new) requires a degree of sophistication and complexity well beyond any currently installed utility applications.
It is not hard to see that the full vision of AMI requires significant developments in the meter and the systems that support them. Cost, function, integration and extensibility are the challenges; standardization and openness, the solution.
Clearly a meter that is much “smarter” and more function-rich than an AMR meter is required to realize the benefits of AMI. Such meters in the market today are generally too expensive to be deployed on a large scale to all customers. To achieve the cost point required, the industry needs to take a page out of the telecommunications industry’s play book-standardization and openness. This will drive the cost of AMI meters down significantly, and enable the development of the innovation in AMI meter functions required to realize AMI benefits.
The systems to support AMI will require scaleable, flexible and extensible integration architecture. The large volume increase in data processed relative to today’s utility applications is typically an initial concern. But scalability is just the first problem. AMI requires integrating batch orientated billing systems, real-time outage systems, and near real-time customer information analytics applications-all utilizing the same data stream from the same AMI system infrastructure.
A simple integration approach of gerrymandering various vendor and utility applications together with even current best practice techniques is not sufficient and will yield sub-optimal results. Again, as with the meter, standardization and openness are required. Building systems around web services and SOA architectures is a practice already adopted by industries with the same fundamental problem of building similarly complex and extensible systems. Utilities need to demand such architectures as a requirement of the systems, and both vendors and utilities will need to architect/rearchitect their systems utilizing such standard and open principles.
An open meter built to communications industry standards and integrated with AMI systems in an open scaleable architecture is the path of evolution to AMI. It will lower costs and enable the level of systems innovation required to deliver the benefits of AMI. In short, the approach to developing AMI meters and the systems that support them needs to be as visionary as AMI itself.
Stephen J. Callahan is a partner in the energy and utility industry strategy and change practice at IBM Global Business Services, where he specializes in strategy, transformation and performance management.