By Belvin Louie
Through its SmartMeter™ programme, Pacific Gas and Electric (PG&E) is deploying the largest implementation of advanced metering infrastructure (AMI) in the United States to date, and one of the most functionally rich AMI implementations in the world. Through 2011, PG&E will deploy 10 million SmartMeter™ gas and electric meters, several major communication networks, and many supporting back-end systems.
To enable the massive scale of this programme, PG&E is deploying a robust meter data management system (MDMS). The MDMS provides the critical linchpin that ties together a dizzyingly complex collection of IT systems. In the past, it was virtually impossible to obtain detailed energy usage data, even within the utility. With a robust MDMS, it will be possible in the future to provide any authorised user relatively easy access to energy usage data – a capability that will support data mining analytics and ultimately transform the very core of PG&E’s business, and its relationship to customers.
WHAT IS AN MDMS AND WHY IS IT IMPORTANT?
AMI systems create huge volumes of data. In the past, PG&E collected one reading a month from each meter. Once the SmartMeter™ programme is fully deployed, we will be collecting daily and near-hourly data from each of our 4.1 million gas meters, hourly data from each of our 4.3 million residential electric meters, and 15-minute interval data from each of our 750,000 commercial/industrial business electric meters. As a result, the volume of data we will collect and process on a daily basis will increase an astounding 720-fold for the residential customers alone. The SmartMeter™ programme is radically changing the scale of meter data processing and storage requirements.
An MDMS is an essential system for handling the huge volumes of data generated through automated metering. The MDMS enables loose coupling between systems. Multiple automated meter reading (AMR) systems send their data via their respective head-end servers to the MDMS, where validation, estimation, and editing (VEE) routines fill in any gaps in the data, creating clean, integrated, and bill-ready data sets. Backend utility systems such as billing, data warehouse, or outage management, in turn, obtain their data from the MDMS for their specific purposes.
At PG&E, we have several AMR collection systems providing meter data to our MDMS – one system for gas meters, several systems for electric meters, and a legacy system for the largest commercial/industrial customers. Our back-end applications such as our billing engine, Customer Care & Billing (CC&B), obtain interval meter data from the MDMS without concern for which AMR system collected the data. This loose coupling creates what is virtually a plug-and-play capability, ensuring that as our systems evolve, we will have the flexibility we need to upgrade or change out parts of the systems with minimal disruption, cost and effort.
MDMS CAN PLAY A NUMBER OF ROLES
In addition to performing VEE and serving as the authoritative source for data, the MDMS can play a number of other roles within the larger IT ecosystem. It can act as a traffic director, a data repository, a data framing engine, an infrastructure map, and an asset management system.
The MDMS can act as a traffic director, connecting back-end applications to specific AMR systems on a dynamic basis, making access to meter data easy and transparent to the business user. For example, PG&E customer service representatives (CSRs) will soon have the ability to “ping” SmartMeter™ electric meters for their status without having to know which system is providing the response.
The MDMS serves as the intermediary between the back-end applications requesting the meter information (in this case, CC&B) and the specific AMR systems that collect this information. The MDMS, while primarily an online transaction processing system, also acts as an interim data repository. For example, PG&E’s MDMS stores 14 months of customer interval usage data, which it uses as a historical baseline when performing VEE analyses. For extensive data analytics, number crunching and presentation, interval data is streamed to a separate data warehouse, called our Measure, Bill, and Collect Data Warehouse (MBCDW) where the data is stored and available on-line for 7 years.
The MDMS can also be a framing engine, assigning interval usage data into specific billing determinants for purposes of billing complex rates. This is important, for instance, when a customer is on a time-of-use or peak day pricing rate, where rates vary by time of day. While PG&E performs this activity within its newly upgraded CC&B system, utilities with less robust billing systems have the option of performing this activity within their MDMS.
Another common MDMS feature is the ability to house a detailed virtual map of the electric infrastructure components – meters, transformers, distribution circuits, substations, and their interconnections. The MDMS uses this connectivity model to isolate outages based on ”last gasp” outage message alarms from meters losing power, creating information that can be passed to outage management systems to augment traditional power outage customer calls and supervisory control and data acquisition (SCADA) systems. It also uses power restoration messages to identify where power has been restored after an outage, including the identification of so-called “nested” outages – outages that are located within larger outages. The ability to identify nested outages quickly enables the utility to deploy field crews more efficiently, saving operational costs.
Finally, an MDMS supports asset management. The virtual map of field infrastructure can be augmented with detailed asset data such as depreciation schedules and maintenance records – a feature that may be of special interest to smaller utilities that lack the scale to support a stand-alone asset management system.
Whether or not these additional features are deployed, the MDMS provides an essential service within an AMI infrastructure: effective integration with reduced infrastructure complexity. It integrates any number of different AMR systems, each with its own processing schedule, into a consistent, validated data set that can be leveraged by any number of back-end systems – a loosely coupled technical environment that can easily accommodate changes to its parts without impacting the whole.
CHALLENGES OF MDMS DEPLOYMENT
Deploying an MDMS does have its challenges. Efforts at PG&E to deploy a very large scale MDMS highlighted several major challenges.
MDMS data must be synchronised with data in other major systems. For example, customer moves captured in the customer database must be reflected in the billing system, the MDMS, and the AMR head-end systems to ensure that new customer information is correctly associated with the proper meter data in a timely manner.
The interfaces between the MDMS and other utility systems must achieve two ends simultaneously; they must provide efficient processing that minimises processing time, and they must ensure sufficient flexibility to accommodate future system changes. To achieve these ends simultaneously, PG&E deploys three IT practices.
First, we use a service-oriented architecture (SOA). A SOA enables us to build code once and leverage it when needed as a standard service, thereby reducing the cost of code development and enhancing flexibility to accommodate continuing advances in AMI technologies.
Second, to promote flexibility and data re-use, we leverage Enterprise Application Integration (EAI) service buses as the preferred interface both between the AMR systems and the MDMS and between the MDMS and back-end applications. The EAI bus uses a publish/subscribe model to transfer data. For example, the MDMS publishes meter data on the EAI service bus as it becomes available. Utility back-end applications, in turn, pull the data they require from the EAI service bus as needed. Here, again, we have loose coupling.
Despite its clear advantage in terms of flexibility, an EAI service bus approach to system integration is not always appropriate. For very large data transfers, we maintain direct linkages between the MDMS and other systems, principally the back-end billing system – our third practice. In these instances, the benefit of processing speed, and not “dragging down” the service bus performance, trumps the benefit of flexibility achieved through loose coupling.
Integrating an MDMS system within the utility’s IT landscape requires trade-offs and the development of a tailored approach to optimise both flexibility and speed.
When dealing with the huge volumes of data generated by AMI, scalability is a critical system requirement. At PG&E, we will have 10 million advanced meters at full deployment, which means we will pump huge amounts of data through our systems on a daily basis. Every day we produce bills for about 5% (500,000) of our meters and process roughly 10,000 account changes. We also process interval data for 100% of our meters for use in operations, analysis, and for data presentation to customers. In addition, we must be able to process outage and tamper alarms as they occur in real time, which – in the event of a storm – can be very high in volume. And on top of all this, we must process status pings initiated by the CSRs to support customer inquiries. All these transactions must be processed at the appropriate service levels to accommodate ever-rising customer expectations as well as regulatory mandates. The challenge is enormous.
To ensure the MDMS will scale as needed, PG&E conducted extensive tests using a number of scenarios with different assumptions. We found that it is important to construct tests based on the most conservative assumptions conceivable. If the system can operate under the worst case test scenario, it is more likely to meet the real requirements that will be placed on it in full operation. Even assumptions that seem realistic or probable may fail to fully expose the system limitations that can arise at scale. Because AMI technologies are new, and industry experience is limited, it is best to err on the side of caution. In fact, we have increased the number of performance and scalability tests we perform to ensure the systems will support projected volumes. In addition to recognising that some of the initial assumptions were wrong, we have had to account for an expanding technology mix in our maturing AMI implementation as well as an expanding set of technology options as the AMI industry matures. Scalability testing is crucial and should be given ample attention.
Deployment of an MDMS entails a huge number of system configuration decisions: rules, groups, group alarms, constants. Because these configurations can impact customer bills, they require a clear governance process and version control.
The MDMS touches many systems, each with its own processing cycles. And the MDMS impacts customer billing which, in the case of California, is subject to a regulatory mandate – customer bills must be generated within 24 hours of the read on which they are based. MDMS deployment thus requires effective synchronisation of processing cycles across multiple systems, all aligned with a 24 hour clock. Synchronising various distinct but inter-related 24 hour clocks is a complex undertaking that requires focus and attention.
JUST A BEGINNING
As complex and daunting the challenge of deploying an MDMS for AMI may seem, it is just a beginning. AMI is merely an enabling technology; it provides only a foundation of what – over time – will evolve into a smart energy system.
A smart energy system will need to handle vastly larger quantities of data generated from sensors and control devices situated across the electric grid. Data will drive automation of both transmission and distribution operations. On the customer side of the meter, data will enable electric demand management, energy efficiency, distributed electric generation and storage, and electric vehicle use. And as greater volumes of electricity from intermittent renewable generation sources come on to the grid, data will be needed to maintain balance in a dance among increasingly varied and distributed energy resources – generation, demand curtailment, storage, and electric vehicles. We will need to handle more data and greater data processing at ever greater levels of accuracy.
We had better get used to the world of MDMS; there is much more to come.