01 Overview MDM

1
Oracle Utilities
Meter Data Products
Copyright 2010, Oracle. All rights reserved.
The 5 Minute Overview

The system maintains information about all
meters and the service points at which they
are installed (the CIS is the system-of-record)
The system orchestrates service
requests to enable and disable service
at service points
The System
Meters and Service
Points
The system orchestrates long-running

business processes that commission,
decommission, and monitor the state of
smart meters
The system is the system-of-record for

all measurements and meter events
CIS
Service Requests
Outage
Management
Smart Meter
Messages
Market
Participant
Measurements and
Events
Billable Usage
The system transforms measurements into

usage that is used by subscribing systems
1-2
Note well: some of the

functionality described on
this slide will be delivered in
future releases
Mobile
Workforce
High Volumes Are The Norm

Every meter sends initial
measurements that record how much
was consumed throughout a day
The "System"
A utility with 1 million such meters where

each meter sends its measurements 3
times each day will have 3 million initial
measurements each day
1
Each measurement is subject to validation,
editing (if they are obviously wrong), and
estimation (if they are missing). 3 million
per day means 35 initial measurements must
be VEE'ed every second of every day
(assuming continuous execution and this is a
bad assumption).
Initial measurements are normalized into
final measurements where each final
measurement is for a specific date and time
for a specific register / channel
Load Initial
Measurements
2
Validate Edit Estimate

Initial Measurements
3
Determine Final
Measurements
The final measurements are periodically

transformed into more concise and
palatable usage for the subscribing systems
For example, if a CIS subscribes to time-ofuse totals, it would receive "only" 3 million
records per month rather than 2.88 billion
measurements
4
Calculate Usage
For example, a meter configured to measure

15 minute intervals will have roughly 2,880
measurements each month. A million such
devices results in 2,880,000,000 (billion)
measurements each month.
1-3
Unit of Measure
kWh
kWh
kWh
Time of Use Quantity

On peak
1,200
Off peak
401
Shoulder
654
CIS
Complex Message Processing Is The Norm

<requestType>DECOMMISSION</requestType>
CIS
Other systems send requests

to the meter
<servicePointId>12312131212</service PointId>
<internalRequestId>4903929101</internalRequestId>
The System
Implemented by creating an
outbound communication
Inbound Communication
Request
Echelon Decommissioning
Process
Acknowledge request
Send ping
Validate request and

identify SP
Wait for response
<yourRequestID>4903929101</yourRequestID>
<ourTrackingID>6494930303</ourTrackingID>
<status>ACKNOWLEDGED</status>
yourRequestID>4903929101</yourRequestID>
<ourTrackingID>6494930303</ourTrackingID>
Send initial
commissioning signal
Identify device's headend and commence

vendor-specific process
Wait for response
<status>DECOMMISIONED</status>
Wait
6
8
1-4
Functional Areas
Service Provider
A service provider exists for every system that:
Sends information to any meter data product. For

example, a service provider must exist for every
head-end system that sends information to the
system
Receives information from any meter data product.

For example, a service provider must exist for the
CIS system that receives bill determinants from the
system
Every service provider has processing methods that
define the type of business object(s) that are created
when the service provider sends information
Processing methods also define the type of information a
service provider subscribes to and how the subscribed
information is sent
For example, an outage system can indicate it is

interested in "last-gasp" meter events and the
method used to apprise it of these events (e.g., via
web service calls or via a batch process)
1-6
Service Provider
Device Management
A device exists for every asset that consumes
resources
Note - most devices are meters
Device information includes its manufacturer and

model, a variety of logical identifiers (serial
number, badge number, ), the head-end
system that records its measurements, and
much more
Every device has one or more measuring components
that define what it measures
Note - scalar registers and interval channels are

classic measuring components
A device configuration is a record of how a device's
measuring components are configured at a point in
time
The system requires knowing how a device is

configured over time so it can calculate
retroactive requests for usage
1-7
Service Provider
Device Management
Validate-Edit-Estimate (VEE)
A device's measuring components are periodically measured
This occurs infrequently (e.g., once a quarter) for scalar

meters
This occurs frequently (e.g., every 15 minutes) for interval

meters
An initial measurement is created to record a measurement event:
Note: each Smart Grid Gateway (SGG) product supplies the

