meter data management: the key to unlocking the benefits...

Meter Data Management: The Key to Unlocking the Benefits of Advanced Metering

Aclara Software White Paper

March, 2008

© Aclara Software Inc. 2008 1

Introduction: Why MDMS?

Until recently, even though most utilities have had to cope with some amount of interval

data, the category of systems known as Meter Data Management Systems (MDMS)

essentially did not exist. The recent exploding interest in Advanced Metering

Infrastructures (AMI), along with the introduction of systems that require interval data,

such as settlement systems, has driven the need for an entirely new generation of class of

Meter Data Management Systems.

Given current industry drivers of system efficiency, including demand-side management,

the potential of carbon credits, and the linking of retail to wholesale pricing, the industry is

driving to deploying AMI. But making the most of AMI data is not a simple matter.

Over the past several years, the concept of an MDMS as the key software enabler for AMI

has begun to evolve, as utilities have begun to understand that AMI cannot achieve all of

the desired benefits unless the data can be effectively cleansed, processed, stored, and

applied to address and enhance key business processes.

The long list of benefits of implementing an AMI system is compelling. If managed

properly, the availability of AMI data can generate significant benefits and enhance a

range of processes, including not only internal-facing processes such as revenue

protection, outage management, and distribution system planning, but perhaps even more

so customer-facing processes that result in enhanced customer satisfaction and reduced

customer service costs. The “customer side of AMI” is where some key benefits are

gained; for example, the combination of AMI/MDM should be able to empower customers

to truly leverage creative pricing programs that have been shown to effectively reduce

resource requirements. Thus, many of the benefits promised by AMI relate to how

metered data is managed after it is collected, and how it is stored, formatted and deployed

across the enterprise. In other words, collecting the data is just one part of the AMI

savings equation; the utility must also be able to use its AMI data to support decision-

making throughout the organization to achieve the maximum return on its AMI investment.

A critical step, therefore, to maximizing the potential of AMI is the creation of a central

repository that is the single source for all metered and interval data. Further, given the

ever-increasing amounts of AMI data, such a repository must have the ability to scale in

volume and in data complexity to accommodate future needs, without the risk of long-term

costs for database changes. This system - the MDMS - must be built not only with these

AMI business processes and data needs in mind, but also with the understanding that

several other converging trends within the utility industry are transforming most utilities

even more into data management organizations in addition to the traditional “wires

management” role. This is being driven by regulatory demands and rapidly evolving

technology and standards that affect both the quantity and quality of data that are

becoming available, all the way from inside the substation fence to inside the homes of

residential customers.


An effective MDMS must recognize and support all of these evolving trends and

requirements.

MDMS’ Place in the Range of Utility Enterprise Systems

Before describing what constitutes an effective MDMS, let’s explore both why there is a

need for a new system, and what an MDMS is not.

CIS vs. MDMS

One question often asked is whether an entirely new system is needed, or whether these

new needs can be met by expansion of the Customer Information Systems (CIS).

The CIS has evolved into the full cycle “meter-to-cash” engine in the utility and, as such,

the key system used to leverage meter data. However, CIS system design pre-dates the

needs that are driving the current interest in Meter Data Management. Energy companies

looking to fully exploit interval data need to consider the roles that can be played by their

CIS systems and the role that should be addressed by separate MDMS systems.

A CIS ingests meter data, typically via a monthly consumption read (although there is

always some more granular data that is incorporated into the appropriate buckets). When

this data has been stored, monthly bill cycles are run to create invoices, generally based

on simple billing determinants. Once the customer has been invoiced, related areas are

addressed by the CIS, such as credit and collections, payment arrangements, financial

functions, etc. CIS systems are often the launching point for CSRs to facilitate other

customer activities that are managed by downstream systems, including taking service

orders and inputting outage reports.

However, even before the advent of MDMS systems, CIS systems were generally

insulated from the raw details of interval metering data by other systems, such as MV90.

For example, CIS systems were not designed to perform validation on interval data; such

validations were performed elsewhere. In addition, most CIS systems only handle simple

rates for the majority of the customer base. Commercial and Industrial customers with

more complex rates requiring interval data are often handled by specialty complex billing

systems or manual processes that send information to the CIS in an aggregated manner

for invoicing and posting to the general ledger.

The MDMS is being increasingly seen as the logical broker between the AMI systems and

any enterprise systems that may need access to AMI data or AMI actions – such as on

demand reads or connect/disconnect – in real or near-real time. By leveraging an MDMS,

