Open Standards in AMI

Proprietary versus Open Standards in AMI

Hugh D. Baker, Jr.

Proprietary versus Open Standards in AMI

Hugh D. Baker, Jr., MeterSmart, TX, USA

A new generation of metering equipment, metering software and metering vendors promises to deliver on the vision of the intelligent grid at the utility–customer interface. As with any period of rapidly changing technology, there will be winners and losers, including not only vendors, but those who make technology choices as a buyer. This article discusses the pitfalls of proprietary architectures in the Advanced Metering Infrastructure (AMI) technology space and why open protocols are necessary for the utility industry to realize the full potential of AMI systems.

The AMI business case is usually built around several basic value propositions. AMI offers the promise of increasing operational efficiencies, improving reliability, reducing costs, and improving customer service within the utility. Layered onto the need to achieve these operational objectives, the typical utility must deploy an AMI system under challenging business and operating conditions. In order for a system to withstand these conditions while also functioning in the most efficient manner, the AMI systems and related technologies must operate together.

One can find support and appreciation for the advantages of open AMI systems by looking at the practical implications of utilizing proprietary systems, a situation with which our firm has direct experience.

Case in point, a wires only T&D utility in a competitive retail market came to our firm to implement an AMI system. With a very flat, compact and highly dense service area, the business case was simple. Read and process the meter data on three billing cycles per month and give customers access to their interval usage data via the web. From an AMI deployment perspective, the conditions were ideal. Since this was the first AMI deployment across 100% of a utility’s customer base, there were many lessons learned, the most notable being the overall hindrance derived from proprietary hardware and wireless communications with a proprietary protocol.

Since deploying the system, newer technologies have become available that have greater capabilities, even within the narrow value proposition that the current system addresses. In a rapidly changing technology environment, a proprietary metering system provides very little hedge against technological obsolescence. Another takeaway from this experience was that the system cannot address additional business requirements that may occur in the future, including the need to add programs such as load control switches, remote control thermostats, and demand response.

In conclusion, open AMI systems provide utilities with the opportunity to minimize duplication of hardware and software, maximize the available infrastructure, and easily deploy a cost effective, secure, high performance AMI system. AMI open standards is a win/win situation for all, with open systems allowing utilities to face lower risk, lower costs and have greater flexibility, while vendors are able to concentrate on what they do well, gain access to a much larger potential market, and therefore have less business risk. Last but not least, utility customers benefit from the ability of an open AMI system infrastructure to deliver innovative new value-added services.

Proprietaryversus Open Standards in AMI

Hugh D. Baker, Jr.

President

MeterSmart, L.P.

These are exciting times in the utility industry and particularly in electric utility metering. While insiders have known for years that the electric utility system is one of the most complicated machines in the world [1], outsiders have historically viewed the industry as decidedly “low tech.” There is probably no single element in the electric utility system that reinforces that notion more than the electric meter. The basic electromechanical meter still predominantly in use today is a technology that dates to the late 1800’s. But things are changing rapidly. Low cost, solid-state, addressable devices are proliferating in the metering world. Cheap and ubiquitous two-way communications pathways allow access to these addressable devices to not only pull data from the device, but to push information and even control signals to those devices as well. Indeed, a new generation of metering equipment, metering software and metering vendors is out there promising to deliver on the vision of the intelligent grid at the utility-customer interface.

As with any period of rapidly changing technology, there will be winners and losers, including not only vendors, but those who make technology choices as a buyer. This article discusses the pitfalls of proprietary architectures in the Advanced Metering Infrastructure (AMI) technology space, references a proprietary system deployment case study and explains how open protocols allow theutility industry to realize the full potential of AMI systems.

AMI Value Propositions

Improving operation efficiencies is becoming more critical as the ranks of the aging workforce in the utility industry begin to thin. Automation has long been in place in other industries allowing businesses to do more things with fewer resources. AMI similarly promises to reduce labor costs and at the same time allow more services to be offered to utility customers.

Many also believe that the reliability of the electric system is in peril due to aging infrastructure. AMI offers protection of the electric infrastructure by promptly locatingoutages, allowing the problem to be quickly serviced and restored. Such a system cansignificantly improvea utility’s response time,restoration management and communications to the customer during an outage.