OSB configuration and business objects to load each
vendor's "standard" measurement format
After initial measurements are loaded, VEE rules are executed to
validate and sanitize the initial measurements
The product is delivered with many VEE rules
Implementations can develop additional rules as needed

Logical sets of VEE rules are consolidated into VEE groups
A measuring component is associated with a VEE group
In addition, regions, customer types, device types, usage

patterns, can also have VEE groups
When an initial measurement is VEE'ed, the rules from its specific
group and the rules associated with its regions / customer type /
device type / usage pattern / are executed
The VEE engine may be called real-time and in batch
1-8
Service Provider
Device Management
Validate-Edit-Estimate
Measurement
Final measurements are created after the initial measurements
have passed VEE
If a measuring component is re-measured, multiple

initial measurements will exist, but only one final
measurement is allowed for a specific date and time
Note - the term "measurement" is used throughout this

class to refer to a final measurement
Measurements may have derived values in addition to the
measured value, examples include:
The value after the channel multiplier is applied
The value after distribution loss is calculated
The value after conversion into a different unit of

measure
The amount conserved compared to "normal"
Derived values can be re-derived if the factors were incorrect
Note - the reason the derived values are kept

"redundantly" is to improve performance during usage
calculation. In addition, the derived values can be
displayed on the numerous graphs.
1-9
Service Provider
Device Management
Measurement
Installation Information
A service point exists for every geographic
location at which a device can be installed
Service point information includes postal

address, geographic identifiers, and other
geographic-related attributes that impact
VEE and usage calculation logic
In deregulated markets, service points also

define the market in which they participate
and the service providers that deliver
service
Installation events are created whenever a device
configuration is installed at a service point
The installation event maintains the on / off

history and the removal date (if any) so the
system can recalculate historical usage
A service point will reference a measurement
cycle if it is manually read and/or if its
consumption is pushed to subscribers
1 - 10
Service Provider
Device Management
Measurement
Usage Subscription
A usage subscription is a record of an ongoing
request to calculate bill determinants for one or
more service points
A usage subscription has a 1:1 correlation

with a "contract" in the CIS and the CIS is
the system-of-record
All contractual information that impacts how bill
determinants are calculated is defined on the
usage subscription (and must be kept in sync with
the CIS)
A contact exists for every entity (e.g., customer)
related to a usage subscription
There is no limit to the number of contacts

linked to a subscription
A contact has a 1:1 correlation with a

"person" in the CIS and the CIS is the
system of record
1 - 11
Service Provider
Device Management
Measurement
Usage Subscription
Usage Calculation Rules

Periodically, the system executes usage rules to
calculate and validate the bill determinants derived for a
usage subscription for a given time period
The base-package is delivered with the classic

rules, for example:
One rule applies a time-of-use map to

measurements (taking into account dynamic
options if critical peak events occur during the
calculation period)
Another rule can apply a formula to multiple curves
to derive another curve
Another rule retrieves the scalar readings
Service Provider
Device Management
Measurement
Usage Subscription
Implementations can develop additional rules as

needed
Logical sets of usage rules are consolidated into usage
groups
The usage calculation engine may be invoked:
Real-time (e.g., to retrieve "up to now" bill

determinants for a self service application)
In batch (the standard integration to a CIS)
1 - 12
Usage Transaction
Usage transactions record the results of a usage calculation
that will be sent to one or more MDM participants
For example, a usage transaction could be sent to the

service provider behind the subscription and to the
energy service provider associated with the
subscription's service point
Implementations can use either of the following methods to
create usage transactions:
A service point's measurement cycle can be configured

to periodically push usage
Service Provider
Device Management
Measurement
Usage Subscription
A usage transaction is created each time a SP's

consumption is pushed
Usage Transaction
The CIS can request usage when it requires bill

determinants
If a measurement is corrected, any usage transactions that
were calculated using the prior version of the measurement are
marked as subsequent correction
This, in turn, sends a notification to the original

recipients; it is up to these systems to re-request the
corrected usage
Usage transactions can be calculated online / real-time
1 - 13
The term bill determinant is another

way to refer to a usage transaction.
The meter data products have not
espoused this term because the
usage calculation engine can
calculate things other than bill
determinants.
Communication
An inbound communication is a record of a
message sent by a service provider
(including head-end and "edge applications")
Note, while initial measurements are

true inbound communications, they are
not persisted as inbound
communications due to their high
volumes
An outbound communication is a record of a
message sent to an MDM participant
(including head-end and edge applications)
While usage transactions are true