interactions with multiple AMI (and other) systems can be accomplished via many-to-one

rather than many-to-many relationships. CIS systems were never intended to play this

type of role.


Today’s CIS systems generally do what they do very well, but they were simply not

designed to play a central role in processing and managing large quantities of interval

data, nor managing a set of real time interactions with meter data collection systems.

Adding that capability to a CIS will increase complexity in what is an already overly

complex system in most cases, and increase overall risk of system problems. In fact, an

all encompassing CIS system would run counter to the current trend of moving to best of

breed, componentized systems. As a pundit once observed, CIS systems know very little

about the “Customer” nor have a great deal of “Information”; they are essentially a form of

accounting system that performs billing. Extending them into a full featured meter data

processor and repository stretches them well beyond what they were intended to be. The

diversity of systems resulting from using a separate MDMS enables innovation and

flexibility, reduces risk, and centralizes the issues of complex interval data management in

a system where it can be accessed through the increasing array of standards.

Meter Data vs. Meter Asset Management

There is often also confusion about Meter Data Management Systems vs. Meter Asset

Management Systems. It is sometimes presumed that a new MDMS will also serve as a

Meter Asset Management system.

The two functions are, of course, closely related, and share a fair amount of common

information. However, these two systems play very different roles with very different

needs.

A Meter Data Management system is all about usage at the Service Point. One needs to

know what meter is at a Service Point at any point in time, but the key metrics being

tracked deal with usage and activity, regardless of what meter is installed.

Conversely, a Meter Asset Management system, or more correctly a Meter Device

Management system, is all about the meter or other device. In this case, the key metrics

being tracked deal with device performance, no matter where it is located, as well as

device location at any particular point in time.

Thus, while these 2 systems need to be joined at the hip, trying to cram both functions into

a single system can result in sub-optimal performance for both.

Once again, the role of the CIS is an issue. In many cases, utilities did not have effective

Meter Device Management systems in place. As a result, the CIS has been made the

system of record on meter assets and their location. But like other functions, this was

never a capability intended for a CIS. An effective Meter Device Management System

tracks all information about meter assets, including test results and other indications of

performance, device associations, and cradle to grave location, not just location at


premises. If there is such a system in place, it makes much more sense for the Meter

Device Management System to be the system of record.

Device Configuration

Device Groups

Device Class

Device Associations

Firmware Versions

Firmware Upgrade

Location and GPS Information

Site Configuration Information

Device History Information

Meter Changes – Change Outs, New Meters and Removed Meters

Device Events

Device Messages

Asset Communications ID’s

AMI Event Codes

ADMS MDMS CIS SOA

A Meter Device Management System – much like the MDMS - becomes particularly

important with the roll out of an AMI system. First of all, with an AMI rollout there will be

tens of thousands or even hundreds of thousands of meters and other AMI devices being

installed in a year that need to be tracked and supported. Secondly, there will be much

more complex device associations than in the past – as well as the need to test and

calibrate not just meters but an integrated set of devices. An AMI Device Management

System – or AMDS1 to differentiate it from an MDMS – becomes an important pre-

requisite for AMI. Thus, while a single system should not be expected to perform both

functions, the MDMS and ADMS need to be planned together, and designed to be tightly

integrated. This should go so far as to allow users looking at meter asset information in

the ADMS, for example, to easily link to and pull up relevant usage information in the

MDMS, and vice versa.

1 We have switched to the ADMS term from the more commonly applied term Meter Asset Management

because that is sometimes confused with a Financial Asset system. In most cases, utilities have an enterprise Financial Asset System covering all capital assets, including meters. That system needs to be interfaced with the ADMS, but an ADMS should not be expected to perform this function.


Elements of an Effective MDMS

An effective MDM solution consists of multiple elements:

1. First and foremost, the underlying MDM repository and infrastructure must be able to

effectively:

ingest AMI data from multiple sources in a timely manner;

process AMI data as required - including performing Validation, Estimation

and Editing (VEE) to cleanse the database, and creating billing determinants,

not only for traditional mass market rates but for evolving time-based rates as

well;

store data for all commodities in a way that supports smaller utilities and

those just focused on C&I customers, but scales to meet the needs of larger

utilities with millions of customers and hourly or sub-hourly data;

distribute the data to the appropriate systems, including the CIS. To do this

effectively, the core MDM architecture must be designed with full recognition of

the way in which the data will be used by other systems; without that

perspective from the outset, there is a risk that large inefficiencies will be

introduced, or that some potential benefits are not achieved;

manage events relating to AMI data and equipment, serving as the broker