An AMI system will also automate the process of reading meters. This in turn will reduce both labor and opportunity costs. The utility workforce is able to increase their operational efficiencies while providing additional protection to the information that is essentially the utility’scash register. Timely and accurate meter information is the key to improving the billing process and in the process the customer service experience.

These are just a few of the ways that an AMI system can benefit a utility and its customers. Typically the business case for AMI requires more than one of these value propositions to be present in order to demonstrate an acceptable return on investment in a system side AMI deployment.

Outside of the core value propositions, there are many uses for an AMI infrastructure. The billing department is only one of several internal clients who need to leverage the AMI system. Load research may need sample interval data across customer classes. Distribution operations may need meter status reports to diagnose customer outages. Customer service may want to utilize load profiles to diagnose billing complaints.

Externally, the customer and the regulator are also clients of the AMI system. Utility business models in the 21st century will evolve to a point where utilities provide more to customers than just keeping the lights on and getting the bill out on time. Utilities are best positioned to take a leadership role in helping customers manage demands, conserve energy and achieve the lowest possible cost of service. Time-based pricing, energy information programs, in-premises energy use displays, automated alerts, load control switches and remote control thermostats and online customer-initiated move-in and move-out tickets are just several of the types of services that can be provided to utility customers utilizing the AMI system.

Typical Deployment Challenges

Layered onto the need to achieve multiple operational objectives, the typical utility must deploy an AMI system under challenging business and operating conditions. Rarely is the service area homogenous in term of customer density and topology. The “Achilles Heal” in most remote metering device situations is communications. What works in one area of the system may not work in another. Low customer density, mountains, buildings and other obstacles may make certain wireless technologies unreliable or cost prohibitive. Accordingly, multiple communications technologies may be desirable or even required for a full system AMI deployment.

Utility AMI Requirements

The forgoing objectives and operating requirements translate into specific requirements that are desirable in an AMI system. In order for a system to function in the most efficient manner, AMI systems and related technologies must operate together. This means that ideally, two different AMI technologies would, at some level, be compatible and provide inputs and outputs in a standard format or protocol. Further, other customer facing operational needs (e.g., load control switches) would also utilize similar protocols and be able to leverage the AMI infrastructure.

Large utility systems or those that have very low customer density may need to rely on multiple communications pathways and technologies in order to deploy AMI on a system-wide basis. In such circumstances, an AMI system that is agnostic with respect to communications is desirable.

Our firm’s past experiences have demonstrated on multiple occasions that the most common utility concern regarding AMI is technology risk. AMI represents a substantial expenditure in almost any deployment. Utilities and regulators alike would like to see a system that will last many years, even if technologies change in the interim. Nobody is willing to bet their career on a system that may be obsolete in a few short years.

Finally, utilities need systems that are cost effective in terms of set-up and operating costs. Further and more importantly, utilities need systems that can be scaled in a cost effective manner as new requirements are identified. These are some of the challenges that utilities are faced with when making the decision to implement an AMI system. I believe that open AMI systemsallow utilities to rise above many of these challenges.

Proprietary Systems

Refer to Figure 1 for the architecture that must be utilized to deploy proprietary systems under the utility conditions outlined in the previous section of this article. At the end-user level, a proprietary meter is installed. A communications pathway brings the data back to a head-end in a proprietary format where the information is processed and converted to a format that can be used in the meter data management (MDM) platform. The data is then exported to the utility for further use. As shown in Figure 1, this example anticipates a requirement to deploy multiple AMI technologies.

Figure 1

Typical Proprietary AMI System

Metering Only

An inspection of this diagram highlights the pitfalls of a proprietary system in an environment where multiple systems and technologies are required. Duplicative hardware requirements can be substantial in a large system. Similarly, special purpose software can be expensive and can represent a single point of failure for the metering group that utilizes a particular proprietary technology. Multiple systems may require multiple experts within the utility. In addition to the costs of training, this may be an inefficient use of resources in a constrained labor environment. Depending on the software platform’s export capabilities, there may be integration issues with the MDM platform as well.