outbound communications, they are
not persisted as outbound
communications due to their highvolumes
1 - 14
Service Provider
Device Management
Measurement
Usage Subscription
Usage Transaction
Communication
Meter Event
Devices can send many different types of
events, for example:
If a meter detects power loss is

imminent, it can send a "last gasp"
message
A meter can send a "tamper detection"

when it suspects inappropriate
behavior
A meter event is created for these events

Meter events are sent to service providers
that register their interest
1 - 15
Service Provider
Device Management
Measurement
Usage Subscription
Usage Transaction
Communication
Meter Event
Activity
Most significant events are held in the various
transaction objects previously discussed:
Inbound communications
Outbound communications
Initial measurements
Usage transactions
Meter events
However, there are other types of events
For example, the receipt of a "payload" of

measurements from a service provider
An activity is created to hold these events
An activity can be a simple record of an event

taking place; alternatively, it can be more
interesting
Device Management
Measurement
Usage Subscription
For example, a payload event could create a To Do

entry if the number of final measurements created
is not in sync with the number on the payload
An activity can be related to any combination of

"master data" objects
1 - 16
Service Provider
For example, an activity could be related to a

service providers, service points, devices,
measuring components, contacts,
Usage Transaction
Communication
Meter Event
Activity
Service Requests
A service request is created to orchestrate
communications sent to head-end systems
A request to commission a meter, turn
a meter off, ping a meter, are all
orchestrated via a service request
Service requests can be created via:
A service call from an external system
A user online / real-time
A business process
Note: each SGG product supplies the BPEL
configuration and business objects for the
vendor's "classic" communication
orchestrations
1 - 17
Service Provider
Device Management
Measurement
Usage Subscription
Usage Transaction
Communication
Meter Event
Activity
Service Request
There Are Multiple Products
1 - 18
The Product Footprint Depends On What Is

Installed
The following matrix illustrates several installation scenarios:
Functionality
Implementation
This implementation only purchases and

installs the L+G SGG product
installs the Echelon SGG product
installs both L&G and Echelon products
installs the VEE and usage calculation product
This implementation purchases and installs all
products
This means that there is no single, monolithic
product. Rather, the system's functionality is
divided into multiple products and a customer
selects which products are installed.
1 - 19
The Product Stack

F1 - Framework
D1 - Meter Data Framework
D2 - Meter Data
Management
(MDM)
D3 - L+G SGG
Just as the Framework (F1) holds tables

and business processes that are
common to all UGBU products, the
Meter Data Framework (D1) product
holds tables and business processes
that are shared by more than one of the
child products
D4 - Echelon SGG
Any combination of child products can be installed by an implementation
For example: tables, business rules, and

user interface objects related to devices
and service points reside in D1 because
more than one child product uses these
objects
At least one child product must be installed as D1 doesn't contain specific functionality
An implementation can install additional child products over time (e.g., a
customer who initially purchases D3 can decide at a future date to purchase D4)
Just as D1 is installed in the same database as F1, if an implementation installs multiple
child products, all will exist in the same database instance (i.e., while the products are
separately installable, when they are installed together, their data exists in the same
database; this means that to an implementation, it looks like one "system")
This means that all products installed at an implementation will be installed under the
same releases of F1 and D1
The meter data products have been designed to coexist with any combination of sibling
products and this coexistence requires no implementation integration efforts
1 - 20
Each Implementation Has Its Own "Product"

F1 - Framework
D2 - Meter Data
Management
(MDM)
D3 - L+G SGG
D4 - Echelon SGG
CM - Implementation Extensions
When the meter data products are installed, the installation
scripts set up the system so that new features / business rules
added by the implementation are owned by yet another product
This allows future releases of the base-products to be easily
upgraded without upsetting extensions made by an
implementation
Note - the owner of implementation-extensions is CM (customer
modification) and it inherits all behavior in the higher products
1 - 21
There Are Other Meter Data Products

The meter data family of products will grow over time
F1 - Framework
D2 - MDM
D3 - L+G
D4 Echelon
D5 - MV90
A list of the installed products appears

when the "O" is clicked
1 - 22
Dx -
This Class Describes All Products

F1 - Framework
Device
VEE Group
Initial
Measurement
Subscription
Device
Configuration
VEE Rule
Measurement
Usage
Transaction
Measuring
Component
Eligibility Criteria
Measurement
Log
D2 - MDM
1 - 23
D3 - L&G
Dx
An aside: there are no tables specific to