between other systems – such as OMS – and the AMI systems in order to take

full advantage of the availability of AMI on a real-time basis, and;

publish the data for use by downstream systems, and for customer and other

stakeholder or partner access, and make it available for ad hoc reporting.

2. Second, an overall solution should offer a set of integrated business applications

that address key operational processes which benefit most from the availability of AMI

data, such as revenue protection, load research, load forecasting, settlement, complex

billing, and distribution asset optimization.

3. Finally, the overall solution should also address the customer side of AMI. This

needs to go well beyond the simple presentation of load profiles to customers - many

of whom will not be able to readily leverage such information – to include the

appropriate systems and tools that enable customers to understand their options and

the impact of these options, and to take actions.

Key issues in delivering these types of capabilities are explored in subsequent sections

below.

Critical Characteristics of an MDM Data Repository

An MDMS must be built around the needs of managing large quantities of data. To best

do this requires more than just using the types of databases generally found in CIS

systems, which are typically organized around customer and premise. The MDMS must


bridge the gap between incoming interval meter data and enterprise-wide business

functions, such as CIS, in an optimized, scalable, and efficient manner.

To accomplish this, an MDMS needs to look more to best practices in data warehouse

than to CIS data structures. For example, the star schema architecture has been shown

within the data warehousing community as an effective design methodology for large

volumes of infrequently changing time series data, in terms of both performance and

scalability. Further, “wide storage” – where data for interval units of 1 hour or less are

stored as columns in a daily record rather than as 24 or more individual records – can

significantly reduce storage requirements and increase performance. Consider the case

of 15 minute data, for example. In a traditional “tall storage” configuration, a day’s worth

of 15 minute data would require 96 records. In a wide storage environment this is a single

record, resulting in a dramatic savings in storage requirements. Moreover, since an

MDMS is a very I/O intensive application, this also directly translates into significantly

faster performance.

These types of architectural issues are critical to scalability – the ability for the MDMS to

process and store data for utilities with millions of meters and hourly or sub-hourly data for

all. An N-Tier architecture that enables the system to leverage multiple application and

database servers is also critical to achieving scalability. In addition, an MDM needs to

support load balancing and leverage multi-threading capabilities in order to effectively take

advantage of scalability provided by the inexpensive addition of application servers.

Data in the repository should also be optimized for integration with analytical engines that

can be used to drive other functionality. For example, segmentation and aggregation are

critical to such functions such as load forecasting, settlement, distribution planning etc.

Furthermore, the repository needs to be able to store multiple versions of data resulting

from different processing steps, and readily apply the right data to the right business

process.

The other key question is the overall data structure architecture. Many CIS systems have

hard-wired data schemas that are very difficult to change. Given the fact that AMI and

MDM are still in their infancy, and markets are in a state of flux, it is critical that the MDMS

be able to quickly adapt to changing market conditions. Thus, a rigid data schema that

requires extensive coding or scripting and table changes every time there is a need for a

new data element will have significant implications on cost and time to market. Instead, it

is important for an MDMS to have a flexible data structure that lends itself to rapid change,

without the need for programming. Ideally, the system should be designed, perhaps with

the use of a meta-data layer, to enable the business users to add new database objects

and attributes and to change relationships without the need for database table or structure

changes.


Effective Data Processing

Validation Estimation and Editing (VEE)

One of the most basic functions expected of an MDMS system is the Data Cleansing

process, commonly referred to as Validation, Estimation and Editing, or VEE.

Processing interval data collected via AMI is much more complex than processing

consumption data collected via manual or semi-manual methods. An effective MDMS

should not only deal with this level of complexity, but also provide significant flexibility in

how data cleansing is accomplished. In fact, flexibility is the key to delivering effective

data cleansing. The following must be considered in the design of an effective VEE

process:

There are a number of generally accepted validation tests that any MDM needs to

perform, such as Missing Interval Check, Zero Check, Negative Value Check,

Static Value Check, Spike Check and Sum Check. (These are all part of the

standard California VEE rule set). However, an effective MDMS also needs to

provide users with the ability to easily create custom validation – and estimation –

rules for a variety of purposes. Requiring programming or scripting to create

special rules only adds to the cost and time associated with system deployment

and operations.

The system should allow the user to create different VEE work flows for different

groups of customers; for example based on rate class or perhaps competitive

supplier in a deregulated market where the distributor manages the MDMS. There

needs to be a simple way to group customers together for VEE, and even the

ability to include customers in different groupings for different purposes.