Now let’s assume that we add another business application to the mix, for example a remote control thermostat for purposes of implementing a demand response program. See Figure 2. The communications backbone for this AMI system uses proprietary protocols so it may be useless in effecting the load control program. Additional training and support may be required to operate the system. And once again, we face the challenge of system integration. Unless the vendor happens to offer a technology that works with the proprietary AMI system, we are now in a position of duplicating infrastructure and costs again.

Figure 2

Proprietary AMIWith Proprietary Load Control

It is also worth looking at the proprietary situation from the vendor point of view. Of course it is an ideal situation if one can dominate a market with an AMI system that can anticipate every conceivable field condition, every possible communications difficulty and every possible utility customer service business model. Practically, however, the structure of the utility industry in the United States is fragmented in terms of distinct utility cultures, ownership structures, regulatory regimes, competitive market structures and regional ISO/RTO operating practices. So it seems impossible for a vendor with a single proprietary system to ultimately win the entire market.

Table 1highlights the challenge that a proprietary AMI vendor faces.

Table 1

AMI Vendor Strategic Positioning

Proprietary and Open Protocol AMI

Factor / Proprietary / Open
Utility as the Customer Experience / Must be able to own the user experience from end to end. / User selects components for the system as needed.
Inter-operability / Must support many possible utility applications. / Applications and technologies expand easily.
Manufacturing / Limited production runs can make product more expensive. / Large production runs allow for lower costs.
Design Issues / Design flaws may be fatal. / Design flaws can more easily be overcome.
Competitive Positioning / Must sell on high quality, high price and high margins. / Consistent quality, lower price and lower margins.
Sourcing / Vendor is single source. / Multiple vendors, many already partnered.

In other words, a proprietary vendor must do a lot of things very well. The vendor must establish a market share position that makes it the de facto standard in order to ensure that competitors will be locked out.

Our firm has experience with the implementation and management of a proprietary AMI system. The case in point involves a wires only T&D utility in a competitive retail market. The service area is flat, very compact and has relatively high consumer density. The business case was simple. Read and process the meter data on three billing cycles per month and give customers access to their interval usage data via the web. In other words, from an AMI deployment perspective, conditions are ideal. Under our contract with the utility, our firm, as a third party provider, owns the meters, maintains the communications channel, reads the meters and provides data back to the utility for billing purposes. In addition, we collect 15-minute interval data from 100% of the meters and provide the utility’s customers with web-based access to the data updated on a daily basis. This may not be the very first case of this type, but it is certainly one of the first deployments of an AMI system across 100% of a utility’s customer base.

The system itself consists of a single family of proprietary hardware, wireless communications with a proprietary protocol and a software platform that translates the data into a file that is usable by the MDM system for verification, editing and estimation routines.

We have learned a number of things from this deployment. First, one must anticipate encountering vendor issues from the start. In our case, we ran into issues obtaining the large stocks of hardware required for the project, which delayed deployment. This is most commonly an issue during the startup phase of an AMI deployment.

Secondly, it is wise to negotiate airtight warranties regarding system performance. The system we deployed had problems with the proprietary software which restricted our capability to obtain and process interval data. There was no “Plan B” available, short of pulling the entire stock of meters from the field and replacing them with a different system – not something that one wishes to contemplate. Upon inspection of the vendor’s form agreement, governing the sale and installation of the system, we had almost no recourse against the vendor for a system that did not, at that moment, work. To their credit, the vendor did earn goodwill by escalating the issue on their end and the problem has since been resolved and the system functions as advertised.

Since deploying the system only two years ago, newer technologies have become available that have greater capabilities, even within the narrow value proposition that the current system addresses. In a rapidly changing technology environment, a proprietary metering system provides very little hedge against technological obsolescencedriven by falling prices for on-board system memory, processor speed and communications capabilities. Another takeaway from this experience is that the system cannot address additional business requirements that may occur in the future. For example, if the utility decided to offer an air conditioner load control program, it would require the deployment of a completely separate system. There is no way to leverage the existing metering infrastructure to interface with other hardware to provide additional services to the customer.