a child product. For example, there are
no tables that are exclusively used by
MDM. This means that all tables for the
various meter data products are
delivered with Meter Data Framework
(D1).
The child products contain business

objects, plug-ins, portals, zones,
The Format Of This Class
1 - 24
The Format Of This Class

This class describes the out-of-the-box
functional components and the configuration
tasks necessary to implement the system
assuming no extensions
The MDM Advanced course describes the
various business objects behind each of the
functional areas and how classic extensions
can be implemented
Students who plan to take the MDM
Advanced course MUST complete the 22-week configuration tools course
1 - 25
Service Provider
Device Management
Measurement
Usage Subscription
Usage Transaction
Communication
Meter Event
Activity
Service Request
Note: Product Identification

If a slide has functionality that is only available if the implementation has
licensed a specific meter data child product, the respective product code
appears in the upper left corner of the slide
If a product code does not appear in the upper left corner, this means the
functionality is part of meter data framework (D1) and is available
regardless of which meter data child products have been installed
This means that the
functionality described on this
slide is only available if the D2
(MDM) product is installed
1 - 26
A Few Ancillary Topics Before We Start
1 - 27
The User Documentation

The user documentation includes the following:
The Configuration Guide describes all of the administration
tables (i.e., control tables) and the order in which they must
be set up
The User Guide describes many business processes and
has how-to sections
Some of the information in these documents is discussed during
this course, but not everything
Sooner or later, you will have to read them
1 - 28
Not End-User Training

This class is NOT an end-user training class.
Rather, this class is meant to expose you to the
systems major concepts so you can understand
how it works and how it can be configured for
your specific requirements.
The System
Meters and Service
Points
Service Requests
Outage
Management
Smart Meter
Messages
Market
Participant
Measurements and
Events
Billable Usage
1 - 29
CIS
Mobile
Workforce

01 Overview MDM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01 Overview MDM

Uploaded by

Copyright:

Available Formats

1

Copyright 2010, Oracle. All rights reserved.

The 5 Minute Overview

The system orchestrates long-running

The system is the system-of-record for

The system transforms measurements into

Note well: some of the

Copyright 2010, Oracle. All rights reserved.

High Volumes Are The Norm

A utility with 1 million such meters where

Validate Edit Estimate

The final measurements are periodically

For example, a meter configured to measure

Copyright 2010, Oracle. All rights reserved.

Time of Use Quantity

Complex Message Processing Is The Norm

Other systems send requests

Validate request and

Wait for response

Identify device's headend and commence

Wait for response

Copyright 2010, Oracle. All rights reserved.

Copyright 2010, Oracle. All rights reserved.

Sends information to any meter data product. For

Receives information from any meter data product.

For example, an outage system can indicate it is

Copyright 2010, Oracle. All rights reserved.

Note - most devices are meters

Device information includes its manufacturer and

Note - scalar registers and interval channels are

The system requires knowing how a device is

Copyright 2010, Oracle. All rights reserved.

This occurs infrequently (e.g., once a quarter) for scalar

This occurs frequently (e.g., every 15 minutes) for interval

Note: each Smart Grid Gateway (SGG) product supplies the

The product is delivered with many VEE rules

Implementations can develop additional rules as needed

A measuring component is associated with a VEE group

In addition, regions, customer types, device types, usage

Copyright 2010, Oracle. All rights reserved.

If a measuring component is re-measured, multiple

Note - the term "measurement" is used throughout this

The value after the channel multiplier is applied

The value after distribution loss is calculated

The value after conversion into a different unit of

The amount conserved compared to "normal"

Derived values can be re-derived if the factors were incorrect

Note - the reason the derived values are kept

Copyright 2010, Oracle. All rights reserved.

Service point information includes postal

In deregulated markets, service points also

The installation event maintains the on / off

Copyright 2010, Oracle. All rights reserved.

A usage subscription has a 1:1 correlation

There is no limit to the number of contacts

A contact has a 1:1 correlation with a

Copyright 2010, Oracle. All rights reserved.

Usage Calculation Rules

The base-package is delivered with the classic

One rule applies a time-of-use map to

Implementations can develop additional rules as

Real-time (e.g., to retrieve "up to now" bill

In batch (the standard integration to a CIS)