In fact, it is easy to envision how different uses of the data may require different

VEE rules, or even different sets of data. Revenue Protection analysis, for

example, clearly requires the use of raw data for analysis purpose, rather than

data where 0 values have been estimated. On the other hand, a Settlements

system might require an additional level of VEE on the already processed data,

based on the local market rules. An effective MDM will provide full flexibility in

establishing VEE work flows.

As suggested above, VEE is often driven by the regulatory environment. There

may be radically more complex VEE requirements imposed in a deregulated area

where data needs to be delivered to multiple parties. A system needs to be able to

support different VEE work flows in different jurisdictions.

The availability of interval data provides an unprecedented ability to create

accurate customer load profiles. The MDM needs to be able to readily leverage

these load profiles, certainly for the Estimation process where they can reliably fill

in missing data with the appropriate weather modeling, but perhaps for use in

Validation testing as well.


A VEE workflow must also consider the overall business process. Under what

circumstances are data automatically estimated, and under what circumstances

should there be manual intervention? How are exceptions routed and handled?

Finally, the VEE process must recognize the importance of timing. When should a

work flow be scheduled and when should it be triggered by another event, such as

data loading? How much if any VEE should be done as the data is being loaded,

and how much needs to wait until the end of the day so that sum checks can be

run and estimations performed with all available data points? Again, an MDM

must be able to demonstrate significant flexibility in order to maximize

effectiveness.

Billing Determinants

Historically, the creation of billing determinants, at least as it relates to mass market

customers, has been the domain of the CIS. As AMI systems began to be implemented

this essentially did not change. Typically the CIS would use monthly consumption reads

to create billing determinants, even in cases where daily data was available.

Utilities are now consistently looking for the MDMS to create the billing determinants.

There are a variety of reasons for this. First and foremost, utilities are looking to isolate

the CIS from the AMI systems – particularly where they may be more than one. The

MDMS, therefore, becomes the logical choice for this function. Secondly, with the

movement to expand the use of Time-of-Use rates, many CIS systems simply do not have

the ability to create billing determinants for all customers.

Introducing the MDMS in the mix, however, creates a major timing risk. Many utilities are

already challenged to fit the billing process into the defined overnight time windows. Now

there must be synchronization with a separate system. Moreover, that system is busy

collecting interval data from all customers on a daily basis, not just from those customers

on the daily billing cycle, and these data loads can take a considerable amount of time.

For an MDMS to play this role effectively, it needs several things:

1. A user controlled method for easily creating any type of billing determinant, so that

the system can readily compute the appropriate determinants, and rapidly respond

to changes over time, particularly as new rate classes are introduced.

2. A high level of performance, to ensure that all of the required processes are

performed in the available time windows.

3. A robust scheduling system to ensure that different processes can scheduled to

avoid contention.

It is too early in the evolution of the MDMS to determine how well different systems

perform this critical function.


MDMS as a Broker of Requests to the AMI System and Manager of Events

As utilities consider the business case of rolling out an AMI system, it quickly becomes

apparent that the AMI system needs to interact with numerous enterprise systems, in

many cases in real time. Is it necessary to provide direct interfaces between these

systems and the AMI system?

A recent IBM Utility Integration Whitepaper included the following diagram and noted:

“The point-to-point approach results in numerous complex connections that need to be

maintained”

In fact, as the concept of an MDMS has evolved over the last 2 years, it has become

increasingly clear that an alternative to direct linking between all systems and each AMI

head-end directly is to leverage the MDMS to broker requests between the AMI systems

and the other systems. There are several reasons that this makes sense:

First, in many cases utilities are putting in AMI systems from 2 or more vendors, in

order to spread risk, leverage different technologies better suited to specific

geographical areas (e.g., utilize Power Line Systems in rural areas while relying on

RF in denser parts of the service territory), or take advantage of different

technologies for different commodities. Whatever the reason, multiple AMI

systems would require many-to-many interfaces between the enterprise systems

and the AMI systems. Alternatively, leveraging the MDMS as a broker requires

only many-to-one interfaces with the MDM, letting the MDM worry about identifying

and communicating with the right AMI system.

Not only does the existence of multiple AMI systems complicate interface

requirements, but it also requires that there be appropriate logic to know which

system to interact with. This type of logic would need to be added to each

enterprise system interface. Instead, with the MDMS as a broker, only the MDMS


need maintain this type of logic, and a well designed MDMS will support this out-

of-the-box.

Finally, other than perhaps the case of the newest systems, most enterprise

applications were not designed with real time interaction in mind. While even with

