09 - Usage BO

9
Usage Subscription
Review From The Fundamentals Course
Copyright 2010, Oracle. All rights reserved.
The Usage Calculation Process

MDM can push usage to a
service provider on an
ongoing basis (via the
Measurement Cycle
Schedule batch processes
(see chapter 4)
CIS
Usage Transaction
Periodic Push
Process
US Id: 123910119192
UT Id: 12391011919232
Load Usage Transaction

Requests
An external system can

request usage (typically
as part of the bill
creation process)
Start Date/Time: 1-Jan-10 3:00pm

Acceptable Consumption Thru Window:
29-Jan-10 12:00am to 31-Jan-10 12:00am
US Id: 123910119192
UT Id: 12391011919232
Usage
Calculation
Engine
The usage calculation engine is very similar to the

VEE engine in that it is driven by configurable rules.
These rules calculate a usage transaction's usage
(bill determinants).
Usage calculation rules can also be configured to
validate the usage that was calculated by earlier
rules. If problems are found, the usage transaction
is transition to the Exception state.
9-2
Usage Transaction

End Date/Time: 30-Jan-10 12:00am
Acceptable Consumption Thru Window:
29-Jan-10 12:00am to 31-Jan-10 12:00am
UOM / TOU
Usage
kWh / On peak
1200.1 kWh
kWh / Off peak
401.2 kWh
kWh / Shoulder
654.8 kWh
Exception: kWh curve is not continuous
Most requests for

usage result in the
creation of a usage
transaction
The word most was
used because it's
possible for an
external system to
invoke the usage
calculation engine
real-time. In other
words, usage can be
retrieved for a usage
subscription real-time
without creating a
usage transaction.
This technique is only
recommended for
online requests, not
as part of batch
processes.
A Usage Transaction's Start Date Is Fixed

The End Date/Time Can Be A Window
Usage Transaction
US Id: 123910119192
Usage Transaction
Periodic Push
Process
CIS

Requests
UT Id: 12391011919232
Start Date/Time: 29-Dec-09 12am
For all rules
Thru Window Option: Window is specified

Acceptable Scalar Thru Window:
30-Jan-10 12am to 1-Feb-10 12am
Estimates Allowed: Yes
For scalar-oriented
usage rules
Estimate Date: 31-Jan-10 12am

Acceptable Interval Thru Window:
30-Jan-10 12am to 1-Feb-10 12am
For interval-oriented
usage rules
Because the creator of the UT won't know what type of

MC is installed, it's a good practice for a calling system
to populate both the scalar and interval thru windows
9-3
A Usage Calc Group Contains Rules

During the usage calculation process, the system executes the
usage rules defined in a usage group
Usage Transaction
Usage Group: Residential TOU
Seq
Usage Rule
10
Apply TOU map to kWh channel
Usage rules derive a usage transaction's usage using the measurements

linked to the US's SPs
Base-package rules are delivered that calculate common bill determinants
including:
- Scalar reads
- TOU consumption (by applying a TOU map to an interval channel)
- Interval curves (either real or derived)
9-4
US Id: 123910119192
UT Id: 12391011919232
UOM / TOU
Usage
kWh / On peak
1200.1 kWh
kWh / Off peak
401.2 kWh
kWh / Shoulder
654.8 kWh
Eligibility Criteria
Just like VEE rules, a usage rule may optionally have eligibility criteria
to control if the rule is applied
This feature can reduce the number of usage groups required by
an implementation because it allows a single usage group to
have conditional rules (rather than requiring a distinct usage
group for every combination of usage rules)
Seq
10
20
9-5
Usage Rule
Apply Solar TOU map to kWh channel
Criteria: Apply if customer has solar power
Apply Regular TOU map to kWh channel

Criteria: Apply if customer does not have solar power
This rule is applied if the customer has

solar power
This rule is applied if the customer does
not have solar power
Reusable Groups Of Rules

Analogous to the VEE rule equivalent, a usage rule can execute the
rules encapsulated in a different usage group
This allows commonly used rules to be encapsulated in reusable
usage groups for easy maintenance
Seq
10
20
30
Usage Rule
Apply Solar TOU map to kWh channel
Criteria: Apply if customer has solar power
Apply Regular TOU map to kWh channel

Criteria: Apply if customer does not have solar power
Apply Usage Group Calc Common BDs
Usage Group: Calc Common BDs

This rule executes the rules in the
referenced usage group
9-6
Seq
Usage Rule
10
Calculate number of days in period
20
Calculate total kWh
Effective Dates
CCB note: With MDM 2.0.1, multiple calc groups in a

period will result in multiple "bill calc headers" under a
single bill segment (where each is calc header is
calculated by calling rate application using the bill
determinant values derived by each calc group)
Unlike VEE rules, usage rules do not have individual effective dates
Rather a usage subscription can have different usage groups over time
In MDM 2.0.0, the system uses the group effective at the start of the usage
transaction period
In MDM 2.0.1, the system calculates separate bill determinants for each group
effective in the usage period
In other words, the entire usage group is effective-dated rather than the individual rules
US ID: 1234123112
Usage Group: Residential Scalar

Seq
10
Usage Rule
Retrieve start / end readings
US Type: Electric Commercial Interval

Contact: Pam Brown
Calc Group
Start Date

Residential Scalar
Seq
Usage Rule
10
Apply TOU map to kWh channel
9-7
Residential TOU
1-Jan-2010
15-Nov-2010
End Date
A Usage Transaction Can Have Date Breaks

The subscribing system can supply
date breaks when it requests usage
(only the subscribing system knows if
and when its prices and pricing rules
change during the billing period). If an
implementation has additional criteria
that causes date breaks, these criteria
can be easily added to the UT's
business rules.
Usage
Calculation
Engine
9-8
Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
A usage transaction can optionally

have one or more date breaks. In this
example, the UT has been created for
the month of January with a single
date break on 20-Jan.

29-Jan-10 12am to 31-Jan-10 12am
Date Break(s):
20-Jan-10
Usage Period
If a usage transaction has date

break(s), the usage calc engine
segregates the usage into usage
periods. If there are no date breaks,
a single usage period is created.
Date/Time Range:
1-Jan-10 12:00am to 20-Jan-10 12:00am
UOM / TOU
Usage
kWh / On peak
1200.1 kWh
kWh / Off peak
401.2 kWh
Usage Period
kWh / Shoulder
654.8 kWh
Date/Time Range:
20-Jan-10 12:00am to 31-Jan-10 12:00am
UOM / TOU
Usage
kWh / On peak
865.5 kWh
kWh / Off peak
221.2 kWh
kWh / Shoulder
356.3 kWh
A Usage Period Has Service Quantities (SQs)

Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
29-Jan-10 12:00am to 31-Jan-10 12:00am
Usage Period
Date/Time Range:
1-Jan-10 12:00am to 31-Jan-10 12:00am
The SQs are calculated by the usage group's rules. In

this example, the SQs have been calculated by a single
rule that applies a TOU map to the kWh channel on the
device configuration installed at the SP
UOM / TOU / SQI
Usage
Usage
Group / Rule
TOU Map
SP
MC
kWh / On peak
1200.1 kWh
Commercial
TOU /
Apply simple
TOU map
1239219876
(Bakery)
39191912312
(18 Main St)
8382821921
(kWh
channel)
kWh / Off peak
401.2 kWh
Commercial
TOU /
Apply simple
TOU map
1239219876
(Bakery)
39191912312
(18 Main St)
8382821921
(kWh
channel)
kWh / Shoulder
654.8 kWh
Commercial
TOU /
Apply simple
TOU map
1239219876
(Bakery)
39191912312
(18 Main St)
8382821921
(kWh
channel)
9-9
Every usage period contains

service quantities (SQs)
Notice that each SQ
references the source of the
quantities (for audit
purposes)
There Are Different Types Of Service Quantities

Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
Cutoff Date/Time Range:
29-Jan-10 12:00am to 31-Jan-10 12:00am
Usage Period
The base-package usage rules can calculate different

types of SQs. The following example illustrates a usage
group with two rules:
- The first retrieves and snapshots the interval for the
kWh channel
- The second applies a TOU map to the channel and
saves the results
Date/Time Range:
1-Jan-10 12:00am to 31-Jan-10 12:00am
UOM / TOU / SQI
Usage
Usage Group /
Rule
kWh
1200.1 kWh
Commercial /
Retrieve kWh
intervals
kWh / Off peak
401.2 kWh
Commercial /
Apply simple
TOU map
kWh / Shoulder
654.8 kWh
Commercial /
Apply simple
TOU map
9 - 10
TOU Map
SP
MC
39191912312
(18 Main St)
8382821921
(kWh
channel)
1239219876
(Bakery)
39191912312
(18 Main St)
8382821921
(kWh
channel)
1239219876
(Bakery)
39191912312
(18 Main St)
8382821921
(kWh
Performance
note: the
channel)
Intervals
base-package rule that snapshots

intervals can create a large amount of data (30 days of 15
minute intervals is 2,880 intervals). This should only be
used if the subscribing system requires the intervals (i.e.,
don't snapshot intervals on a UT for audit purposes).
A Usage Transaction Can Have Scalar Details

Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
Scalar-oriented rules do not have Date

Break logic as it's up to the CIS to prorate
scalar consumption (MDM doesn't have the
intervals so it cannot accurately compute the
amount in each period)

29-Jan-10 12am to 31-Jan-10 12am
Date Break(s):
20-Jan-10
Usage Period
Date/Time Range:
1-Jan-10 3:00pm to 30-Jan-10 4:00pm
UOM / TOU / SQI
Usage
BTU
505 BTU
The scalar-oriented usage rule

retrieves scalar readings for the SPs
linked to the US and then creates a
single Usage Period for the UT's
entire period.
This example shows what

happens if there is a meter
exchange (notice the 2 entries
in the Scalar Details). It also
shows how the rule can convert
a Measured UOM into a Final
UOM (e.g., cubic feet to therms)
Scalar Details
9 - 11
Final
Usage
Usage Group /
Rule
Measured Usage
UOM / TOU / SQI
SP
MC
Start
Measurement
End
Measurement
202 BTU
Residential /
Retrieve Scalar
200 CCF
39191912312
(18 Main St)
8382821921
(CCF register)
1-Jan-10 3pm
10000
15-Jan-10 6pm
10200
303 BTU
Residential /
Retrieve Scalar
300 CCF
39191912312
(18 Main St)
8382821921
(CCF register)
15-Jan-10 6pm
10200
30-Jan-10 4pm
10500
SQs Are Populated For Scalar Reads Too

Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
29-Jan-10 12:00am to 31-Jan-10 12:00am
Scalar Details
Final
Usage
Usage Group /
Rule
Measured Usage
UOM / TOU / SQI
SP
MC
Start
Measurement
End
Measurement
202 BTU
Residential /
Retrieve Scalar
200 CCF
39191912312
(18 Main St)
8382821921
(CCF register)
1-Jan-10 3pm
10000
15-Jan-10 6pm
10200
303 BTU
Residential /
Retrieve Scalar
300 CCF
39191912312
(18 Main St)
8382821921
(CCF register)
15-Jan-10 6pm
10200
30-Jan-10 4pm
10500
Usage Period
Date/Time Range:
1-Jan-10 12:00am to 31-Jan-10 12:00am
UOM / TOU / SQI
Usage
Usage
Group / Rule
BTU
505
Residential /
Retrieve
Scalar
9 - 12
TOU Map
SP
MC
39191912312
(18 Main St)
8382821921
(CCF
register)
Notice that the SQ entry

contains the total for the
scalar reads.
A Usage Transaction Can Have Exceptions

Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
Recall that usage rules can both

calculation usage and validate that
the calculated usage is reasonable
Usage
Calculation
Engine

29-Jan-10 12:00am to 31-Jan-10 12:00am
UOM / TOU
Usage
kWh / On peak
1200.1 kWh
kWh / Off peak
0 kWh
kWh / Shoulder
0 kWh
Exception
Exception: There is no off peak kWh
An exception is created for each problem.

Notice that the exceptions are held within
the usage transaction (in its CLOB).
Contrast this to IMDs where each IMD
exception is a distinct MO in its own right.
This is intentional as usage transaction
exceptions should be very rare whereas
VEE exceptions are relatively common.
9 - 13
Exception Category: Issue
Exception
Exception: There is no shoulder kWh
Multiple exceptions can be

created (so that users can
see all of the problems
detected by the usage
calculate process)
Three Exception Categories (Just Like VEE

Exceptions)
Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
29-Jan-10 12:00am to 31-Jan-10 12:00am
Usage
Calculation
Engine
UOM / TOU
Usage
kWh / On peak
1,101 kWh
kWh / Off peak
201 kWh
kWh / Shoulder
678 kWh
Exception
The Issue category is used to report a

problem that will prevent the usage
transaction from being finalized. Multiple
"issue exceptions" can be created during
usage calculation. If at least one issue
exists after all rules have been applied, the
usage transaction is transitioned to the
exception state.
Exception: There is no off peak kWh
Just like VEE exceptions, there

is an Info category that is used
to highlight something
interesting, but not sufficient to
cause the usage calculation to
be put into the exception state.
9 - 14
Exception
Exception: There is no KW but there is kWh
Exception Category: Terminate
The Terminate category is used to report a

severe issue that will cause the usage
calculation process to stop and the UT to
be transitioned immediately to the
exception state. Only one terminate
exception can be issued (as the first one
causes usage calculation to stop).
A User Can Recalculate, Discard or Manually Override

a UT in the Exception State
When a UT is recalculated,
prior exceptions are removed
Usage
Calculation
Engine
"Info" exceptions
may exist
MDM
After correcting the cause of the
issues, a user can recalculate a UT
A user can discard a UT in the

Exception state
Transition UT to the
Exception state
Transition UT to the
Discarded state
A user can manually complete the UT. This will

cause UT to be sent to the subscriber "as is".
Complete the UT
Regardless of the action taken
by the user, the system will
complete the To Do entry that
was created when the UT
entered the Exception state
9 - 15
2.0.1 Preview - The System Retries Until Consumption In

The Thru Window Is Found
Usage Transaction
Periodic Push
Process
Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
CIS

Requests
Start Date/Time: 29-Dec-09 12am

30-Jan-10 12am to 1-Feb-10 12am
Retry until the retry

date expires or
consumption is found
Retry Until: 3-Feb-10 12am
Usage Transaction
US Id: 123910119192
UT Id: 12391011919232
Usage
Calculation
Engine
Start Date/Time: 1-Jan-10 3pm
Interval-oriented usage rules will

create an exception if interval
consumption does not exist in the
thru window. The system will
periodically retry until the retry
date expires or no rules find
exceptions.

30-Jan-10 12am to 1-Feb-10 12am
Retry Until: 3-Feb-10 12am
Exception: Measurements cannot be
found and retry period has expired
9 - 16
The subscribing system (or the

push process) must supply the
acceptable interval consumption
thru window and the date/time
when the usage calc engine
should give up looking for it
If consumption cannot be found by

the expiration of the retry date, the
UT will be transitioned to the
discarded state (and a notice of
such sent to the subscriber)
CCB Integration Preview: Usage Requests
Note - some of the XML in the upcoming

slides has been simplified and does not
necessarily match the base-package
Billing Creates Consumption Requests
Batch Process
For BD-oriented SAs, billing creates a Bill

Segment in "error" (Requested bill
determinants) and a Consumption object,
the consumption object is the request to
MDM for bill determinants.
CCB
Billing
Bill Segment
Consumption
Request
BD's Requested
In Progress
JMS Queue
Outbound Consumption Requests
The consumption requests are

placed into a JMS queue when
they are created during billing
<request>19291010</request>
<start>2010-03-14 12:00AM</start>
<cutoff>2010-04-14 12:00AM</cutoff>
<saID>12929192919</saId>
<dateBreaks>
<dateBreak>2010-04-01</breakDate>
</dateBreaks>
If an acknowledgement is not received

in time, another request will be placed
into the queue (up to X times)
JMS Queue
Inbound Bill Determinant Requests
BPEL consumes the requests from CCB and transforms

them into the MDM bill determinant request format and
places them back into a JMS queue for MDM to consume
<start>2010-03-14 12:00AM</start>
<saID>12929192919</saId>
<dateBreaks>
</dateBreaks>
MDM
BPEL
See next slide for what happens in MDM
9 - 18
MDM Responds With Bill Determinants (or Errors)

JMS Queue
MDM
<start>2010-03-14 12:00AM</start>
<saID>12929192919</saId>
<dateBreaks>
</dateBreaks>
If the engine detects no

problems, the calculated
bill determinants are put
into the JMS queue
Usage Transaction
Usage Transaction
Pending
Sent
Usage
Calculation
Engine
or
Usage Transaction
JMS Queue
JMS Queue
Outbound Bill Determinant Responses
Inbound Bill Determinant Responses
<start>2010-03-14 12:00AM</start>
<saID>12929192919</saId>
<usagePeriodsList>
<start><2010-03-14 12:00AM</start>
<end>2010-04-01 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
<quantity>1000</quantity>
</serviceQuantity>
</usagePeriodsList>
<usagePeriodsList>
<start><2010-04-01 12:00AM</start>
<end>2010-04-14 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
</serviceQuantity>
</usagePeriodsList>
<start>2010-03-14 12:00AM</start>
<saID>12929192919</saId>
<consumptionPeriod>
<start><2010-03-14 12:00AM</start>
<end>2010-04-01 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
</serviceQuantity>
</consumptionPeriod>
<consumptionPeriod>
<start><2010-04-01 12:00AM</start>
<end>2010-04-14 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
</serviceQuantity>
JMS Queue
Outbound Bill Determinant Responses
Discarded
If the calculator detects fatal issues, the

fatal issue is returned to CCB (non-fatal
issues can be handled in MDM - more
about this later)
9 - 19
<errorNumber>12910</errorNumber>
BPEL
BPEL consumes the response and transforms

them into the CCB consumption response
format and places them back into a JMS
queue for CCB to consume
<errorComment>US 19209102 cannot

be found</errorComment>
CCB
Inbound Bill Determinant Requests
The Consumption Request Creates A Bill Segment

(and Potentially Completes the Bill)
JMS Queue
<start>2010-03-14 12:00AM</start>
<rate>E1</rate>
<consumptionPeriod>
<start><2010-03-14 12:00AM</start>
<end>2010-04-01 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
</serviceQuantity>
<consumptionPeriod>
<start><2010-04-01 12:00AM</start>
<end>2010-04-14 12:00AM</cutoff>
<serviceQuantity>
<spId>19209102</spId>
<uom>KWH</uom>
<tou>PEAK</tou>
</serviceQuantity>
CCB
Consumption
Request
Bill Segment
Complete
Frozen
Bill
If the calculator returns bill determinants, the

consumption request is updated with them. The
consumption object will then call rate app and populates
the results on a bills segment (and freezes it if given the
authority). Note, separate bill calc headers will be
created for each consumption period returned (and all
such bill calc headers will be linked to the same bill
segment).
Complete
If the consumption object sees that all bill segments are

frozen, it can complete the bill (if given permission)
JMS Queue
<errorNumber>12910</errorNumber>
<errorComment>SP 19209102 cannot
be found</errorComment>
CCB

Consumption
Request
Bill Segment
Error
Error
If the consumption returns an error, the bill segment will

be updated with the specific error number (and the error
comment will be put into its message parms so that the
specific verbiage from MDM will be visible)
Error bill segments will be corrected as they are today
(delete and recreate)
9 - 20
Usage Tables and MOs
Used to ensure the

appropriate device
configurations are
installed at a US's SPs
Device
Config Type
Usage Group
CH, X
Subscript.
Type
Fallback (edate)
US Type /
Usage
Group
Valid Device
Configuration
Type
Usage
Subscript.
Override (edate)
US / Usage
Group
A usage group
has rules
Category
It's possible to invoke the usage

calc engine and limit the
execution to rules with a given
category (useful when different
rules should execute during
different stages of a UT's
lifecycle)
Usage Rule
CH, X
For audit
purposes
A usage rule
may execute a
different usage
group's rules
Only populated if the UT is

created by the process
that periodically pushes
UTs to subscribers
For use in 2.0.1 when multiple

usage groups in a period will result
in multiple "sub usage transactions"
Eligibility
Criteria
CH, X
Usage
Relationship
Type
Usage
Transaction
ST, CH, X
Usage Period
X
Legend
Scalar Detail
X
UOM
UOM
Trans. Data
Admin Data
SQ
X
SP ID
TOU
Only populated
by scalar rules
Master Data
FW Data
SQI
MO Boundary
TOU
SQI
Factor
Usage Rule
MC ID
Many FKs for audit purposes

9 - 22
Multiple usage periods

exist when there are date
breaks defined on the UT
Related Usage
Transaction
MC ID
A usage rule can have

many eligibility criterion.
Each one can cause the
rule to be skipped,
executed, or judgment to
be deferred to the next
eligibility criterion.
Measurement Route
Schedule
SP ID
TOU Map
Described
elsewhere
ST - Status
CH - Characteristics
X - CLOB
BO Definition
BO Definition
Usage
Group
Usage Rule
Business
Object
Eligibility
Criteria
Business
Object
Usage
Transaction
A UT's BO is defined by its creator:

- If the UT is created by a user manually, the BO is defined by the user.
- If the UT is created as a result of a request for an external system or by the
period push process, it is defined on the UT when it is created.
- Note, in 2.0.1, the BO can also be determined using a "seeder BO" (identical to
the method used to determine IMD BOs sent from a head-end)
9 - 24
Legend
Tran. Data
Admin Data
Master Data
FW Data
Usage Transaction BO
The Usage Transaction Schema
Intuitive / standard elements
The usage transaction engine can create separate usage

periods for the date breaks (these are typically supplied
by the calling system)
Contains the acceptable consumption thru dates used by
interval-oriented usage rules
Contains the acceptable consumption thru dates used by
scalar-oriented usage rules
Discussed on the upcoming slides
The trace group is populated by the engine if isTraceOn
is true. It contains information to help "debug" and
performance tune the rules. We recommend disabling
the trace when in production.
9 - 26
Scalar Details Are Only Populate If There Are Scalar-Oriented

Calculation Rules
These values contain the scalar measurements

that are populated by scalar-oriented rules.
Most are fairly intuitive.
9 - 27
Usage Period Information Is Calculated By Most Rules (Scalar

and Interval)
An entry is created in the usagePeriodsList for

each dateBreak defined on the usage
transaction
These values contain the bill determinants that

are billed by the CIS
These values are for audit purposes
These values are only populated by rules that

snapshot interval curves (it's a good idea to limit
the number of UTs with such rules as this takes
up a bit of space)
9 - 28
Usage Transaction Lifecycle

A deferred monitor can be defined to prevent UTs from transitioning
through their lifecycle when they are created (as this would slow down
the load processes). Notice that the base-package does NOT have
this monitor plugged in.
An enter plug-in invokes the usage transaction engine.
This state will only be used in 2.0.1 when the system detects multiple
usage groups are effective during the usage transaction's period.
Only happens if the usage subscription indicates that approval is
required.
Sends the usage transaction to the subscriber

When an IMD is normalized, final measurements are created. If the
system suspects the final measurement was used to calculate the
information on a UT, the UT will be transitioned to this state
Think of this as a logical delete
9 - 29
The Usage Calculation Engine Applies Usage

Rules To Calculate A Usage Transaction's
Values
An Enter Algorithm Executes The Calculation Engine

The usage calculation
engine is invoked by an
enter plug-in
The monitor algorithms transition to the

Exception state if there are issues or terminate
exceptions. If none, the IMD is transitioned to
the Approval In Progress or Sent states (based
on whether the US has been configured to
require approval)
9 - 31
The Usage Calculation Engine Is Dynamically Passed The Usage

Transaction BO
The engine is supplied basic information
about what usage group to use, the
effective date to use, and if only rules of a
specific category should be invoked.
The engine can be invoked real-time
without a persistent UT. When invoked in
this mode, the invoker must supply the US
Id so the rules can find the SPs that the
MCs are linked to (via their device
configuration)
This raw element is the XML
definition of the UT; this is what the
usage rules interrogate and what
they update with calculated bill
determinants
Recall that usage rules can create
exceptions
9 - 32
There Are Many Usage Rules
A BO Exists For Every Usage Rule

Because all usage rules share a common set of
elements, they are developed as child BOs under a
common parent. The comment parent BO simply
defines the elements that are shared by all usage
rule BOs (there are no business rules defined for it)
The base-package has many usage rules.
Every type of usage rule has a BO that
defines:
- the algorithm that contains the usage rule
logic
- the type of configuration options that the
algorithm can interpret (e.g., high/low factors)
In 2.0.1, a standalone data area is included in

case an implementation needs to add
common elements to all usage rules (the
OUAF allows base-package owned
standalone data areas to be extended and the
extensions will survive future upgrades).
9 - 34
Usage Rule BOs Are Simple

Usage rule BOs are simple, they have:
No lifecycle (and therefore no lifecycle rules)
A plug-in that validates the configuration entered by a user
when they create a new instance of the rule
A plug-in that holds the usage logic; these plug-ins can
change anything on a UT and / or create exceptions
The standard display and maintenance UI maps as well as
the navigation option for its maintenance portal
9 - 35
Usage Rule Schemas May Be Simple or Complex

Note: notice how most of the configuration
options are stored in the usage rule's CLOB
(as XML). This means no table changes are
necessary if an implementation needs to
introduce additional configuration options)
Usage rules without

sophisticated configuration
options have simple schemas (an
example from a TOU map rule)
Usage rules with sophisticated
configuration options have larger
schemas (an example from a demo
rule that can apply a freeform formula
to calculate bill determinants)
9 - 36
Read The Apply Usage Rule Algorithm Type

Description
The best way to learn what a usage rule does is to navigate to
its Apply Usage Rule algorithm (or its algorithm type) and read
its Detailed Description
9 - 37
Some Usage Rule Algorithm Types Have Soft

Parameters
Only 1 usage rule algorithm type uses soft parameters
Recall that soft parameters are used for configuration options that have a high
probability of being the same for every instance of the rule (and can therefore be
shipped with the base-package)
For example, the high/low usage rule algorithm didn't want to

hard code condition code ranges for different types of
measurements. Instead, the ranges are defined in its Apply
Usage Rule algorithm's soft parameters.
These algorithms are shipped preconfigured and plugged in on their usage

rules. An implementation will only need
to create new algorithms if they disagree
with the base-package configuration.
9 - 38
A Recap Of Some Usage Rules
Worry About Performance

You will find that different usage rules can achieve similar results. For
example, it's possible to return the sum of all measurements for a period using
different rules:
You could use a rule that retrieves the individual measurements for the
usage transaction period and then creates a service quantity for the total
You could use a rule that uses a SQL statement to apply a TOU map to
the individual measurements and return the total
If all you needed was the total, this would be wasteful (and very slow)
This is much faster than procedurally adding up the individual

measurements, but why use a TOU map when all you need is the sum of
thousands of measurements
You could use a rule that uses a SQL statement to select the sum of
measurements
There is no faster way to add up / find the maximum value from thousands
of measurements than to let the database do it
In the upcoming discussion, it's important to understand how each rule

retrieves its information so that you can use the most efficient rule for the task
at hand
9 - 40
Get TOU Mapped Usage

The Get TOU Mapped Usage rule applies a TOU map to all MCs linked to the US's
SPs that have a measuring component with a value with a given UOM and SQI
It calculates the sum / max of each distinct TOU code in the period
Device
Usage
Subscription
Service Point
US/SP
This rule uses SQL to join the TOU map's data to the
MC(s) final measurements (using the respective
measurement column that corresponds to the UOM /
SQI on the rule). The database returns a separate
row for each TOU code in the calculation period.
Please note that a separate entry will be placed in
the usage transaction's SQsList for each MC and
TOU combination. This means that if there are
multiple MCs linked to the US, multiple entries will
exist for every UOM / TOU combination. If you want
another entry in the SQsList with the grand total of
each UOM / TOU combination, add a subsequent
Service Quantity Math rule (described later).
9 - 41
Device Config.
Install Event
MC Type
MC
Measurement
UOM/TOU/SQI
Measurement
Usage Rule
TOU Map
TOU Data
XML
TOU
UOM
SQI
Service Quantity Math

The Service Quantity Math rule performs simple arithmetic on entries already in the
SQsList. The result of the calculation is added to the SQsList.
Note - this rule exists in demo (a productized version is coming in 2.0.1)
This is the UOM / TOU / SQI that will be placed in the SQsList with the
results of the calculation; the source of each variable's value is defined
in the Variables grid.
The sum of all entries in the SQsList with this

UOM / TOU / SQI is calculated and added to the
sum of the entries with the Operand's UOM /
TOU / SQI.
Note: you can also use a Factor instead of a service

quantity (e.g., you could multiply a loss factor, therm
conversion factor, to an entry in SQsList).
9 - 42
Apply Math - Interval Data

The Apply Math (Interval Data) rule creates a single entry in the SQsList that is
calculated using a user-defined mathematical expression
This is the UOM / TOU / SQI that will be placed in the SQsList; the
value of the entry is calculated using the Mathematical Expression
The mathematical expression is a free-form expression

that can reference up to 10 variables (this example
multiplies variable 1 and variable 2). The source of each
variable's value is defined in the Variables grid.
A variable in the mathematical expression can be any of the following:

The minimum, maximum, or sum of all final measurements linked to interval MC(s) with a given UOM / SQI. This is
the fastest way to retrieve such a value because the database returns the sum / max / min (rather than this being
calculated procedurally from the individual measurements)
A numeric factor (the system will derive the value using the standard factor value derivation logic)
The number of hours in the usage period
9 - 43

Common Configurations
This configuration returns the peak KW from all MCs that measure kWh.
Notice how the Calculation Type is Single Value rather than Mathematical Expression.
This could have also been defined as a Mathematical Expression of V1 (both
configuration do the same thing in the same way).
This means that a SQL MAX function will be used against the kWh measurements. The
result will be converted to KW. It should be noted that the logic takes into account
disparate SPIs on the MCs.
This configuration returns the total kWh from all MCs that measure KW. It should be
noted that the logic takes into account disparate SPIs on the MCs.
This means that a SQL SUM function will be used against the KW measurements. The
result will be converted to kWh. It should be noted that the logic takes into account
disparate SPIs on the MCs.
9 - 44

Mathematical Expression Can Be More Interesting
Notice the trig functions in the Mathematical Expression. There are
many other operators that can be used (the same ones that were
defined in the Apply Formula section)
9 - 45
Get Scalar Details

The Get Scalar Details rule creates one or more entries in the
scalarDetailsList for each measurement in the usage period
linked to the US's scalar MCs
Please note:
If a device is exchanged during the period, multiple entries
will be added (one per exchange sub-period)
If multiple MCs are linked to the US with the defined UOM /
TOU / SQI, multiple entries will be added
If Build Service Quantity is set to true, an entry will be
added to the SQsList for each MC. You'd set this to false if
the subscriber was just interested in the scalar readings
and didn't need the totals computed.
9 - 46
Get Interval Data

The Get Interval Data rule creates entries in the SQsList for
each interval MC in the usage period linked to the US
This entry contains every individual final measurement in the
curve and therefore it should only be used if the subscriber
needs every measurement
If this rule is executed for large volumes, performance issues
could ensue
Please note that a separate entry will be placed in the usage
transaction's SQsList for each interval MC linked to the US with
the given UOM / TOU / SQI in its final measurements.
Each entry in the SQsList will have the ENTIRE CURVE plus a
total from all of the measurements in the curve. The total will
be either the Sum or the Maximum value from the curve
depending on how this is configured.
9 - 47
Vector Math
In the VEE - Part II section, the Apply Formula service was described. Recall that
this service is used to apply a formula to one or more vectors to create a final value
vector (the service can also apply a final formula to the values in the final value
vector to create a scalar quantity)
The Vector Math rule is simply a front-end to this service that is used to derive an
interval curve from other curves (the resultant curve is placed in the SQsList)
If this rule is executed for large volumes, performance issues could ensue
Note - this rule exists in demo (a productized version is coming in 2.0.1)
Interval
IV1
kVARh
IV2
kWh
10:00 AM
1.2
0.23
0.188240
11:00 AM
1.234
1.321
0.730760
12:00 PM
2.0121
2.12
0.725323
1:00 PM
1.456
1.12
0.609710
2:00 PM
1.2345
0.12
0.096749
3:00 PM
1.0012
2.1212
0.904328
4:00 PM
0.012
2.65
0.999989
5:00 PM
0.121
0.121
0.707106
Final
Value
9 - 48
FV
COS(ATAN(IV1/IV2))
0.999989
In this example, the rule populates 2

vectors by retrieving the sum / max of the
final measurements from MCs with given
UOM / TOU / SQI combinations.
It then applies a formula to calculate the
final values vector: COS(ATAN(IV1/IV2))
It then applies a formula to calculate the
maximum value of the final values.
And finally, an entry is added to the
SQsList with the final value and the final
value vector
Vector Math - An Example

This is the UOM / TOU / SQI that will be placed in the SQsList; the
value of the entry is calculated using the Vector Formula
This is the SPI of the entries in the vector (the rule will convert all
measurements into this SPI before the Vector Formula is applied)
Each Vector defines the source of the
quantities in its vector. This configuration will
populate a vector with the sum / max value for
each interval MC linked to the US with the
given UOM / TOU / SQI in its final
measurements.
In addition to final measurements from MCs
linked to the US, a vector's values can also be
retrieved from a specific MC or from a Profile
Factor (the next slide has an example)
The definitions of the variables referenced in the Vector Formula

and Scalar Value Formula. Notice that only V1 and V2 are defined;
this is because IV1 and IV2 are references to the interval vectors
defined above. Note, you can also reference a numeric factor.
The final value vector's values are calculated using this
formula (this is applied to every row in the vector matrix)
The ratio of the minimum value from the final value vector / the
maximum value of the final value vector is the SQsList entry's total
9 - 49
Vector Math - Another Example
Notice the very specific SPI
Notice that a specific MC is

referenced; this means the vector's
values are this MC's final values
Ditto
Notice the variables are a combination of

values derived from numeric factors and
from the final values vector
A more interesting formula (note, constants

can be defined in the formula but this usecase required the values to change over
time and factors are good at that)
9 - 50
Creating New Usage Rules
Worry About Performance

The previous section described some of the base-package usage rules and explained how
they access final measurements (so that you can use the most efficient rule for a requirement)
These rules may suffice for some implementations; other implementations may require
additional rules
While usage rules are executed less frequently than VEE rules, they tend to access much
more information (a month's worth of measurements as compared to a day's worth)
Therefore, just as for new VEE rules:
It is very important that usage rules be written as efficiently as possible as the impact of
inefficient logic could cause usage calculation to run slowly
Use the base-package services to do the "heavy lifting" when possible as they are
efficient
The upcoming section will explain several of these services
However, even these services can be slow if supplied with "wide" date ranges
If a rule is used exclusively by low volume usage transactions (e.g., an industrial-only

rule), it can be written in Java or scripting / xpath2 (the script overhead won't be
significant)
If a rule is used by the mass market, you should prototype it in scripting and determine
if it performs adequately. If not, it should be rewritten in Java
Avoid retrieving large numbers of individual final measurements
If you develop a new rule using scripting / xpath2, it is far better to move group nodes
rather than move individual elements
9 - 52
It is much better to invoke base-package service that use the database to calculate
sums / averages / maximums from final measurements
If you do not require xpath2 functions, xpath1 is faster
An Example Of A Custom Usage Rule

It may have been obvious, but the final value vector derived by
the vector math rule resides in XML on the usage transaction /
SQ table (in a CLOB)
The XML-based vectors in this table can be displayed
graphically in a zone on the usage transaction portal (so endusers can see the shape of derived vectors)
But what if the implementation wanted the derived vector values
to exist as rows on the final measurement table (e.g., so they
could be shown on the 360 graphs or used in VEE rules or )
In this case, the derived vector values would need to be saved
as separate values on a MC
The next slide shows an example of such a rule
9 - 53
The Rule's BO and An Instance Example

The rule's schema
(notice how all of the
configuration options
reside in the rule's
CLOB as XML)
An instance of this rule

(defines the MC ID that the
final measurements will be
stored under and the UOM /
TOU / SQI whose curve will
stored as final measurements
The BO has the

standard display and
maintenance UI maps
The BO has the algorithm that's
invoked by the usage calculation
engine (described on the next
slide)
9 - 54
The Rule's Script
The edit data view of these 3 steps

(it's pretty simple if you understand
how to select entries from a list
and move entries in a list)
10: edit data - Read the Add IMD Usage Rule BO

move null to "Rule";
move "parm/hard/applyUsageRuleAlgorithmInputData/usageRuleCode/id/usageGroupId" to "Rule/usageGroup";
move "parm/hard/applyUsageRuleAlgorithmInputData/usageRuleCode/id/usageRule" to "Rule/usageRule";
invokeBO 'DM_IMDAdd' using "Rule" for read;
15: edit data - Move Usage Transaction data into local data area
move "parm/hard/applyUsageRuleAlgorithmInputOutputData/usageTransactionBOData/data" to "UsageTransaction";
20: edit data - Find the SQ curve for the current usage period and create an IMD (via the IMD seeder) using its intervals
// Move the source UOM, SQI from the rule
move "Rule/addIMDDetails/source/uom" to $uom;
move "Rule/addIMDDetails/source/sqi" to $sqi;
// For the SQ curve that matches the source UOM, and SQI, move the data into the IMD seeder
move "UsageTransaction/usagePeriods/usagePeriodsList[1]/SQs/SQsList[uom=$uom and sqi=$sqi]/intervals" to "IMDSeeder/preVEE/msrs";
move "Rule/addIMDDetails/result/mcId" to "IMDSeeder/preVEE/mcId";
move 'D1IL' to "IMDSeeder/preVEE/imdType";
move "UsageTransaction/usagePeriods/usagePeriodsList/startDateTime" to "IMDSeeder/preVEE/stDt";
move "UsageTransaction/usagePeriods/usagePeriodsList/endDateTime" to "IMDSeeder/preVEE/enDt";
invokeBO 'D1-IMDSeeder' using "IMDSeeder" for fastAdd;
9 - 55
One Last Word About Factors Before The Practices
Refresher: During Usage Rule Execution

Factor: Territory-based KJ conversion
Usage Group: Residential Scalar
Type of Characteristic: SP Territory Code
Usage Rule
Retrieve the sum of cubic meters from
the SPs linked to the US and multiply it
by the territory-based KJ conversion
factor
Valid Characteristic Values For This Factor

Northern territory
This rule references a factor. At run time,

the rule finds the conversion factor value
using the territory code defined on the SP
linked to the US
Southern territory
Eastern territory
Western territory
Characteristic Value: Southern Territory

If the SP linked to the US is located in the
southern territory, the system retrieves this
territory's conversion factor effective on
the start date of the usage period
In this example, the characteristic value is retrieved from
the SP linked to the US, but it could be derived /
retrieved from anything related to the US
9 - 57
Effective Date
Conversion Factor Value
15-Jan-2010
1.23921
16-Feb-2010
1.32910
23-Apr-2010
1.28191
Factor Values Can Have An Override Value On A

Usage Subscription
When you set up a numeric factor, you can indicate if its value
can be overridden on a usage subscription
If a numeric factor has a value defined on a usage subscription,
this value is used rather than the value from the factor tables
This factor's value can not be
overridden in a usage subscription
Usage
Subscription
Factor
Factor Override
If a factor has an override value defined on a

usage subscription, this value is used rather than
the value from the factor tables. Note, the
override value is effective-dated so it can change
over time. It can also be expired.
9 - 58
Practice 9-1 (60 Minutes)

As set up in the prior chapter, customers with water service have two usage subscriptions: one for the
amount of water they used, and the other for the waste water treatment of the water they used
In general, the water and waste water usage subscriptions are assumed to use the total amount of
water measured by the water MC
However, a customer can petition the utility if a significant percentage of their water usage is for their
garden (as water used in a garden does not go down the sewer and therefore their waste water
consumption should be reduced by the amount of water attributed to their garden)
A "flow factor" (a percentage) is assigned to such customers whose value is dependent on the
amount of water usage that's used for gardening.
The total water usage is multiplied by this flow factor when the waste water bill determinants are
calculated
The subscribing system would like three values: the total consumed, the flow factor used, and
the resultant value (total * flow factor)
In this practice, you will:
Create a usage calc group / rule(s) for the water usage subscriptions that calculates the grand
total of liters for the entire usage period
Create a usage calc group / rule(s) for the waste water usage subscriptions that calculates the
amount for waste water
Add an IMD for several days of consumption for your residential water meter
Create usage transactions for the water and waste water usage subscriptions
The next slide provides a summary of the data that will be set up
9 - 59
9-1 Data Overview

4
Subscript. Type
Fallback (edate)
Usage Group
Device Config
Type
US Type /
Usage Group
Valid Device
Configuration
Type
1
Usage
Subscript.
Factor
3
7
Category
US / Factor
Override
Factor / Char
Value
Usage Rule
2
Usage
Transaction
Factor Value
MC
Usage Period
UOM
Initial Meas.
Data (IMD)
SQ
8
Legend
TOU
Trans. Data
Admin Data
SQI
Master Data
FW Data
Factor
Usage Rule
MC ID
SP ID
TOU Map
Measurement
MO Boundary
Described
elsewhere
ST - Status
X - CLOB
9 - 60
9-1 Solution
Add A Factor
Navigate to Admin / F / + Factor to add a Factor that holds
the flow factor (prefixed with your initials)
Factor
Description
Identifying BO
RW-FF
RW - Flow Factor
Factor Number
Indicate the value can be overridden in a usage

subscription
This factor's value will always be 1 unless

overridden in a usage subscription. Because it's
value does not vary based on some characteristic,
you can use the N/A char type and char value.
9 - 61
9-1 Solution
Add The Default Factor Value
Click the Add icon to define the value for this
characteristic
9 - 62
9-1 Solution
Update Your Waste Water US
3
Find your waste water usage subscription (using

360 Search or the Usage Subscription search)
and then define an override value for your flow
factor (set it to .6 meaning that 60% of the water
consumption can be used for waste water
consumption)
9 - 63
9-1 Solution
Add Usage Groups
Navigate to Admin / U / + Usage Group to add these Usage
Groups (prefixing each with your initials)
Usage Group
Description
Identifying BO
RW-W-RES
RW - Water- Residential Simple (Interval)
Usage Group
RW-WW-RES
RW - Waste Water - Residential

- Simple (Interval)
Usage Group
Define your water device configuration type

(the 60 min simple water configuration)
9 - 64
9-1 Solution
Update Your US Types
5
US Type
RW-W-RES
RW-WW-RES
Specify the your water usage group on

the water US type and your waste water
usage group on the waste water US type
9 - 65
9-1 Solution
Add SQIs
6
SQI
Description
Identifying BO
RW-FFADJ
RW - Flow Factor Adjusted
Service Quantity
Identifier
RW-FF
RW - Flow Factor
Service Quantity
Identifier
9 - 66
Navigate to Admin / S / +
Service Quantity Identifier to
add SQIs for:
- The flow factor adjusted water
consumption on the waste water
usage transactions
- The flow factor service quantity
used on the waste water usage
transactions
(prefixed with your initials)
9-1 Solution
Add Water Usage Rule
Usage Rule
Description
Identifying BO
RW-RTL
RW - Retrieve Total Liters
Apply Math
(Interval Data)
7.1
Navigate to Admin / U / + Usage Group and select

your Water Usage Group to navigate to the Usage
Group portal. Once there, click the Add link in the
Usage Rules List zone to add a usage rule to your
usage group.
Recall that the fastest way to retrieve a total

quantity from interval measurements is to use an
Apply Math (Interval Data) rule as this executes a
Select SUM and the database does the aggregation
This is the UOM / TOU / SQI that will be placed in the SQsList
for the total water consumption (use your Liters UOM)
This rule just needs the grand total of all MCs with a given
UOM therefore (i.e., a single variable), therefore you can
use the Single Value Calculation Type
9 - 67
Specify the UOM on your water MC type (all MCs linked to the
US with a final measurement with this UOM will be aggregated)
Specify Sum to
get the grand total
9-1 Solution
Add The First Waste Water Usage Rule (Retrieve Total
Liters) Add the first of three usage rules to your waste
Usage Rule
Description
Identifying BO
RW-RTL
RW - Retrieve Total Liters
Apply Math
(Interval Data)
7.2
9 - 68
water usage group. The first one will be a duplicate

of the rule you just created so use the Duplicate
action on the Usage Rule zone. When prompted,
specify:
Your waste water usage group
A usage rule code of your choice
9-1 Solution
Add Retrieve Flow Factor Usage Rule
7.3
Usage Rule
Description
Identifying BO
RW-RFF
RW - Retrieve Flow
Factor
Apply Math
(Interval Data)
Click the Add link in the Usage Rules List

Dashboard zone to add another usage rule to your
waste water usage group
The Apply Math (Interval Data) is misnamed as it

can also be used to retrieve a factor's value (as
shown below)
Specify a Variable Type of Factor
9 - 69
Specify your flow factor
At execution time, if the

related usage
subscription has an
override value, it is used;
otherwise the value
defined on the factor is
used
9-1 Solution
Add Adjust Consumption Using Flow Factor Usage Rule
7.4
Usage Rule
Description
Identifying BO
RW-ADJFF
RW - Adjust Consumption
Using Flow Factor
Service Quantity
Math

Dashboard zone to add another usage rule to your
waste water usage group
Because two entries in the SQsList already contain
the values to be multiplied to calculate the flow
factor adjusted consumption, you can use the
Service Quantity Math rule (it is much faster to use
this rather than any of the other rules)
The UOM / TOU / SQI that will be placed in the SQsList for
this rule (specify your Flow Factor Adjusted SQI, you can
optionally define a UOM of Liters)
Specify the UOM / TOU / SQI of the
entry added to the SQsList in the
first rule (the total liters)
Multiply
??? Bug note - specifying just the SQI from

the last rule doesn't operate right now so
we are just specifying the factor as the
Operand
Specify your flow factor Factor
9 - 70
9-1 Solution
Create Usage Transactions
9.1
Add a usage transaction for your waste water usage

subscription. The easiest way to do this is as
follows:
Find the usage subscription using 360 Search
Click the Usage Subscription context menu and
then select + Usage Transaction
When prompted,
enter the following
Notice that the

consumption
through period is
an exact time
9 - 72
9-1 Solution
Create The Waste Water Usage Transaction
9.2
Examine the waste usage transaction
Notice the 3 service quantities
9 - 73
9-1 Solution
Create Usage Transactions
9.3
Add a usage transaction for your water usage

subscription using the same date range.
9 - 74
Practice 9-2 (30 Minutes)

The electric usage group will execute different usage groups depending on
whether the SP has solar generation installed:
If the SP has any type of solar installed, the solar usage group will be
invoked; it returns the following bill determinants:
Return TOU mapped consumption from the generated channel using the demo
TOU map (Year round schedule, 15 minute interval)
Return the peak KW from the generated channel
Return TOU mapped consumption from the consumed channel using the demo
TOU map
Return the peak KW from the consumed channel
Return a curve representing the difference between the consumed - generated
channel (as the CIS wants it)
Otherwise, the regular electric usage group will be invoked; it returns the
following bill determinants:
Return TOU mapped consumption from the kWh channel using the demo TOU
map (Year round schedule, 15 minute interval)
Return the peak KW from the kWh channel
The next slide provides a summary of the data that will be set up
9 - 75
9-2 Data Overview

1
Subscript. Type
Fallback (edate)
Usage Group
Device Config
Type
US Type /
Usage Group
Valid Device
Configuration
Type
7
5
2
Category
Usage
Subscript.
Usage Rule
8
6
4
Algorithm
Usage
Transaction
Eligibility Criteria
Usage Period
UOM
SQ
Legend
TOU
Trans. Data
Admin Data
SQI
Master Data
FW Data
Factor
Usage Rule
MC ID
SP ID
TOU Map
MO Boundary
Described
elsewhere
ST - Status
X - CLOB
9 - 76
9-2 Solution
Add Usage Groups
1
Usage Group
Description
Identifying BO
RW-E-RES
RW - Electric Residential (Interval)
Usage Group
RW-E-RES-SOLAR
RW - Electric Residential - Solar (Interval)
Usage Group
Navigate to Admin / U / + Usage

Group to add these Usage Groups
(prefixing each with your initials).
To save time, we'll skip the regular
electric group
Note, this usage group will be

invoked by the first usage group if
the SP linked to the US has solar
installed
Define your solar electric device

configuration type
Next, we'll add the usage rules for the solar
usage group and then add the rule to the
electric residential usage group
9 - 77
9-2 Solution
Add A Usage Rule - TOU Generated
Usage Rule
Description
Identifying BO
RW-TOUGEN
RW - TOU Map
Generated
Get TOU Mapped

Usage
2.1
Display your Electric Residential - Solar (Interval)

usage group on the Usage Group portal. Once
there, click the Add link in the Usage Rules List
zone to add a usage rule to your usage group.
This is the SQI that will be placed in

the SQsList (in this case, it's the same
as the SQI of the generated channel)
The UOM / SQI of your generated
MC
Please use this TOU map from
demo
9 - 78
9-2 Solution
Add A Usage Rule - Peak KW Generated
Usage Rule
Description
Identifying BO
RW-KWGEN
RW - KW From
Generated
Apply Math
(Interval Data)
2.2

dashboard zone to add another usage rule to your
solar usage group
This is the UOM / SQI that will be

placed in the SQsList (in this case, it's
the same as the SQI of the generated
channel)
The UOM / SQI of your generated

MC type
9 - 79
It is important that the Target UOM be one that

is defined as measuring Peak (it impacts the
conversion from non-peak to a peak UOM)
9-2 Solution
Add A Usage Rule - TOU Consumed
Usage Rule
Description
Identifying BO
RW-TOUCON
RW - TOU Map
Consumed
Get TOU Mapped

Usage
2.3

solar usage group
This is the SQI that will be placed in

the SQsList (in this case, it's the same
as the SQI of the consumed channel)
The UOM / SQI of your consumed
MC
Please use this TOU map from
demo
9 - 80
9-2 Solution
Add A Usage Rule - Peak KW Consumed
Usage Rule
Description
Identifying BO
RW-KWCON
RW - KW From
Consumed
Apply Math
(Interval Data)
2.4

solar usage group

placed in the SQsList (in this case, it's
the same as the SQI of the generated
channel)
The UOM / SQI of your consumed

MC
9 - 81
It is important that the Target UOM be one that

is defined as measuring Peak (it impacts the
conversion from non-peak to a peak UOM)
9-2 Solution
Add A Usage Rule - Consumed minus Generated Vector
2.5
Usage Rule
Description
Identifying
BO
RW-KWCONGEN
RW - Create Vector Of
Consumed minus
Generated
Vector Math

placed in the SQsList

solar usage group
The UOM / SQI of
your consumed MC
The UOM / SQI of

your generated MC
The final value in the SQsList is the sum of the final value vector
Define that V1 is the sum of the final value vector

Define that the final value vector is the consumed channel minus
the generated channel
9 - 82
9-1 Solution
Add SQI - Net Consumption
3
SQI
Description
Identifying BO
RW-NETCON
RW - Net Consumption
Service Quantity
Identifier
Return to the prior usage rule and

update the SQI with the newly
added value
At this point, the solar usage group

has all of its rules
9 - 83
Navigate to Admin / S / + Service

Quantity Identifier to add an SQI
for the net consumption (consumed
- generated) so it can be
differentiated from the other service
quantities on the usage transaction
9-2 Solution
Add A Usage Rule Eligibility Criteria Field Algorithm
Algorithm
Description
RW-GETSOLAR
RW - Retrieve SP's Solar Installed
Navigate to Admin / A / + Algorithm and add an

algorithm as shown. Note, you might find it easier to
add new algorithms by using the algorithm type context
menu on the Algorithm Type page (after finding the
appropriate algorithm type using the Algorithm Entity
search filter).
Using the "big" SP BO to retrieve a single

element will result in the OUAF reading this
entire BO and then returning a single
element. It's faster to extend / create a LITE
BO that contains a small number of
elements and to read it rather than the big
BO. To save time in the class, we'll use the
big BO (but to repeat, you should not do this
in real life).
9 - 84
9-2 Solution
Add A Usage Rule
5
Usage Rule
Description
Identifying BO
RWEXECSOLAR
RW - Execute Solar If
Solar Installed
Execute Usage
Group
Display your Electric Residential (Interval) usage

group on the Usage Group portal. Once there, click
the Add link in the Usage Rules List zone to add a
usage rule to your usage group.
Reference your solar usage group
9 - 85
9-2 Solution
Add Eligibility Criteria For The Usage Rule
6
Eligibility
Sequence
Description
Identifying BO
10
RW - Apply If Solar Installed
Interval Spike Check
After adding the usage rule, you be

transferred to the Usage Rule Portal.
Use the Add link in the Eligibility Criteria
List zone to add the following criteria.
This is the algorithm you just added (it retrieves the

solarInstalled value from the SP linked to the US)
This is not equal
This is "blank"
The rule will be applied if the
solarInstalled element on the SP linked
to the US is not blank
9 - 86
9-2 Solution
Update Your US Type
7
US Type
RW-E-RES
Specify the your water usage group on

the water US type and your waste water
usage group on the waste water US type
9 - 87
9-2 Solution
Create Usage Transaction
8
Add a usage transaction for your electric usage subscription. The easiest way to
do this is as follows:
Find the electric usage subscription using 360 Search
Click the Usage Subscription context menu and then select + Usage
Transaction
When prompted,
enter the following
Notice that the

consumption through
period is an exact time
9 - 88
9-2 Solution
Update Your UOM
9.1
You will be transferred to the usage transaction portal after the UT is created.
Notice that the UT is in error; this is

because the system does not know that
your KWH UOM and the KW UOM can be
converted into each other. To let the
system know this is possible, each UOM
must reference the same "base UOM".
Therefore, you must update your
UOM to indicate it can be converted
to KW (by indicating it shares the
same base UOM as KW)
9 - 89
9-2 Solution
Recalculate The UT
9.2
Recalculate your usage transaction after updating your UOM
Notice the service quantities that have

been calculated by the usage rules
9 - 90
9-2 Solution
Examine The Other Zones
9.3
This is the derived curve (net consumption) that is saved on

the SQsList
9 - 91
Review Questions
9 - 92

09 - Usage BO

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

09 - Usage BO

Hochgeladen von

Copyright:

Verfügbare Formate

9

Review From The Fundamentals Course

Copyright 2010, Oracle. All rights reserved.

The Usage Calculation Process

Load Usage Transaction

An external system can

Start Date/Time: 1-Jan-10 3:00pm

The usage calculation engine is very similar to the

Start Date/Time: 1-Jan-10 3:00pm

kWh / Off peak

Exception: kWh curve is not continuous

Copyright 2010, Oracle. All rights reserved.

Most requests for

A Usage Transaction's Start Date Is Fixed

Load Usage Transaction

For all rules

Thru Window Option: Window is specified

Estimate Date: 31-Jan-10 12am

Because the creator of the UT won't know what type of

Copyright 2010, Oracle. All rights reserved.

A Usage Calc Group Contains Rules

Apply TOU map to kWh channel

Usage rules derive a usage transaction's usage using the measurements

Copyright 2010, Oracle. All rights reserved.

kWh / Off peak

Apply Regular TOU map to kWh channel

This rule is applied if the customer has

Copyright 2010, Oracle. All rights reserved.

Reusable Groups Of Rules

Apply Regular TOU map to kWh channel

Apply Usage Group Calc Common BDs

Usage Group: Calc Common BDs

Calculate number of days in period

Calculate total kWh

Copyright 2010, Oracle. All rights reserved.

CCB note: With MDM 2.0.1, multiple calc groups in a

Usage Group: Residential Scalar

US Type: Electric Commercial Interval

Usage Group: Residential TOU

Apply TOU map to kWh channel

Copyright 2010, Oracle. All rights reserved.

A Usage Transaction Can Have Date Breaks

A usage transaction can optionally

Acceptable Interval Thru Window:

If a usage transaction has date

kWh / Off peak

kWh / Off peak

Copyright 2010, Oracle. All rights reserved.

A Usage Period Has Service Quantities (SQs)

The SQs are calculated by the usage group's rules. In

UOM / TOU / SQI

kWh / Off peak

Copyright 2010, Oracle. All rights reserved.

Every usage period contains

There Are Different Types Of Service Quantities

The base-package usage rules can calculate different

kWh / Off peak

base-package rule that snapshots

Copyright 2010, Oracle. All rights reserved.

A Usage Transaction Can Have Scalar Details

Scalar-oriented rules do not have Date

Acceptable Interval Thru Window:

The scalar-oriented usage rule