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 decisionmaking 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.
© Aclara Software Inc. 2008
2
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.
© Aclara Software Inc. 2008
3
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
© Aclara Software Inc. 2008
4
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 Events
Device Messages
Asset Communications ID’s
AMI Event Codes
CIS
ADMS
SOA
MDMS
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
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 AMDS 1 to differentiate it from an MDMS – becomes an important prerequisite 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.
© Aclara Software Inc. 2008
5
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:
x
ingest AMI data from multiple sources in a timely manner;
x
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;
x
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;
x
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;
x
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;
x
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
© Aclara Software Inc. 2008
6
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.
© Aclara Software Inc. 2008
7
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:
x
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.
x
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.
x
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.
x
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.
x
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.
© Aclara Software Inc. 2008
8
x
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?
x
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.
© Aclara Software Inc. 2008
9
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:
x
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.
x
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
© Aclara Software Inc. 2008
10
need maintain this type of logic, and a well designed MDMS will support this outof-the-box.
x
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.
CIS
AMI
OM
Manual
Reads\
MDMS
WM
SCADA
Other
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
© Aclara Software Inc. 2008
11
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:
x
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;
x
may need, in the case of CPP, to initiate an alert to the customer and perform ondemand reads at the start and end of the event, or more frequently depending
upon the way the customer is being billed;
x
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;
x
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;
x
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 headend 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
© Aclara Software Inc. 2008
12
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:
x
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.
x
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.
x
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
© Aclara Software Inc. 2008
13
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.
© Aclara Software Inc. 2008
14
Current Elements of IEC 61968-9
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.
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
© Aclara Software Inc. 2008
15
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
© Aclara Software Inc. 2008
16
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.
© Aclara Software Inc. 2008
17
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
x
A “bill-to-date” function that estimates a customer’s bill at any time in the month
based on the AMI data
x
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 online how they would have done on alternative rate scheme, and can combine the
effects of rate changes with efficiency actions.
x
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.
x
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.
x
Targeted promotion of key programs based on analysis of AMI data.
© Aclara Software Inc. 2008
18
x
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.
© Aclara Software Inc. 2008
19
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.
Network +
Cost +
Asset + Customer +
Meter Data
9
Failure prediction
Cost +
Asset+ +
Asset
Customer+ +
Customer
MeterData
Data
Meter
9
Detection & 9 ROI and ROA Based
Decision-Making
9 System Loss Detection
Response
Profitability
Profitability
Optimization
Optimization
9 Customer Care
9 Outage
9 Pricing
Design
Detection
&
9 Response
Forecasting
9 Settlement
9 System Loss
9Detection
Unbilled Revenue
Reporting
Revenue Prot.
9 Settlement
Complex
9 Pricing
Design
9 Interval Meter
Validation,
Estimation,
Billing
9 Unbilled Revenue
Editing
9 Forecasting
Reporting
9 Customer
Revenue Prot.
9 Centralized 9Database
Repository
Care
9
9
Meter Data
Only
9
Increasing Value
9 Complex
Billing
T&D Asset
9
Customer
Meter
Data
+ Meter
Only
Data
Management of demand
resources
Outage
99Asset
9 Customer
9 T&D Asset
Asset + +
Customer
Customer
Meter
Data+
Meter Data
9
Operational
optimization
Interval Meter Validation,
Estimation, Editing
Centralized Database Repository
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
© Aclara Software Inc. 2008
20
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.
© Aclara Software Inc. 2008
21