the MDMS acting as broker there will still need to be real time integration with the

MDMS itself, the MDMS can worry about the greater complexities of requesting

and retrieving data from the AMI system to address On Demand Reads,

Connect/Disconnect Requests, Voltage Checks, and other services made feasible

by the availability of AMI.

With this in mind, there are a range of events for which an MDM could become a central

component.

MDMS

Other

WM

OM

CIS

Manual

Reads\

SCADA

AMI

For example, the availability of AMI can support outage management in a variety of ways.

If an outage is reported, the AMI system can be accessed to determine if, in fact, an

outage exists, and potentially the extent of the outage. To accomplish this, either the

OMS or the MDM ideally requires an effective mechanism to be able to determine which

end points should be contacted, and how the information being retuned should be

interpreted. Where the AMI system is sending outage flags in a wide-scale outage

situation, the MDMS needs an effective filtering mechanism to keep from overwhelming

the OMS with messages. The MDM can play a role during the restoration process as well,

selectively pinging meters that are deemed to have been restored, and checking

downstream assets. While some newer OMS systems have an effective predictive

modeling capability to optimize decisions about where to dispatch crews and what parts of

the network are likely restored, it is conceivable that an MDM which incorporates a circuit

model can dramatically enhance this type of capability. While no MDM has yet played this


type of role, this is a future model that should be considered, particularly for those utilities

that continue to use legacy OMS systems.

Another key event that can be managed by an MDM is demand-response. This can take

a variety of forms. At the simplest level, an MDM system can be told to implement direct

load control at specific end point points, and then provide those requests to the

appropriate AMI head-end systems that support load control. However, it is conceivable

that a utility may have multiple demand-response programs, including direct load control,

Critical Peak Pricing (CPP), and a program that pays participants for load shedding,

perhaps managed by a third party. An MDMS:

will either need to know what customers are on what program, or be able to accept

that information from an external source such as a CIS;

may need, in the case of CPP, to initiate an alert to the customer and perform on-

demand reads at the start and end of the event, or more frequently depending

upon the way the customer is being billed;

might provide, for Real Time pricing, day ahead pricing notification through both an

in-home display and through Internet presentment, offer an analysis of options for

reducing costs during high price periods, and provide after the fact presentation of

both load and rates;

needs to know; for 3rd party managed load shedding programs, which parties to

contact, be able to perform on-demand reads and calculate baselines, and create

the appropriate billing determinants, and;

perhaps longer term, have the intelligence to accept only the level of demand

reduction required, and then determine the optimum way to achieve that load

reduction through all of the available options.

Again, there are no MDM systems in place today that even approach this level of

functionality in managing demand-response events, but the potential is there for MDM to

play a broad role.

Complex Event Processing

These types of transactions are examples of complex event processes which require the

handling of transactions, events and exceptions identified by the MDM or other systems

and must process data received from - and needing to be sent to - the various AMI head-

end systems as well as other source systems. While the processes described above may

sound fairly basic, in fact the number of potential events, exceptions, and resulting


workflows generated from MDM can vary greatly, and some of the workflows can grow to

be quite complex.

As a result, an

effective MDM should

provide some basic

Business Process

Management (BPM)

or workflow

capabilities that allow

the systems

integrator initially,

and utility staff

ultimately, to readily

model work flows and

implement processes based on them. An effective BPM implementation can:

Trigger system-to-system business processes without requiring manual

intervention to address exceptions. This is extremely important given the potential

volumes of transactions that will need to be managed and filtered.

Intelligently schedule and assign those activities that do require manual

intervention to the right users based on their roles and workload. This may include

the need to communicate these tasks using several channels – the MDMS

application, e-mail, SMS, PDAs, etc. For some events, the appropriate escalation

may need to occur – for example when tasks have not been completed within a

certain time period, a supervisor may need to be notified.

Provide operational reporting to understand the health and effectiveness of each

business process.

Data Integration

In the previous section, the need to integrate an MDM with AMI systems and enterprise

systems was addressed. In addition to these real time interface requirements, there is

also a need for bulk loads of data, including both AMI data and data that will be needed

from systems such as the CIS. An MDM needs an effective strategy for dealing with both

types of integration challenges

Newer generation systems leverage a Service Oriented Architecture (SOA) to support

integration. SOA has rapidly become an overused industry buzzword that is defined

differently based on different points of view, but in general it refers to an architecture that

packages business processes into services. Services communicate with each other by

passing data from one service to another. SOA allows services to be combined to create


new application, and different applications to exchange data as part of a business

process. In an SOA, data is exposed so that it can be shared with other systems.

To facilitate integration between applications, most utilities are in the midst of rolling out

either an Enterprise Service Bus (ESB) or Enterprise Application Integration (EAI)

architecture. While these architectures are tightly related, they are in fact different, and

there is considerable confusion about what each represents and what the differences are.

This is not the forum to explore the differences, so the discussion will only address the

ESB. An ESB generally provides some level of abstraction on top of a messaging system

layer, which allows the value of messaging to be gained without having to write code. An

ESB does not by itself implement a SOA, but provides features that can be used to

implement one. Similarly, ESB is not necessarily web-services based. Based on EAI

rather than SOA patterns, it tries to remove the coupling between the service called and

the transport medium.

Some MDMS vendors have built their systems around a particular ESB application. This

has concerned some utilities that are reluctant to introduce multiple ESB architectures in a

particular implementation. Instead, it may make sense for MDMS vendors to focus on the

lowest common denominator, which is the messaging layer itself. There is active work

ongoing to create comprehensive messaging standards relating to AMI. For example, the

MultiSpeak initiative has created a set of standards that have been well adopted by

vendors supplying solutions to rural cooperatives in particular. The IEC Technical

Committee 57, Working Group 14 has been actively developing standards (more

commonly known as CIM - Common Information Model), which are similar but cover a

broader range of processes and specifically intended for larger utilities. By adopting these

types of messaging standards – to handle functions such as On Demand Reads etc. - an

MDM vendor can easily integrate with any EAI architecture or ESB. Nonetheless, ESB

functionality within an MDMS will not only support environments where no ESB is present,

but may also simplify integration even where the utility has deployed an ESB architecture.

A robust integration strategy will require multiple elements.


Historically, messaging standards primarily fell into a category known as “Request-Reply”,

where System A would make a request of System B (e.g. an on-demand read), and then

receive and process a reply from System B (e.g. the current register read). Some AMI

interactions may take advantage of a “Publish-Subscribe” model. This model is being

deployed where many entities may need to know about certain events. A broker is

introduced between the “Publisher” and a series of “Subscribers”, so that many to many

interfaces are not required. This form of messaging may be appropriate in the event of

outage flags being generated by the AMI system, so that the OMS, CIS and other

appropriate systems are notified. An effective MDMS should be able to leverage both

Request-Reply and Publish-Subscribe Messaging.

Current Elements of IEC 61968-9

While all of these concepts could be important for batch data loads, there are in fact many

situations in which a more effective strategy would be a simple batch file transfer. For

example, an ESB might introduce overhead that will affect performance, which is critical

when loading millions of records. An MDM needs to have an effective approach for


loading large batch files. This requires capability to Extract, Transform and Load data.,

including robust routines for processing data as it is being loaded. For example, dealing

with DST might be most effectively handled as part of an interface. While comprehensive

VEE cannot be performed during data loads, as suggested earlier, some amount of

validation processing should be done as data is being collected so that exceptions can be

dealt with. An effective MDM integration strategy needs to consider all the ways in which

the MDM must communicate with other systems.

Integrated Business Applications

Providers of Meter Data Management Systems come from several different backgrounds.

Some previously focused on the process of collecting interval and other meter data.

Others are trying to move from the CIS world

Another group of MDM providers have come from the application side; this group focused

on areas such as load research, settlements and complex billing, or other applications that

required the creation of a database that could ingest and manage interval data. An

advantage that this background brings is that it required that there be a technical

architecture, data model, and analytic engines created that enable sharing of useful

information, and not just focused on the storing of data. For an MDMS to be effective in

leveraging the data, it should be able to seamlessly integrate and synchronize multiple

data types, including customer information, network data, system level metering, and

weather information, and aggregate data to the appropriate levels. MDMS systems that

are not designed with these types of capabilities in mind may not be able to readily

support key business applications that can leverage this data. In addition, such

consideration in the design of an MDM may yield advantages in the core MDM

functionality.

For example, consider load profiling. Certainly, load research, forecasting, and settlement

systems must rely heavily on load profiling capabilities. But profiling is a key ingredient in

Estimation, and could play a role in Validation as well. An MDM that incorporates a load

profiling engine to support business applications is likely to have a more robust VEE

capability.

One of the types of business applications that is not even practical without AMI data is

Revenue Protection. AMI data enables the Revenue Protection group to better analyze

loss of revenue opportunities. An effective Revenue Protection application will identify

potential areas of revenue loss due to theft, malfunctioning meters or other factors. This

may involve standard and custom tests that leverage interval data as well as AMI event

data, such as an indication of an outage. Conceivably, load profiles could be leveraged

here as well. A system could include Case Management capabilities to help the Revenue

Protection group manage the process. An MDMS that has an integrated Revenue

Protection application is more likely to support this critical process than one focused


exclusively on data management, and such an application itself will generate significant

value.

Similarly, electric utilities

deploying AMI often look to

Transformer Load Management

(TLM) as an area of potential

benefits. However, with the

appropriate tools it is possible to

leverage AMI data for a broader

set of distribution analysis

applications. Leveraging

segmentation, profiling and

aggregation, as well as

integration with the GIS system,

an application should be able to

accurately estimate hourly load

at any point on network, even when hourly data is not available. This information can help

utilities avoid device failures and outages caused by overload, while also reducing capital

expenditures by enabling more precise sizing and timing of planned system additions. In

addition, such a system should be able to improve phase balancing and circuit utilization,

as well as voltage regulation and capacitor placement. An MDM that has these types of

uses in mind as a result of an integrated Business Application is more likely to have the

underlying engines as well as data structure to ensure that these types of analyses can

readily be fed.

The Customer Side of AMI

One desired benefit of AMI is to reduce customer service costs by making detailed usage

information available to customers, through both customer self-service and the call center.

This can help more quickly resolve billing issues, while at the same time educating

customers about the relationship of their behavior to energy costs. Moreover, a key driver

for AMI is interest in improving the cost-responsiveness of consumer behavior. Meter

systems are needed to provide the hourly cash registers for time-based pricing - which

holds the potential to be a cheaper, cleaner, safer way of meeting future system load

requirements. But deciding how to deliver meter data to customers in a meaningful

manner is a key issue.


This goes beyond simply choosing whether to display the data on the Web or through an

In-Home Display, described further below. An effective and comprehensive approach

requires that the information be provided in a way that customers can understand and act

upon.

The availability of interval data

makes it possible to provide

customers with a rich set of

information to help them better

manage their energy use. In too

many cases, however, load data has

been viewed by utilities as a

separable item, not integrally tied

with other information of interest to

customers, and not provided with

tools to help the customer make

sense of the information. While this

approach may work for larger

companies that have available

energy expertise, it has not worked

effectively for mass-market

customers who will now have access to interval information for the first time.

To deliver information that will work, it is important to tightly integrate usage information

with billing information, which is at the core of utility-customer communications, and

provide customers with a rich set of tools they can use to take best advantage of this

valuable new information. For example, the types of tools that become possible with an

AMI system include

A “bill-to-date” function that estimates a customer’s bill at any time in the month

based on the AMI data

Rate Analysis that not only allows the customer to play what-if games to compare

alternative rates, but also automatically notifies the customer viewing their bills on-

line how they would have done on alternative rate scheme, and can combine the

effects of rate changes with efficiency actions.

E-mail and On-Line Alerts to customers when they appear to be at risk of going

over pre-set monthly usage/costs, and alerts for time-of-use customers of shifts in

usage from off-peak to peak with an estimate of impacts.

Load Shift Analyses that can be used to help customers understand how they can

shift load to the off-peak and how much they might save.

Targeted promotion of key programs based on analysis of AMI data.


Analysis of the impact of different actions to mitigate higher pricing, and

presentment of load overlaid with actual prices so customers can see their usage

during periods with different price points.

These types of tools are examples of what can be accomplished with an MDMS

architecture that provides value-added analytics, not just data storage, and is designed

with the full range of potential uses of data in mind.

Extending MDM into the Home or Business

There has been much talk in the past year about the need to access Home Area Networks

(HAN) for both customer communications and support of demand-response programs.

Indeed, the Open HAN Committee has been working on another set of standards to

support messaging with HAN devices.

There has also been a sometimes spirited debate about how to communicate to the HAN.

On one side are the proponents of the meter network as the communications channel,

and the use of In Home Displays to reach customers. This has led to debates about the

bandwidth that will be required for the meter communication network. On the other side

have been proponents of using the Internet as a means of communications, with the PC

as the display device; this approach would, by definition, be significantly less expensive.

Arguments against this channel range from the need to leave computers on in the home

to the fact that not all homes have Internet connections,

As with many such debates, the reality probably lies somewhere in the middle, with there

potentially being a place for both approaches. From an MDM perspective, the key is to

make sure that the MDM system adheres to the rapidly developing HAN messaging

standards to ensure that it can play a role as HANs evolve.

One of the arguments for the use of the meter network and an In Home Display is that this

is the only way to get up-to-the minute information to the customer. This is exacerbated

by the fact that, given the way data has been collected in some AMI systems, by the time

the customer sees the data on the utility’s portal it may be 2 to 2 days out of date. The

extent to which this will actually be required, however, is still a matter of debate.

Sometimes lost in this discussion, however, is the fact that data coming directly from the

meter has not gone through any VEE process. In the end, this may represent a serious

concern to utilities who are, rightfully, worried about the quality of data customers see. A

better solution might be for AMI systems to deliver data to the MDM on a more frequent

basis, so that customers see at least the previous day’s data. More real time data could

then be routed directly from the meter to a PC on the HAN, to be integrated with the data

available over the Web from the central repository. Basic validation can then be

performed via the portal on this small amount of more recent data, so that customers can

be assured of getting clean information.


The Future of MDM

The term Meter Data Management is already a misnomer. As noted earlier, typically an

MDM will store lots more than just meter data, and include weather data, asset data, GIS

data, and more.

In the future, an MDM may be called on to do a lot more. As Smart Grid initiatives

expand, an MDM may be asked to collect data from sensors located all across the

network. In fact, some MDM systems already are being used to collect summary SCADA

data. Data synchronization requirements will expand as a broader range of data is

ingested and processed. Built in MDM analytics will need to expand to include a range of

predictive modeling capabilities. The Meter Data Management System may evolve into a

full featured Network Data Management System, or NDMS.

Interval Meter Validation,

Estimation, Editing

Centralized Database Repository

Meter Data

Only

Interval Meter Validation,

Estimation, Editing


Meter Data

Only

Complex

Billing

Customer

Care

Customer

+ Meter

Data

Pricing Design

Forecasting

Revenue Prot.

Settlement

Unbilled Revenue

Reporting

Complex

Billing

Customer

Care

Customer

+ Meter

Data

Pricing Design

Forecasting

Revenue Prot.

Settlement

Unbilled Revenue

Reporting

T&D Asset

Optimization

Asset +

Customer +

Meter Data

Outage

Detection &

Response

System Loss

Detection

T&D Asset

Optimization

Asset +

Customer +

Meter Data

Outage

Detection &

Response

System Loss

Detection

Asset

Profitability

ROI and ROA Based

Decision-Making

Cost +

Asset +

Customer +

Meter Data

Customer

Profitability

Asset

Profitability

ROI and ROA Based

Decision-Making

Cost +

Asset +

Customer +

Meter Data

Customer

Profitability

Incre

asin

g V

alu

e

Interval Meter Validation, Estimation,

Editing


Meter Data

Only

Interval Meter Validation, Estimation,

Editing


Meter Data

Only

Complex Billing

Customer Care

Customer +

Meter DataPricing Design

Forecasting

Revenue Prot.

Settlement

Unbilled Revenue

Reporting

Complex Billing

Customer Care

Customer +

Meter DataPricing Design

Forecasting

Revenue Prot.

Settlement

Unbilled Revenue

Reporting

T&D Asset

Optimization

Asset +

Customer +

Meter Data

Outage Detection &

Response System Loss DetectionT&D Asset

Optimization

Asset +

Customer +

Meter Data

Outage Detection &

Response System Loss Detection

Operational

optimization

Management of demand

resources

Network +

Cost +

Asset + Customer +

Meter Data

Failure prediction Operational

optimization

Management of demand

resources

Network +

Cost +

Asset + Customer +

Meter Data

Failure prediction

Meter Data Management May Evolve into Network Data Management

Many of the characteristics cited in this paper that define an effective MDMS – e.g.

scalability, flexible data schema, focus on synchronization of multiple data sources, and

leveraging of underlying analytics – become critically important if the MDMS is to evolve

into an NDMS. However, care needs to be taken to make sure we do not have a repeat of

the CIS experience, where many CIS systems evolved into bloated, inflexible systems that

performed functions well beyond what they were intended to do, and became extremely

expensive to implement and adjust as needs changed. MDM systems need to be flexible,

componentized, easy to integrate with, and continue to focus only on those things that the


MDMS can do best, leaving it to other systems to perform functions that they are better

suited to perform. In this way, the MDMS is best positioned to evolve into one of the

handful of critical utility IT systems - alongside the CIS, ERP, DMS etc. - and allow the

company to best evolve into a 21st century utility.


meter data management: the key to unlocking the benefits...

Documents