MDMR Technical Interface Spec v3 0 20100924 CLEAN

IESO_SPEC_9027
Meter Data Management and

Repository
MDM/R V1.0
Technical Interface Specifications
Version 3.0
24 September 2010
Meter Data Management and Repository MDM/R V1.0 Technical Interface Specifications
IESO_SPEC_9027
Disclaimer
The posting of documents on this Web site is subject to the terms and conditions posted on the
SMSIP Web site. Please be advised that, while the IESO-SMSIP attempts to have all posted
documents conform to the original, changes can result from the original, including changes
resulting from the programs used to format the documents for posting on the Web site as well as
from the programs used by the viewer to download and read the documents. The IESO-SMSIP
makes no representation or warranty, express or implied, that the documents on this Web site
are exact reproductions of the original documents listed. In addition, the documents and
information posted on this Web site are subject to change. The IESO-SMSIP may revise,
withdraw or make final these materials at any time at its sole discretion without further notice. It
is solely your responsibility to ensure that you are using up-to-date documents and information.
Status of these Specifications
This document was put under formal change control on July 31, 2007. As of Version 2.6 review
of all design elements has been completed.
As of Version 3.0, some specific elements of the Meter Read Interfaces have been placed in a
status of “design review”. These elements of this specification have been highlighted in “yellow”
indicating that active review and verification activities are underway, and that these elements
may be subject to revision.
The following elements of this specification are affected:

Section 2.4 – Billing Service Standard Interface Request
§ Resolution of outstanding comments as indicated in this initial draft specification.
Section 2.5 – Billing Service Standard Interface Reply
§ Resolution of outstanding comments as indicated in this initial draft specification.
Version 3.0 – September 24, 2010 § i

IESO_SPEC_9027
Table of Contents
Table of Contents ................................................................................................................. ii
Related Documents ............................................................................................................. iii
Table of Changes ................................................................................................................ iv
1 Introduction .................................................................................................................... 1
1.1 Purpose..................................................................................................................... 1
1.2 Document Scope ....................................................................................................... 1
1.3 Assumptions and Limitations ...................................................................................... 1
1.4 Definition of Terms ..................................................................................................... 2
1.5 Organization of this Document .................................................................................... 5
1.6 Document Relationships ............................................................................................. 6
1.7 Conventions for Data Field Formats .......................................................................... 10
1.8 MDM/R FTS Use of File Names ................................................................................ 11
1.9 Timelines ................................................................................................................. 21
1.10 Position Statement – Meter Read Data Transformations .......................................... 22
2 Technical Interface Specifications ............................................................................... 25
2.1 Universal SDP ID Assignment Request / Response Interface ..................................... 25
2.2 Periodic Audit Synchronization Interface.................................................................... 37
2.3 Incremental Synchronization Interface ....................................................................... 77
2.4 Billing Service Standard Interface - Request ............................................................ 113
2.5 Billing Service Standard Interface - Reply ................................................................ 123
2.6 Billing Quantity Request ......................................................................................... 141
2.7 Billing Quantity Response....................................................................................... 147
2.8 Billing Cycle Schedule Interface .............................................................................. 183
2.9 Aggregated Settlement Data ................................................................................... 187
2.10 Web Services Request/Reply ................................................................................ 194
2.11 Meter Read Interface (Sensus) ............................................................................. 205
2.12 Meter Read Interface (Sensus2)............................................................................ 215
2.13 Meter Read Interface (Elster) ................................................................................ 226
2.14 Meter Read Interface (Trilliant) .............................................................................. 241
2.15 Meter Read Transformation for Transmission via Trilliant CMEP Interface ............... 251
2.16 Meter Read Interface (Tantalus) ............................................................................ 259
2.17 Meter Read Interface (SmartSynch) ...................................................................... 269
2.18 Universal Meter Read Interface (Future) ................................................................ 279
Version 3.0 – September 24, 2010 ii

IESO_SPEC_9027
Related Documents
Document Title Issue Date

IESO_DES_9001: MDM/R V1.0 Detailed Design – Version 2.0 30 April 2008
SME_SPEC_0001: MDM/R V1.0 Reports Technical Specifications – 29 April 2010

Version 3.0
IESO_STD_0078: MDM/R VEE Standard for the Ontario Smart March 31, 2010
Metering System – Issue 3.0
SME_MAN_0005: MDM/R Meter Data Management and Repository December 19, 2008
(MDM/R) TOU Schedule and Calendar Manual – Issue 2.0
MDM/R File Transfer Services and Web Services Configuration October 15, 2008
Workbook – Version 1.0
MDM/R Service and Performance Levels Issue 2.0, December 14, 2006
MDM/R Business Process Descriptions Issue 2.0, December 14, 2006
Ontario Regulation 440/07: Functional Specifications for an July 5, 2007
Advanced Metering Infrastructure, Version 2
Ontario Regulation 233/08: Designation of Smart Metering Entity Made: June 17, 2008
Measurement Canada General Bulletin: GEN-25-E, Policy on the Date: 2000-06-26

Approval, Initial Verification, and Reverification for Electricity and
Gas Meters: Legal Units of Measurement and Functions used for
Billing
Measurement Canada General Bulletin: GEN-31-E (rev.1), Policy Issue Date: 2010-02-10
on Multirate Register Metering Effective Date: 2010-04-01
California Metering Exchange Protocol Version 1.20 – Update for March 7, 2000
EDI DASR compatibility
Elster EnergyAxis® Management System 2010 January 5
AMR Data Exchange Format Reference Release 7.0
Sensus Meter Systems July 28, 2008
Extended CMEP File Format, Version 0.87
SmartSynch – IESO Interface – MDM/R Interface Specification 06-29-2009
SSI Document # RQ-062009-0006, Revision 2
Version 3.0 – September 24, 2010 iii

IESO_SPEC_9027
Table of Changes
The following is a summary of changes to this document from version 2.9 dated 09 July 2009.
Reference
Description of Change
(Section and Page)
Related Documents, § Updated reference to MDM/R V1.0 Reports Technical
page iii Specifications
§ Updated reference to MDM/R VEE Standard for the Ontario Smart
Metering System
§ Added reference to Measurement Canada General Bulletin GEN-
25-E
§ Added reference to Measurement Canada General Bulletin GEN-
31-E (rev.1)
§ Updated reference to Elster EnergyAxis Management System
AMRDEF Reference Release 7.0
Section 1.5, pages 5-6 Organization of this Document
§ Re-ordered sections adding new sections references for
• EnergyIP Billing Service Standard Interface
• Translation for Meter Read Transmission via Trilliant
CMEP Interface
• Universal Meter Read Interface
Section 1.6.2, Table § Updated Table 1.6.1 – Cross Reference between Detailed Design
1.6.1, pages 9-10 and Technical Interface Specifications adding reference to:
• New sections for EnergyIP Billing Service Standard
Interface Request and Reply
• Re-numbered Meter Read Interface sections of this
document
• Re-numbered Billing Quantity Interface and Billing Cycle
Schedule sections of this document
• Re-numbered Aggregated Settlement Data section of this
document
• Renumbered Web Services section of this document
• Added specification for Meter Read Transformation for
Transmission via Trilliant CMEP Interface
• Added Universal Meter Read Interface (FUTURE)
Section 1.8.2, Table § Added new FTS file type “5500” – Billing Service Standard
1.8.1, page 13 Interface – Request
§ Added new FTS file type “6500” – Billing Service Standard
Interface – Reply
§ Added new FTS file type “7500” – Universal Meter Read Interface
Section 1.8.3, pages § FILE ID 2000, Universal SDP ID Assignment Response Version 01
14-18 • Updated description of Version 00 to indicate retirement of
upon deployment of response Version 01
• Added description of response Version 01.
§ FILE ID 3000, Periodic Audit Synchronization – Version 01
Version 3.0 – September 24, 2010 iv

IESO_SPEC_9027
Reference
(Section and Page)
• Updated description of Segment Number to indicate that
the SEGMENT_NO value must be “01” for a file sent as a
single segment
§ FILE ID 4000, Incremental Synchronization – Version 00
• Updated description of Segment Number to indicate that
the SEGMENT_NO value must be “01” for a file sent as a
single segment
§ FILE ID 5500, Billing Services Standard Interface – Request
• Added new FTS File ID for the standard XML request
§ FILE ID 6500, Billing Services Standard Interface – Reply
• Added new FTS File ID for the standard XML response
§ FILE ID 7500, Universal Meter Read Interface (FUTURE)
• Added placeholder for this future register read interface
Section 2.1, pages 25- Updated Universal SDP ID Assignment Request / Response specification
36 to add Response Version 01 providing the End Of File file integrity
enhancement.
§ Added note indicating retirement of the Version 00 response
§ Updated sections 2.2.1 through 2.2.8 to indicate Version 00
§ Added new sections 2.1.9 through 2.1.16 providing Version 01
specifications
§ Added new Table 2.2.13 providing End Of File record file format
specification
Section 2.2.1, page 37 Periodic Audit Synchronization Interface
§ Updated Description to delete reference to the EnergyIP GUI as a
means to update master attribute data.
Section 2.2.2, pages Periodic Audit Synchronization Interface
38-39 § Characteristics – Sub-section 2.2.2.2
• Updated the description for Segment Number to indicate
the mandatory use of the value “01”
§ Synchronization File Set Sequencing – Sub-section 2.2.2.3
• Added clarification that Extracted Date Time for each
subsequent synchronization file set must be later that all
prior synchronization file sets
Section 2.2.3, pages Periodic Audit Synchronization Interface
40-45 § Business Rules – Rule No. 3
• Added clarification regarding new attribute start date/time
§ Business Rules – Rule No. 4
• Revised description to eliminate update of end date
transactions via the GUI.
• Updated description to indicate that control totals are not
provided in Report IR06 – Synchronization Updates Report
consistent with the Report Technical Specification
• Updated RTS section references for Report IR07 –
Synchronization Exception Report
Version 3.0 – September 24, 2010 v

IESO_SPEC_9027
Reference
(Section and Page)
• Expanded rule #12 to provide clarification regarding the
start and end date/times for current state attribute values
§ Business Rules – Rule #15
• Revision to conditions for Start Date Time for new attribute
values
Section 2.2.8, Table Periodic Audit Synchronization Interface
2.2.6, page 52 § Asset Data File Detail Record – Scaling Constant
• Revised Scaling Constant Start Date Time and End Date
Time to be set using ‘Meter to Comm Module Relationship’
start and end times
2.2.12, page 57 § Service Agreement Data File Detail Record – Universal SDP ID to
Framing Structure Relationship
• Updated description for Relationship Start Date and
Relationship End Date to provide clarification regarding the
daily nature of the EnergyIP framing process
• Updated description for Universal SDP ID to Framing
Structure Relationship End Date indicating restriction to
end date/time for Periodic Audit Synchronization
2.2.16, pages 60 § Parameter Data File Detail Record – Universal SDP ID to Framing
Structure Relationship
• Updated description for End Date Time indicating
restriction to end date/time for Periodic Audit
Synchronization
2.2.17, pages 62-63 § Data Values for Param Value field
• Added date/time restriction for ‘Billing Cycle ID’
• Added date/time restriction for ‘CT/PT Multiplier’
2.2.20, page 65 § Corrected reference to Table 2.2.20 in introductory paragraph
§ Added “Future Dates” column to Table 2.2.20 indicating
relationships for which future dates are allowed
2.2.21, pages 66-67 § Relationship Data File Detail Record
Synchronization
2.2.25, page 72 § Component SDP Channel to Formula Data File Detail Record
Synchronization
Section 2.3.1, page 77 Incremental Synchronization Interface
Version 3.0 – September 24, 2010 vi

IESO_SPEC_9027
Reference
(Section and Page)
§ Updated Description to delete reference to the EnergyIP GUI as a
means to update master attribute data.
§ Synchronization File Set Sequencing – Sub-section 2.2.2.3
• Added clarification that Extracted Date Time for each
subsequent synchronization file set must be later that all
prior synchronization file sets
Section 2.3.3, pages Incremental Synchronization Interface
82-84 § Business Rules – Rule No. 7
• Updated RTS section references for Report IR07 –
Synchronization Exception Report
• Revised conditions for submission of Current State
attribute values
• Revised conditions for submission of Current State
attribute values
§ Updated section to describe the availability Retroactive / Future
Date support and the impact to detail data required for Incremental
Synchronization business scenarios.
Section 2.3.10, Tables Incremental Synchronization Interface
2.3.1 through 2.3.14, § Updated all Business Scenarios as affected by Retroactive / Future
pages 86-112 Date support functionality
• Identified all required data elements for each scenario
• Marked data elements no longer required to support each
scenario as OPTIONAL
Section 2.4, pages 113- Billing Service Standard Interface – Request
122 § Added new XML file specification for the Billing Service Standard
Interface – Request
Section 2.5, pages 123- Billing Service Standard Interface – Reply
140 § Added new XML file specification for the Billing Service Standard
Interface – Reply
Section 2.6, pages 141- Billing Quantity Request
146 § Re-numbered Billing Quantity Request interface specification to
Section 2.6
§ Section 2.6.3 – Business Rules
• Updated Business Rules 1.a, 1.b, and 5.d for clarity
Section 2.7, pages 147- Billing Quantity Response – Versions “00” and “01”
182 § Re-numbered Billing Quantity Response interface specification to
Section 2.7
§ Section 2.7.3 – Business Rules
• Business Rule 3.c – Deleted footnote removing limitation
on account changes from active account to active account.
Account changes to or from no account are supported by
Version 3.0 – September 24, 2010 vii

IESO_SPEC_9027
Reference
(Section and Page)
EnergyIP Release 6.3.
§ Tables 2.7.3, 2.7.5, 2.7.7, 2.7.11 – Response detail records
• Updated ‘Transaction Status’ field format and description
to include codes “17” and “18” and to delete codes no
longer produced by EnergyIP
• Updated ‘Estimated Energy Consumption’ field description
to reference codes “17” and “18” and to delete codes no
longer produced by EnergyIP
§ Table 2.7.4 – Transaction Status codes
• Deleted codes ‘03’, ‘04’, and ’05’ no longer produced by
EnergyIP
• Updated applicable EnergyIP release for remaining codes
§ Section 2.7.17 – File Format Billing Quantity Response Version 01
• Added Version 01 File Name Record specification and
examples for File Types 6000, 6100, and 6200.
• Added Version 01 End-Of-File Record specification for File
Types 6000, 6100, and 6200 and sample EOF Record.
Section 2.8, pages 183- § Re-numbered Billing Cycle Schedule interface specification to
186 Section 2.8
Section 2.9, pages 187- § Re-numbered Aggregated Settlement Data interface specification
193 to Section 2.9
Section 2.10, page § Re-numbered Web Services Request/Reply interface specification
194-204 to Section 2.10
§ Added sub-section 2.10.2.3 – Range of Data for Web Services
Request/Response
§ Table 2.10.4 – Validation failure reason codes
• Added codes 524288, 1048576, 2097152
Section 2.11, pages § Re-numbered Sensus Meter Read Interface specification to
205-214 Section 2.11
Section 2.12, pages § Re-numbered Sensus2 Meter Read Interface specification to
215-225 Section 2.11
§ Removed “Design Review” status for this specification
§ Table 2.12.2 – Field Conventions for Sensus2
• Updated ‘Record Type’ field Format and Description to
indicate support for CMEP data type MEPMD091 only
• Updated ‘Record Version’ field definition to indicate that
this field is Not Required updating Description and Format
• Updated ‘Protocol Text’ field Data Type/Length
specification
Section 2.13, pages § Re-numbered Elster Meter Read Interface specification to Section
226-240 2.13
§ Updated specification to indicate support for EnergyAxis
Management System Release 7.0
§ Updates to indicate support for End Of Interval Snapshot
• Section 2.13.2.2 Characteristics
Version 3.0 – September 24, 2010 viii

IESO_SPEC_9027
Reference
(Section and Page)
• Section 2.13.2.3 Transmission of Register Readings
• Table 2.13.2 Consumption Data Elements – added support
for <MeasurementPeriod> = “EndOfIntervalSnapshot”
§ Table 2.13.3 – Updated processing of interval data tagged
‘InvalidTime’
• Deleted reference to the use of the EnergyIP InvalidTime
outage detection algorithm
• Revised notes to indicate rejection of interval data marked
with the InvalidTime tag
• Revised notes to indicate rejection of future dated interval
data
Section 2.14, pages § Re-numbered Trilliant Meter Read Interface specification to
241-250 Section 2.14
§ Sub-section 2.14.8.3 – Deleted reference to Data Quality Flag
Translator retired with deployment of EnergyIP Release 6.3
Section 2.15, pages § Added technical specification for transformation of Meter Read
251-258 data for transmission to the MDM/R via the Trilliant CMEP interface
Section 2.16, pages § Re-numbered Tantalus Meter Read Interface specification to
259-268 Section 2.16
§ Sub-section 2.16.8.3 – Deleted reference to Data Quality Flag
Translator retired with deployment of EnergyIP Release 6.3
Section 2.17, pages § Re-numbered SmartSynch Meter Read Interface specification to
269-278 Section 2.17
§ Table 2.17.2 – Field Conventions for SmartSynch
• Updated ‘Record Type’ field Format and Description to
indicate support for CMEP data type MEPMD091 only
• Updated ‘Record Version’ field definition to indicate that
this field is Not Required updating Description and Format
• Updated ‘Protocol Text’ field Data Type/Length
specification
Section 2.18, page 279 § Added placeholder Section 2.18 for future Universal Meter Read
Interface
Version 3.0 – September 24, 2010 ix

1 Introduction
1.1 Purpose
This document defines the technical interface specifications for the Meter Data
Management and Repository (“MDM/R”). The specifications in this document provide
the detailed format of the interfaces associated with the integration of the MDM/R with
various external systems.
The specifications in this document will be used to complete the required integration of
various external systems with the MDM/R including those belonging to Local
Distribution Companies, and other Interested Parties.
1.2 Document Scope

The scope of this document is limited to the integration specifications between the
MDM/R and various external data systems, including:
§ The specific file formats of the integrations
§ Specific web service definitions that provide external interface into the
MDM/R.
This document does not define the overall design and the internal behaviour of the
MDM/R itself or the technical design and configuration of the File Transfers Services
described in Section 11, File Transfer Services of the MDM/R Detailed Design
Document.
1.3 Assumptions and Limitations

This specification assumes:
1. MDM/R will process Meter Read data that is produced by smart meters that
conform to the criteria described in the Functional Specification for an
Advanced Metering Infrastructure.
2. Meter Reads for Small Volume Consumers where there is no requirement to
meter demand will be transmitted as hourly data taken at the end of each
hour.
3. Meter Reads for Commercial & Industrial Consumers where metering of
demand is required will be transmitted as one of 5, 15, or 60 minute data
taken at the end of each interval.
4. The LDC will ensure that the Smart Meter is providing correct data through
the AMI to the MDM/R.
5. The LDC will determine when a meter is ready for billing. The use of Billing
Quantity data provided by the MDM/R to the LDC for the purpose of billing is
entirely under the control of the LDC.
6. The MDM/R will process Meter Read files that are in any of the AMCC
formats deployed in Ontario in a uniform format for each AMCC technology.
7. Meter Read data received from meters for which no relationship to a SDP
has been established in the MDM/R Master Directory (MMD) will be rejected
and must be re-transmitted by the LDC after the Meter ID to SDP relationship
Version 3.0 – September 24, 2010 1

has been established in the MMD using either the synchronization interface
or by direct entry using the EnergyIP Graphical User Interface.
8. Daily framing of Billing Quantities will only occur within complete calendar
(EST) days.
9. Billing quantities will be inclusive of the first interval of the first Daily Read
Period through the last interval of the last Daily Read Period included in any
Billing Quantity Response.
10. The majority of SDPs for any LDC are expected to be framed as TOU/CPP
with Billing Quantity data delivered as TOU/CPP consumption for the period.
11. SDPs framed as Hourly by any LDC for the purpose of spot pricing are
expected to be a small percentage of the total SDPs. Billing Quantity data
will be delivered as Hourly consumption data for each day.
12. SDPs for Retailer Customers are expected to be initially framed as Periodic
with Billing Quantity data delivered as consumption for the period. Migration
of SDPs for Retailer Customers to Hourly Framing is expected to rise over
time to the number of Customers currently enrolled with Retailers across the
province of Ontario.
13. References to “future delivery” are not included within the scope of the initial
delivery of the MDM/R solution.
1.4 Definition of Terms

Terms used within this document have been defined in Table 1.4.1 below.
Table 1.4.1 – Definitions
TERM Description
AMCC AMCC means the Advanced Metering Control Computer that is
used to retrieve or receive and temporarily store Meter Reads
before or as they are being transmitted to the MDM/R. The
information stored in the AMCC is available to log maintenance
and transmission faults and issue reports on the overall health of
the AMI to the LDC.
AMI AMI means the Advanced Metering Infrastructure, it includes the
meter, Advanced Metering Communication Device (AMCD), Local
Area Network (LAN), Advanced Metering Regional Collector
(AMRC), Advanced Metering Control Computer (AMCC), Wide
Area Network (WAN), and related hardware, software, and
connectivity required for a fully functioning data collection system.
An AMI does not include the MDM/R.
API API means an Application Program Interface, which is the interface
(calling conventions) application program used for accessing
services provided by another module.
AS2 AS2 means Applicability Statement 2 and is a specification of the
Electronic Data Interchange over the Internet (EDIINT) working
group of the Internet Engineering Task Force (IETF).
Billing Quantity Refers to consumption data that has been through VEE and
Framing and is ready for use in billing.
Block Demand Calculated kVA and/or kW demand based on a time period with
fixed boundaries, such as one hour (e.g. 16:00 to 17:00)

TERM Description
CIS The Customer Information System, in which Customer account
information is held.
CST Central Standard Time
Consumer or Refers to residential or small general service consumers where the
Customer metering of demand is not required.
CPP Refers to specific rate structures called Critical Peak Pricing.
Under these structures, the price of electricity is variable. Such an
occurrence will typically occur when wholesale prices for electricity
are very high due to constrained supply. One or more of the TOU
rating periods will be used to track a Consumer’s electricity
consumption during CPP events.
Daily Read Period Means the 24-hour period for collecting Meter Reads, subject to
the two periods during which changes to and from Daylight
Savings Time take place. The Daily Read Period commences at
12:00 midnight each day.
EnergyIP Rebranding of the PIPe product name. The Meter Data
Management system developed by eMeter Inc that forms the
foundation for the MDM/R solution. (Please see the definition of
PIPe below.)
EST Eastern Standard Time
File Transfer The service which manages the transfer of files between the
Service or FTS MDM/R and LDCs and/or the LDC’s authorized agents.
Firmographic Basic profiling information about business organizations and
/Demographic individuals, respectively. Firmographic data is more relevant for
business-to-business transactions involving automated electronic
data exchange between businesses or trading partners; they do
not typically involve Customers.
Framing The process by which interval data is assembled into Billing
Quantities.
Framing Structure Framing Structure means a parameter that denotes the method by
which Meter Reads are assembled into Billing Quantities by the
MDM/R.
GUI Graphical User Interface. The most commonly used type of
computer interface, exemplified by Microsoft Windows and MacOS.
Typical elements of a GUI are a mouse interface and a system of
visual directories that look like file folders.
Interested Party Those entities that are authorized to access specific data from the
MDM/R.
IVR Interactive Voice Response - A computerized system that allows a
person, typically a telephone caller, to select an option from a voice
menu and otherwise interface with a computer system.
kVAh Kilovolt-ampere hour
kVARh Kilovolt-ampere-reactive hour
kWh Kilowatt hour
kW77 Peak Calculated kVA and/or kW demand in the period between 7:00
Demand a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory
holidays within a billing period.

TERM Description
LDC Means a Local Distribution Company, which is an LDC, as defined
in the Ontario Energy Board Act, 1998
Meter Read Is a number generated by a meter that reflects cumulative
electricity consumption at a specific point in time. (The Meter Read
and related data will be reported to the MDM/R at a specific
Service Delivery Point.)
Meter Read Block Meter Read Block is used by the MDM/R for validation and
estimation purposes. All validation and estimation functions are
based on acting upon a set of contiguous intervals bounded by a
start register read and a stop register read. In some instances a
Meter Read Block may span two or more Meter Transfer Blocks.
For a Meter Transfer Block consisting of interval consumption data
with a register reading at the end of a set of interval consumption
data, the start register read for the Meter Read Block will be the
immediately preceding (contiguous) stop register read
Meter Transfer Meter Transfer Block is a set of data transferred from an AMCC (or
Block other system) to the MDM/R relating to Meter Reads for a specific
Universal SDP ID. A Meter Transfer Block is a set of interval
consumption data with a register reading at the end of the set of
interval data, or a set of interval register reads for a number of
contiguous intervals.
MDM/R Means the meter data management and meter data repository
functions within which Meter Reads are processed to produce
Billing Quantity data and the storage of data for future use.
MDM/R An administrator of the MDM/R system. This may be a person
Administrator from the OSP or the Smart Meter Entity (SME) depending on the
task involved.
MMD Means the MDM/R Master Directory, which is a portion of the
MDM/R that contains the data relationship among the Meter Read
data received from the AMCC and the Service Delivery Point.
Organization ID A unique Identifier for an organization that will be assigned within
the MDM/R during the registration process. Examples of
organizations include LDC, billing agents, AMI operators and
Retailers.
OSP Operational Service Provider.
Rolling Demand Calculated kVA and/or kW demand based on calculations from
sub-interval data over a rolling period such as 60 minutes.
PIPe Power Information Platform by eMeter - The Meter Data
Management system developed by eMeter Inc that will form the
foundation for the MDM/R solution. (See also EnergyIP)
RPP Regulated Price Plan (RPP) for Consumers that sets out the prices
per kWh that local electricity utilities charge for electricity use.
SDP Service Delivery Point means the point at which delivery is
metered or calculated. The SDP is the point at which billing occurs
based on input from one or more smart meters.
SDP ID Service Delivery Point Identifier - The LDC supplied and controlled
identifier that relates to the SDP. It can be an existing identifier (or
combination of identifiers) that is unique within the LDC’s systems
and relates to the SDP within the MDM/R.

TERM Description
SDP REF Service Delivery Point Reference - The unique EnergyIP internal
identifier for each Service Delivery Point. It is assigned by the
EnergyIP system as a Service Delivery Point is created for the first
time.
SSL Secure Sockets Layer - A cryptographic protocol which provides
secure communications on the Internet.
SOAP Simple Object Access Protocol – A protocol for exchanging XML
based messages over computer networks normally using Http.
TOU Time of Use - The sale of electricity based on rates established for
certain times of day, days of week, and/or season of year. For
billing purposes, Hourly Meter Reads are grouped into a number of
rating periods, in accordance with the rate structure, to enable the
recording of consumption at certain times of the day, week, or
year.
Universal SDP ID Universal Service Delivery Point Identifier – The MDM/R unique
identifier by which authorized Parties interact with the Service
Delivery Point. This identifier will be provided to the LDC in the
“Universal SDP ID Assignment Response” file. The Universal SDP
ID is unique across the province.
VEE Means Validation, Estimating and Editing of Meter Reads to
identify and account for missed and inaccurate Meter Reads to
derive billing data. The algorithm to complete VEE identifies gaps
in Meter Reads and rebuilds consumption based on historical
trending and averaging.
WPG WebSphere Partner Gateway - provides the platform for the
MDM/R to manage the business to business (B2B) transactions for
file transfer and translations
1.4.1 Integration Terminology

TERM Description
Request/Response An asynchronous pair of related data flows
Request/Reply A synchronous pair of related data flows
Send An asynchronous one-way flow of data
1.5 Organization of this Document

The Technical Interface Specifications Document is comprised of individual sections
that lay out the technical interface specifications for each interface.
The following interfaces are defined in this document:
• Section 2.1: Universal SDP ID Assignment Request/Response Interface
• Section 2.2: Periodic Audit Synchronization Interface
• Section 2.3: Incremental Synchronization Interface
• Section 2.4: Billing Service Standard Interface – Request
• Section 2.5: Billing Service Standard Interface – Reply
• Section 2.6: Billing Quantity Request

• Section 2.7: Billing Quantity Response
• Section 2.8: Billing Cycle Schedule Interface
• Section 2.9: Aggregated Settlement Data
• Section 2.10: Web Services Request/Reply
• Section 2.11: Meter Read Interface (Sensus)
• Section 2.12: Meter Read Interface (Sensus2)
• Section 2.13: Meter Read Interface (Elster)
• Section 2.14: Meter Read Interface (Trilliant)
• Section 2.15: Meter Read Transformation for Transmission via Trilliant CMEP
Interface
• Section 2.16: Meter Read Interface (Tantalus)
• Section 2.17: Meter Read Interface (SmartSynch)
• Section 2.18: Universal Meter Read Interface
Each interface section has a common layout, as follows:
• Description
• Integration
• Business Rules
• Pre-conditions
• Post-conditions
• Assumptions
• Frequency and Timing
• File Formats
1.6 Document Relationships

1.6.1 Related Documents Overview
This document is part of a library that specifies the design, functions and technical
interfaces belonging to the Meter Data Management/Repository (MDM/R). This library
is comprised of the following documents:
1) Meter Data Management and Repository MDM/R V1.0 Detailed Design
(the “Detailed Design”): This document sets out the design of the MDM/R
in accordance with the MDM/R Functional Specification that forms part of the
“MDM/R Specification” document series (described below).
2) Meter Data Management and Repository MDM/R V1.0 Technical
Interface Specifications (the “Technical Interface Specification”): This
document describes the format and content of all file-based technical
interfaces between the MDM/R and various authorized, interested parties.
The Technical Specifications for reports are included in item 4 below.
3) MDM/R File Transfer Services and Web Services Configuration
Workbook: This document is an aide to assist Organizations with their AS2
configurations for file transfers to and from the MDM/R.
4) Meter Data Management and Repository MDM/R V1.0 Reports Technical
Specifications: This document describes the format and content of MDM/R
generated standard and exception reports.

The documents in this library were preceded by the publication of the “MDM/R
Specification” document series, produced by the IESO’s Smart Metering System
Implementation Program (SMSIP). The MDM/R Specification, is a series of documents
developed for the procurement and functional specification of the MDM/R, and includes
the following documents:
1) MDM/R Functional Specification – IESO_SPEC_0241: This document
sets out the functional description of the Meter Data Management and
Repository functions.
2) MDM/R Business Process Description – IESO_SPEC_0240: This
document contains a high-level view of the major business process areas
identified in the, “MDM/R Functional Specification”
3) MDM/R Logical Application and Data Architecture (LADA) –
IESO_ARCH_0008: This document sets out an overview of a logical
architecture for the applications, data and inter-dependencies related to the
Smart Metering System (in general) and the Meter Data Management
Repository (specifically).
4) MDM/R Service and Performance Levels – IESO_SPEC_0239: This
document sets out the volumetric projections, and corresponding
expectations for service and performance for the MDM/R.
The MDM/R Specification document series is available from the SMSIP website
(http://www.smi-ieso.ca). The interrelationships between these various documents are
depicted in Figure 1.6.1.

Figure 1.6.1 – Interrelationships between MDM/R Documents
MDM/R Specification Document Series

MDM/R Logical
(authored by IESO for MDM/R Procurement)
Business Processes to be Applications and
Logically supported by the Data Architecture
MDM/R solution space
IESO_ARCH_0008
MDM/R Functional MDM/R Business
Specification Process
Description
IESO_SPEC_0241
IESO_SPEC_0240
Functions to be
accommodated
MDM/R Service
and Performance
Levels
Business Processes
Functional Description to to be supported by
be accommodated by IESO_SPEC_0239
the MDM/R solution
the MDM/R design
MDM/R V1.0 Technical MDM/R V1.0 Reports

Interface Specifications Technical
Document Specifications
IESO_SPEC_9027 SME_SPEC_0001
MDM/R V1.0– Detailed
Design
SME_DES_9001
MDM/R File Transfer

Services and Web
Services Configuration
Workbook
SME_MAN_9001
Design and Functional

Description Technical Interface Description
MDM/R Document Library for Design, Functions, and Technical Interfaces
1.6.2 Subject Cross-reference: MDM/R Design and Functionality to

Technical Interfaces
As described earlier, the Detailed Design provides a functional overview to the design,
including each of the information flows that are supported by an MDM/R Technical
Interface. All technical interfaces are described from a functional standpoint in section
15 of the Detailed Design. Most of these MDM/R Technical Interfaces are supported by
the form and content of file-based transfers which are described in the Technical
Interface Specifications.
Table 1.6.1 below cross-references the major subjects described in the Detailed
Design with the Technical Interface Specifications.

Table 1.6.1: Cross Reference between Detailed Design subject matter, the Technical Interface
Specifications
Meter Data Management and Repository Meter Data Management and Repository
Detailed Design Technical Interface Specifications
Section Subject Matter Section Subject Matter
Universal SDP ID Assignment Request
2.1
Response Interface
3 Service Delivery Point
2.2 Periodic Audit Synchronization
2.3 Incremental Synchronization
MDM/R Master Data (MMD) 2.2 Periodic Audit Synchronization

4
Synchronization 2.3 Incremental Synchronization
2.11 Meter Reads Interface – Sensus
2.12 Meter Reads Interface – Sensus2
2.13 Meter Reads Interface – Elster
5 Meter Data Collection and Processing 2.14 Meter Reads Interface – Trilliant
2.16 Meter Reads Interface – Tantalus
2.17 Meter Reads Interface – SmartSynch
2.18 Universal Meter Read Interface (Future)
6 VEE Processing n/a n/a
7 Framing of Billing Quantities n/a See Section 8 below
2.4 Billing Service Standard Interface – Request
2.5 Billing Service Standard Interface – Reply
2.6 Billing Quantity Request Interface
8 Billing Quantity Processing
2.7 Billing Quantity Response Interface
2.8 Billing Cycle Schedule Interface
2.9 Aggregated Settlements Data
9 Reporting n/a n/a
10 Security n/a n/a
11 MDM/R File Transfer Services n/a n/a
12 Direct Access GUI n/a n/a
Customer Presentment -
13 2.10 Web Services Interface
Web Services Interface
14 MDM/R Administration n/a n/a
Interface Functional Specification –
Universal SDP ID Assignment Request/
Universal SDP ID Assignment Request 2.1
Response Interface
and Response

2.2 Periodic Audit Synchronization Interface
Periodic Audit Synchronization

2.3 Incremental Synchronization Interface
Incremental Synchronization.
15 2.11 Meter Reads Interface – Sensus
2.12 Meter Reads Interface – Sensus2
2.13 Meter Reads Interface – Elster
2.14 Meter Reads Interface – Trilliant
Meter Reads Interface
2.15 Meter Read Transformation to Trilliant CMEP
2.16 Meter Reads Interface – Tantalus
2.17 Meter Reads Interface – SmartSynch

Meter Data Management and Repository Meter Data Management and Repository
Detailed Design Technical Interface Specifications
Section Subject Matter Section Subject Matter
2.18 Universal Meter Read Interface (FUTURE)
Interface Functional Specification – 2.4 Billing Service Standard Interface – Request
Billing Quantity Request Interface 2.6 Billing Quantity Request Interface
Interface Functional Specification – 2.5 Billing Service Standard Interface – Reply

Billing Quantity Response Interface 2.7 Billing Quantity Response Interface
Billing Cycle Schedule
2.10 Web Services Interface
Web Services Interface
Aggregation for Settlement 2.9 Aggregated Settlement Data
1.7 Conventions for Data Field Formats

The conventions used for the data fields in the files contained within this document are
as follows.
Table 1.7.1 Data Field Formats
Data Fixed Number (X) or Time

Char(X) Varchar(X) Date/Time
Type Number (X) Number (X,Y) Interval
A floating
numeric field
A fixed
A variable with a maximum A length of
length
length A fixed length of “X” digits to time as
alphanumer
alphanumeric numeric field the left of the A Date/Time indicated in
Description ic field with
field with a with a defined decimal and a or Date field. months, days,
a defined
maximum length of “X” maximum of “Y” hours and
length of
length of “X” digits to the right minutes.
“X”
of the decimal (if
existing).
yyyyMMddHH
mmss
Format AAAAA AAAAA NNNNN NNNNN.NN MMDDhhmm
or
yyyyMMdd
Includes the Date/Time
full ASCII fields must
character set, always be
Includes the with the expressed in
full ASCII exception of Eastern
character the Pipe (|) Standard
set, with the character Time (EST)
exception of yyyy – Year
the Pipe (|) All Meter MM – Month
MM – Month
character Fields of this
Read dd – Day DD – Day
Special Character Interface files: type must be
Instructions padded to the HH – Hour, in hh – Hour, in
count must The optional
left with zeros. 24 hour format 24 hour format
always be Segment
the defined mm – Minutes mm – Minutes
Number file
length. name element ss – Seconds
Padding is is limited to
not CMEP Meter
alpha and
acceptable Data files
number
or required provide
characters.
Date/Time as:
Special
characters of yyyyMMddHH
the ASCII mm

Data Fixed Number (X) or Time
Char(X) Varchar(X) Date/Time
Type Number (X) Number (X,Y) Interval
character set
Elster Meter
must not be
Data files
used.
provide
Date/Time as:
yyyy-mmdd
hh24:mi:ss
Web Services
provides
Date/Time as:
YYYY-MM-
DDTHH:MI:SS
.sss[[+|-
]TZH:TZM]
Date/Time
Fixed Number Time Interval
Varchar(10) Number (5,2) 20070220
Format Char(6) (3) 00000100
AB123C 123 130703
example AB123C 123 indicating 1
ABC123DEFG 12345.67 Date
045 hour intervals
20070220
1.8 MDM/R FTS Use of File Names

The MDM/R FTS refers to each registered organization as a Community Participant.
The value assigned to the Community Participant is used in two places.
• The first is in the configuration of the Community Participant AS2 client. The
AS2 client will add the AS2 ID to the AS2 protocol headers attached to each
file that it sends to the MDM/R.
• The second is in the list of Community Participants and their associated
Organization ID’s. This list is part of the MDM/R FTS configuration files and is
maintained by the MDM/R Administrator.
Each file that is sent by a Community Participant to the MDM/R or by the MDM/R to a
Community Participant has a file name that meets the specifications in this section.
MDM/R FTS depends on the file name specification to direct incoming files into the
appropriate directory for processing by the target application such as EnergyIP or
MDM/R Staging Table Loader without looking into the content of the file. Likewise, the
Community Participant is able to rely on the names of files received from the MDM/R.
1.8.1 Structure of MDM/R file names

The file names used by MDM/R are structured into two groups of elements.
The first group of elements is common to all file names and each element must always
be present and in the order in which they are specified in the next section.
The second group of elements is dependent upon the file type being named. If an
element is specified for a file type then it must be present and it must be in the order in
which it is specified.
File name elements are separated by a period (.).
File name elements may contain letters (A-Z, a-z) and numbers (0-9). Other than
letters, numbers and the separator character, no other characters are permitted in the
file name elements.

The file name ends with the extension .DAT.
The file name specification does not speak to the manner in which data in the file is
organized. Files containing delimited data and files containing XML encoded data will
both have a .DAT extension.
The general syntax for the file name is:
<ORG_ID_1>.<ORG_ID_2>.<FILE_ID>.<FILE_VER>.<DATE_TIME>{.request
specific element n}.DAT
The specific elements of the file name are described in the following sections.
1.8.2 File name elements common to all files

The first five elements described below are common to all file names.
Element 1: ORG_ID_1 (Organization ID)
This mandatory element is the 8 character Organization ID, beginning with ORG, that
identifies the Community Participant on whose behalf the file has been submitted for or
received on behalf of.
The Organization ID must be a valid Organization ID that is already known to the
MDM/R FTS.
In the situation where a Community Participant is submitting its own files the
Organization ID and the Agent Organization ID will be identical.
The relationship of Organization ID to Agent Organization ID must be known to the
MDM/R FTS at the time the relationship is asserted through an incoming file name.
This information is captured when the relationship is established. It is maintained by
the MDM/R Administrator in MDM/R FTS configuration files.
Agent Organization ID is used in situations where one organization is acting on behalf
of another organization. An example of such a relationship is a third party AMI operator
submitting meter read data on behalf of the LDC with which it has a contract.
Element 2: ORG_ID_2 (Agent Organization ID)
This mandatory element is the 8 character Organization ID, beginning with ORG, that
identifies the Community Participant that is acting as the agent for the Community
Participant on whose behalf the file has been submitted for or received on behalf of.
The Agent Organization ID must be a valid Organization ID that is already known to the
MDM/R FTS.
In the situation where a Community Participant is submitting its own files the
Organization ID and the Agent Organization ID will be identical.
The relationship of Organization ID to Agent Organization ID must be known to the
MDM/R FTS at the time the relationship is asserted through an incoming file name.
This information is captured when the relationship is established. It is maintained by
the MDM/R Administrator in MDM/R FTS configuration files.
Agent Organization ID is used in situations where one organization is acting on behalf
of another organization. An example of such a relationship is a third party AMI operator
submitting meter read data on behalf of the LDC with which it has a contract.
Element 3: FILE_ID (FILE ID)
This mandatory element is a four digit value that identifies the type of file.

FILE ID comes from the list of valid files that can be sent to the MDM/R. This list is
maintained by the MDM/R Administrator and is part of the MDM/R FTS configuration
files. This list only changes when a new type of file is introduced or retired.
The MDM/R Technical Interface Specifications document contains the list of valid
files and the specification of each. The MDM/R Reports Technical Specifications
document contains the list of valid reports and the specification of each.
Table 1.8.1: Valid file types
FILE ID File Type Comments

1000 Universal SDP ID Request for the assignment of one or more Universal
Assignment Request Service Delivery Points
2000 Universal SDP ID Response containing the requested assignment of
Assignment Response Universal Service Delivery Points.
3000 Periodic Audit Process a complete synchronization of the MDM/R
Synchronization Master Directory with the LDC Data Source(s)
4000 Incremental Update the MDM/R Master Directory as SDP
Synchronization attributes and relationships changes are supplied by
the LDC to the MDM/R, based on changes in LDC
Data Source(s)
5000 Billing Quantity Request Requests to the MDM/R for Billing Quantity data
5500 Billing Service Standard EnergyIP standard XML requests to the MDM/R for
Interface – Request Billing Quantity data
6000 Billing Quantity Response Response from the MDM/R for TOU/Periodic Billing
– TOU/CPP & Periodic Quantity data
6100 Billing Quantity Response Response from the MDM/R for Hourly Billing Quantity
– Hourly data
6200 Billing Quantity Response Response from the MDM/R for Peak Demand
– Demand Quantities and Coincident Quantities data
6500 Billing Service Standard EnergyIP standard XML reply from the MDM/R for
Interface – Reply Billing Quantity data – TOU, Periodic, Hourly
7000 Meter Read Interface Deliver Meter Read data for smart meters to the
(Sensus) MDM/R
(Sensus2) MDM/R
(Elster) MDM/R
(Trilliant) MDM/R
(Tantalus) MDM/R
(SmartSynch) MDM/R
7500 Universal Meter Read Deliver externally estimated register read data to the
Interface (FUTURE) MDM/R
8000 Billing Cycle Schedule Inform the MDM/R of the billing cycle schedule dates
that map to each billing cycle
9000 Data Aggregation File The daily Aggregated Settlement data provided to
LDCs

FILE ID File Type Comments
9100 Data Aggregation The daily listing of SDP, Loss Factor Classification,
Contributors File and Meter combinations contributing to the daily
Aggregated Settlement data
Element 4: FILE_VER (File Version)

This mandatory element is a fixed two digit value that identifies the format version of
the file.
The file format version starts at 00 and increases as new versions of each file format
are introduced.
File format version is provided to allow multiple format versions of the same file type to
co-exist. This is of use in situations where the MDM/R is migrating to a new format
version of a file but must maintain the previous version long enough for each
Community Participant to migrate to the new format.
The MDM/R Technical Interface Specifications documents the valid request
versions.
Element 5: DATE_TIME (Date and Time)
This mandatory element is a 14 digit value that identifies the date and time of the file.
The format of the field is yyyyMMddHHmmss where yyyy is the year, MM is the month,
dd is the day, HH is the hour in 24 hour clock format, mm is the minutes and ss is the
seconds. All positions must be numeric and meet the standard validity tests of date
and time.
The value in this field is set by the sender. The value in this field should not be
assumed to be the file creation date and time. The business meaning of this field is
further defined in the specification of the individual request types.
Where a request is made up of multiple files e.g. Periodic Audit Synchronization
Request each file in the set must have the same value for DATE_TIME.
1.8.3 File name elements specific to individual interface files

File ID 1000 – Universal SDP ID Assignment Request
This file does not have any additional file name elements.
File ID 2000 – Universal SDP ID Assignment Response – Version 00

Version 00 will be retired upon deployment of response version 01.
File ID 2000 – Universal SDP ID Assignment Response – Version 01

File ID 3000 – Periodic Audit Synchronization – Version 00

Version 00 of the Periodic Audit Synchronization interface has been retired.

File ID 3000 – Periodic Audit Synchronization – Version 01
Version 01 of the Periodic Audit Synchronization interface is a single file set made up
of a set of 7 related files. The additional file name elements in the file name link these
files such that the MDM/R is able to determine which files belong to any given
submission and when the complete set (all 7 files) has been received.
Element 6 – TX_ID (Transaction Identifier)
This mandatory element is a fixed 6 character value that relates all 7 files in this file
type. The same value must be present in this element position for each file that makes
up the synchronization file set.
The value that is placed in this element is defined by the sender. The value is used to
group a given file set together and as a reference for the sender.
Element 7 – FILE_NO (File Number)
This mandatory element is a 2 digit value that identifies which of the 7 files that make
up a Periodic Audit Synchronization file set the particular file is.
00. Manifest File
01. Asset Data File
02. Premise Data File
03. Service Agreement Data File
04. Parameter Data File
05. Relationship Data File
06. (Not Used)
07. Component SDP Channel to Channel & Channel to Formula Data File
Element 8 – SEGMENT_NO (Segment Number)
This mandatory element is a fixed 2 digit value that represents the file segment number.
The purpose of this is to allow an LDC to break up a large synchronization file into
smaller synchronization files.
For example, if you are submitting three Asset files, the segment numbers will be 01,
02, and 03.
If a file is sent as a single segment the value for the Segment Number element must be
01.
File ID 4000 – Incremental Synchronization – Version 00

Version 00 of the Incremental Synchronization is conceptually a single file but it is
made up of a set of 7 related files in the same way as Version 01 of the Periodic Audit
Synchronization.
Element 6 – TX_ID (Transaction Identifier)
This mandatory element is a fixed 6 character value that relates all 7 files in this file
type. The same value must be present in this element position for each file that makes
up the synchronization file set.
The value that is placed in this element is defined by the sender. The value is used to
group a given file set together and as a reference for the sender.
Element 7 – FILE_NO (File Number)

This mandatory element is a 2 digit value that identifies which of the 7 files that make
up an Incremental Synchronization file set the particular file is.
00. Manifest File
01. Asset Data File
02. Premise Data File
03. Service Agreement Data File
04. Parameter Data File
05. Relationship Data File
06. (Not Used)
07. Component SDP Channel to Channel & Channel to Formula Data File
This mandatory element is a fixed 2 digit value that represents the file segment number.
The purpose of this is to allow an LDC to break up a large synchronization file into
smaller synchronization files.
For example, if you are submitting three Asset files, the segment numbers will be 01,
02, and 03.
If a file is sent as a single segment the value for the Segment Number element must be
01.
File ID 5000 – Billing Quantities Request

File ID 5500 – Billing Service Standard Interface – Request

File ID 6000 – Billing Quantities Response (TOU/CPP & Periodic)

File ID 6100 – Billing Quantities Response (Hourly)

File ID 6200 – Billing Quantities Response (Demand)

File ID 6500 – Billing Service Standard Interface – Reply

File ID 7000 – Meter Read Interface (Sensus)

This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.

NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7001 – Meter Read Interface (Sensus2)

(upper and lower case letters) and number characters integers (0 through 9) of the
others).
File ID 7100 – Meter Read Interface (Elster)

others).
File ID 7200 – Meter Read Interface (Trilliant)
others).
File ID 7300 – Meter Read Interface (Tantalus)

others).
File ID 7400 – Meter Read Interface (SmartSynch)
others).
File ID 7500 – Universal Meter Read Interface (FUTURE)
(Future)
File ID 8000 – Billing Cycle Schedule

File ID 9000 – Data Aggregation

File ID 9100 – Data Aggregation Contributors

1.8.4 File Name Record

Different AS2 clients have different ways of treating filenames. While some will retain
the original file name when transferring the file from one AS2 system to another, others
will change the name. To ensure that the file names are retained regardless of what
AS2 client an Organization chooses to install, the file name is the first record of every
inbound file from an Organization to the MDM/R and every outbound file from the
MDM/R to an Organization.
1.8.5 MDM/R File Name Examples

The following examples illustrate the naming of files exchanged with the MDM/R.
Assume that the following organizations or Community Participants have been enrolled
with the MDM/R and assigned Organization ID’s (ORG_ID):
§ ORG11111 is Acme Hydro (a fictitious utility)
§ ORG22222 is Ace AMI Operations Limited (a fictitious AMI operations
company)
Further assume that Acme Hydro has outsourced its AMI operations to Ace AMI
Operations Limited. This business relationship has been registered with the MDM/R
and the MDM/R Operator has updated the necessary configuration files.

The general syntax from the sections above is:
<ORG_ID_1>.<ORG_ID_2>.<FILE_ID>.<REQ_VER>.<DATE_TIME>{.request
specific element n}.DAT
Table 1.8.2 Examples of File Names
Transaction description File Name

A version 01 Universal ORG11111.ORG11111.1000.01.20070214221345.DAT
SDP ID Assignment
Request file is sent by
Acme Hydro to the
MDM/R.
The MDM/R processes ORG11111.ORG11111.2000.01.20070214221345.DAT
the work in the example
above and sends back a
version 01 Universal SDP
ID Assignment Response
file to Acme Hydro.
Ace AMI Operations ORG11111.ORG22222.7100.01.20070214221345.DAT
Limited sends a version
01 file of meter data from
the Acme Hydro Elster
AMI system to the
MDM/R.
Ace AMI Operations ORG11111.ORG22222.7000.00.20080504221345.OL 53590.DAT
Limited sends a version ORG11111.ORG22222.7000.00.20080504221345.OL 54900.DAT
00 file of meter data from ORG11111.ORG22222.7000.00.20080504221345.OL 54627.DAT
the Acme Hydro Sensus
ORG11111.ORG22222.7000.00.20080504221345.OL 75439.DAT
AMI system to the MDM/R
consisting of four
segments on May 4,
2008.
Acme Hydro sends a ORG11111.ORG11111.3000.00.20070214221345.ababab.01.DAT
version 00 Periodic Audit ORG11111.ORG11111.3000.00.20070214221345.ababab.02.DAT
Synchronization file set to ORG11111.ORG11111.3000.00.20070214221345.ababab.03.DAT
the MDM/R. In this
ORG11111.ORG11111.3000.00.20070214221345.ababab.04.DAT
example, the unique
identifier assigned by ORG11111.ORG11111.3000.00.20070214221345.ababab.05.DAT
Acme Hydro to this ORG11111.ORG11111.3000.00.20070214221345.ababab.06.DAT
specific request is ORG11111.ORG11111.3000.00.20070214221345.ababab.07.DAT
‘ababab’. ORG11111.ORG11111.3000.00.20070214221345.ababab.08.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.09.DAT
Acme Hydro sends a ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.00.01.DAT
version 01 Periodic Audit ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.01.01.DAT
Synchronization file set to ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.02.01.DAT
the MDM/R. In this
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.03.01.DAT
example, the unique
identifier assigned by ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.04.01.DAT
Acme Hydro to this ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.05.01.DAT
specific request is ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.07.01.DAT
‘cdcdcd’.

Transaction description File Name
Acme Hydro sends a ORG11111.ORG11111.3000.01.20070214221345.efefef.00.01.DAT
version 01 Periodic Audit ORG11111.ORG11111.3000.01.20070214221345.efefef.01.01.DAT
Synchronization file set to ORG11111.ORG11111.3000.01.20070214221345.efefef.01.02.DAT
the MDM/R. Acme Hydro
chooses to split their ORG11111.ORG11111.3000.01.20070214221345.efefef.01.03.DAT
Asset file into 3 separate ORG11111.ORG11111.3000.01.20070214221345.efefef.02.01.DAT
files. In this example, the ORG11111.ORG11111.3000.01.20070214221345.efefef.03.01.DAT
unique identifier assigned ORG11111.ORG11111.3000.01.20070214221345.efefef.04.01.DAT
by Acme Hydro to this ORG11111.ORG11111.3000.01.20070214221345.efefef.05.01.DAT
specific request is ‘efefef’.
ORG11111.ORG11111.3000.01.20070214221345.efefef.07.01.DAT
Acme Hydro sends a ORG11111.ORG11111.4000.00.20070214221345.J39x82.00.01.DAT
version 00 Incremental ORG11111.ORG11111.4000.00.20070214221345.J39x82.01.01.DAT
Synchronization file set to ORG11111.ORG11111.4000.00.20070214221345.J39x82.02.01.DAT
the MDM/R. In this
ORG11111.ORG11111.4000.00.20070214221345.J39x82.03.01.DAT
example, the unique
identifier assigned by ORG11111.ORG11111.4000.00.20070214221345.J39x82.04.01.DAT
Acme Hydro to this ORG11111.ORG11111.4000.00.20070214221345.J39x82.05.01.DAT
specific request is ORG11111.ORG11111.4000.00.20070214221345.J39x82.07.01.DAT
‘J39x82’.

1.9 Timelines
Figure 1.9.1 depicts the typical processes involved in the daily receipt of Meter Read
and MMD update data and the daily production of Billing Quantities for the last Daily
Read Period included in any billing period.
This figure illustrates the timing for file transfer of synchronization data, meter read
data and billing quantity data. Please note that meter read data may be supplied at a
minimum once per day. The preference is for meter read data to be provided as
frequently as possible with as little latency between the data collection from the field
and the data being sent onto the MDM/R.
Frequency and timing for each individual file transfer are specified in the later sections
of this document.
Figure 1.9.1 MDM/R Timeline for Last Daily Read Period “N” included in a Billing Period

1.10 Position Statement – Meter Read Data Transformations
Regarding: Data transformations involving Meter Read data prior to transmission to
the MDM/R.
Authority: This MDM/R Position Statement has been issued by the Independent
Electricity System Operator (IESO) acting in the capacity of the Smart Metering Entity
(SME) as set out in Electricity Act (S.O. 1998, c. 15, Sch. A) and through its regulatory
right to establish detailed requirements for all inbound meter read interfaces to the
MDM/R (Ontario Regulation 233/08 “Designation of Smart Metering Entity”).
The Issue: It has come to the attention of the IESO that some MDM/R service
recipients (i.e. organizations registered with the IESO as users of the MDM/R and their
agents) may be applying various data transformations to meter read data prior to its
transmission from the Advanced Metering Control Computer (AMCC) to the Meter Data
Management Repository (MDM/R). These data transformations are in some cases
taking place outside of components of the smart metering systems that are governed
by either:
§ The provincial government regulation pertaining to the functional
specification of the Advanced Metering Infrastructure, specifically Ontario
Regulation 440/07 “Functional Specifications for an Advanced Metering
Infrastructure”, or
§ The Technical Interface Specification documents issued by the IESO.
A contextual diagram of the issue addressed by this position statement is provided in
Figure 1.10.1.
The MDM/R is the recipient of such transformed meter read data and the IESO has the
right to specify the nature of the meter read interface to the MDM/R under the authority
of Ontario Regulation 233/08 “Designation of Smart Metering Entity”. Therefore, this
Position statement is intended to clarify the IESO’s view of such data transformations.
Position Statement: From the IESO’s viewpoint, meter read data transformations
taking place between an MDM/R service recipient’s AMCC (or an AMCC belonging to
a service recipient’s duly registered agent for the purpose of sending meter read data
to the MDM/R) and the MDM/R meter read interface:
1. are allowable,
2. shall be in compliance with all applicable law (including any applicable
regulations governing the role of the SME) and not contradict the role of the
MDM/R with respect to the Validation Estimation and Editing (VEE) Standard
for the Ontario Smart Metering System, and
3. the resulting meter read data arriving at the MDM/R interface will, in all
circumstances be processed in the manner set out in these MDM/R V1.0
Technical Interface Specifications.

Governance of the AMI to MDM/R interface:
MDM/R
Position MDM/R V1.0 Technical
Ontario Regulation 440/07: “Criteria and Requirements for meters and metering Interface Specifications
equipment systems and technology” Statement: (IESO_SPEC_9027)
Meter read data

Electricity Gas and transformations:
Inspection Act 1) are allowable;
(R.S.C. 1985, c. E-4) 2) shall be in
compliance with
all applicable law;
and,
Inbound Meter Read Data Flow: 3) meter read
data arriving at
the MDM/R
interface will be
processed in
accordance with
Advanced Metering the MDM/R
Regional Collectors Technical
(AMRCs) Interface
Specifications
Advanced Metering
Regional Collectors Advanced Metering
Smart Meters – including (AMRCs) Control Computer Meter Data
Advanced Metering (AMCC) Management Repository
Communication Device (MDM/R)
(AMCD)
Meter Read Data Transition States: State 3:

State 1: State 2:
State 0: Meter read data arriving
Meter read Meter read
Meter read at MDM/R interface in a
data as data as
data within the format stipulated by the
recorded by recorded by
smart meter State 2(b): MDM/R Technical
AMRC devices AMCC devices
Optional state Interface Specifications
transition:
Meter read data
altered from native
AMCC format prior
to transmission to
MDM/R
Figure 1.10.1 Contextual View of this Position Statement
Background – State Transition of Meter Read Data:

For the purposes of this MDM/R Position Statement, meter read data may described in
terms of its transition through various states along its data flow path from the smart
meter to the MDM/R. These states are depicted in figure ‘A’, and include:
State 0: In this state, the Meter Read data resides within the smart meter itself.
Key regulatory instruments governing Meter Read data in this state include the
federal Electricity, Gas and Inspection Act (R.S.C. 1985, c. E-4) and associated
regulations. This act also has various provisions governing the integrity of Meter
Read data once it is extracted from the meter.
State 1: Within the context of the Ontario smart metering system, Meter Read
data is read from smart meters (AMCD) using a component of the Advanced
Metering Infrastructure (AMI) known as the Advanced Metering Regional

Collector (AMRC). All components of the AMI (including the smart meters
themselves) are subject to the functional specification set out in Ontario
Regulation 440/07. This regulation also requires AMI components to comply with
regulatory requirements established by Industry Canada, the Canadian
Standards Association, the Ontario Energy Board and the Electrical Safety
Authority.
State 2: AMRCs feed Meter Read data to the Advanced Metering Control
Computer (AMCC) for assembly into meter read files that must be transmitted to
the MDM/R. AMCC’s are also deemed to be a portion of the AMI infrastructure
governed by Ontario Regulation 440/07.
State 3: Meter Read data arriving at the MDM/R interface will be processed in
accordance with these MDM/R V1.0 Technical Interface Specifications
(IESO_SPEC_9027) and any applicable provisions or regulations made under
the Electricity, Gas and Inspection Act (R.S.C. 1985, c. E-4). The technical
interface specification document sets out the interface requirements that must be
met by all Meter Read data. Presently this document and the associated MDM/R
interface makes accommodation for different types of smart metering technology
(see Meter Read Interface specifications in this document for further details).
State 2 (b) – Optional State Transition: Changes to the format or content of

Meter Read data between “State 2” and “State 3” are the subject of this MDM/R
Position statement. These changes may take place outside the scope of the AMI
and its associated, governing instruments. However, Meter Read data is still
subject to a number of applicable laws including various information privacy laws.
It is the responsibility of the MDM/R service recipient to be informed of all
applicable law governing such data and to adhere to it. As noted above, the
IESO does not seek to restrict an MDM/R service recipient from carrying out
such data transformations, so long as it is clearly understood that Meter Read
data arriving at the MDM/R interface will be processed in accordance with these
MDM/R V1.0 Technical Interface Specifications (IESO_SPEC_9027) and the
MDM/R Validation Estimation and Editing Standard for the Ontario Smart
Metering System (IESO_STD_0078).

2 Technical Interface Specifications
2.1 Universal SDP ID Assignment Request / Response Interface
Note: Version 00 of the Response interface will be retired and replaced by Version 01
with the deployment of EnergyIP Release 7.0 into the MDM/R Production environment.
For the Version 01 specification see Sections 2.1.9 through 2.1.16.
2.1.1 Description – Version 00

The purpose of this interface is to process requests from the LDC for Universal Service
Delivery Point Identifiers (Universal SDP IDs) and to return the assigned Universal
SDP IDs to the LDC.
This interface meets a business requirement that a province-wide unique identifier be
made available to the LDC in order to pair it with an LDC-specific Service Delivery
Point ID (SDP ID) and to be able to uniquely identify itself to the MDM/R in future
transactions.
The LDC uses this interface to request one or more Universal SDP IDs at a time.
The LDC sends a Universal SDP ID Assignment Request File with an LDC ID that
uniquely identifies the LDC, along with LDC-generated SDP IDs to which the
corresponding Universal SDP IDs is assigned to through this interface. SDP IDs are
generated by the LDC, and are unique within the LDCs systems.
The Universal SDP ID Assignment Response File is sent back to the LDC with a
Universal SDP ID assigned against every SDP ID in the Universal SDP ID Assignment
Request File.
This interface uses the Universal SDP ID Generator features within the MDM/R system
to manage the assignment of Universal SDP IDs.
Universal SDP IDs and SDP IDs are described in detail in Section 3 of the MDM/R
Detailed Design Document, Service Delivery Point.
2.1.2 Integration – Version 00

2.1.2.1 File Direction
Universal SDP ID Assignment Request: LDC to the MDM/R
Universal SDP ID Assignment Response: MDM/R to the LDC
2.1.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text
files.
The Universal SDP ID Assignment Request File contains all of the information
described in tables 2.1.1 to 2.1.3.
The Universal SDP ID Assignment Response File contains all of the information

Once the Universal SDP ID Assignment Request File is delivered to the MDM/R (see
Section 11, File Transfer Services of the MDM/R Detailed Design) the Universal SDP
ID Assignment process will process the request file and generate the response file.
2.1.3 Business Rules – Version 00

1. Universal SDP IDs will not be assigned for an invalid LDC ID. An LDC ID is
invalid if it is not recognized by the MDM/R, or if the LDC ID has originated
from a directory belonging to a different LDC.
2. If any record in the Universal SDP ID Assignment Request File includes an
SDP ID which has already been recorded as receiving a Universal SDP ID, a
Universal SDP ID is not assigned.
3. For each valid Universal SDP ID request, the Universal SDP ID Generator:
a. Assigns the next available Universal SDP ID to the LDC and
associates this Universal SDP ID with the SDP ID.
b. Includes the Universal SDP ID in the response.
4. The interface creates a Universal SDP ID Assignment Response File and
includes records for those SDP IDs that have a Universal SDP ID assigned.
The response will also include records for requests that did not receive a
Universal SDP ID assignment and the reason for such exceptions. This file is
placed in the designated storage location for the File Transfer Services to
transfer to the LDC. The Universal SDP ID Assignment Request File is
moved to the processed directory in the MDM/R.
5. The following are exception cases:
a. The MDM/R Universal SDP ID Assignment Adapter detects
exceptions in regards to invalid file format and data type exceptions.
b. The MDM/R detects exceptions when the LDC Identifier values are
not known by the system.
c. The MDM/R detects exceptions when the SDP ID has had a
Universal SDP ID previously assigned.
d. The MDM/R detects exceptions when the file contains LDC Identifier
values that do not correspond to the LDC Identifier that the file was
received from.
6. The following exception report is created:
§ The Universal SDP ID Assignment Request Summary Exception
Report has control totals such as number of records read, processed
and rejected (Refer to Report IR01 in Section 2.4.1 of the MDM/R
Reports Technical Specifications).
The interface creates an exception report and places it in the designated storage
location for File Transfer Services (FTS) transfer to the LDC.
2.1.4 Pre-conditions – Version 00

The following must exist for the input file to be processed through the interface:
§ The LDC is enrolled and has an LDC ID assigned.
§ The LDC includes a SDP ID for each Universal SDP ID request.

2.1.5 Post-conditions – Version 00
The following outcome results from the file being processed through the interface:
§ The LDC has a valid Universal SDP ID assigned for each SDP ID.
§ The LDC has received applicable Transaction Status codes in the
Universal SDP ID Assignment Response detail records for all conditions.
§ The LDC has received Report IR01: Universal SDP ID Assignment
Request Summary Exception Report via File Transfer Services (FTS).
2.1.6 Assumptions – Version 00

§ The LDC will ensure that Universal SDP IDs are being requested only for
SDPs that are or will be associated with Smart Meters.
2.1.7 Frequency and Timing – Version 00

Frequency: A Universal SDP ID Assignment Request File may be sent at any time by
the LDC.
Timing: The Universal SDP ID Assignment Request File is processed by the EnergyIP
application upon receipt by the ‘USDP Assignment’ shell script – a scheduled job
configured to run every 15 minutes daily.
2.1.8 File Format – Version 00

2.1.8.1 Universal SDP ID Assignment Request File
2.1.8.1.1 File Name Record for the Universal SDP ID Assignment Request File
The first record in this interface file is used to store the name of the file as specified in
Section 1.8. This record is used in the event that the original file name is modified
during the transfer between the MDM/R and an Organization.
The first record of the interface file contains the following three elements:
Table 2.1.1 File Name Record for the Universal SDP ID Assignment Request File
Field Name Data Type/Length Format Required Description

Prefix Char (7) Specific Y This field always contains the record
Usage: type “<FTSFN>”
<FTSFN>
File Name Varchar (250) Refer to Y This field contains the name of the
Section 1.8 file on the originating system, as
defined in Section 1.8
Suffix Char (8) Specific Y This field always contains the record
Usage: type “</FTSFN>”
</FTSFN>
An example of this record for Version 00 would be:

<FTSFN>ORG11111.ORG22222.1000.00.20070214221345.DAT</FTSFN>
NOTE: Please reference Section 1.8.2 for use of file format version number.

2.1.8.1.2 Universal SDP ID Assignment Request File Header Record
The second record will be a header record as described in table 2.1.2.
Table 2.1.2: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD
Data Element Data Type/Length Format Required Comments

Record Type Char(1) General: Y This field indicates that this
A record is a header record. It
Specific: must be ‘H’
H
LDC ID Char (8) General: Y The unique organization
AAAAAAAA identifier assigned to the LDC
Example: during the
registration/enrollment
‘ORG30153’ process.
Request ID Number (8) General: N Populated with an LDC
NNNNNNNN generated identifier for the
request. Used to correlate the
Example:
Universal SDP ID
‘543’ Assignment response with
the request.
Request Date Date/Time yyyyMMddHHmmss Y The date and time the data in
and Time this file was produced.
2.1.8.1.3 Universal SDP ID Assignment Request File Detail Record

The data records start after the header and will contain one line for each request of an
individual Universal SDP ID as defined in table 2.1.3.
Table 2.1.3 UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD

Record Type Char (1) General: Y This field indicates that this
A record is a detail record. It must
be ‘D’
Specific:
D
SDP ID Varchar (50) No format Y Either:
prescribed a) A unique LDC Identifier for a
SDP that will be associated with
a smart meter. If the LDC does
not have a unique value for
each SDP, then one can
potentially be derived (e.g.
potentially combining the LDC
premise # and socket # at that
premise), or
b) An LDC identifier for a virtual
SDP (not any physical SDP but
rather an aggregation other
physical Universal SDP ID’s) for
which a Universal SDP ID
needs to be assigned.

2.1.8.2 Universal SDP ID Assignment Response File
2.1.8.2.1 File Name Record for the Universal SDP ID Assignment Response File
Table 2.1.4 File Name Record for the Universal SDP ID Assignment Response File

<FTSFN>
</FTSFN>

2.1.8.2.2 Universal SDP ID Assignment Response File Header Record

Table 2.1.5 UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD

H
LDC ID Char(8) General: Y The unique organization
Example: during the
‘ORG23153’ registration/enrollment
process.
Response ID Number (8) General: N Populated with the Request
NNNNNNNN ID from the Universal SDP ID
Example: Assignment Request file.
‘543’
Response Time Date/Time yyyyMMddHHmmss Y The date time the data in this
file was produced.
The data records start after the header and will contain one line for each assigned
Universal SDP ID as defined in table 2.1.6. The file will not contain records for SDP
ID’s for which a Universal SDP ID cannot be assigned. The exception report described
in Section 2.1.5 includes these SDP ID’s and the reason for the exception.

2.1.8.2.3 Universal SDP ID Assignment Response File Detail Record
Table 2.1.6 UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD

General:
A This field indicates that this
Record Type Char (1) Y record is a detail record. It must
Specific: be ‘D’
D
A unique LDC Identifier for a

No format SDP that will be associated with
SDP ID Varchar (50) Y
prescribed a smart meter as provided in the
request file.
General:
Universal SDP NNNNNNNN This field is populated with the
Fixed Number (8) Y
ID Example: assigned Universal SDP ID.
‘00037482’
This field is populated with the
transaction status.
General: 00 – Universal SDP ID assigned
successfully
Transaction NN
Fixed Number (2) Y 01 – Invalid LDC ID
Status Example:
02 – Universal SDP ID already
“01” assigned to SDP ID
03 – Incomplete data request as
submitted

(NOTE: For Version 00 Specification see Sections 2.1.1 through 2.1.8)

The purpose of this interface is to process requests from the LDC for Universal Service
Delivery Point Identifiers (Universal SDP IDs) and to return the assigned Universal
SDP IDs to the LDC.
This interface meets a business requirement that a province-wide unique identifier be
made available to the LDC in order to pair it with an LDC-specific Service Delivery
Point ID (SDP ID) and to be able to uniquely identify itself to the MDM/R in future
transactions.
The LDC uses this interface to request one or more Universal SDP IDs at a time.
The LDC sends a Universal SDP ID Assignment Request File with an LDC ID that
uniquely identifies the LDC, along with LDC-generated SDP IDs to which the
corresponding Universal SDP IDs is assigned to through this interface. SDP IDs are
generated by the LDC, and are unique within the LDCs systems. The file version
number for the Universal SDP ID Assignment Request File version 01 remains
unchanged at version “00”.
The Universal SDP ID Assignment Response File is sent back to the LDC with a
Universal SDP ID assigned against every SDP ID in the Universal SDP ID Assignment
Request File. The Universal SDP ID Assignment Response File for version 01 of this
specification adds an End-Of-File (EOF) record and the response file version number
is changed to “01”.
This interface uses the Universal SDP ID Generator features within the MDM/R system
to manage the assignment of Universal SDP IDs.
Universal SDP IDs and SDP IDs are described in detail in Section 3 of the MDM/R
Detailed Design Document, Service Delivery Point.

Universal SDP ID Assignment Request: LDC to the MDM/R
Universal SDP ID Assignment Response: MDM/R to the LDC
files.
The Universal SDP ID Assignment Request File contains all of the information
The Universal SDP ID Assignment Response File contains all of the information
Once the Universal SDP ID Assignment Request File is delivered to the MDM/R (see
Section 11, File Transfer Services of the MDM/R Detailed Design) the Universal SDP
ID Assignment process will process the request file and generate the response file.

1. Universal SDP IDs will not be assigned for an invalid LDC ID. An LDC ID is
invalid if it is not recognized by the MDM/R, or if the LDC ID has originated from
a directory belonging to a different LDC.
2. If any record in the Universal SDP ID Assignment Request File includes an
SDP ID which has already been recorded as receiving a Universal SDP ID, a
Universal SDP ID is not assigned.
3. For each valid Universal SDP ID request, the Universal SDP ID Generator:
a. Assigns the next available Universal SDP ID to the LDC and
associates this Universal SDP ID with the SDP ID.
b. Includes the Universal SDP ID in the response.
4. The interface creates a Universal SDP ID Assignment Response File and
includes records for those SDP IDs that have a Universal SDP ID assigned.
The response will also include records for requests that did not receive a
Universal SDP ID assignment and the reason for such exceptions. This file is
placed in the designated storage location for the File Transfer Services to
transfer to the LDC. The Universal SDP ID Assignment Request File is
moved to the processed directory in the MDM/R.
a. The MDM/R Universal SDP ID Assignment Adapter detects
exceptions in regards to invalid file format and data type exceptions.
c. The MDM/R detects exceptions when the SDP ID has had a
Universal SDP ID previously assigned.
d. The MDM/R detects exceptions when the file contains LDC Identifier
values that do not correspond to the LDC Identifier that the file was
received from.
6. The following exception report is created:
§ The Universal SDP ID Assignment Request Summary Exception
Report has control totals such as number of records read, processed
and rejected (Refer to Report IR01 in Section 2.4.1 of the MDM/R
The interface creates an exception report and places it in the designated storage
location for File Transfer Services (FTS) transfer to the LDC.

§ The LDC includes a SDP ID for each Universal SDP ID request.


§ The LDC has a valid Universal SDP ID assigned for each SDP ID.
§ The LDC has received applicable Transaction Status codes in the
Universal SDP ID Assignment Response detail records for all conditions.
§ The LDC has received Report IR01: Universal SDP ID Assignment
Request Summary Exception Report via File Transfer Services (FTS).

§ The LDC will ensure that Universal SDP IDs are being requested only for

Frequency: A Universal SDP ID Assignment Request File may be sent at any time by
the LDC.
Timing: The Universal SDP ID Assignment Request File is processed by the EnergyIP
application upon receipt by the ‘USDP Assignment’ shell script – a scheduled job
configured to run every 15 minutes daily.
2.1.16 File Format – Version 01

2.1.16.1 Universal SDP ID Assignment Request File – Version 01
2.1.16.1.1 File Name Record for the Universal SDP ID Assignment Request File
Table 2.1.7 File Name Record for the Universal SDP ID Assignment Request File

<FTSFN>
</FTSFN>

2.1.16.1.2 Universal SDP ID Assignment Request File Header Record


Table 2.1.8: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD

H
LDC ID Char (8) General: Y The unique organization
Example: during the
process.
Request ID Number (8) General: N Populated with an LDC
NNNNNNNN generated identifier for the
Example: request. Used to correlate the
‘543’ Universal SDP ID
Assignment response with
the request.
Request Date Date/Time yyyyMMddHHmmss Y The date and time the data in
and Time this file was produced.
2.1.16.1.3 Universal SDP ID Assignment Request File Detail Record

The data records start after the header and will contain one line for each request of an
individual Universal SDP ID as defined in table 2.1.9.
Table 2.1.9 UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD

Record Type Char (1) General: Y This field indicates that this
A record is a detail record. It must
D
SDP ID Varchar (50) No format Y Either:
prescribed a) A unique LDC Identifier for a
SDP that will be associated with
a smart meter. If the LDC does
not have a unique value for
each SDP, then one can
potentially be derived (e.g.
potentially combining the LDC
premise # and socket # at that
premise), or
b) An LDC identifier for a virtual
SDP (not any physical SDP but
rather an aggregation other
physical Universal SDP ID’s) for
which a Universal SDP ID
needs to be assigned.
2.1.16.2 Universal SDP ID Assignment Response File – Version 01
2.1.16.2.1 File Name Record for the Universal SDP ID Assignment Response File

Table 2.1.10 File Name Record for the Universal SDP ID Assignment Response File

<FTSFN>
</FTSFN>

2.1.16.2.2 Universal SDP ID Assignment Response File Header Record

Table 2.1.11 UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD

A record is a header record.
Specific usage: Value must be ‘H’
H
Example: during the
process.
Example: Assignment Request file.
‘543’
file was produced.
The data records start after the header and will contain one line for each assigned
Universal SDP ID as defined in table 2.1.12. The file will not contain records for SDP
ID’s for which a Universal SDP ID cannot be assigned. The exception report described
in Section 2.1.13 includes these SDP ID’s and the reason for the exception.
2.1.16.2.3 Universal SDP ID Assignment Response File Detail Record

Table 2.1.12 UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD

General:
This field indicates that this
A
Record Type Char (1) Y record is a detail record. It must
D

A unique LDC Identifier for a
No format SDP that will be associated with
SDP ID Varchar (50) Y
prescribed a smart meter as provided in the
request file.
General:
Universal SDP NNNNNNNN This field is populated with the
Fixed Number (8) Y
ID Example: assigned Universal SDP ID.
‘00037482’
This field is populated with the
transaction status.
General: 00 – Universal SDP ID assigned
successfully
Transaction NN
Fixed Number (2) Y 01 – Invalid LDC ID
Status Example:
02 – Universal SDP ID already
“01” assigned to SDP ID
03 – Incomplete data request as
submitted
2.1.16.2.4 Universal SDP ID Assignment Response File EOF Record

The last record in the response file will be an End of File (EOF) record as described in
table 2.1.13. Other than the Record Type being set to ‘E’, the remaining fields in this
record will contain the same values as found in the header record of the file.
Table 2.1.13 UNIVERSAL SDP ID ASSIGNMENT RESPONSE EOF RECORD

A record is the last or end-of-file
record of the response file.
Specific usage:
Value must be ‘E’
E
during the
Example:
registration/enrollment
‘ORG23153’ process.
Assignment Request file.
Example:
‘543’
file was produced.

2.2 Periodic Audit Synchronization Interface
SDP attributes can be updated through the Periodic Audit Synchronization Interface, or
the Incremental synchronization Interface. The purpose of the Periodic Audit
Synchronization interface is to process a complete synchronization of the MDM/R
Master Directory (MMD) with the LDC data source(s).
This interface is used by LDC’s to:
§ “Create” Service Delivery Point (SDP) objects in the MDM/R. This is a one-
time activity to be completed for every new Universal SDP ID that has
already been “assigned” by the Universal SDP ID Assignment
Request/Response Interface.
§ Update SDP attributes for SDPs that already exist in the MDM/R Master
Directory.
§ Initialize the MDM/R Master Directory with SDP and all related data
attributes and relationships. This is a one-time process to support the initial
data load during LDC Enrollment.
The synchronization ensures that all SDP and associated data attributes and
relationships are current with the LDC data source(s). The synchronization process
compares the MDM/R Master Directory data with the Periodic Audit Synchronization
file, overwrites SDP attributes and relationships in the MDM/R Master Directory
assuming the Periodic Audit Synchronization File to be the master, and reports
updates.
The Periodic Audit Synchronization File must contain a record from the LDCs source
system for each SDP that has either already been created in the MDM/R Master
Directory or is to be created. If an SDP that has already been created in the MDM/R
Master Directory is not included in the Periodic Audit Synchronization File, it is set to
inactive in the MDM/R.
The handling of interface files through the initial file checks is described in Section 11
of the MDM/R Detailed Design Document, File Transfer Services.
Section 4 of the MDM/R Detailed Design Document, MDM/R Master Data
Synchronization discusses both Periodic Audit and Incremental Synchronization.

LDC to the MDM/R
files.
The Periodic Audit Synchronization consists of a set of seven files, as follows:
§ File No. 00 – A Manifest File, listing each file that is included in the specific
Periodic Audit Synchronization data set submission.

§ File No. 01 – One or more Asset Data Files that describes the primary
attributes associated with an SDP, a Meter, and a Communication Module
§ File No. 02 – One or more Premise Data Files that describes the premise
related attributes (e.g. physical address) associated with an SDP
§ File No. 03 – One or more Service Agreement Data Files that describe the
Framing Structure and Commodity Type associated with an SDP
§ File No. 04 – One or more Parameter Data Files that describes additional
attributes of an SDP or a Meter.
§ File No. 05 – One or more Relationship Data Files that describes the
relationship between two assets or an asset and an organization.
§ File No. 06 – Not Used
(NOTE: The Meter Read Data file has been eliminated from the Version 01
Periodic Audit Synchronization file set. File Number 06 should not be
submitted, and if submitted will not be processed by the MDM/R. First and
last register readings can be submitted using the Meter Read Interface.)
§ File No. 07 – One or more Component SDP Data Files that describes
‘Channel to Channel’ and ‘Channel to Formula’ relationships between
virtual and physical SDPs for all existing and new Virtual Service Delivery
Points.
For Periodic Audit Synchronization Version 01, File Numbers 00, 01, 02, 03, 04 and 05
are mandatory and must be submitted as part of the sync file set. Periodic Audit
Synchronization Detail Records are required for each SDP that has either already been
created in the MDM/R or is to be created (reference TIS Section 2.2.1). The data
contained in the Periodic Audit Synchronization file set must represent a consistent
data set for each SDP.
In order to allow for the efficient transmission of Synchronization data file sets,
synchronization data files can be split or segmented into multiple smaller files. All
records in a segmented file must be complete. File segmentation can only be between
complete records. Partial records will result in exceptions. For example, an LDC
submitting 1000 records for an Asset Data File could submit a single file with 1000
records, or 10 files with 100 records. These file segments must be appropriately
named (as described in Section 1.8.3 of this document) and the name of each file
submitted in the single Manifest File for the synchronization submission.
The Staging Table Loader (STL) will process each segmented file as submitted in the
Manifest File for Periodic Audit Synchronization Version 01. The segment numbers of
any one file of the file set must include the value 01 but may have gaps and do not
need to be sequential. The STL does load the data for each of the mandatory files of
the sync file set (i.e. files 01, 02, 03, 04 and 05) in a particular order but does not
consider order when loading the data from any one segmented file. A file sent as one
segment must have the SEGMENT_NO value set to 01.
The Incomplete Synchronization File Set Report informs the LDC that their
synchronization file set was not accepted by the MDM/R, The following cases would
result in this condition:
• All files for a particular synchronization file set have not been received after an
allowed length of time and has been rejected;
• The synchronization file set was received out of sequence and is being held,
awaiting for the missing synchronization file set(s) to be submitted;

• The synchronization file set was received out of sequence, the missing
synchronization file set(s) have not been received after an allowed length of
time, and the file set has been rejected.
The Synchronization Staging Table Loader Exception Report provides exceptions for
problems encountered during the staging table loading process which precedes the
synchronization process. Any errors encountered other than errors designated as
“Warning” in the report will result in the termination of the loading of the
synchronization files.
2.2.2.3 Synchronization File Set Sequencing

The “Sequence Number” provided as a mandatory element in the Manifest File Header
Record defines the processing sequence for both Version 01 Periodic Audit
Synchronization and Version 00 Incremental Synchronization file sets. Thus the
“Sequence Number” must be incremented by the LDC for any Periodic or Incremental
file set transmission in the sequence that the LDC intends each Periodic Audit
Synchronization Version 01 and Incremental Synchronization Version 00 file set to be
processed.
The Extracted Date Time of each sequential synchronization file set must be greater
than or equal to the maximum Extracted Date Time from all previously submitted and
successfully processed synchronization file sets. The Extracted Date Time must be
the same in each file of the same synchronization file set.
Periodic and Incremental Synchronization file sets will be processed in numeric
sequence. In the event that an LDC requires a Periodic or Incremental synchronization
file set to be processed out of sequence (that is, process a synchronization file set that
is not the next file set in sequence), the LDC must communicate to the MDM/R
Operator the Sequence Number (i.e. the value of the “Sequence Number” field in the
Manifest File Header Record) of that synchronization file set. The MDM/R Operator
will manually set the Sequence Number in the MDM/R. Once this is completed, the
LDC can submit the synchronization file set.
NOTE: Once the MDM/R operator manually sets the new Sequence Number, the LDC
cannot submit a synchronization file set with a Sequence Number less than the new
Sequence Number. If the LDC requires a synchronization file set to be processed with
a Sequence Number less than the new Sequence Number, the LDC must follow the
same process described above. For example, if the most recent Sequence Number is
003726 and the LDC requires that the next synchronization file set to be processed is
003744, the LDC must provide this Sequence Number to the MDM/R Operator. The
MDM/R Operator will change the last Sequence Number provided to the MDM/R from
003726 to 003743. When this is done, the LDC would be able to submit the next
synchronization file set with the Sequence Number 003744. However, the LDC would
not be able to submit synchronization file sets with Sequence Numbers 003727
through 003743 unless they follow the same process to reset the sequence number.
The synchronization file set Sequence Number will be updated by the MDM/R upon
successful completion of the synchronization process. In the event that the
synchronization process (e.g.: file set reported on IR10, file set reported on IR14 as not
successfully loaded, or threshold checks are exceeded) does not complete
successfully the synchronization file set Sequence Number will not be updated by the
MDM/R.

1. Periodic Audit Synchronization supports the submission of records providing
the current and future state attribute values describing assets and related
attributes.
a. With the deployment of EnergyIP Release 6.1+, Periodic Audit
Synchronization supports the submission of current and future state
attribute values. The Asset Data File and Premise Data File includes
one record per asset and premise. The Service Agreement Data File,
Parameter Data File, Relationship Data File, and Component SDP
Data File can contain multiple records that describe the current state
or current and future state of attribute values related to the provided
assets. The record provided must only describe the current in effect
record (i.e.: the record must have a start date and no end date
associated with it) or the current in effect record (i.e.: the record must
have a start date and a future end date associated with it) plus a
record that will take effect in the future (i.e.: the record must have a
future start date and no end date associated with it). Use of end
dates prior to the Extracted Date/Time of the synchronization file set
is NOT supported in Periodic Audit Synchronization, as Periodic Audit
Synchronization is a point in time snapshot.
2. Where an asset or premise exists in the MDM/R and no record is provided in
the Periodic Audit Synchronization for that asset or premise then the asset or
premise that existed within the MDM/R will be inactivated.
Where an service agreement, parameter or relationship exists in the MDM/R

and no record is provided in the Periodic Audit Synchronization for that
service agreement, parameter or relationship, then the service agreement,
parameter or relationship that existed within the MDM/R will be ended with an
end date/time equal to the Extracted Date/Time of the synchronization file set
submitted in the synchronization process.
3. Where a new attribute value with a start date/time prior to the Extracted
Date/Time in the header records of the synchronization files is submitted via
Periodic Audit Synchronization, the currently in effect attribute value will be
inactivated with an end date/time equal to the submitted start date/time of the
new attribute value.
a. With the deployment of EnergyIP Release 6.1+, a new attribute value
with a start date/time greater than the Extracted Date/Time of the
synchronization file set can also be submitted via Periodic Audit
Synchronization. This future state record may have an end date/time
that is greater than its start date time or have no end date/time. If
there is a currently in effect attribute value then it must be provided
with an end date/time equal or less than the start date/time of the new
submitted future state attribute value.
b. The new attribute value start date/time must be greater than or equal
to the existing in-effect attribute value start date/time
4. Where the end date of the previous attribute value needs to be prior to the
start date of the current relationship for business purposes (e.g. a period of
time in which no meter or no account is associated with an SDP), the

Incremental Synchronization interface must be used to submit the end date
transaction.
5. Three threshold checks are conducted to determine the number of updates.1
Thresholds for these checks are defined with the LDC during Enrollment but
may be updated based upon operational and business requirements. These
three checks are performed sequentially. Checks 1 and 2 are performed
prior to making any updates to the MMD. If either of these checks fail, no
updates to the MMD will be made. Check 3 is performed during the
synchronization process. Failure of check 3 allows for MMD updates to be
made up to the point in the synchronization process at which the check fails
but terminates the synchronization process preventing further MMD updates.
The three checks are:
Critical Tables Check – Check 1
Upon submission of the synchronization file set the synchronization staging
tables will be populated based on the information contained in the
synchronization files. Once the synchronization staging tables have been
populated, a check will be performed to ensure that there is at least 1 record
in each of a sub-set of the synchronization staging tables. The selection of
synchronization staging tables used for this check is configured globally.
If each synchronization staging table used for the Critical Tables Check does
not contain at least one record, this check has failed. Failure of Check 1 will
result in the following:
• Termination of the synchronization process and creation of a system
error notification to the OSP. Notification of the failure is not captured in
any of the MDM/R reports provided to the LDC. The OSP will initiate
communication of the failure through the Service Management process.
• No updates will be made to the MMD.
Validate Minimum Records Percentage – Check 2
The number of records populated in a larger set of the synchronization
staging tables as the result of the current synchronization is compared to the
number of records populated in the same set of synchronization staging
tables from the previous synchronization. The selection of synchronization
staging tables used for this check is configured globally. The defined
threshold percentage used for the Validate Minimum Records Percentage
Check is configured for each LDC and applies to all selected tables.
The comparison is performed on each synchronization staging table and if
the difference is less than a defined percentage on any table, this check has
failed. The same configured percentage is used on each table. For example,
if this threshold is set to 60% and in the previous synchronization there were
10 records, then synchronization will abort if the current synchronization
contains less than 6 records in the same synchronization staging table. This
check is to prevent erroneously inactivating a large number of SDPs by
inadvertently submitting partial files. Failure of this check will result in the
following:
1
These threshold checks are disabled during initial loading of the synchronization and initial testing.

any of the MDM/R reports provided to the MDM/R service recipient. The
OSP will initiate communication of the failure through the Service
Management process.
• No updates will be made to the MMD.
Max Compare_Max Publish – Check 3
This check is performed during the synchronization process on an expanded
set of the synchronization staging tables. For each table, the synchronization
process performs a ‘compare’ to determine the required updates and then
performs a ‘publish’ to make the required updates to the database. The
‘compare’ and ‘publish’ steps are performed sequentially on each table.
Some tables will require these steps to be performed multiple times. For
each table this check is performed in two parts:
a. Max Compare Failure – During the compare, the number of updates
required is compared to a defined value. If the number of updates
exceeds this value this check has failed, the synchronization process
is terminated, and no updates will be published for the affected
compare step. All updates published for previous tables will not be
reversed in the MMD.
b. Max Publish Failure – During the publish the number of exceptions
incurred is compared to a defined value. If the number of exceptions
exceeds this value this check has failed at the table for which its
defined value was exceeded, and the synchronization process will
terminate. All updates previously published on the affected publish
step and all updates published on prior tables will not be reversed in
the MMD.
The defined values used for the Max Compare Failure and the Max Publish
Failure are configured for each table for each LDC. Failure of either check
will result in the following:
any of the MDM/R reports provided to the LDC. The OSP will initiate
communication of the failure through the Service Management process.
• The MMD updates performed and exceptions incurred prior to the failure
of the check will be returned in the IR06 and IR07 reports.
6. For SDPs that exist in the MDM/R Master Directory data and in the Periodic
Audit Synchronization File set, the MDM/R compares and updates the
existing SDP attributes in the MDM/R for which changes have been detected
with the respective attributes and relationships provided for the SDPs in the
Periodic Audit Synchronization File set.
7. For SDPs that do not exist in the MDM/R Master Directory Data but are in the
Periodic Audit Synchronization File with valid LDC ID, SDP ID and an
assigned Universal SDP ID, the MDM/R Master Directory data creates the
SDP and associates any parameters, service agreements, and relationships
that are provided in the Periodic Audit Synchronization File set.

8. The processed Periodic Audit Synchronization File sent by the LDC is placed
in the Processed Directory in the MDM/R, which is an internal EnergyIP
directory.
a. The MDM/R Synchronization Adapter detects exceptions in regards
to invalid pipe (|) delimited file formats and data type errors.
b. The MDM/R detects exceptions when the LDC Identifier or Universal
SDP ID values are not known by the system.
c. The MDM/R detects exceptions when, in the file, the Universal SDP
ID is associated with an LDC Identifier and SDP ID for which that
Universal SDP ID was not originally assigned.
d. The MDM/R detects exceptions when a synchronization file does not
contain data in a field that is required.
e. The MDM/R detect exceptions when an asset (SDP ID, Meter ID, or
AMCD ID) is provided in the Relationship Data file that does not exist
in the MDM/R or in the submitted synchronization file set.
f. The MDM/R detects exceptions when a virtual SDP (Type field = ‘V’
in the Asset Data File) is related to either a physical Meter or a CT/PT
Multiplier.
g. The MDM/R detects exceptions when either of the following are true
without the Relationship Start and End Dates being mutually
exclusive:
i. Multiple Meters are associated to a given SDP
ii. Multiple Accounts are associated to a given SDP
iii. Multiple CT/PT Multipliers are associated to a given SDP
iv. Multiple Framing Structures are associated to a given SDP
v. Multiple VEE Services are associated to a given SDP
vi. Multiple AMI Operators are associated to a given SDP
vii. Multiple Billing Agents are associated to a given SDP
viii. Multiple Energy Service providers are associated to a given
SDP
10. Update and exception reports for the Periodic Audit Synchronization are
created with the following detail:
§ The Synchronization Updates Report provides a complete listing of
the records that were updated via the Periodic Audit Synchronization
process. (Reference Report IR06 in Sections 2.4.6 and 2.4.7 of the
MDM/R Reports Technical Specifications).
§ The Synchronization Exception Report provides a complete listing of
the records that were not updated via the Periodic Audit
Synchronization process because an error occurred. (Reference
Report IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports
Technical Specifications).

The interface creates the updates and exception reports and places them in
the designated storage location for the File Transfer Services (FTS) transfer
to the LDC.
Rules Affecting Future and Retroactive Dating

The data contained in the synchronization file set represent the condition of the master
data in LDC’s source system(s) at a point in time. This point in time is identified in the
header records of the synchronization file set as the Extracted Date Time. This is the
date and time that the data in the synchronization file set was extracted from the
source system(s). This time will likely be coincident with the time that the files were
created.
With the deployment of EnergyIP Release 6.1+, the synchronization file set’s Extracted
Date Time will provide the point in time against which all transactions are evaluated to
determine if such transactions are intended to make changes in the past or in the
future. Periodic Audit Synchronization will only support the submission of Current
State and Future State attribute values. Incremental Synchronization must be used for
Prior State attribute value changes and/or corrections. Incremental Synchronization
supports the Current State, Future State and Retroactive Date synchronization
functionality.
Date effective changes are generally state changes related to three specific periods of
time, namely Future State, Current State, and Prior State. Three types of value and/or
date related changes/corrections can be accomplished using the synchronization
process. These are:
§ Future State Value Changes – where the new attribute value is being
supplied with a Start Date/Time that is after the Extracted Date Time. The
Current State attribute value (i.e. the value currently in effect) is also
supplied with its existing Start Date/Time and an End Date/Time that
precedes or aligns with the Start Date/Time of the Future Date attribute
value. The future dated attributes are not considered to be in effect until
the future dated attribute value Start Date/Time has been reached.
§ Current State Value Changes – where the new attribute value is being
supplied with a Start Date/Time that is equal to or after the Start Date/Time
of the existing attribute value (i.e. the value currently in effect) in the MMD
but starts before the Extracted Date Time provided in the synchronization
file set. Once processed, the new attribute value would become the
Current State attribute value with no End Date/Time and the previous
attribute value is ended with an End Date/Time equal to the Start
Date/Time of the supplied new attribute value.
§ Prior State Value and/or Date Corrections – where a series of attribute
values are being supplied with start date/times that are before the Current
State attribute value (i.e. the value currently in effect) already in the MMD
and start before the Extracted Date Time provided in the synchronization
file set. The processing of the new attribute values and dates is intended
to:
o Correct Prior State Values – where previously submitted attribute
values are being corrected but the dates over which these values were
effective is remaining unchanged, or

o Correct Prior State Dates – where previously submitted attribute values
are remaining unchanged (both value and order over time) but the
dates over which they were effective is being corrected, or
o Correct Prior State Value and Date – where both the previously
submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules
11. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync
V00.
12. The Future Dated Value Change must provide the Current State attribute
value that is currently in effect as well as the attribute value that will start at a
future date/time.
a. The Current State attribute value Start Date/Time must be earlier than the
Extracted Date Time.
b. The Current State attribute value End Date/Time must be later than the
Extracted Date Time, and
c. The Current State attribute value End Date/Time must be earlier or equal
to the Start Date/Time of the Future Date attribute value.
d. If there is not a currently in effect attribute value the Future Date attribute
value may be provided alone.
13. Subsequent synchronization file set submissions must include the Future
Dated Value Change until it becomes the Current State for that attribute
value.
a. All subsequent P-Sync V01 submissions must include the pair of records
until the Future Dated attribute value becomes the Current State attribute
value (currently in effect).
b. If the Future Dated attribute value is not provided in a subsequent P-Sync
V01 submission then the future dated attribute value will be dropped from
the MMD.
c. Subsequent I-Sync V00 submissions only need to provide the pair of
Future Dated Value Change records if there is a need to change the
contents or effective dates of the Future Dated Value Change records.
Current State Value Change Business Rules
14. Current State Value Changes can be submitted using P-Sync V01 and I-Sync
V00.
15. To end the Current State attribute value (i.e. the value currently in effect) and
start a new Attribute value (to become the value currently in effect):
a. The P-Sync records may provide the new attribute value with a Start
Date/Time that equals or is after the Start Date/Time of the existing
attribute value.
b. The Periodic Audit Synchronization process will end date the existing
attribute value with an End Date/Time equal to the Start Date/Time of the
new attribute in accordance with Business Rule No. 3.

NOT start a new attribute value
a. The Incremental Synchronization process must be used to end an
existing attribute value in accordance with Business Rule No. 1.
Prior State Value and/or Date Corrections Business Rules
Prior State Value and/or Date Corrections can ONLY be submitted using the
Incremental Synchronization process in accordance with Business Rule No. 4.

§ The LDC has requested and has been assigned a Universal SDP ID for
each SDP in the Periodic Audit Synchronization File.

§ Should the transmission of the synchronization file set be incomplete for
more than the allowed length of time the LDC has received the Incomplete
Synchronization File Set report.
§ The LDC has received the Synchronization Staging Table Loader
Exception Report.
§ SDPs, associated attributes, and relationships are fully aligned in EnergyIP
with data supplied from LDC data sources.
§ The LDC has received the updates report and the exception Reports
outlined in Section 2.2.3 via File Transfer Services.

§ Information in the Periodic Audit Synchronization File set will only be for
§ With the synchronization file set above, it may be defined that multiple
Measurements can be associated to a given Meter (if that meter is a multi-
channel meter), multiple Interested Parties roles can be associated to a
given SDP, and multiple SDPs can be related to a single account.
§ With the synchronization file set, it may be defined that multiple Accounts
can be related to a given SDP, multiple Meters can be related to a given
SDP, multiple CT/PT Multipliers can be associated to a given SDP, multiple
Framing Structures can be associated to a given SDP, multiple VEE
services can be associated to a given SDP, multiple AMI operators can be
related to a given SDP, and multiple Billing Agents can be related to a
given SDP. These relationships and associations must have mutually
exclusive start and end dates (please refer to Business Rule 1.a).

Frequency: The Periodic Audit Synchronization File may be sent as frequently as once
per day. The frequency of this synchronization process will be determined jointly
between the MDM/R operator and the LDC based on the LDC’s experience in keeping
their master data consistent.
Timing: To Be Determined
2.2.8 File Format – Periodic Audit Synchronization Version 01 and

Incremental Synchronization Version 00
2.2.8.1 Manifest File
2.2.8.1.1 File Name Record for the Manifest File

Table 2.2.1 FILE NAME RECORD FOR THE MANIFEST FILE

<FTSFN>
</FTSFN>
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcedf.00.01.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.00.01.DAT</FTSFN>
2.2.8.1.2 Manifest File Header Record

The second record will be a header record as described in table 2.2.2:
Table 2.2.2 MANIFEST FILE HEADER RECORD
Data P Sync V01 I Sync V00

Field Format Description
Type/Length Required Required
Record Char (1) General: Y Y This field indicates that this
Type A record is a header record. It
H

LDC ID Char (8) General: Y Y The unique Organization
Example: during the
process.
Process Varchar General: Y Y Populated with
Mode (20) AAAAAAAAAAAAA “PeriodicAuditSync” or
Specific Usage: “IncrementalSync”
‘PeriodicAuditSync’ or
‘IncrementalSync’
Process Char General: Y Y Always populated with
Object (20) AAAAAAAAAAAAAA “Manifest”
A
Specific Usage:
‘Manifest’
Extracted Date/Time yyyyMMddHHmmss Y Y The date and time the data in
Date Time this synchronization file set
was extracted from the
source systems. This maybe
coincident with the time that
the creation of this
synchronization file set was
started.
Sequence Number (6) General: Y Y This mandatory element is a
Number AAAAAA fixed 6 digit value that defines
a sequence for Periodic and
Incremental synchronization
Examples:
file sets. If an LDC submits a
000001
sequence number that is not
007353 the next sequential number,
999999 the file set will not be
processed
The value that is placed in
this element will begin with
000001 and increment by 1
with every new Periodic Audit
Synchronization file set or
Incremental Synchronization
file set. In the event that the
maximum value is reached
(999999) then the number will
reset to 000001.
2.2.8.1.3 Manifest File Detail Record

The Manifest File Detail Record provides a complete list of all of the files that are part
of a single synchronization file set. At a minimum, this file must contain one of each
file (including the manifest file itself), as defined in Section 1.8.3. If multiple files of the
same type are submitted, then all of those file names must be provided in the manifest
file.
Table 2.2.3 MANIFEST FILE DETAIL RECORD

Filename Varchar (250) Y Y This is the full file name of each
synchronization file being submitted as part
of the synchronization file set, as described
in section 1.8 of this document.

2.2.8.2 Asset Data File
2.2.8.2.1 File Name Record for the Asset Data File

Table 2.2.4 FILE NAME RECORD FOR THE ASSET DATA FILE

<FTSFN>
</FTSFN>
be:
or
2.2.8.2.2 Asset Data File Header Record

Table 2.2.5 ASSET DATA FILE HEADER RECORD

Record Char (1) General; Y This field indicates that
Type A this record is a header
Specific: record. It must be ‘H’
H
LDC ID Char (8) General: Y The unique
AAAAAAAA Organization identifier
Example: assigned to the LDC
File Name
‘ORG25153’ during the
Record and registration/enrollment
Header
process.
Record are
Process Varchar General: Y required Populated with
Mode (20) AAAAAAAAAAAAA whether or not “PeriodicAuditSync” or
Specific Usage: Detail Record “IncrementalSync”
‘PeriodicAuditSync’ data are
or ‘IncrementalSync’ required.

Process Char General: Y Always populated with
Object (20) AAAAAAAAAAAAA Please refer to “Asset”
AA Section 2.3.10
Specific Usage: for Files and
‘Asset’ Detail data
Fields
Extracted Date/Time yyyyMMddHHmmss Y required for The date and time the
Date Time each Business data in this
Scenario. synchronization file set
source systems. This
maybe coincident with
the time that the
creation of this
synchronization file set
was started.
2.2.8.2.3 Asset Data File Detail Record

The Asset Data File allows the LDC (or its designated agents) to create various assets
within the MDM/R. The following are the different types of assets that are available
within the MDM/R:
• SDP
• Meter
• Communication module
Table 2.2.6 ASSET DATA FILE DETAIL RECORD

Record Varchar (50) General: Y This field indicates the type of record
Indicator AAAAAAAA being submitted.
Specific Usage: Acceptable values for Periodic Audit
One of the Sync and Incremental Synchronization
following are:
‘SDP’ SDP
‘Meter’ Meter
‘Communication Communication Module
Module’
Universal Fixed Number General: If Record The Ontario-wide unique identifier
SDP ID (8) NNNNNNNN Indicator is assigned by the Universal SDP ID
Example: “SDP”, then Y Assignment Request/Response
‘00037482’ If Record integration.
Indicator is This field will only be populated if the
not “SDP”, Record Indicator field is populated with
then N “SDP”
SDP ID Varchar (50) No format If Record This identifier is maintained in the LDC
prescribed Indicator is systems and uniquely identifies the
“SDP”, then Y Please refer SDP
If Record to Section This field will only be populated if the
Indicator is 2.3.10 for Record Indicator field is populated with
not “SDP”, Files and “SDP”
then N Detail data
Type Varchar (50) General: If Record Fields For SDPs, this indicates whether this is
A Indicator is required for a physical or virtual service delivery
“SDP” or each point. ‘P’ is for physical. ‘V’ is for virtual.
Specific Usage: Business
“Meter”, then For Meters, this indicates whether this
ONE of the Scenario.
Y is a physical or virtual Meter. ‘P’ is for

following If Record physical. ‘V’ is for virtual.
characters, ‘P’ Indicator is This field will only be populated if the
or ‘V’ not “SDP” or Record Indicator field is populated with
“Meter”, then “SDP” or “Meter”
N
Service Varchar (50) General: If Record Flag indicates whether electric service
Status A Indicator is is connected to the Service Delivery
Specific Usage: “SDP”, then Y Point (i.e. wires leading to the meter
ONE of the If Record have been disconnected)
following Indicator is This field will only be populated if the
characters, ‘Y’ not “SDP”, Record Indicator field is populated with
or ‘N’. If Type = then N “SDP”
‘V’ for a virtual
meter, then field
must be ‘Y’.
Load Varchar (50) General: If Record Flag indicates whether electric service
Status A Indicator is is available to the Customer (e.g.
Specific Usage: “SDP”, then Y whether the meter is booted/sleeved or
If Record not)
ONE of the
following Indicator is This field will only be populated if the
characters, ‘Y’ not “SDP”, Record Indicator field is populated with
or ‘N’. If Type = then N “SDP”
‘V’ for a virtual
meter, then field
must be ‘Y’.
Meter ID Varchar (50) No format If Record This is an identifier of the installed
prescribed Indicator is meter and must be unique within an
“Meter”, then LDC
Y This field will only be populated if the
If Record Record Indicator field is populated with
Indicator is “Meter”
not “Meter”,
then N
AMCD Varchar (50) No format If Record This is the LDC’s unique identifier for
ID prescribed Indicator is the AMCD. This is the ID that is used
“Communicati as a key for the integration between the
on Module”, Please refer MDM/R and AMCC. Depending on the
then Y to Section AMI technology this may be, for
If Record 2.3.10 for example, the Meter ID above, the
Indicator is Files and Meters Serial Number or the ID of the
not Detail data smart meters communication module.
“Communicati Fields See the Meter Read Integrations
on Module”, required for section per AMCC vendor for
then N each information of what to populate in this
Business field
Scenario. This field will only be populated if the
Record Indicator field is populated with
“Communication Module”
AMCC Varchar (50) General: If Record This is the type of AMI technology
Type AA Indicator is utilized for this meter. Acceptable
Specific Usage: “Communicati values are
on Module”, ‘01’ is for Elster
ONE of the
then Y
following ‘01’, ‘02’ is for Sensus
‘02’, ‘03’, ‘04’, If Record
‘03’ is for Trilliant
or ‘05’ Indicator is
not ‘04’ is for Tantalus
“Communicati ‘05’ is for SmartSynch
on Module”, This field will only be populated if the
then N Record Indicator field is populated with
“Communication Module”
Interval Number (3) General: If Record This field is populated with the length of

Length NNN Indicator is the interval in minutes that will be
Example: “Meter”, then delivered from the meter that is related
‘60’ Y to the SDP.
If Record The “SDP to Meter Relationship” Start
Indicator is Date Time and End Date Time will be
not “Meter”, used in the Meter to Channel
then N Relationships, Channel to Channel
Relationships and Channel Parameters
(for derived channels).
Channel Number (2) General: If Record This is the set identifier that will be used
Configur NN Indicator is to control the creation of information
ation Set Specific Usage: “Meter”, then channels into which Meter Read Data
Y and related derived data will be stored.
One of the
following If Record The “SDP to Meter Relationship” Start
Indicator is Date Time and End Date Time will be
‘01’
not “Meter”, used in the Meter to Channel
‘02’ then N Relationships, Channel to Channel
‘03’ Relationships and Channel Parameters
‘04’ (for derived channels).
Please refer
‘05’ to Section NOTE: The synchronization process
‘06’ 2.3.10 for will use valid values provided in the
Files and Asset Data File. If a value is not
Detail data provided then a default value of ‘01’ will
Fields be created. Please refer to Section
required for 2.2.10 – Channel Configuration Sets.
Scaling Number (20,10) General: If Record each This is the factor that will be used to
Constant NNNNN.NN Indicator is Business multiply the Register Readings received
Examples: “Meter”, then Scenario. as part of the Meter Transfer Block.
‘1’, ‘100’, Y The “Meter to Comm Module
‘130.33’ and If Record Relationship” Start Date Time and End
‘99999.99’ Indicator is Date Time will be used for this Meter
not “Meter”, Parameter
then N NOTE: The synchronization process
will use valid values provided in the
Asset Data File. If a value is not
provided then a default value of ‘1.00’
will be created for this Meter parameter.
Asset Varchar (50) No format This field must This field must Reserved for future use
Extra 1 prescribed be empty be empty
2.2.8.3 Premise Data File
2.2.8.3.1 File Name Record for the Premise Data File


Table 2.2.7 FILE NAME RECORD FOR THE PREMISE DATA FILE

<FTSFN>
</FTSFN>
be:
or
2.2.8.3.2 Premise Data File Header Record

Table 2.2.8 PREMISE DATA FILE HEADER RECORD

H
LDC ID Char (8) General: Y The unique Organization
AAAAAAAA identifier assigned to the
Example: LDC during the
File Name
Record and process.
Header
Process Varchar General: Y Record are Populated with
Mode (20) AAAAAAAAAAAAA required “PeriodicAuditSync” or
Specific Usage: whether or not “IncrementalSync”
‘PeriodicAuditSync’ Detail Record
or data are
“IncrementalSync” required.
Please refer to
Process Char General: Y Section 2.3.10 Always populated with
Object (20) AAAAAAAAAAAAA for Files and “Premise”
AA Detail data
Specific Usage: Fields
‘Premise’ required for
each Business
Extracted Date/Time yyyyMMddHHmmss Y Scenario. The date and time the
Date Time data in this
maybe coincident with the
time that the creation of

this synchronization file
set was started.
2.2.8.3.3 Premise Data File Detail Record

The Premise Data File Detail Record allows the LDC to provide premise related data to
the MDM/R, such as address.
Table 2.2.9 PREMISE DATA FILE DETAIL RECORD

Indicator AAAAAAAAAA being submitted. For this file this will
Specific Usage: always be “Premise”
“Premise”
Universal Fixed Number General: Y This identifier is maintained in the LDC
SDP ID (8) NNNNNNNN systems and uniquely identifies the
Example: SDP
‘00037482’
Premise Varchar (100) No format Y The physical address of the SDP.
Address prescribed Alternatively, the LDC may provide the
Premise ID or other value as may be
determined by the LDC.
Please refer
City Varchar (20) No format Y This is the city in which the SDP exists
to Section
prescribed 2.3.10 for or other value as may be determined by
the LDC.
Files and
Province Varchar (20) No format Y Detail data This is the province in which the SDP
prescribed Fields exists or other value as may be
required for determined by the LDC.
each
Postal Varchar (10) No format Y Business This is the postal code associated with
Code prescribed Scenario. the SDP or other value as may be
determined by the LDC.
Time Char(3) General: Y This is the time zone associated with
Zone AAA Meter Read data as stored and
Specific Usage: presented in the MDM/R.
‘EST’ Since all Meter Read data transmitted
to the MDM/R must be in Eastern
Standard Time (EST) for all premise
locations, this value must always be
‘EST’.
Meter Read data is stored with the
‘Local Read Time’ = ‘EST’ and
presented in the EnergyIP GUI as Time
= ‘EST’.
Premise Varchar (50) No format This field must This field must Reserved for future use

2.2.8.4 Service Agreement Data File
2.2.8.4.1 File Name Record for the Service Agreement Data File
Table 2.2.10 FILE NAME RECORD FOR THE SERVICE AGREEMENT DATA FILE

<FTSFN>
</FTSFN>
be:
or
2.2.8.4.2 Service Agreement File Header Record

The second record will be a header record as described in table 2.2.11
Table 2.2.11 SERVICE AGREEMENT FILE HEADER RECORD

Record Char (1) General: Y This field indicates that
H
AAAAAAAA File Name identifier assigned to the
Example: Record and LDC during the
‘ORG83458’ Header registration/enrollment
Record are process.
Mode (20) AAAAAAAAAAAAA whether or not “PeriodicAuditSync” or
‘PeriodicAuditSync’ data are
or required.
“IncrementalSync” Please refer to

Process Varchar General: Y Section 2.3.10 Always populated with
Object AAAAAAAAAAA for Files and “Service Agreement”
(20)
Detail data
Specific Usage:
Fields
‘Service Agreement’
required for
Extracted Date/Time yyyyMMddHHmmss Y each Business The date and time the
Date Time Scenario. data in this
may be coincident with
the time that the creation
of this synchronization
file set was started.
2.2.8.4.3 Service Agreement Data File Detail Record

The Service Agreement Data File allows LDCs to associate Framing Structures to a
particular SDP.
The data records start after the header and will contain one line for each Service
Agreement associated with each Universal SDP ID as defined in table 2.2.12.
Table 2.2.12 SERVICE AGREEMENT DATA FILE DETAIL RECORD

Record Varchar (50) General: Y This field indicates the type
Indicator AAAAAAAAAA of record being submitted.
Specific Usage: For this file this will always
‘Service Agreement’ be “Service Agreement”
Commodity Char(1) General: Y Always “E” for when the

A underlying commodity is
Specific Usage: electricity.
ONE of the following Future placeholders of “G”
characters, for gas and “W” for water.
‘E’, or ‘G’, or ‘W’
Framing Char (2) General: Y From this framing structure
Structure ID AA ID attribute, the MDM/R
Specific Usage: determines the billing
For energy one of quantities that are to be
delivered for the related
‘01’, ‘02’, ‘03’ or ‘04’
Universal SDP ID.
or for demand
See Table 2.2.13 for
based framing:
Framing Structure ID code
‘05’, ‘06’, ‘07’, ‘08’, Please refer to
values and associated
‘09’, ‘10’, ‘11’, ‘12’, Section 2.3.10
Framing Structures
‘13’, ‘14’, ‘15’, ‘16’, for Files and
‘17’, ‘18’, ‘19’, ‘20’, Detail data
‘21’, ‘22’, ‘23’, ‘24’, Fields
’25’, ‘26’, ‘27’, ‘28’. required for
each Business
Universal Fixed Number General: Y This identifier is maintained
Scenario.
SDP ID (8) NNNNNNNN in the LDC systems and
Example: uniquely identifies the SDP
‘00037482’
Universal Date/Time yyyyMMddHHmmss Y This is the date/time for
SDP ID to which the Framing
Framing Structure and Universal
Structure SDP ID relationship starts.
Relationship This date/time is inclusive

Start Date and considered to be the
start of the day.
EnergyIP performs a daily
framing process that uses
the Framing Structure that
is in effect for each SDP at
the start of each day. The
start date/time should be
submitted as the inclusive
start of day (N) at time
HHmmss = 000000 to
assure that each entire day
is processed using the
same Framing Structure.
This time must be reported
in EST.
Universal Date/Time yyyyMMddHHmmss For P-Sync, This is the date/time for
SDP ID to (See note) which the Framing
Framing Structure and Universal
Structure SDP ID relationship ends.
Relationship For I-Sync, This date/time is exclusive
End Date N and considered to be the
Please refer to first moment that the
Section 2.3.10 relationship is not in effect.
for Files and EnergyIP performs a daily
Detail data framing process that uses
Fields the Framing Structure that
required for is in effect for each SDP at
each Business the start of each day. The
Scenario. end date/time should be
submitted as the exclusive
end of day (N + n) at time
HHmmss = 000000 (where
n ≥ 0 whole days) to
assure that each entire day
is processed using the
same Framing Structure.
This time must be reported
in EST.
NOTE: For P-Sync this
field must be ‘null’ unless
providing an end date/time
that is later than the
Service Varchar (50) No format This field must This field must Reserved for future use
Agreement prescribed be empty be empty
Extra 1
Extra 2
Extra 3
Table 2.2.13 provides a cross reference of the Framing Structure ID codes to

associated Framing Structures together with a brief description of the resulting Billing
Quantity data components and associated time reference for each Billing Quantity data
component. This table also provides the resulting Energy Purchase Service service
type names viewable in the EnergyIP GUI and reported in Report IR06:

Synchronization Updates Report for each Framing Structure, together with the
Measurement Profile attribute values as viewable in the EnergyIP GUI within the Data
Delivery Service and used by EnergyIP to determine the type of Billing Quantity
response.
Table 2.2.13 Cross Reference Framing Structure ID; Framing Structure; Energy Purchase
Service and Measurement Profile Values
Framing Framing Structure Data Delivery Service –
Structure Energy Purchase Service – Service Type Name Measurement Profile
ID Billing Quantity Data Components and Time Basis Attribute Values
"TOU/CPP (EST)"
“01” "Energy Purchase Service, TOU/CPP (EST)" "MP TOU Billing Quantities"
TOU/CPP kWh (EST)
"TOU/CPP (CST)"
“02” "Energy Purchase Service, TOU/CPP (CST)" "MP TOU Billing Quantities"
TOU/CPP kWh (CST)
"Hourly"
“03” "Energy Purchase Service, Hourly" "MP Hourly Billing Quantities"
Hourly kWh (EST)
"Periodic"
“04” "Energy Purchase Service, Periodic" "MP Periodic Billing Quantities"
Periodic kWh (EST)
"Periodic 15 minute Block (EST)"
"Energy Purchase Service, Periodic 15 minute Block "MP Periodic 15 minute Block
“05” Periodic kWh and 15 minute Block Demand calculations (EST)" Billing Quantities"
(EST) with kW77 Peak Demand (EST)
"Periodic 15 minute Block (CST)"
“06” Periodic kWh and 15 minute Block Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"Periodic 60 minute Block (EST)"
“07” Periodic kWh and 60 minute Block Demand calculations (EST)" Billing Quantities"
"Periodic 60 minute Block (CST)"
“08” Periodic kWh and 60 minute Block Demand calculations (CST)" Billing Quantities"
"Periodic 15 minute Rolling (EST)"
"Energy Purchase Service, Periodic 15 minute Rolling "MP Periodic 15 minute Rolling
“09” Periodic kWh and 15 minute Rolling Demand (EST)" Billing Quantities"
calculations (EST) with kW77 Peak Demand (EST)
"Periodic 15 minute Rolling (CST)"
“10” Periodic kWh and 15 minute Rolling Demand (CST)" Billing Quantities"
calculations (EST) with kW77 Peak Demand (CST)
"Periodic 60 minute Rolling (EST)"
“11” Periodic kWh and 60 minute Rolling Demand (EST)" Billing Quantities"
"Periodic 60 minute Rolling (CST)"
“12” Periodic kWh and 60 minute Rolling Demand (CST)" Billing Quantities"
"Hourly 15 minute Block (EST)"
"Energy Purchase Service, Hourly 15 minute Block "MP Hourly 15 minute Block
“13” Hourly kWh and 15 minute Block Demand calculations (EST)" Billing Quantities"
"Hourly 15 minute Block (CST)"
“14” Hourly kWh and 15 minute Block Demand calculations (CST)" Billing Quantities"
"Hourly 60 minute Block (EST)"
“15” Hourly kWh and 60 minute Block Demand calculations (EST)" Billing Quantities"
"Hourly 60 minute Block (CST)"
“16” Hourly kWh and 60 minute Block Demand calculations (CST)" Billing Quantities"
"Hourly 15 minute Rolling (EST)"
"Energy Purchase Service, Hourly 15 minute Rolling "MP Hourly 15 minute Rolling
“17” Hourly kWh and 15 minute Rolling Demand calculations (EST)" Billing Quantities"
"Hourly 15 minute Rolling (CST)"
“18” Hourly kWh and 15 minute Rolling Demand calculations (CST)" Billing Quantities"
"Hourly 60 minute Rolling (EST)"
“19” Hourly kWh and 60 minute Rolling Demand calculations (EST)" Billing Quantities"
"Hourly 60 minute Rolling (CST)" "Energy Purchase Service, Hourly 60 minute Rolling "MP Hourly 60 minute Rolling
“20”
Hourly kWh and 60 minute Rolling Demand calculations (CST)" Billing Quantities"

Framing Framing Structure Data Delivery Service –
Structure Energy Purchase Service – Service Type Name Measurement Profile
ID Billing Quantity Data Components and Time Basis Attribute Values
"TOU/CPP 15 minute Block (EST)"
"Energy Purchase Service, TOU/CPP 15 minute Block "MP TOU 15 minute Block Billing
“21” TOU/CPP kWh (EST) and 15 minute Block Demand (EST)" Quantities"
"TOU/CPP 15 minute Block (CST)"
“22” TOU/CPP kWh (CST) and 15 minute Block Demand (CST)" Quantities"
"TOU/CPP 60 minute Block (EST)"
“23” TOU/CPP kWh (EST) and 60 minute Block Demand (EST)" Quantities"
"TOU/CPP 60 minute Block (CST)"
“24” TOU/CPP kWh (CST) and 60 minute Block Demand (CST)" Quantities"
"TOU/CPP 15 minute Rolling (EST)"
"Energy Purchase Service, TOU/CPP 15 minute Rolling "MP TOU 15 minute Rolling
“25” TOU/CPP kWh (EST) and 15 minute Rolling Demand (EST)" Billing Quantities"
"TOU/CPP 15 minute Rolling (CST)"
“26” TOU/CPP kWh (CST) and 15 minute Rolling Demand (CST)" Billing Quantities"
"TOU/CPP 60 minute Rolling (EST)"
“27” TOU/CPP kWh (EST) and 60 minute Rolling Demand (EST)" Billing Quantities"
"TOU/CPP 60 minute Rolling (CST)"
“28” TOU/CPP kWh (CST) and 60 minute Rolling Demand (CST)" Billing Quantities"
2.2.8.5 Parameter Data File
2.2.8.5.1 File Name Record for the Parameter Data File

Table 2.2.14 FILE NAME RECORD FOR THE PARAMETER DATA FILE

<FTSFN>
</FTSFN>
be:
or

2.2.8.5.2 Parameter Data File
The second record of the file will be a header record as described in table 2.2.15
Table 2.2.15 PARAMETER DATA FILE HEADER RECORD

H
AAAAAAAA File Name identifier assigned to the
Example: Record and LDC during the
Record are process.
Mode (20) AAAAAAAAAAAA whether or not “PeriodicAuditSync” or
data are
‘PeriodicAuditSync’ required.
or
“IncrementalSync” Please refer to
Section 2.3.10
Process Varchar General: Y for Files and Always populated with
Object (20) AAAAAAAAAAAA Detail data “Parameter”
Specific Usage: Fields
‘Parameter’ required for
each Business
Extracted Date/Time yyyyMMddHHmmss Y Scenario. The date and time the
Date Time data in this
this synchronization file
set was started.
2.2.8.5.3 Parameter Data File Detail Record

The Parameter Data File Detail Record allows the LDC to associate different
parameters with either a meter or an SDP. These parameters are outlined in Table
2.2.16 and 2.2.17.
Table 2.2.16 PARAMETER DATA FILE DETAIL RECORD

Specific always be “Parameter”
Usage:
Please refer
‘Parameter’ to Section
UDC ID Varchar(50) General: Y 2.3.10 for Depending on what kind of parameter
AAAAAAAAAA Files and is being submitted, this value will be
Example; Detail data either the Universal SDP ID or the
984233 Fields Meter ID that will be associated with
required for the parameter.
each
Param Varchar(50) General: Y Business This defines the type of parameter that
Name AAAAAAAAA Scenario. is being submitted.
For UDC ID = Universal SDP ID,
values are:

“Loss Factor Classification”
“Service Volts”
“Service Amps”
“Service Phases”
“Service Form”
“Dem-firm #1”
“Dem-firm #2”
“Dem-firm #3”
“Dem-firm #4”
“IVR PIN”
“Billing Cycle ID”
“CT/PT Multiplier”
“VEE Service”
Please refer For UDC ID = Meter ID, Values are:
to Section “Dials”
2.3.10 for “Meter Volts”
Files and
Detail data “Meter Amps”
Fields “Meter Phases”
required for “Meter Form”
each
Param Refer to Table Refer to Table Refer to Table Business This is the value that is associated with
Value 2.2.17 2.2.17 2.2.17 Scenario. the parameter being submitted.
Refer to Table 2.2.17 for descriptions
of these data elements.
Start Date/Time yyyyMMddHH Y This is the start date associated with
Date mmss the parameter. This date/time is
Time inclusive and is considered the first
moment that the parameter is active.
This time must be reported in EST.
End Date Date/Time yyyyMMddHH For P-Sync, This is the end date associated with
Time mmss (See note) the parameter. This date/time is
exclusive and considered to be the first
moment that the parameter is not in
For I-Sync,
effect. This time must be reported in
N
EST.
NOTE: For P-Sync this field must be
‘null’ unless providing an end date/time
that is later than the Extracted Date
Time.
Table 2.2.17 Data Values for Param Value field
Param Data P Sync V01 I Sync V00

Format Description
Value Type/Length Required Required
If UDC ID = Universal SDP ID
Loss Factor Number (2) General: N N This will be used to drive aggregation.
Classification NN For each LDC and for each ‘loss factor
Valid classification’, the MDM/R will produce
Values: a data set with 24 hourly totals that
represent the aggregation for each hour
‘01’ through
across SDPs sharing the same ‘loss
‘12’
factor classification’.
NOTE: This SDP Parameter will be
displayed in the EnergyIP GUI with an
Attribute Name of “Loss Factor”
Service Volts Varchar (20) No format N N Volts of the service to the SDP.
prescribed Supplied to the MDM/R for informational

Format Description
purposes only.
Service Amps Varchar (20) No format N N Amps of the service to the SDP.
prescribed Supplied to the MDM/R for informational
purposes only.
Service Varchar (20) No format N N Phase of the service to the SDP.
Phases prescribed Supplied to the MDM/R for informational
purposes only.
Service Form Varchar (20) No format N N Service wires i.e. 3 phase 4 wire, 3
prescribed phase 3 wire. Supplied to the MDM/R
for informational purposes only.
Dem-firm #1 Varchar (50) No format N N Placeholder for future demographic
prescribed data.
prescribed data.
prescribed data.
prescribed data.
IVR PIN Fixed Number General: N N A number assigned by the LDC to
(4) NNNN permit the current Customers access to
Examples: their meter read and Billing Quantity
‘0000’ data via the IVR (see Section 13 of the
MDM/R Detailed Design Document).
‘9999’
NOTE: This SDP Parameter will be
displayed in the EnergyIP GUI with an
Attribute Name of “IVR PIN”
Billing Cycle Varchar (3) General: Y, if Y, if This ID specifies the billing cycle that
ID AAA Scheduled Scheduled the MDM/R will use to deliver billing
Examples: “PUSH” is “PUSH” is quantities for the Universal SDP ID in a
used for used for scheduled ‘push’ approach. See Section
‘1’
Billing Billing 2.6 for details.
‘C45’ Quantities Quantities This SDP Parameter will be
stored/displayed by EnergyIP GUI in the
N, if “Request/ N, if “Request/ “Route ID” field with a value = ORG_ID
Response” is Response” is + Billing Cycle ID.
used used NOTE: The Start Date Time or End
exclusively exclusively Date Time for this SDP parameter must
NOT be later than the Extracted Date
Time for the synchronization file set.
CT/PT Number General: N N The multiplier that should be applied to
Multiplier (20,10) NNNNN.N the metering data received from the
N AMCC.
Examples: NOTE: This multiplier is the product of
‘1’, ‘100’ the meter multiplier and any applicable
‘130.33’. CT and PT ratios.
and If a unity value or no value is provided in
‘99999.99’ a Periodic Audit Synchronization, the
‘CT/PT Multiplier’ will not be applied to
interval consumption data, effectively
defaulting the value to “1” although
values of “1” are not stored in the MMD.
If no value is provided in an Incremental
Synchronization, no change will be
made to the existing data.
Values = “0” are not processed by the
MDM/R.
This SDP Parameter will be
stored/displayed in the EnergyIP GUI as
CT-PT Multiplier with the value

Format Description
displayed in the form as entered by the
MDM/R Administrator.
See also specification for Report IR06,
Version 01, ‘SDP CTPT Detail Record’
in the MDM/R Reports Technical
Specifications.
NOTE: The Start Date Time or End
Date Time for this SDP parameter must
NOT be later than the Extracted Date
Time for the synchronization file set.
VEE Service Char (2) General : Y Please refer to This defines the VEE rule set that
AA Section 2.3.10 applies to the Universal SDP ID defined
Example : for Files and below.
‘02’ Detail data Allowable values:
Fields
01, 02, 03, 04 … 30
required for
each Business Valid values will only include
Scenario. established VEE services.
If UDC ID = Meter ID
Dials Number (2) General: Y Please refer to This is the number of dials or in the
NN Section 2.3.10 case of solid state meters, the number
for Files and of digits reported by the AMCC for this
Examples
include: Detail data meter.
Fields
‘6’ required for
each Business
Scenario.
Meter Volts Varchar (20) No format N N Volts of the Meter. Supplied to the
prescribed MDM/R for informational purposes only.
Meter Amps Varchar (20) No format N N Amps of the Meter. Supplied to the
Meter Phases Varchar (20) No format N N Phase of the Meter. Supplied to the
Meter Form Varchar (20) No format N N This is the meter form factor for the
prescribed SDP as defined by the ANSI C12.10
standard (i.e. 2S, 16S, etc). Supplied to
the MDM/R for informational purposes
only.
2.2.8.6 Relationship Data File
2.2.8.6.1 File Name Record for the Relationship Data File

Table 2.2.18 FILE NAME RECORD FOR THE RELATIONSHIP DATA FILE

<FTSFN>

</FTSFN>
be:
or
2.2.8.6.2 Relationship Data File Header Record

Table 2.2.19 RELATIONSHIP DATA FILE HEADER RECORD

Record Char (1) General; Y This field indicates that this
Type A record is a header record.
Specific: It must be ‘H’
H

AAAAAAAA identifier assigned to the
Example: File Name LDC during the
‘ORG84153’ Record and registration/enrollment
Header Record process.
are required
Process Varchar General: Y Populated with
whether or not
Mode (20) AAAAAAAAAAAA “PeriodicAuditSync” or
Detail Record
Specific Usage: data are “IncrementalSync”
‘PeriodicAuditSync’ required.
or Please refer to
“IncrementalSync” Section 2.3.10
Process Varchar General: Y for Files and Always populated with
Object (20) AAAAAAAAAAAAA Detail data “Relationship”
AAA Fields required
Specific Usage: for each
‘Relationship” Business
Scenario.
Extracted Date/Time yyyyMMddHHmms Y The date and time the data
Date Time s in this synchronization file
set was extracted from the
this synchronization file set
was started.

2.2.8.6.3 Relationship Data File Detail Record
The Relationship Data File Detail Record allows the LDC to define the relationship
between assets and/or accounts in the MDM/R. The LDC or its designated agent must
submit the relationships in a particular order as defined in table 2.2.20
Table 2.2.20 DEFINED RELATIONSHIPS
Values – Relationship Values – Relationship Required

Future Dates
Identifier 1 Identifier 2 Relationship
SDP METER Required Not Allowed
SDP ACCOUNT Optional Allowed
METER COMMUNICATION MODULE Required Not Allowed
SDP BILLING AGENT Required Not Allowed
SDP AMI OPERATOR Required Not Allowed
SDP ENERGY SERVICE PROVIDER Optional Not Allowed
SDP CCA SERVICE PROVIDER Optional Not Allowed
Table 2.2.21 RELATIONSHIP DATA FILE DETAIL RECORD

Specific Usage: always be “Relationship”
“Relationship”
Object 1 If Relationship Y Based on what is submitted in the
Identifier 1 is “Object 1” field, this value could be
“SDP” - Fixed § The Universal SDP ID
Number (8) § The Meter ID
“METER” -
Varchar (50)
Relations Varchar (50) General: Y This is the type of asset being
hip AAAAAAAAAA submitted in the “Relationship Identifier
Identifier Specific Usage 1” field
1 Acceptable values are defined in table
“SDP”
2.2.20
or
“METER”
Object 2 If ‘Relationship Y, if field is : Based on what is submitted in the
Identifier 2’ is: “METER”, “Object 2” field, this value could be
“METER” - “COMMUNICA § The Meter ID
Varchar (50) TION Please refer to
Section 2.3.10 § The Account ID
“ACCOUNT’ – MODULE”, § The AMCD ID
“BILLING for Files and
Varchar(50)
AGENT”, Detail data § The Billing Agent Organization ID
“COMMUNICA Fields § The AMI Operator Organization ID
TION “AMI required for
MODULE” – OPERATOR” § The Energy Service Provider
each Business
Varchar(50) N, if field is: Organization ID
Scenario.
“BILLING “ACCOUNT”, § The CCA Organization ID
AGENT”, “AMI “ENERGY NOTE 1: The SDP to ACCOUNT
OPERATOR”, SERVICE relationship is used to track Customer
“ENERGY PROVIDER”, move in/ move out actions. Account
SERVICE changes provide estimation services
“CCA
PROVIDER”, only against the current account, and
SERVICE also provide segmentation of Billing
or “CCA
PROVIDER”
SERVICE Quantity response for account change
PROVIDER” – events. These services are not

Char(8) provided if an account is not provided.
NOTE 2: The SDP-ACCOUNT
relationship will be ended if an Account
ID is not submitted for P Sync V01.
NOTE 3: The SDP to BILLING AGENT
relationship determines the organization
to which Billing Quantity values are
provided in each Billing Quantity
response.
NOTE 4: The SDP to AMI OPERATOR
relationship determines the agent
organization that may submit Meter
Read data. Both an agent organization
designated in this relationship and the
LDC may each submit Meter Read data
for the same SDP.
NOTE 5: The SDP to ENERGY
SERVICE PROVIDER relationship
determines the organization to which
read-only web services access is
granted for each SDP. LDCs may use
this relationship to provide data access
to a Retailer organization for which a
customer is signed up with the Retailer.
NOTE 6: The SDP to CCA SERVICE
PROVIDER relationship determines the
organization to which read-only web
services access is granted for each
SDP. LDCs may use this relationship
to provide data access to another
organization registered with the MDM/R
for which a customer contract
relationship exists.
Relations Varchar (50) General: Y This is the type of asset being
hip AAAAAAAAAA submitted in the “Object 2” field
Identifier Specific Usage Acceptable values are defined in table
2 Please refer to 2.2.20
One of:
Section 2.3.10
‘METER’ for Files and
‘ACCOUNT’ Detail data
‘COMMUNICA Fields
TION required for
MODULE’ each Business
‘BILLING Scenario.
AGENT’
‘AMI
OPERATOR’
‘ENERGY
SERVICE
PROVIDER’
‘CCA
SERVICE
PROVIDER’
Start Date/Time yyyyMMddHH Y This is the start date of the relationship.
Date mmss This date/time is inclusive and is
Time considered the first moment that the
relationship is active. This time must be
reported in EST.
End Date Date/Time yyyyMMddHH For P-Sync, This is the end date of the relationship.
Time mmss (See note) This date/time is exclusive and
considered to be the first moment that
For In-Sync,
the relationship is not in effect. This

N time must be reported in EST.
NOTE: For P-Sync this field must be
‘null’ unless providing an end date/time
that is later than the Extracted Date
Time. Please refer to Table 2.2.20 for
relationships that can use future dates.
2.2.8.7 Meter Reads Data File

This file will not be used as part of Periodic Audit Synchronization Version 01 or
Incremental Synchronization Version 00. Synchronization File Number 06 should not
be submitted as part of any synchronization file set. Any File Number 06 listed in a
Manifest File will be ignored, all submitted records related to File Number 06 will not be
processed, and no error message will be returned.
NOTE: First and last register readings may be submitted using the Meter Read
Interface.
2.2.8.8 Component SDP Channel to Channel & Channel to Formula Data File
2.2.8.8.1 File Name Record for the Component SDP Channel to Channel & Channel to Formula
Data File
Table 2.2.22 FILE NAME RECORD FOR THE COMPONENT SDP CHANNEL TO CHANNEL &
CHANNEL TO FORMULA DATA FILE

<FTSFN>
</FTSFN>
be:
or
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.07. 02.DAT</FTSFN>

2.2.8.8.2 Component SDP Channel to Channel & Channel to Formula Data File Header Record
Table 2.2.23 COMPONENT SDP CHANNEL to CHANNEL & CHANNEL to FORMULA DATA
FILE HEADER RECORD

Record Char (1) General; Y This field indicates that this
Type A record is a header record. It
H
AAAAAAAA File Name identifier assigned to the LDC
Example: Record and during the
Record are process.
Process Varchar General: Y required if Populated with
Mode (20) AAAAAAAAAAA Detail Record “PeriodicAuditSync” or
Specific Usage: data are “IncrementalSync”
required.
‘PeriodicAuditSync’ or
“IncrementalSync”
Please refer to
Process Char General: Y Section 2.3.10 Always populated with
Object (20) AAAAAAAAAAAA for Files and “ComponentSDP”
Specific Usage: Detail data
‘ComponentSDP’ Fields
required for
Extracted Date/Time yyyyMMddHHmmss Y The date and time the data in
each Business
Date this synchronization file set
Scenario.
Time was extracted from the
source systems. This maybe
coincident with the time that
the creation of this
synchronization file set was
started.
2.2.8.8.3 Component SDP Channel to Channel Data File Detail Record

The “Channel to Channel” relationship data records start after the header and will
contain one line for each contributing Member interval information channel associated
with a Parent interval information channel as defined in table 2.2.24. These records
must be provided in conjunction with a related “Channel to Formula” record.
NOTE: Until the Retroactive / Future Dated support is deployed in EnergyIP,
Component SDP Data File records will not be processed into EnergyIP.

Table 2.2.24 COMPONENT SDP CHANNEL TO CHANNEL DATA FILE DETAIL RECORD

Record Varchar (50) General; Y This field indicates the type of
Indicator AAAAAAAA record being submitted. For
this file detail record this will
Specific Usage:
always be “Channel to
‘Channel to Channel”
Channel’
Parent Fixed Number General: Y The Ontario-wide unique

Universal (8) NNNNNNNN identifier assigned by the
SDP ID Example: Universal SDP ID
Assignment Request
‘00098472’
/Response integration.
Please refer to The Parent of the Channel to
Section 2.3.10 Channel Relationship must
for Files and be a Virtual Interval Channel
Detail data which can exist on a physical
Fields or virtual SDP depending on
required for the specified Meter Asset –
each Business “Channel Configuration Set”.
Scenario. This is the Parent Universal
SDP ID associated with the
contributing Member
Universal SDP ID below.
Parent Varchar (15) General: Y This is the unit of
Unit of AAAAAAAAAA measurement for the Parent
Measure Specific Usage: of the Channel to Channel
ment One of ‘kWh’, Relationship. The Parent is
always a Virtual Interval
‘kVAh’, or
Channel.
‘kVARh’
Acceptable values are: kWh,
kVARh and kVAh
Parent Number (3) General: Y This is the interval length for
Interval NNN the Parent of the Channel to
Length Specific Usage: Channel Relationship. The
Parent is always a Virtual
One of
Interval Channel.
‘5’, ‘10’, ‘15’, ‘30’,
Acceptable values expressed
or ‘60’
in minutes are: 5, 10, 15, 30
and 60

Member Fixed Number General: Y The Ontario-wide unique
Universal (8) NNNNNNNN identifier assigned by the
SDP ID Example: Universal SDP ID
Assignment Request
‘00037482’
/Response integration.
This is the contributing
Member Universal SDP ID
associated with the Parent
Universal SDP ID above.
The contributing Member of
the Channel to Channel
Relationship can be either a
Physical Interval Channel
which can exist on a physical
SDP or a Virtual Interval
Channel existing on a
Physical SDP or Virtual SDP
depending on the specified
Please refer to Meter Asset – “Channel
Section 2.3.10 Configuration Set”.
for Files and
Member Varchar (15) General: Y Detail data This is the unit of
Unit of AAAAAAAAAA Fields measurement for the
Measure Specific Usage: required for contributing Member of the
ment each Business Channel to Channel
One of ‘kWh’,
Scenario. Relationship.
‘kVAh’, or
‘kVARh’ Acceptable values are: kWh,
kVARh and kVAh
Member Number (3) General: Y This is the interval length for
Interval NNN the contributing Member of
Length Specific Usage: the Channel to Channel
One of Relationship. The contributing
Member can be a Physical
‘5’, ‘10’, ‘15’, ‘30’,
Interval Channel or a Virtual
or ‘60’
Interval Channel.
Acceptable values expressed
in minutes are: 5, 10, 15, 30
and 60
Member Varchar (30) General: Y This is a symbolic name for
Alias AAAAAAAAAA the contributing Member of
the Channel to Channel
Relationship. The Alias is
used in the “Formula
Expression” provided in the
related “Channel to Formula”
record.
Channel Date/Time yyyyMMddHHm Y This is the inclusive date/time
to mss for which the Parent Interval
Channel Channel to contributing
Relations Member Interval Channel
hip Start relationship starts.
Date
Channel Date/Time yyyyMMddHHm N This is the exclusive
to mss date/time for which the
Channel Parent Interval Channel to
Relations Please refer to contributing Member Interval
hip End Channel relationship ends.
Section 2.3.10
Date

Member Varchar (50) General: Y for Files and This indicates whether the
Channel “A” Detail data Member channel is a physical
Type Specific Usage: Fields or virtual channel
required for
ONE of the
following each Business
Scenario.
characters,
“P” or “V”
2.2.8.8.4 Component SDP Channel to Formula Data File Detail Record

The “Channel to Formula” relationship data records start after the header and will
contain one line for each Parent interval information channel as defined in table 2.2.25.
These records must be provided in conjunction with related “Channel to Channel”
records.
NOTE: Until the Retroactive / Future Dated support is deployed in EIP, Component
SDP Data File records will not be processed into EIP.
Table 2.2.25 COMPONENT SDP CHANNEL TO FORMULA DATA FILE DETAIL RECORD

Record Varchar 50 General; Y This field indicates the type of
Indicator AAAAAAAA record being submitted. For this
Specific Usage: file detail record this will always be
‘Channel to “Channel to Formula”
Formula’
Parent Fixed Number General: Y The Ontario-wide unique identifier
Universal (8) NNNNNNNN assigned by the Universal SDP ID
SDP ID Example: Assignment Request /Response
‘00098472’ integration.
The Parent of the Channel to
Formula Relationship must be a
Please refer to Virtual Interval Channel which can
Section 2.3.10 exist on a physical SDP or virtual
for Files and SDP depending on the specified
Detail data Meter Asset – “Channel
Fields Configuration Set”.
required for This is the Parent Universal SDP
each Business ID associated with the Parent
Scenario. Interval information channel.
Parent Varchar (15) General: Y This is the unit of measurement for
Unit of AAAAAAAAAA the Parent of the Channel to
Measure Specific Usage: Formula Relationship. The Parent
ment One of ‘kWh’, is always a Virtual Interval
‘kVAh’, or Channel.
‘kVARh’ Acceptable values are: kWh,
kVARh and kVAh
Parent Number (3) General: Y This is the interval length for the
Interval NNN Parent of the Channel to Formula
Length Specific Usage: Relationship. The Parent is always
One of a Virtual Interval Channel.
‘5’, ‘10’, ‘15’, ‘30’, Acceptable values expressed in
or ‘60’ minutes are: 5, 10, 15, 30 and 60

Formula Varchar (15) General: Y This field identifies the type of
Type NNNNNNNN calculation to be performed with
Example: the result stored in the identified
‘Summator’ or Parent Interval Information
‘Expression’ Channel.
‘Summator’ sums all contributing
members with the result stored in
the identified Parent Interval
Information Channel.
‘Expression’ evaluates the
provided formula expression using
the Alias identified contributing
Members with the result stored in
the identified Parent Interval
Please refer to Information Channel.
Section 2.3.10
for Files and
Channel Date/Time yyyyMMddHHm Y Detail data This is the inclusive date/time for
to mss Fields which the Parent Interval Channel
Formula required for to Formula relationship starts.
Relations each Business
hip Start Scenario.
Date
Channel Date/Time yyyyMMddHHm For P-Sync, This is the exclusive date/time for
to mss (See note) which the Parent Interval Channel
Formula to Formula relationship ends.
Relations NOTE: For P-Sync this field must
hip End For I-Sync,
be ‘null’ unless providing an end
Date N date/time that is later than the
Formula Varchar (2000) General: If “Formula This is the Formula Expression
Expressi AAAAAAAAAA Type” is that will be evaluated when the
on specified as Formula Type is specified as
“Expression” ‘Expression’.
then Y Note: Refer to Section 3 of the
Otherwise N MDM/R Detailed Design
Document for information on the
valid operators that can be used
when constructing the “Formula
Expression”.

2.2.9 SDP Activation and Services Relationships
Table 2.2.26 identifies all of the SDP attributes and which attributes are required throughout for
the various SDP services.
Table 2.2.26 SDP ATTRIBUTES AND SERVICES
Effective Date
Attributes
SDP Service
SDP Attributes SDP Life Cycle SDP Processing Services
Providers
CCA Service Provider

Data Delivery service
Persistence Service
SDP Object Created
Energy Purchase
Generic Framing
Start/stop Dates
Virtual Channel
Data Collection
Data Collection
Energy Service
Billing Service
Universal SDP
Universal SDP
SDP Inactive
VEE Service
Associated
SDP Active
Requested
Assigned
Provider
Provider
Provider
Service
Service
service
Universal SDP ID NO NA MF MF MF MF MF MF MF MF MF MF MF MF MF MF
LDC ID NO M MF MF MF MF MF MF MF MF MF MF MF MF MF MF
SDP ID NO M MF MF MF MF MF MF MF MF MF MF MF MF MF MF
Premise Address NO NA NA MO MO MO MO MO MO MO MO MO MO MO MO MO
City NO NA NA MO MO MO MO MO MO MO MO MO MO MO MO MO
Province NO NA NA MO MO MO MO MO MO MO MO MO MO MO MO MO
Postal Code NO NA NA MO MO MO MO MO MO MO MO MO MO MO MO MO
Time Zone NO NA NA MP MP O MP MP MP MP MP MP MP MP MP MP
Service Status NO NA NA MP MP O MP MP MP MP M M M M M M
Load Status NO NA NA MP MP O MP MP MP MP M M M M M M
Type (Physical or
Virtual) NO NA NA MF MF MF MF MF MF MF MF MF MF MF MF MF
For SDP & Meter
Loss Factor
YES NA NA OP OP OP OP OP OP OP OP OP OP OP OP OP
Classification
Retailer Classification This attribute is no longer used by EnergyIP
Billing Cycle
(denotes the Data YES NA NA O O O O O O O O O O O O O
Delivery Service)
Commodity YES NA NA M M M M M M M M M M M M M
Billing Agent ID YES NA NA O M O O O O M O O O M O O
AMI Operator ID YES NA NA O MP O O MP MP O O O M O O O
ENERGY SERVICE
YES NA NA O O O O O O O O O O O M O
PROVIDER ID
Customer Contracted
YES NA NA O O O O O O O O O O O O M
Agent ID
Service Volts YES NA NA O O O O O O O O O O O O O
Service Amps YES NA NA O O O O O O O O O O O O O
Service Phases YES NA NA O O O O O O O O O O O O O
Service Form YES NA NA O O O O O O O O O O O O O
Number of Dials YES NA NA O MP MP MP MP MP MP MP MP MP MP MP MP

Effective Date
Attributes
SDP Service
Providers

SDP Object Created
Persistence Service
Energy Purchase
Generic Framing
Start/stop Dates
Virtual Channel
Data Collection
Data Collection
Energy Service
Billing Service
Universal SDP
Universal SDP
SDP Inactive
VEE Service
Associated
SDP Active
Requested
Assigned
Provider
Provider
Provider
Service
Service
service
Dem-firm#1 YES NA NA O O O O O O O O O O O O O
Meter ID YES NA NA O MP O MP M MP M M MV MP M M M
AMCD ID YES NA NA O MP O MP MP MP MP MP - MP MP MP MP
Meter AMCC Type
Related to data NA NA O MP O MP MP MP MP MP - MP MP MP MP
collection service
Meter Volts YES NA NA O O O O O O O O O O O O O
Meter Amps YES NA NA O O O O O O O O O O O O O
Meter Phase YES NA NA O O O O O O O O O O O O O
Meter Form YES NA NA O O O O O O O O O O O O O
Last Register Read YES NA NA O O O O O O O OP - OP OP OP OP
First Register Read YES NA NA O O O O O O O OP - OP OP OP OP
Account ID YES NA NA O O O O O O O O O O O O O
CT/PT Multiplier YES NA NA O O O O O O O OP OP OP OP OP OP
IVR PIN YES NA NA O O O O O O O O O O O O O
Framing Structure
(denotes the Energy YES NA NA O M O O M M M M M M M M M
Purchase Service)
VEE Service
(denotes the VEE YES NA NA O MP O MP MP MP M - - MP M - -
service)
Channel Configuration
Set (Replaces Unit of NO NA NA O M O MP M MP M M M O M O O
Measurement)
Interval Length NO NA NA O MP O MP M MP M M MV MP M - -
Demand Reset This attribute is no longer used by EnergyIP
Parent Universal SDP
YES NA NA O O O - O - MV O MV O MV - -
ID (virtual SDP only)
Parent Unit of
Measurement YES NA NA O O O - O - MV O MV O MV - -
(virtual SDP only)
Parent Interval Length
YES NA NV O O O - O - MV O MV O MV - -
(virtual SDP only)
Member Universal SDP YES NA NA O O O - O - MV O MV O MV - -

Effective Date
Attributes
SDP Service
Providers

SDP Object Created
Persistence Service
Energy Purchase
Generic Framing
Start/stop Dates
Virtual Channel
Data Collection
Data Collection
Energy Service
Billing Service
Universal SDP
Universal SDP
SDP Inactive
VEE Service
Associated
SDP Active
Requested
Assigned
Provider
Provider
Provider
Service
Service
service
ID
(physical or virtual SDP)
Member Unit of
Measurement YES NA NA O O O - O - MV O MV O MV - -
Member Interval Length
Member Alias
Formula Type
(Target virtual channel)
Formula Expression
(Target virtual channel)
Table 2.2.27 SDP ATTRIBUTES AND SERVICES - Legend

LEGEND:
M – Mandatory for both physical and virtual SDPs / Meters
MF - Mandatory and once set is not changeable; applies to both physical and virtual SDPs / Meters
MO - Mandatory content but content is not used by MDM/R; applies to both physical and virtual SDPs
MP – Mandatory for physical SDPs only. This attribute is not relevant for virtual SDPs and will be ignored if present.
MV – Mandatory for Virtual SDP only
MI – Mandatory for Physical SDP only if it is associated with a Virtual SDP
O - Optional
OP – Optional for Physical SDP only
NA - Not Available at stage in lifecycle

2.2.10 Channel Configuration Sets
Table 2.2.28 identifies all of the Channel Configuration Sets that are used to define which
channels by Unit of Measurement and Type are required for a given meter (physical or virtual)
Table 2.2.28 CHANNEL CONFIGURATION SETS
Number
Derived
Register
Classification Type Interval Data Data (virtual Notes
Data
channel)
Physical Meter
Default Physical Physical Derived Usage Derived data calculations controlled by
01 Physical Channels
Configuration Channel kWh Channel kWh & kW Demand specified SDP Framing Structure
(kWh only)
Physical Physical Derived Usage
Physical Meter Channel kWh Channel kWh & kW Demand
Derived data calculations controlled by
Physical Channels Physical specified SDP Framing Structure
Physical C & I Physical
02 (kWh, kVARh, Channel Derived Usage
Configuration Channel kVARh Virtual kVAh channel data derived from
derived kVAh & kVARh
physical kWh & kVARh channel data
kVA) Virtual Channel Derived Usage
kVAh & kVA Demand
Physical Physical Derived Usage Derived data calculations controlled by
Physical Meter Channel kWh Channel kWh & kW Demand specified SDP Framing Structure
Physical C & I
03 Physical Channels Physical Derived data calculations controlled by
Configuration Physical Derived Usage
(kWh, kVAh) Channel specified SDP Framing Structure
Channel kVAh & kVA Demand
kVAh
Physical Physical Derived Usage
Channel kWh Channel kWh & kW Demand
Physical Meter Physical
Physical
Physical C & I Physical Channels Channel Derived Usage Derived data calculations controlled by
04 Channel kVARh
Configuration (kWh, kVARh, kVARh specified SDP Framing Structure
kVAh) Physical
Physical Derived Usage
Channel
Channel kVAh & kVA Demand
kVAh
Virtual SDP Virtual Channel Derived data calculations controlled by
Virtual Meter kWh specified SDP Framing Structure
Virtual Derived Usage
05
Configuration Virtual Channels (with virtual & kW Demand
(kWh) channel formula)
Virtual Channel
kWh Derived Usage
(with virtual & kW Demand
Virtual SDP channel formula)
Virtual Meter Virtual Channel Derived data calculations controlled by
Virtual Virtual Channels kVARh specified SDP Framing Structure
06 Derived Usage
Configuration (with virtual Virtual kVAh channel data derived from
(kWh, kVARh,
derived kVAh & channel formula) virtual kWh & kVARh channel data
kVA) Virtual Channel
kVAh Derived Usage
(with virtual & kVA Demand
channel formula)

2.3 Incremental Synchronization Interface
2.3.1 Description
SDP attributes can be updated through the Periodic Audit Synchronization Interface, or
the Incremental Synchronization Interface. The purpose of the Incremental
Synchronization interface is to update the MDM/R Master Directory (MMD) as SDP
related attributes and relationships changes are supplied by the LDC to the MDM/R,
based on changes in LDC data source(s). The Incremental Synchronization data file
set may be sent by the LDCs whenever the changes are made, or can be accumulated
throughout the day into a single file set.
This interface is used to:
§ “Create” Service Delivery Point (SDP) objects in the MDM/R Master
Directory. This is a one-time activity completed for every new Universal
SDP ID that has already been “assigned” by the Universal SDP ID
Assignment Request/Response Interface. The SDP object is “created” in
the MDM/R Master Directory along with the attributes sent through this
interface by the LDC. The SDP is created as “active” or “inactive” based on
the attribute information associated with the SDP. A SDP is set ‘inactive” if
only a minimum set of attributes is provided for that SDP. An SDP status is
set to “active” if all SDP attributes that are required to support billing
activities are provided for that SDP. Minimum and additional attributes
required for each SDP are described in detail in Section 3.4 of the MDM/R
Detailed Design Document, SDP Attributes of this document.
§ Update SDP attributes for Universal SDP IDs that already exist in the
MDM/R Master Directory.
The functionality of the Incremental Synchronization Interface is similar to the Periodic
Audit Synchronization defined in Section 15.2 of the MDM/R Detailed Design
Document, Periodic Audit Synchronization Interface. However, the Incremental
Synchronization allows the LDC to update less than the complete set of SDPs, SDP
attributes and relationships.
Section 4 of the MDM/R Detailed Design Document, MDM/R Master Data
Synchronization of this document discusses both Periodic Audit and Incremental
Synchronization. Section 2.3 of the Technical Interface Specifications provides
technical details of this interface.
2.3.2 Integration
2.3.2.1 Direction
LDC to the MDM/R
files.

An Incremental Synchronization File may contain information related to only those
assets whose attributes or relationship data has changed since the last Incremental or
Periodic Audit Synchronization File set.
Version 00 of the Incremental Synchronization consists of the same set of seven files
as Version 01 of the Periodic Audit Synchronization. The seven files are as follows:
§ File No. 00 – A Manifest File, listing each file that is included in the specific
Periodic Audit Synchronization data set submission.
§ File No. 01 – One or more Asset Data Files that describes the primary
attributes associated with an SDP, a Meter, and a Communication Module
§ File No. 02 – One or more Premise Data Files that describes the premise
related attributes (e.g. physical address) associated with an SDP
§ File No. 03 – One or more Service Agreement Data Files that describe the
Framing Structure and Commodity Type associated with an SDP
§ File No. 04 – One or more Parameter Data Files that describes additional
attributes of an SDP or a Meter.
§ File No. 05 – One or more Relationship Data Files that describes the
relationship between two assets or an asset and an organization.
§ File No. 06 – Not Used
(NOTE: The Meter Read Data file has been eliminated from the Version 00
Incremental Synchronization file set. File Number 06 should not be
submitted, and if submitted will not be processed by the MDM/R. First and
last register readings can be submitted using the Meter Read Interface.)
§ File No. 07 – One or more Component SDP Data Files that describes
relationships between virtual and physical SDPs for updates to Virtual
Service Delivery Points.
For Incremental Synchronization Version 00, File Numbers 00, 01, 02, 03, 04 and 05
are mandatory and must be submitted as part of the Incremental Synchronization file
set. These five files must contain a consistent data set for the updates being
submitted, which for some updates may result in an empty file. Thus, not only can a
file consisting of only a File Name Record and a File Header Record be submitted
without any Detail Records, such a file for any one or more of the mandatory files must
be submitted.
In order to allow for the efficient transmission of Synchronization data file sets,
synchronization data files can be split or segmented into multiple smaller files. All
records in a segmented file must be complete. File segmentation can only be between
complete records. Partial records will result in exceptions. For example, an LDC
submitting 1000 records for an Asset Data File could submit a single file with 1000
records, or 10 files with 100 records. These file segments must be appropriately
named (as described in Section 1.8.3 of this document) and the name of each file
submitted in the single Manifest File for the synchronization submission.
The Staging Table Loader (STL) will process each segmented file as submitted in the
Manifest File for Incremental Synchronization Version 00. The segment numbers of
any one file of the file set may have gaps and do not need to be sequential. The STL
does load the data for each of the mandatory files of the sync file set (i.e. files 01, 02,
03, 04 and 05) in a particular order but does not consider order when loading the data
from any one segmented file.

The Incomplete Synchronization File Set Report informs the LDC that their
synchronization file set was not accepted by the MDM/R, The following cases would
result in this condition:
• All files for a particular synchronization file set have not been received after an
allowed length of time and has been rejected;
• The synchronization file set was received out of sequence and is being held,
awaiting for the missing synchronization file set(s) to be submitted;
• The synchronization file set was received out of sequence, the missing
synchronization file set(s) have not been received after an allowed length of
time, and the file set has been rejected.
The Synchronization Staging Table Loader Exception Report provides exceptions for
problems encountered during the staging table loading process which precedes the
synchronization process. Any errors encountered other than errors designated as
“Warning” in the report will result in the termination of the loading of the
synchronization files.
2.3.2.3 Synchronization File Set Sequencing

The “Sequence Number” provided as a mandatory element in the Manifest File Header
Record defines the processing sequence for both Version 01 Periodic Audit
Synchronization and Version 00 Incremental Synchronization file sets. Thus the
“Sequence Number” must be incremented by the LDC for any Periodic or Incremental
file set transmission in the sequence that the LDC intends each Periodic Audit
Synchronization Version 01 and Incremental Synchronization Version 00 file set to be
processed.
The Extracted Date Time of each sequential synchronization file set must be greater
than or equal to the maximum Extracted Date Time from all previously submitted and
successfully processed synchronization file sets. The Extracted Date Time must be
the same in each file of the same synchronization file set.
Periodic and Incremental Synchronization file sets will be processed in numeric
sequence. In the event that an LDC requires a Period or Incremental synchronization
file set to be processed out of sequence (that is, process a synchronization file set that
is not the next file set in sequence), the LDC must communicate to the MDM/R
Operator the Sequence Number (i.e. the value of the “Sequence Number” field in the
Manifest File Header Record) of that synchronization file set. The MDM/R Operator
will manually set the transaction identifier in the MDM/R. Once this is completed, the
LDC can submit the synchronization file set.
NOTE: Once the MDM/R operator manually sets the new transaction identifier, the
LDC cannot submit synchronization file sets with a sequence number less than the
new transaction identifier. If the LDC requires a synchronization file set to be
processed with a transaction identifier less than the new transaction identifier, the LDC
must follow the same process described above. For example, if the most recent
transaction Identifier is 003726 and the LDC requires that the next synchronization file
set to be processed is 003744, the LDC must provide this transaction identifier to the
MDM/R Operator. The MDM/R Operator will change the last transaction identifier
provided to the MDM/R from 003726 to 003743. When this is done, the LDC would be
able to submit synchronization file set transaction identifier 003744. However, the LDC
would not be able to submit synchronization file sets with transaction identifier 003727
through 003743 unless they follow the same process to reset the sequence number.

The synchronization file set transaction identifier will be updated by the MDM/R upon
successful completion of the synchronization process. In the event that the
synchronization process (e.g. file set reported on IR10, file set reported on IR14 as not
successfully loaded, or threshold checks are exceeded) does not complete
successfully the synchronization file set sequence number will not be updated by the
MDM/R.

1. The File Name Record, File Header Record and File Detail Records must be
included for each of the synchronization files for which detail data are
required. Necessary files will be listed in the Manifest File Detail Record.
For each change, the affected detail records will be transmitted per the
Business Scenarios for Incremental Synchronization specified in Section
2.3.9. If there is no change, no detail records will be transmitted.
2. The Max Compare_Max Publish Check is performed for each Incremental
Synchronization. Thresholds for these checks are defined by the LDC during
Enrollment but may be updated based upon operational and business
requirements.
Max Compare_Max Publish Check
This check is performed during the synchronization process on an expanded
set of the synchronization staging tables. For each table, the synchronization
process performs a ‘compare’ to determine the required updates and then
performs a ‘publish’ to make the required updates to the database. The
‘compare’ and ‘publish’ steps are performed sequentially on each table.
Some tables will require these steps to be performed multiple times. For
each table this is performed in two parts:
a. Max Compare Failure – During the compare the number of updates
required is compared to a defined value. If the number of updates
exceeds this value this check has failed, the synchronization process
is terminated, and no updates will be published for the affected
compare step. All updates published for previous steps will not be
reversed in the MMD.
b. Max Publish Failure – During the publish the number of exceptions
incurred is compared to a defined value. If the number of exceptions
exceeds this value this check has failed at the table for which it’s
defined value was exceeded and the synchronization process will
terminate. All updates previously published on the affected publish
step and all updates published on prior tables will not be reversed in
the MMD.
The defined values used for the Max Compare Failure and the Max Publish
Failure are configured for each table for each LDC. (These defined values
are configured separately for P-Sync and I-Sync.) Failure of either check for
any table will result in the following:
any of the MDM/R reports provided to the MDM/R service recipient. The
OSP will initiate communication of the failure through the Service
Management process.

• The MMD updates performed and exceptions incurred prior to the failure
of the check will be returned in the IR06 and IR07 reports.
3. For SDPs that exists in the MDM/R Master Directory and in the Incremental
Synchronization File, the MDM/R replaces the SDP attributes in the MDM/R
with the attributes and relationships for the Universal SDP IDs in the
Incremental Synchronization File.
4. For SDPs that do not exist in the MDM/R Master Directory but are in the
Incremental Synchronization File with valid LDC ID, SDP ID and an assigned
Universal SDP ID, the MDM/R “creates” the SDP and associates any
parameters, service agreements, and relationships that are provided in the
Incremental Synchronization File set.
5. The processed Incremental Synchronization File sent by the LDC is placed in
the Processed Directory in the MDM/R, which is an internal EnergyIP
directory.
a. The MDM/R Synchronization Adapter detects exceptions in regards to
invalid pipe (|) delimited file formats and data type errors.
b. The MDM/R detects exceptions when the LDC Identifier or Universal
SDP ID values are not known by the system.
c. The MDM/R detects exceptions when, in the file, the Universal SDP ID
is associated with an LDC Identifier and SDP ID for which that
Universal SDP ID was not originally assigned.
d. The MDM/R detects exceptions when a Parent interval information
channel within the Component SDP Data format is not a virtual interval
information channel.
e. The MDM/R detects exceptions when a virtual SDP (Type field = ‘V’ in
the Asset Data File) is related to either a physical Meter or a CT/PT
Multiplier.
f. The MDM/R detects exceptions when a synchronization file does not
contain data in a field that is required.
g. The MDM/R detect exceptions when an asset (SDP ID, Meter ID, or
AMCD ID) is provided in the Relationship Data file that does not exist in
the MDM/R or the submitted synchronization file set.
h. The MDM/R detects exceptions when either of the following are true
without the Relationship Start and End Dates being mutually exclusive:
i. Multiple Meters are associated to a given SDP
ii. Multiple Accounts are associated to a given SDP
iii. Multiple CT/PT Multipliers are associated to a given SDP
iv. Multiple Framing Structures are associated to a given
SDP
v. Multiple VEE Services are associated to a given SDP
vi. Multiple AMI Operators are associated to a given SDP
vii. Multiple Billing Agents are associated to a given SDP

viii. Multiple Energy Service providers are associated to a
given SDP
7. Update and exception reports for the Incremental Synchronization are
created with the following detail.
§ The Synchronization Updates Report provides a complete listing of
the records, that were updated via the Incremental Synchronization
process (Refer to Report IR06 in Sections 2.4.6 and 2.4.7 of the
MDM/R Reports Technical Specifications).
§ The Synchronization Exception Report provides a complete listing of
the records that were not updated via the Incremental
Synchronization process because an error occurred (Refer to Report
IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports Technical
Specifications).
The interface creates exception reports and places them in the designated
storage location for the File Transfer Services (FTS) transfer to the LDC.
Rules Affecting Future and Retroactive Dating

The data contained in the synchronization file set represent the condition of the master
data in LDC’s source system(s) at a point in time. This point in time is identified in the
header records of the synchronization file set as the Extracted Date Time. This is the
date and time that the data in the synchronization file set was extracted from the
source system(s). This time will likely be coincident with the time that the
synchronization file set was created.
With the deployment of EnergyIP Release 6.1+ the synchronization file set’s Extracted
Date Time will provide the point in time against which all transactions are evaluated to
determine if such transactions are intended to make changes in the past or in the
future. Periodic Audit Synchronization will only support the submission of Current
State and Future State attribute values. Incremental Synchronization must be used for
Prior State attribute value changes and/or corrections. Incremental Synchronization
supports the Current State, Future State and Prior State synchronization functionality.
Date effective changes are generally state changes related to three specific periods of
time, namely Future State, Current State, and Prior State. Three types of value and/or
date related changes/corrections can be accomplished using the synchronization
process. These are:
§ Future State Value Changes – where the new attribute value is being
supplied with a Start Date/Time that is after the Extracted Date Time. The
Current State attribute value (i.e. the value currently in effect) is also
supplied with its existing Start Date/Time and an End Date/Time that
precedes or aligns with the Start Date/Time of the Future Date attribute
value. The future dated attributes are not considered to be in effect until
the future dated attribute value Start Date/Time has been reached.
§ Current State Value Changes – where the new attribute value is being
supplied with a Start Date/Time that is equal to or after the Start Date/Time
of the existing attribute value (i.e. the value currently in effect) in the MMD
but starts before the Extracted Date Time provided in the synchronization
file set. Once processed, the new attribute value would become the
Current State attribute value with no End Date/Time and the previous

attribute value is ended with an End Date/Time equal to the Start
Date/Time of the supplied new attribute value.
§ Prior State Value and/or Date Corrections – where a series of attribute
values are being supplied with start date/times that are before the Current
State attribute value (i.e. the value currently in effect) already in the MMD
and start before the Extracted Date Time provided in the synchronization
file set. The processing of the new attribute values and dates is intended
to:
o Correct Prior State Values – where previously submitted attribute
values are being corrected but the dates over which these values were
effective is remaining unchanged, or
o Correct Prior State Dates – where previously submitted attribute values
are remaining unchanged (both value and order over time) but the
dates over which they were effective is being corrected, or
o Correct Prior State Value and Date – where both the previously
submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules
8. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync
V00.
9. The Future Dated Value Change must provide the attribute value that is
currently in effect as well as the attribute value that will start at a future
date/time.
10. Subsequent synchronization file set submissions must include the Future
Dated Value Change until it becomes the Current State for that Attribute
Value.
a. All subsequent P-Sync V01 submissions must include the pair of records
until the Future Dated attribute value becomes the Current State Attribute
value (currently in effect).
b. If the Future Dated attribute value is not provided in a subsequent I-Sync
V00 submission then the future dated attribute value will be dropped from
the MMD.
c. Subsequent I-Sync V00 submissions only need to provide the pair of
Future Dated Value Change records if there is a need to change the
contents or effective dates of the Future Dated Value Change records.
Current State Value Change Business Rules
11. Current State Value Changes can be submitted using P-Sync V01 and I-Sync
V00.
start a new Attribute value (to become the value currently in effect):
a. If the new attribute value Start Date Time is greater than the Start Date
Time of the existing attribute value (i.e. the value currently in effect) then
the existing attribute value must be provided with the same Start Date
Time as that existing attribute value stored in the MMD and its new End
Date Time that is equal to or less than the Start Date/Time of the new
attribute value.

b. If the new attribute value Start Date Time is equal to the Start Date Time
of the existing attribute value (i.e. the value currently in effect) then the
existing attribute value must NOT be provided. The synchronization will
end the existing attribute value by setting its End Date/Time equal to the
Start Date/Time of the existing attribute value.
c. If the new attribute value Start Date Time is less than the Start Date Time
of the existing attribute value (i.e. the value currently in effect) and there
are no Prior State records before the existing attribute value, then the
existing attribute value must NOT be provided. The synchronization will
end the existing attribute value by setting its End Date Time equal to the
Start Date Time of the existing attribute value.
13. To end the Current State Attribute value (i.e. the value currently in effect) and
NOT start a new Attribute value
a. The I-Sync records must provide the attribute value that is currently in
effect in the MMD (providing the same Start Date/Time as that existing
attribute value stored in the MMD) and its new End Date/Time.
Prior State Value and/or Date Corrections Business Rules
14. Prior State Value and/or Date Corrections can ONLY be submitted using
I-Sync V00.
15. The series of Prior State attribute value records must provide a complete set
of attribute values with effective date/times to correct the existing attribute
values for that period of time up to and including the Current State attribute
value and Future State attribute value if required.
a. Existing attribute value records that are being replaced by the Prior State
attribute value records must NOT be provided. Any existing attribute
value record that is no longer required once the Prior State attribute value
records are applied will have the End Date Time set equal to the Start
Date Time by the synchronization process.
16. The earliest record in the Prior State correction series submission must
provide an attribute value with a Start Date/Time that aligns with an existing
Prior State attribute value record and its Start Date/Time within the MMD.
The existing prior state attribute value record within the MMD must be in
effect for a period of time where the existing Prior State attribute value record
has a Start Date/Time that is less than it’s End Date Time (i.e. the existing
record value within the MMD must be a value that exists for a non-zero
length of time). This rule applies to the following special cases:
a. Where the series of Prior State attribute value records needs to start
before the Start Date/Time of the first attribute value record within the
MMD then the first record in the series of Prior State attribute value
records can specify a Start Date/Time that predates the earliest Start
Date/Time for the attribute value records in the MMD and the series of
Prior State attribute value records will correct all of the attribute value
records in the MMD for that SDP.
b. Where the series of Prior State attribute value records needs to start after
the Start Date/Time of the first attribute value record within the MMD then
the first record in the series of Prior State attribute value records must be
the earliest attribute value record and its Start Date/Time from the MMD

with its End Date/Time set to be equal to its Start Date/Time. This will
result in the first attribute value record within the MMD being reduced to
being effective for no time since Start Date/Time is an inclusive date/time
and End Date/Time is an exclusive date/time and if these two date/times
are the same then there is no effect period for the record. It will remain in
the MMD for audit purposes only. The remaining records in the series of
Prior State attribute value records will correct all of the attribute value
records in the MMD up to and including the Current State attribute value
record and Future State attribute value if required for that SDP.
2.3.4 Pre-conditions
§ The LDC has requested and has been assigned a Universal SDP ID for
each SDP in the Incremental Synchronization File.
2.3.5 Post-conditions
§ Should the transmission of the synchronization file set be incomplete for
more than the allowed length of time the LDC has received the Incomplete
Synchronization File Set report.
§ The LDC has received the Synchronization Staging Table Loader
Exception Report.
§ SDPs and attribute changes identified in the Incremental Synchronization
File are updated in the MDM/R Master Directory.
§ The LDC has received the updates report and the exceptions report
outlined in section 2.3.3 via File Transfer Services.
2.3.6 Assumptions
§ Information in the Incremental Synchronization File will only be for SDPs
that are or will be associated with Smart Meters
§ With the synchronization file set above, it may be defined that multiple
Measurements can be associated to a given Meter (if that meter is a multi-
channel meter), multiple Interested Parties roles can be associated to a
given SDP, multiple SDPs can be related to a single account
§ With the synchronization file set, it may be defined that multiple Accounts
can be related to a given SDP, multiple Meters can be related to a given
SDP, multiple CT/PT Multipliers can be associated to a given SDP, multiple
Framing Structures can be associated to a given SDP, multiple VEE
services can be associated to a given SDP, multiple AMI operators can be
related to a given SDP, and multiple Billing Agents can be related to a
given SDP. These relationships and associations must have mutually
exclusive start and end dates.

2.3.7 Frequency and Timing
Frequency: The Incremental Synchronization File may be sent as often as needed by
the LDC.
Timing: Incremental Synchronization Files received by 16:00 will be processed by
midnight.
2.3.8 Data Mapping and File Format

The data mapping definitions and the file format layout are as defined in Version 01 of
the Periodic Audit Synchronization Interface.
§ The “Process Mode” field in the Manifest File Header Record will contain
“IncrementalSync” rather than, “PeriodicAuditSync”.
2.3.9 Incremental Synchronization – Impact of Future Deployments

With the deployment of EnergyIP Release 6.3 and the provision of Retroactive / Future
Date support, and the elimination of the Organizational Synchronization and related
EnergyIP GUI Security / Access enhancements, only the modified and expressly
related information for an SDP definition must be provided in the Incremental
Synchronization file set. This results in all required end date related elements being
provided and only the elements that describe the new elements of the SDP being
provided. This “Modified Information Only” approach results in only the information that
is changing and any directly related information being provided. The LDC can choose
to continue providing all elements of the SDP definition.
The Business Scenario Tables 2.3.1 through 2.3.14 have been updated to indicate the
required “Modified Information Only” detail data fields. For ease of reference data
fields that previously were required for each specific scenario are indicated as
“Optional”.
2.3.10 Business Scenarios for Incremental Synchronization

Tables 2.3.1 through 2.3.14 list business scenarios that can happen during the course
of regular business for a LDC, and the Files and detail data Fields that must be
submitted as part of an Incremental Synchronization file set for updates using the
Incremental Synchronization process.
The Data Type/Length, Format, and Description for the fields listed in the tables below
can be found in Section 2.2.16, Periodic Audit Synchronization Version 01.
Table 2.3.1 Business Scenario 1 - Meter Change
File Field Notes

Part 1: Remove the Old Meter from SDP
Asset Record Indicator “Meter”
(The meter asset being Meter ID This is the meter ID of the meter being
ended/removed from the removed from the SDP
SDP must be provided so
that the related Meter to Type This indicates whether this is a physical or
Channel relationships and virtual meter.
Scaling Constant can also Interval Length This is the Interval Length of the old
be ended) Meter
(This is a required element.)
Channel Configuration Set This identifies the set of information
channels to be created for the old meter.

File Field Notes
Scaling Constant This is the Scaling Constant for the old
meter.
Relationship Record Indicator “Relationship”
(This is a required element.) Object 1 The SDP ID that the meter is being
removed from
Relationship Identifier 1 “SDP”
Object 2 The Meter ID that is being removed
Relationship Identifier 2 “METER”
Start Date Time The inclusive start date/time of the
relationship
End Date Time The exclusive end date/time of the
relationship
Asset Record Indicator “Communication Module”
(only applicable to AMCD ID This is the AMCD ID that is related to the
Communication Modules meter being removed.
related to Physical Meters)
AMCC Type This is the AMCC Type that is associated
with the AMCD ID.
(only applicable to Object 1 This is the Meter ID that is being
Communication Modules removed.
Required to correctly end
the related Data Collection Object 2 This is the AMCD ID that is related to the
Service. meter that is being removed.
(This is a required element.) Relationship Identifier 2 “COMMUNICATION MODULE”
Start Date Time This is the inclusive start date/time of the
relationship.
End Date Time This field can be left null if the Meter to
Communication Module Relationship is
being left In-Effect.
OR
This field can provide the exclusive end
date/time if the Meter to Communication
Module Relationship is being ended when
the old meter is removed.
Part 2: Provide the New Meter and all other Mandatory elements of the existing SDP
Asset Record Indicator “SDP”
(OPTIONAL) Universal SDP ID This is the Universal SDP ID that was
assigned to the SDP ID
SDP ID This is the SDP ID that resides in the
LDC’s system of record
Type “P” or “V”, depending on whether the SDP
is Physical or Virtual
Service Status “Y” or “N”, depending if the service is
connected to the SDP or not
Load Status “Y” or “N”, depending if there is load
connected to the meter or not
(This is a required element.) Meter ID This is the meter ID of the meter being
installed
Type This indicates whether this is a physical or
virtual meter.
Interval Length This is the Interval Length of the new

File Field Notes
Meter
channels to be created for the new meter.
Scaling Constant This is the Scaling Constant for the new
meter.
(only applicable to AMCD ID This is the AMCD ID that is being installed
Communication Modules
related to Physical Meters) AMCC Type This is the AMCC Type that is associated
with the AMCD ID.
Parameter Record Indicator “Parameter”
(This only needs to be UDC ID This is the Meter ID that the Dials will be
provided if the new meter associated to
does not already exist)
Param Name “Dials”
Param Value These are the number of dials on the new
meter.
new Dials parameter.
End Date Time This field must be null.
(only applicable to Object 1 This is the Meter ID that is being installed.
related to Physical Meters) Relationship Identifier 1 “METER”
(This is a required element.) Object 2 This is the AMCD ID that is being
installed.
Relationship Identifier 2 “COMMUNICATION MODULE”
relationship.
End Date Time This field is left null.
(OPTIONAL) UDC ID This is the Universal SDP ID that the
VEE Service is associated to
Param Name “VEE Service”
Param Value This is the existing VEE Service.
existing VEE Service parameter.
Part 3: Create relationships between SDP, Meter and Organizations
(This is a required Object 1 The SDP ID that the meter is being added
element.) to
Object 2 This is the Meter ID that is being installed.

relationship.
(OPTIONAL)
Object 1 The SDP ID that the meter is being added
to

File Field Notes
Object 2 This is the Billing Agent for the SDP.

NOTE: Either the LDC Org ID or its Billing
Agent Org ID must be in-effect.
Relationship Identifier 2 “BILLING AGENT”
relationship.
(OPTIONAL) Object 1 The SDP ID that the meter is being added
to
Object 2 This is the AMI Operator for the SDP.
NOTE: Either the LDC Org ID or its AMI
Operator Org ID must be in-effect.
Relationship Identifier 2 “AMI OPERATOR”
relationship
Billing Cycle will be associated to
Param Name “Billing Cycle ID”
Param Value This is the Billing Cycle ID for the
Universal SDP ID.
Billing Cycle ID parameter.
Part 4: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14
(Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.2 Business Scenario 2 - Meter Removal
File Field Notes

Part 1: Remove the Old Meter (provide ONLY the identified elements)
(The meter asset being Meter ID This is the meter ID of the meter being
ended/removed from the removed from the SDP
SDP must be provided so
that the related Meter to Type This indicates whether this is a physical or
Channel relationships and virtual meter.
Scaling Constant can also Interval Length This is the Interval Length of the old
be ended) Meter
channels to be created for the old meter.
Scaling Constant This is the Scaling Constant for the old
meter.
(This is a required element.) Object 1 The SDP ID that the meter is being
removed from

Object 2 The Meter ID that is being removed
Start Date Time The inclusive start date/time of the
relationship
End Date Time The exclusive end date/time of the
relationship
(only applicable to AMCD ID This is the AMCD ID that is related to the
Communication Modules meter being removed
AMCC Type This is the AMCC Type that is associated
with the AMCD ID
(only applicable to Object 1 This is the Meter ID that is being removed
Required to correctly end Object 2 This is the AMCD ID that is related to the
the related Data Collection meter that is being removed
Service.
relationship
End Date Time This field can be left null if the Meter to
Communication Module Relationship is
being left In-Effect
OR
This field can provide the exclusive end
date/time if the Meter to Communication
Module Relationship is being ended when
the old meter is removed
Table 2.3.3 Business Scenario 3 - Add new meter
File Field Notes

Part 1: Create the New Meter
(This is a required element.) Meter ID This is the meter ID of the meter being
installed
virtual meter.
Interval Length This is the Interval Length of the new

File Field Notes
Meter
channels to be created for the new meter.
meter.
(only applicable to AMCD ID This is the AMCD ID that is being installed
with the AMCD ID
(This is a required element.) UDC ID This is the Meter ID that the Dials will be
associated to
Param Value These are the number of dials on the new
meter
new Dials parameter
End Date Time This field must be null
(only applicable to Object 1 This is the Meter ID that is being installed
(This is a required element.) Object 2 This is the AMCD ID that is being installed
relationship
End Date Time This field is left null
(OPTIONAL) UDC ID This is the Universal SDP ID that the VEE
Service is associated to
Param Value This is the existing VEE Service
VEE Service parameter
Part 2: Create relationships between SDP, Meter and Organizations
Relationship Record Indicator “Relationship
(This is a required element.) Object 1 The SDP ID that the meter is being added
to
Object 2 This is the Meter ID that is being installed
relationship
(OPTIONAL)
Object 1 The SDP ID that the meter is being added
to

File Field Notes
Object 2 This is the Billing Agent for the SDP.

relationship
(OPTIONAL) Object 1 The SDP ID that the meter is being added
to
Object 2 This is the AMI Operator for the SDP.
relationship
Parameter Record Indicator “Parameter
(Mandatory if Scheduled UDC ID This is the Universal SDP ID that the
“PUSH” is used for Billing Billing Cycle will be associated to
Quantities)
Param Value This is the Billing Cycle ID for the
Universal SDP ID
Billing Cycle ID parameter
Table 2.3.4 Business Scenario 4 - Service Cut at Pole
File Field Notes

Part 1
(This is a required element.) Universal SDP This is the Universal SDP ID associated
with the SDP where the meter was cut at
the pole
SDP ID The is the SDP ID associated with the
SDP where the meter was cut at the pole
Type “P”
Service Status “N”
Load Status This will be either “Y” or “N”, which ever
status is currently true for the SDP.

Table 2.3.5 Business Scenario 5 - Booting a Meter
File Field Notes

Part 1
(This is a required element.) Universal SDP This is the Universal SDP ID associated
with the SDP where the meter was booted
SDP ID The is the SDP ID associated with the SDP
where the meter was booted
Type “P”
Service Status This will be either “Y” or “N”, which ever
status is currently true for the SDP.
Load Status “N”
Table 2.3.6 Business Scenario 6 - Framing Structure Change
File Field Notes

Part 1: End the existing Framing Structure
Service Agreement Record Indicator “Service Agreement”
(This is a required element.) Commodity “E”
Framing Structure ID This is the existing Framing Structure ID
Universal SDP ID This is the Universal SDP ID associated
with the existing Framing Structure
Universal SDP ID to Framing This is the inclusive start date/time of the
Structure Relationship Start Date existing Framing Structure
Universal SDP ID to Framing This is the exclusive end date/time of the
Structure Relationship End Date existing Framing Structure
Part 2: Start the new Framing Structure
Framing Structure ID This is the new Framing Structure ID
Universal SDP ID This is the Universal SDP ID to be
associated with the new Framing
Structure
Structure Relationship Start Date new Framing Structure. The start
date/time should be equal to the end
date/time of the existing Framing
Structure
Universal SDP ID to Framing This field must be null
Structure Relationship End Date
Object 1 The Universal SDP ID that the meter is
NOTE: The new Framing being added to
Structure will not show in
the GUI Account Tab if an
SDP to Account Object 2 This is the Account ID that is associated
Relationship is not in-effect. with the Universal SDP ID
Relationship Identifier 2 “ACCOUNT”
(OPTIONAL)

File Field Notes
relationship
Part 3: If the Framing Structure Change also results in a change of the Energy Service Provider then
end the existing relationship between the SDP and the existing Energy Service Provider (Retailer). Start
the new relationship between the SDP and the new Energy Service Provider. This is only necessary if
the Energy Service Provider must be changed on the SDP
(OPTIONAL) Object 1 This is the Universal SDP ID that the
Energy Service Provider is associated to
Object 2 This is the existing Energy Service
Provider for the SDP
NOTE: The SDP to ENERGY SERVICE
services access is granted for each SDP.
LDCs may use this relationship to provide
data access to a Retailer organization for
which a customer is signed up with the
Retailer.
Relationship Identifier 2 “ENERGY SERVICE PROVIDER”
relationship
End Date Time This is the exclusive end date/time of the
relationship
Relationship Record Indicator “Relationship
Object 2 This is the new Energy Service Provider
for the SDP
Retailer.
Start Date Time This is the inclusive start date of the
relationship
Table 2.3.7 Business Scenario 7 - Billing Cycle ID Change
File Field Notes

Part 1: End the existing Billing Cycle
(This is a required element.) UDC ID This is the Universal SDP ID that the
Billing Cycle is associated to

File Field Notes
Param Value This is the existing Billing Cycle ID
existing Billing Cycle ID parameter
existing Billing Cycle ID parameter
Part 2: Start the new Billing Cycle
Billing Cycle will be associated to
Param Value This is the new Billing Cycle ID
new Billing Cycle ID parameter
Table 2.3.8 Business Scenario 8 - VEE Service Change
File Field Notes

Part 1: End the existing VEE Service
(This is a required element.) UDC ID This is the Universal SDP ID that the VEE
Service is associated to
Param Value This is the existing VEE Service
existing VEE Service parameter
existing VEE Service parameter
Part 2: Start the new VEE Service
(This is a required element.) UDC ID This is the Universal SDP ID that the VEE
Service will be associated to
Param Value This is the new VEE Service
new VEE Service parameter

File Field Notes
(OPTIONAL) Meter ID This is the meter ID of the existing Meter
virtual meter.
Interval Length This is the Interval Length of the existing
Meter
channels related to the existing Meter.
Scaling Constant This is the Scaling Constant for the
existing meter.
(OPTIONAL) Object 1 The Universal SDP ID that the meter is
being added to
Object 2 This is the Meter ID that is installed
relationship
Object 1 The Universal SDP ID that the meter is
NOTE: The new VEE being added to
Service will not show in the
GUI Account Tab if an SDP
to Account Relationship is Object 2 This is the Account ID that is associated
not in-effect. with the Universal SDP ID
(OPTIONAL)
relationship
Table 2.3.9 Business Scenario 9 - CT/PT Multiplier Change
File Field Notes

Part 1: End the existing CT/PT Multiplier
(This is a required element.) UDC ID This is the Universal SDP ID that the CT/PT
multiplier is associated to
Param Name “CT/PT Multiplier”
Param Value This is the existing CT/PT multiplier
SDP to CT/PT Multiplier relationship
SDP to CT/PT Multiplier relationship
Part 2: Start the new CT/PT Multiplier

File Field Notes
(This is a required element.) UDC ID This is the Universal SDP ID that the CT/PT
multiplier will be associated to
Param Value This is the new CT/PT multiplier
CTPT relationship
Table 2.3.10 Business Scenario 10 - Account Change
File Field Notes

Part 1: End relationship between the SDP and the existing Account
(This is a required element.) Object 1 This is the Universal SDP ID that the
existing account is associated to
Object 2 This is the Account ID that is currently

associated to the SDP
relationship
relationship
Part 2: Start relationship between the SDP and the new Account
(This is a required element.) Object 1 This is the Universal SDP ID that the new
account is associated to
Object 2 This is the new Account ID that is to be
relationship
Part 3: If the old Account was under a Retailer Contract then end the existing relationship between the
SDP and Energy Service Provider (Retailer). Start the new relationship between the SDP and Energy
Service Provider. This is only necessary if the Energy Service Provider must be changed on the SDP
existing Energy Service Provider is
associated to
Object 2 This is the existing Energy Service Provider
for the SDP

File Field Notes
Retailer.
SDP to Energy Service Provider
relationship
relationship
Object 2 This is the new Energy Service Provider for
the SDP
Retailer.
relationship
(OPTIONAL) Commodity “E”
Framing Structure ID This is the Framing Structure ID.
Universal SDP ID This is the Universal SDP ID associated
with the Framing Structure
Structure Relationship Start Date relationship
Table 2.3.11 Business Scenario 11 - Billing Agent Change
File Field Notes

Part 1: End relationship between the SDP and the existing Billing Agent
(OPTIONAL) Universal SDP This is the Universal SDP ID associated
with the SDP where the Billing Agent
change is taking place
SDP ID This is the SDP ID associated with the SDP
where the Billing Agent change is taking
place

File Field Notes
Type “P” or “V”, depending on whether the SDP is
Physical or Virtual
Service Status This is whatever Service Status is
associated with the SDP
Load Status This is whatever Load Status is associated
with the SDP
(OPTIONAL) Meter ID This is the meter ID of the existing meter
Type “P” or “V”, depending on whether the Meter
meter
channels associated with the existing meter.
Scaling Constant This is the Scaling Constant for the existing
meter
(only applicable to AMCD ID This is the AMCD ID
with the AMCD ID
(OPTIONAL)
existing Billing Agent is associated to
Object 2 This is the Billing Agent’s Organization ID
that is currently associated to the SDP.
relationship
relationship
Part 2: Start relationship between the SDP and the new Billing Agent
(This is arequired element.) Object 1 This is the Universal SDP ID that the new
Billing Agent is being associated to
Object 2 This is the new Billing Agent’s Organization
ID that is to be associated to the SDP.
relationship
(OPTIONAL) Object 1 This is the Universal SDP ID that the AMI
Operator is associated to
Object 2 This is the existing AMI Operator’s

File Field Notes
Organization ID that is associated to the
SDP.
existing AMI Operator relationship
associated to
Object 2 This is the existing Meter ID that is

relationship
Object 1 This is the Universal SDP ID that the new
NOTE: The new Billing Billing Agent is being associated to
Agent will not show in the
GUI Account Tab if an SDP
to Account Relationship is Object 2 This is the Account ID that is currently
not in-effect. associated with the Universal SDP ID that
the new Billing Agent is being associated to
(OPTIONAL) Relationship Identifier 2 “ACCOUNT”
relationship
(only applicable to Object 1 This is the Meter ID that is currently
Communication Modules associated with the Universal SDP ID that
related to Physical Meters) the new Billing Agent is being associated to
(OPTIONAL)
Object 2 This is the AMCD ID that is currently
associated with the Meter ID that is
currently associated with the Universal SDP
ID that the new Billing Agent is being
associated to
relationship

Table 2.3.12 Business Scenario 12 - AMI Operator Change
File Field Notes

Part 1: End relationship between the SDP and the existing AMI Operator
(OPTIONAL) Universal SDP This is the Universal SDP ID associated
with the SDP where the AMI Operator
change is taking place
SDP ID This is the SDP ID associated with the
SDP where the AMI Operator change is
taking place
Service Status This is whatever Service Status is
Load Status This is whatever Load Status is
(OPTIONAL) Meter ID This is the Meter ID associated with the
SDP where the AMI Operator change is
taking place
Type “P” or “V”, depending on whether the
Meter is Physical or Virtual
meter
channels associated with the existing
meter.
Scaling Constant This is the Scaling Constant for the
existing meter
Asset Record Indicator “COMMUNICATION MODULE”
(only applicable to AMCD ID This is the AMCD ID
with the AMCD ID
(OPTIONAL)
existing AMI Operator is associated to
Object 2 This is the AMI Operator’s Organization
ID that is currently associated to the SDP.
relationship
relationship
Part 2: Start relationship between the SDP and the new AMI Operator
AMI Operator is being associated to
Object 2 This is the new AMI Operator’s
Organization ID that is to be associated to

File Field Notes
the SDP.
relationship
Billing Agent is associated to
Object 2 This is the existing Billing Agent’s
Organization ID that is associated to the
SDP.
existing Billing Agent relationship
associated to
Object 2 This is the existing Meter ID that is
installed
relationship
Object 1 This is the Universal SDP ID that the new
NOTE: The new AMI AMI Operator is being associated to
Operator will not show in
the GUI Account Tab if an
SDP to Account Object 2 This is the Account ID that is associated
Relationship is not in-effect. with the Universal SDP ID the new AMI
Operator is being associated to
(OPTIONAL) Relationship Identifier 2 “ACCOUNT”
relationship
(only applicable to Object 1 This is the existing Meter ID that is
Communication Modules installed
(OPTIONAL) Object 2 This is the existing AMCD ID that is
installed
relationship

File Field Notes
Table 2.3.13 Business Scenario 13 – Energy Service Provider (Retailer) Change
File Field Notes

Part 1: End relationship between the SDP and the existing Energy Service Provider
existing Energy Service Provider is
associated to
Object 2 This is the Energy Service Provider’s
Organization ID that is currently associated
to the SDP
Retailer.
relationship
relationship
(only end the existing Commodity “E”
Framing Structure if Framing
Structure is changing when Framing Structure ID This is the existing Framing Structure ID
the Energy Service Provider Universal SDP ID This is the Universal SDP ID associated
relationship is changing) with the Framing Structure
(OPTIONAL) Structure Relationship Start Date relationship
Universal SDP ID to Framing This is the exclusive end date/time of the
Structure Relationship End Date relationship
Part 2: Start relationship between the SDP and the new Energy Service Provider
Energy Service Provider is being
associated to
Object 2 This is the new Energy Service Provider’s
Organization ID that is to be associated to
the SDP
Retailer.

File Field Notes
new SDP to Energy Service Provider
relationship
Commodity “E”
(OPTIONAL)
Framing Structure ID This is the Framing Structure ID associated
with the SDP that the new Energy Service
Provider is being associated with.
If the Framing Structure was not ended in
the previous step, then this will be the
existing Framing Structure ID and it’s Start
Date will be it’s existing start date/time.
If the Framing Structure was ended in the
previous step, then this is the new Framing
Structure ID and the Start Date will be the
new start date/time.
Universal SDP ID This is the Universal SDP ID that the
Framing Structure will be associated with
Structure Relationship Start Date relationship
Table 2.3.14 Business Scenario 14 – Provide all elements that define an SDP in order to
either: Create a New SDP; OR Provide the definition of an existing SDP.
File Field Notes

Part 1: Provide Assets: SDP, Meter and Communication Module
(This is a required element.) Universal SDP ID This is the Universal SDP ID that was
SDP is Physical or Virtual
(This is a required element.) Meter ID This is the meter ID of the new or
existing meter associated with the
Universal SDP ID being provided under
this scenario
Meter is Physical or Virtual
Interval Length This is the Interval Length of the new or
existing meter
channels associated with the new or

File Field Notes
existing meter. Optional – defaults to ‘01’
– kWh related channels only.
or existing meter. Optional – defaults to
‘1.00’
Asset Record Indicator “COMMUNICATION MODULE”
(only applicable to AMCD ID This is the AMCD ID of the new or
Communication Modules existing Communication Module
related to Physical Meters) associated with the Meter ID being
(This is a required element.) provided under this scenario
AMCC Type This is the AMCC Type that is
associated with the AMCD ID
Part 2: Provide Premise: for new or existing Premise
Premise Record Indicator “Premise”
(This is a required element.) Universal SDP ID This is the Universal SDP ID associated
with the premise
Premise Address This is the address, or other value as
determined by the LDC, that the SDP
resides at
City This is the city, or other value as
resides in
Province This is the province, or other value as
resides in
Postal Code This is the postal code, or other value as
resides in
Time Zone “EST” or “CST”, depending on the time
zone the SDP resides in
Part 3: Provide mandatory SDP and Meter Parameters for new or existing SDPs
(Mandatory if Scheduled UDC ID This is the Universal SDP ID that the
“PUSH” is used for Billing parameter will be associated to
Quantities)
Param Value This is the Billing Cycle ID
Start Date Time This is the inclusive start date/time for
the new or existing Billing Cycle ID
parameter
End Date Time This must be null
parameter will be associated to
Param Value This is the VEE Service
the new or existing VEE Service
parameter
(Mandatory for Physical UDC ID This is the Meter ID that the parameter
Meters only) will be associated to

File Field Notes
Param Value This is the number of dials
the number of Dials associated with this
new or existing Meter
Part 4: Provide Framing Structure for new or existing SDPs
Framing Structure ID This is the Framing Structure that will be
Universal SDP ID This is the Universal SDP ID that the
Framing Structure will be associated with
Universal SDP ID to Framing Structure This is the inclusive start date/time for
Relationship Start Date the new or existing Framing Structure
Universal SDP ID to Framing Structure This must be null
Relationship End Date
Part 5: Provide relationships between SDP, Meter, Communication Module and Organizations for new or
existing SDPs
(This is a required element.) Object 1 This is the Universal SDP ID that will be
associated with the new or existing
meter
Object 2 This is the new or existing Meter ID that
will be associated with the SDP
the new or existing relationship
(OPTIONAL) Object 1 This is the Universal SDP ID that will be
NOTE: The Framing account
Structure; VEE Service; Billing Relationship Identifier 1 “SDP”
Agent, and AMI Operator will
not show in the GUI Account Object 2 This is the new or existing Account ID, or
Tab if an SDP to Account other value that the LDC determines will
Relationship is not in-effect. be associated with the SDP
(only applicable to Object 1 This is the Meter ID that will be
Communication Modules associated with the Communications
related to Physical Meters) Module
Object 2 This is the AMCD ID that will be
Meter

File Field Notes
Billing Agent
Object 2 This is the Billing Agent Organization ID
that will be associated with the SDP.
NOTE: Either the LDC Org ID or its
Billing Agent Org ID must be in-effect.
associated with the new or existing AMI
Operator
Object 2 This is the AMI Operator Organization ID

that will be associated with the SDP
Object 1 This is the Universal SDP ID that will be
(OPTIONAL) associated with the new or existing
Energy Service Provider
Object 2 This is the Energy Service Provider
Organization ID that will be associated
with the SDP
LDCs may use this relationship to
provide data access to a Retailer
organization for which a customer is
signed up with the Retailer.
Start Date Time This is the inclusive stat date/time for the
new or existing relationship
Part 6: Create new or provide existing Component SDP related elements of Virtual SDPs
Channel to Channel Record Indicator “Channel to Channel”
Relationship
Parent Universal SDP ID This is the Parent Universal SDP ID
(Only applicable to Virtual associated with the contributing Member
SDPs.) Universal SDP ID below.

File Field Notes
Parent Unit of Measurement This is the unit of measurement for the
Parent of the Channel to Channel
Relationship. The Parent is always a
Virtual Interval Channel.
Parent Interval Length This is the interval length for the Parent
of the Channel to Channel Relationship.
The Parent is always a Virtual Interval
Channel.
Member Universal SDP ID The contributing Member of the Channel
to Channel Relationship can be either a
Physical Interval Channel which can
exist on a physical SDP or a Virtual
Interval Channel existing on a Physical
SDP or Virtual SDP depending on the
specified Meter Asset – “Channel
Configuration Set”.
Member Unit of Measurement This is the unit of measurement for the
contributing Member of the Channel to
Channel Relationship.
Member Interval Length This is the interval length for the
Channel Relationship. The contributing
Member can be a Physical Interval
Channel or a Virtual Interval Channel.
Member Alias This is a symbolic name for the
Channel Relationship. The Alias is used
in the “Formula Expression” provided in
the related “Channel to Formula” record.
Channel to Channel Relationship Start This is the inclusive date/time for which
Date the Parent Interval Channel to
contributing Member Interval Channel
relationship starts.
Channel to Channel Relationship End This is the exclusive date/time for which
Date the Parent Interval Channel to
contributing Member Interval Channel
relationship ends.
Channel to Formula Record Indicator “Channel to Formula”
Relationship
Parent Universal SDP ID This is the Parent Universal SDP ID
(Only applicable to Virtual associated with the Parent Interval
SDPs.) information channel.
Parent Unit of Measurement This is the unit of measurement for the
Parent of the Channel to Formula
Relationship. The Parent is always a
Virtual Interval Channel.
Parent Interval Length This is the interval length for the Parent
of the Channel to Formula Relationship.
The Parent is always a Virtual Interval
Channel.
Formula Type This field identifies the type of calculation
to be performed with the result stored in
the identified Parent Interval Information
Channel.
Channel to Formula Relationship Start This is the inclusive date/time for which
Date the Parent Interval Channel to Formula
relationship starts.
Channel to Channel Relationship End This is the exclusive date/time for which
Date the Parent Interval Channel to Formula
relationship ends.

File Field Notes
Formula Expression This is the Formula Expression that will
be evaluated when the Formula Type is
specified as ‘Expression’.
Part 7: Create new or provide existing optional elements of an SDP
Param Name “Loss Factor Classification”
Param Value This will be used to drive aggregation.
the Loss Factor Classification associated
with this new or existing SDP
Param Name “Service Volts”
Param Value Volts of the service to the SDP.
the Service Volts associated with this
new or existing SDP
Param Name “Service Amps”
Param Value Amps of the service to the SDP.
the Service Amps associated with this
new or existing SDP
Param Name “Service Phases”
Param Value Phase of the service to the SDP.
the Service Phase associated with this
new or existing SDP
Param Name “Service Form”
Param Value Service wires i.e. 3 phase 4 wire, 3
phase 3 wire.
the Service Form associated with this
new or existing SDP

File Field Notes
Param Name “Dem-firm #1”
Param Value Placeholder for future demographic data.
the Demographic-Firmographic #1 value
associated with this new or existing SDP
Param Name “IVR PIN”
Param Value A number assigned by the LDC to permit
the current Customers access to their
meter read and Billing Quantity data via
the IVR
the IVR PIN associated with this new or
existing SDP

File Field Notes
Param Value The multiplier that should be applied to
the metering data received from the
AMCC.
the CT/PT Multiplier associated with this
new or existing SDP
(OPTIONAL) UDC ID This is the Meter ID that the parameter
will be associated to
Param Name “Meter Volts”
Param Value Volts of the Meter.
the Meter Volts associated with this new
or existing Meter
Param Name “Meter Amps”
Param Value Amps of the Meter.
the Meter Amps associated with this new
or existing Meter
Param Name “Meter Phases”
Param Value Phase of the Meter.
the Meter Phase associated with this
new or existing Meter
Param Name “Meter Form”
Param Value This is the meter form factor for the SDP
as defined by the ANSI C12.10 standard
(i.e. 2S, 16S, etc).
the Meter Form associated with this new
or existing Meter
(OPTIONAL) Object 1 This is the Universal SDP ID that will be
associated with the new or existing CCA
Service Provider
Object 2 This is the CCA Service Provider

Organization ID that will be associated

File Field Notes
with the SDP
Relationship Identifier 2 “CCA SERVICE PROVIDER”


2.4 Billing Service Standard Interface - Request
Note: This new Billing Service Standard Interface Request will replace the existing
Billing Quantity Request and will be developed and deployed to support the MDM/R
Universal Solution for verification and reconciliation of billing quantities based on
Measurement Canada approved meter registrations.
2.4.1 Description
The EnergyIP Billing Service Standard Interface is used to retrieve Billing Quantity data
for an SDP for a specific time span. Using this interface an LDC or its Billing Agent
can schedule an on-cycle billing request, schedule an off-cycle billing request, retrieve
billing determinants for billing purposes or for information only.
The MDM/R supports two methods for preparing Billing Quantity data to send to LDCs
or their billing agents. An LDC or its billing agent may choose to use one or the other
method based on operational requirements:
§ Request-Response Billing Data Service (request-response) method delivers
Billing Quantity data in response to a request from the LDC or its billing agent
using this EnergyIP Billing Service Standard Interface RequestMessage. This
method is used for requesting Billing Quantity data for both on-cycle and off-cycle
billing.
§ Scheduled Billing Data Service (PUSH) method, which provides the Billing
Quantity data automatically based on a billing cycle attribute attached to the SDP.
This method can be used for scheduled billing cycles only where the SDP data
required to properly prepare the billing quantities has been synchronized by the
LDC or its billing agent with the MDM/R. The EnergyIP Billing Service Standard
Interface RequestMessage is not required to be used by this method.
2.4.2 Integration
LDC or their Billing Agent to the MDM/R
This is a batch process involving the transfer and processing of the EnergyIP Billing
Service Standard Interface RequestMessage files in an .xml file format using the
EnergyIP BillingXmlFileImportAdaptor.
2.4.3 Business Rules

1. The following checks are performed:
a. The SDP must have a Framing Structure that specifies the framing of interval
data into TOU/CPP, Periodic or Hourly kWh energy quantities. The
applicable Framing Structures are as specified in the Technical Interface
Specifications, Section 2.2.8, Table 2.2.13.
b. The RequestMessage must be submitted by the organization (either the LDC
or its Billing Agent) associated with the Billing Service for the SDP. The SDP
to BILLING AGENT Relationship must be the in-effect relationship for the

submitting organization for each SDP as submitted in the Relationship Data
file of the Synchronization file set.
c. The request must have a valid end date/time for the requested billing period
for each SDP.
d. If the request has a start date/time for the requested billing period, the start
date/time for the requested billing period must be prior to the requested end
date/time.
2. The duration of the billing period for the Billing Quantity data will be determined in
one of two ways:
a. The LDC (or its Billing Agent) includes the request startTime and the request
endTime in the RequestMessage / Request. The start date and time in each
request is inclusive, and the end date and time in each request is exclusive.
b. The LDC (or its Billing Agent) includes only the request endTime in the
RequestMessage / Request. In this case the startTime for the request will
equal the date and time of the endTime of the billing period for the previous
billing period response.
3. With the deployment of EnergyIP Release 7.1 the notion of “Billing Window” is re-
defined as a “Register Read Billing Window” and an additional request
“Execution Window” is introduced (replacing the earlier notion of “Billing
Window”). Billing quantity request processing utilizes these two windows or
timeframes as follows:
• Register Read Billing Window – This is the range of time when a register
reading must occur to be considered an acceptable end register reading
to be used in the billing quantity response.
• Execution Window – This is the range of time during which a billing
quantity request remains active.
4. For each request the Register Read Billing Window is determined by the
RequestMessage endTime and the billing service properties.
• The request message endTime sets the date and time of the anchor point
around which the Register Read Billing Window is set by the following
billing service properties.
• AllowableReadAge (for on-cycle requests) or OffCycleAllowableReadAge
(for off-cycle requests) defines the timeframe before the request message
endTime within which a register reading is valid for billing quantity
processing.
• Read Window – Max (for on-cycle requests) or OffCycle Read Window –
Max (for off-cycle requests) defines the timeframe after the request
message endTime within which a register reading is valid for billing
quantity processing.
5. For each request the Execution Window is determined by the RequestMessage
endTime and the following combinations of the billing service properties and the
RequestMessage processStartDate and processEndDate.
i. The request message endTime sets the Execution Window start date and
time. The Execution Window end date and time is set by the request
message endTime plus the LatestReportDays (for on-cycle requests) or the

OffCycleLatestReportDays (for off-cycle requests). This Execution Window
can be modified for each request by including the processStartDate and
processEndDate as follows:
ii. The processStartDate is a date and time specified by the LDC (or its Billing
Agent) at which to start processing of the request. If the request includes a
processStartDate without a processEndDate, the end date and time of the
Execution Window is the processStartDate plus the LatestReportDays (for
on-cycle requests) or the OffCycleLatestReportDays (for off-cycle requests).
iii. If the processStartDate and processEndDate is specified in the request by
the LDC (or its Billing Agent) then the start date and time of the Execution
Window is the request processStartDate and the end date and time of the
Execution Window is the request processEndDate. When both
processStartDate and processEndDate are specified in the request the billing
service properties are not used.
6. For each request ODEST exception handling (if enabled) is determined by the
RequestMessage endTime and the following combinations of the billing service
properties and the RequestMessage processStartDate and processEndDate.
i. The start date and time for the ODEST process is set by the request
message endTime plus the TriggerAfterDays (for on-cycle requests) or the
OffCycleTriggerAfterDays (for off-cycle requests). The ODEST process start
can be modified for each request by including the processStartDate and
processEndDate as follows:
ii. The processStartDate is a date and time specified by the LDC (or its Billing
Agent) at which to start processing of the request. If the request includes a
processStartDate without a processEndDate, the start date and time of the
ODEST process is the processStartDate plus the TriggerAfterDaysDays (for
on-cycle requests) or the OffCycleTriggerAfterDays (for off-cycle requests).
iii. When the processStartDate and processEndDate is specified in the request
by the LDC (or its Billing Agent) the date time for the request
processEndDate must be greater than the date and time of the
processStartDate plus the TriggerAfterDays (for on-cycle requests) or the
request processStartDate plus the OffCycleTriggerAfterDays (for off-cycle
requests). The ODEST process will not initiate if the request
processEndDate is less than the request processStartDate plus the
TriggerAfterDays (for on-cycle requests) or the request processStartDate
plus the OffCycleTriggerAfterDays (for off-cycle requests).
a. EnergyIP detects exceptions when the Universal SDP ID value is not
submitted in the billing quantity request.
b. EnergyIP detects exceptions when the LDC ID or Universal SDP ID values
are not known by the system.
c. EnergyIP detects exceptions when the Universal SDP ID is associated with
an LDC ID and SDP ID for which that Universal SDP ID was not originally
assigned.
d. EnergyIP detects exceptions when mandatory attributes of the
RequestMessage are not provided.

e. EnergyIP detects exceptions when the billing quantity request does not have
a request endTime.
f. EnergyIP detects exceptions when the billing quantity request startTime or
endTime malformed or is an invalid date.
g. EnergyIP detects exceptions when the request startTime is greater than the
request endTime.
h. EnergyIP detects exceptions when there is not an associated Billing Service
for the SDP during the requested date range.
i. EnergyIP detects exceptions when the requesting organization (i.e. the LDC
or its Billing Agent) is not the currently in-effect organization defined by the
SDP to BILLING AGENT Relationship associated with the Billing Service for
the SDP.
8. The following Billing Quantity Request exception report is created:
§ The Billing Request Detailed Exception Report has error message(s) for
each rejected record explaining the reason. (Refer to Report IR08 in
Section 2.4.10 of the MDM/R Reports Technical Specifications).
storage location for the File Transfer Services (FTS) transfer to the LDC or Billing
Agent.
§ The LDC is enrolled and has an Organization ID assigned.
§ The LDC has requested and received Universal SDP IDs for each SDP.
§ The Billing Agent is enrolled and has an Organization ID assigned.
§ The SDP to BILLING AGENT Relationship is associated with the LDC or its
Billing Agent.
§ The SDP is “created” with the corresponding attributes in the MDM/R Master
Directory through the synchronization process.
§ The SDP must have an Energy Purchase Service with a Framing Structure
identified.
§ The SDP must have a VEE service.
§ The Billing Service Loader (BSL) calculates the Register Read Billing
Window and the request Execution Window.
§ Valid Billing Quantity requests are passed to the Billing Service Reads
Processor (BSRP).
§ The LDC and/or their Billing Agent receive Report IR08: Billing Request
Detailed Exception Report via File Transfer Services.

2.4.6 Assumptions
Additional attributes will be added to the XML request/reply to provide validation of the
SDP to Billing Agent Relationship and to provide an external file identifier utilizing the
‘EXTNL_BATCH_ID’ in the ‘billing_request’ table schema to support the .xml file format.

Frequency: This interface is triggered by the submission of a Billing Service Standard
Interface RequestMessage file from the LDC or its Billing Agent.
Timing: None
2.4.8 File Format

2.4.8.1 File Name Record for the Billing Service RequestMessage File
Table 2.4.1 FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE

<FTSFN>
</FTSFN>

2.4.8.2 Request Message

The RequestMessage portion of the EnergyIP billing service standard interface
includes the two elements listed below. Refer to the diagram that follows for an XML
schema view of these elements.
§ Header – Contains general, descriptive information about the message
payload.
§ Request – Contains the details regarding the request.

Table 2.4.2 REQUEST MESSAGE HEADER – RequestMessage/Header
Data Type/
<Attribute> Format Required Description
Length
<?xml version=“1.0” encoding=“UTF-8”?>
<XML declaration> Specific Usage: Y Defines the XML version and
<?xml version=“1.0” the character encoding used in
encoding=“UTF-8”?> the document
<tns:RequestMessage>
<tns:RequestMessage> Specific Usage: Y Location of the xml name space
xmlns=“http:/www.eme
ter.com/energyip/reads
forbillinginterface2”xml
ns:xsi=“http:/www.w3.o
rg/2001/XMLSchema-
instance”xsi:schemaLo
cation=”http://www.em
eter.com/energyip/read
sforbillinginterface2Eip
ReadsForBillingInterfa
ce2.xsd”
<tns:Header>
<tns:verb> String Specific Usage: Y Must be set to the literal
“create” “create”.
<tns:noun> String Specific Usage” Y Main subject of message.
One of: Must be set to the literal
“ReadsForBilling” “ReadsForBilling,” if the billing
or response is to be used for billing
purposes.
“ReadsForBilling
Informational” or “ReadsForBilling
Informational” if it is to be used
for information only purposes.
Note: The “ReadsForBilling”
literal sets the
‘USED_FOR_BILLING’ flag in
the ‘register-read’ table for
Register Read data and the
‘SENT_FOR_BILLING_MILEST
ONE_DATE’ on the SDP Asset
for Interval data when billing
quantity data is successfully
exported. These data flags
generate billing data change
events and are the triggers for
the BR03 Re-Billing Report
when flagged Register Read
data or Interval data changes.
Use of the “ReadsForBilling
Informational” literal does not
set these flags for Register
Reads or Interval data when “for
information” billing quantity data
is successfully exported.
<tns:revision> String Specific Usage: Y Revision level of message type.
“2” The version of the request
message xml.
Must be set to “2”.
<tns:dateTime> Date/Time Standard XML N The date/time when the request
ISO8601 Date format was initiated in EST
with full timezone
qualification will be
used:

Data Type/
Length
YYYY-MM-
DDTHH:MI:SS.sss[[+|-
]TZH:TZM]
Example:
“2008-04-31T12:00:00-
05:00”
<tns:source> Varchar (100) Example: Y This value will be populated in
“ABC8642” the ‘LAST_UPD_BY’ field of
‘billing_request’ table.
This RequestMessage / Header
<source> value is returned as
the value for the ReplyMessage
/ Header <source> attribute. Comment [MS1]: To be confirmed by testing.
Expected values TBD.
<tns:messageID> Varchar (30) General: N Unique identifier used to co-
AAAAAAAAAAA relate this request with its
response and for other tracking
purposes.
This ID is provided by the
requestor and stored as the
‘EXTNL_BILLING_REQUEST_I
D’ in the ‘billing_request’ table.
</tns:Header>
Table 2.4.3 REQUEST MESSAGE – RequestMessage/Request
Data Type/
Length
<tns:Request>
<tns:startTime> Date/Time Standard XML N Start date and time for
ISO8601 Date format requested billing period in EST.
with full timezone If not provided, previous bill
qualification will be period end time will be the start
used: time for the request if billing
YYYY-MM- quantities have been
DDTHH:MI:SS.sss[[+|- successfully exported for a prior
]TZH:TZM] billing period. (Read Status =
For example: READ_FOUND, Export Status =
EXPORT_SENT.
“2010-05-14T00:00:00-
SENT_FOR_BILLING = “S” in
05:00”
the ‘billing_detail’ table.)
If a startTime is not provided
and if no previous completed
billing request exists the
startTime will be based on the
date/time of a register read if
found within the ‘Start Read
Tolerance’ of the Data Delivery
Service assigned to the SDP.
‘Start Read Tolerance’ is the
number of seconds before or
after the ‘startTime’ that
EnergyIP will look for register
read values. For segmented
billing quantity replies it is only
the number of seconds after the
‘startTime’.
<tns:endTime> Date/Time Standard XML Y End date and time for the
ISO8601 Date format requested billing period.

Data Type/
Length
with full timezone This is the exclusive end date
qualification will be for a given request. It
used: represents the first date/time
YYYY-MM- that will NOT be included in
DDTHH:MI:SS.sss[[+|- quantities for the SDP
]TZH:TZM] associated with the request.
The endTime is an exclusive
end time. It is treated as the
beginning of the period or
interval following the last interval
requested. For a Daily Read
Period which ends at midnight it
is the beginning 00:00:00 of the
exclusive end date).
For example, an endTime of
2007-05-01T05:00:00.000-05:00
would request data that occurs
up to 00:00:00 EST on May 1,
2007 (which is the end of April
30, 2007)
(FUTURE) If the requested end
time is part way though the
reported interval of the meter
the data set returned will end
with the last interval quantity
prorated.
<tns:versionTime> Date/Time Standard XML N Allows the requestor to request
ISO8601 Date format Billing Quantity data over a
with full timezone specified period but only using
qualification will be Meter and Usage data up to the
used: versionTime. This is a date time
YYYY-MM- other than the current date time.
DDTHH:MI:SS.sss[[+|- If the intent of the request is to
]TZH:TZM] validate or rebuild previously
delivered Billing Quantity data
underlying previously delivered
Billing Quantity data, then this
date time must be the same as
the ReplyMessage /
MeterReadings / MeterReading /
Reading / Quality
<versionTime> attribute of the
delivered Billing Quantities
Response.
NOTE 1: For billing quantity
responses consisting of multiple
measurements (for example
three TOU quantities and a start
and end register reading) each
measurement can have differing
version date times. Using the
maximum version date time from
all the response measurements
will produce the original billing
quantity response.
NOTE 2 : If no versionTime
specified, the most current
version of data will be delivered.
<tns:objectIdType> Varchar (30) General : AAAAAAAA Y Defines the type of asset ID
Specific Usage: provided in request.
SDP_X_UNIVERSAL_ For the MDM/R this field will
ID indicate the object type of
Universal SDP ID for the

Data Type/
Length
<objectId>.
“SDP_X_UNIVERSAL_ID” will
always be used
<tns:objectIdNameSpac Char (8) AAAAAAAA Y The organization identifier
e> Example: assigned to the LDC during the
MDM/R Registration/Enrolment
ORG12345
process.
Value that uniquely identifies the
<objectId>.
Value must be the ORG_ID
assigned to the LDC that owns
the SDP.
<tns:objectId> Fixed Number AAAAAAAA Y Universal SDP ID (Physical or
(8) For example: Virtual)
“87654321”
<tns:offcycle> Boolean Specific usage N If set to true, indicates the
Only for off-cycle request is an off-cycle request.
requests: For off-cycle requests value
“true” must be “true”.
For on-cycle requests the
<offcycle> attribute must not be
present.
<tns:utilityName> Char (8) General: AAAAAAAAA Y The organization identifier
Example: assigned to the LDC during the
MDM/R Registration/Enrolment
ORG12345
process.
Utility name to use to generate
the exceptions or statistics. Comment [MS2]: eMeter has confirmed this use.
Value must be the ORG_ID
assigned to the LDC that owns eMeter has also confirmed that the Standard Billing
the SDP. XML does not presently support an element that is
used to verify the SDP to Billing Agent Relationship
<tns:processStartDate> Date/Time Standard XML N The date/time in EST when the
for the request/response, but intends that this
ISO8601 Date format execution window for the
validation should be part of the Standard Billing
with full timezone request should start.
XML for the EnergyIP product.
qualification will be If provided, the billing request
used: will be processed when this date
YYYY-MM- is reached.
]TZH:TZM]
Example:
“2008-04-31T12:00:00-
05:00”
<tns:processEndDate> Date/Time Standard XML N The date/time in EST when the
ISO8601 Date format execution window for the
with full timezone request should end.
qualification will be If provided, the billing request
used: will be stopped when this date is
YYYY-MM- reached.
]TZH:TZM]
Example:
“2008-04-31T12:00:00-
05:00”
</tns:Request>
</tns:RequestMessage>

2.x.8.2.1 Sample RequestMessage
<FTSFN>ORG12345.ORG12345.5500.00.20100819233017</FTSFN>
<?xml version=”1.0” encoding=”UTF-8”?>

<tns:RequestMessage xmlns:tns="http://www.emeter.com/energyip/readsforbillinginterface2"
xmlns:xsi="http:/www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation=”http://www.emeter.com/energyip/readsforbillinginterface
2EipReadsForBillingInterface2.xsd">
<tns:Header>
<tns:verb>create</tns:verb>
<tns:noun>ReadsForBilling</tns:noun>
<tns:revision>2</tns:revision>
<tns:dateTime>2010-08-20T09:30:15-05:00</tns:dateTime>
<tns:source>ABC8642</tns:source>
<tns:messageID>6888281</tns:messageID>
</tns:Header>
<tns:Request>
<tns:startTime>2010-05-14T00:00:00-05:00</tns:startTime>
<tns:endTime>2010-07-01T00:00:00-05:00</tns:endTime>
<tns:objectIdType>SDP_X_UNIVERSAL_ID</tns:objectIdType>
<tns:objectIdNamespace>ORG12345</tns:objectIdNamespace>
<tns:objectId>12345678</tns:objectId>
<tns:offcycle>true</tns:offcycle>
<tns:utilityName>ORG12345</tns:utilityName>
<tns:processStartDate>2010-08-20T11:00:00-05:00</tns:processStartDate>
<tns:processEndDate>2010-08-20T11:30:00-05:00</tns:processEndDate>
</tns:Request>
</tns:RequestMessage>

2.5 Billing Service Standard Interface - Reply
Note: This new Billing Service Standard Interface Reply will replace the existing Billing
Quantity Response and will be developed and deployed to support the MDM/R
Universal Solution for verification and reconciliation of billing quantities based on
Measurement Canada approved meter registrations.
2.5.1 Description
The EnergyIP Billing Service Standard Interface billing quantity response is called a
ReplyMessage.
The purpose of this interface is to prepare the file with Billing Quantity data and send
the file to the LDC or authorized Billing Agent based on either a scheduled Billing Cycle
Schedule or as a result of processing a Billing Service Standard RequestMessage file.
or their billing agents. An LDC or its billing agent may choose to use one or the other
method based on operational requirements:
Billing Quantity data in response to a request from the LDC or its billing agent
using this EnergyIP Billing Service Standard Interface RequestMessage. This
method is used for requesting Billing Quantity data for both on-cycle and off-
cycle billing.
Quantity data automatically based on a billing cycle attribute attached to the
SDP. This method can be used for scheduled billing cycles only where the
SDP data required to properly prepare the billing quantities has been
synchronized by the LDC or its billing agent with the MDM/R. The EnergyIP
Billing Service Standard Interface RequestMessage is not required to be used
by this method.
Section 7 of the MDM/R Detailed Design Document, Framing of Billing Quantities
discusses the framing of Billing Quantity data.
2.5.2 Integration
MDM/R to the LDC or Billing Agent
This is a batch process involving the transfer and processing of the EnergyIP Billing
Service Standard Interface ReplyMessage files in an .xml file format.

1. In MDM/R, Billing Quantity data are computed based on the startTime and
endTime specified in the EnergyIP Billing Service Standard Interface
RequestMessage or the Read Date identified in the Billing Cycle Schedule (to a
time of mid-night of the day configured for the BillingCycleDate parameter for the
BillingCycleModule).

2. Multiple Billing Quantity responses (initiated by either the request-response or
scheduled push billing service) may be provided for a single Billing Quantity
request if the following conditions occur:
a. A season change (i.e. a global RPP price change event) occurred during
the period being requested. For any SDP for which the Framing Structure
is TOU/CPP or Periodic the billing service looks for a global price change
event that falls within the billing period and delivers Billing Quantities for
each sub-period defined by one or more global price change events. The
global RPP price change events are defined in the Energy Purchase
Service Calendar associated with the Framing Structure assigned to each
SDP.
b. The framing structure for an SDP changed during the period being
requested.
c. A SDP to Account relationship changed during the period being requested.
The billing service looks for an Account to SDP relationship change that
falls within the billing period and delivers Billing Quantities for each sub-
period defined by one or more Account to SDP relationship change events.
d. Meter Change and CT/PT Multiplier Change – The SDP to Meter
relationship or the SDP – CT/PT Multiplier parameter changed during the
period requested. The billing service looks for an SDP to Meter
relationship change and/or a change to the SDP to CT-PT ID asset
relationship that falls within the billing period and delivers Billing Quantities
for each sub-period defined by one or more relationship change events.
i. The last register reading for the removed meter should be provided to
the MDM/R. The date/time of the last register reading must be less
than the end date/time of the SDP to Meter relationship for the removed
meter.
ii. The first register reading of the new meter should be provided to the
MDM/R with a date/time equal to or greater than the start date/time for
the SDP to Meter relationship for the new meter.
iii. A CT/PT Multiplier change must be submitted with a corresponding
Meter Change using the Synchronization process to assure the
application of the correct CT/PT Multiplier to each segment. Applying a
logical meter change (removing/ending and installing/starting the SDP
to Meter relationship for the same meter) when a CT/PT Multiplier only
change event occurs will provide the correct CT/PT Multiplier applicable
for the Billing Validation Sum Check for each segment.
a. The MDM/R is unable to produce a Billing Quantity Response since there
was no meter associated with the SDP in the required period.
b. The MDM/R is unable to produce a Billing Quantity Response due to
missing intervals in the required period.
c. One or more intervals have the VEE outcome of “NVE”
d. Start register reading and/or end register reading required for the Billing
Quantity response is not available.

§ A Billing Service Standard Interface RequestMessage file has been
submitted and has been processed by the Billing Quantity Request Interface
for PULL requests.
§ For PUSH requests, the LDC or Billing Agent has provided the MDM/R with a
Billing Cycle Schedule.
§ For PUSH requests, the Billing Cycle attribute for an SDP has been
populated with a Billing Cycle that is contained in the Billing Cycle Schedule.
§ A Billing Service Standard Interface ReplyMessage file has been sent to the
Organization associated with the Data Delivery Service via File Transfer
Services.
§ The LDC and/or their Billing Agent receives Report BR04: Billing Delivery
Detail Report via File Transfer Services.
§ The LDC and/or their Billing Agent receives Report BR06: Billing No Reads
Report via File Transfer Services.
§ The LDC and/or their Billing Agent receives Report BR05: Billing Validation
Sum Check Failure Report via File Transfer Services.
2.5.6 Assumptions
Additional attributes will be added to the XML request/reply to provide validation of the
SDP to Billing Agent Relationship and to provide an external file identifier utilizing the
‘EXTNL_BATCH_ID’ in the ‘billing_request’ table schema to support the .xml file format.

Frequency: For the Request-Response Billing Service (“Pull”) a Billing Service
Standard Interface ReplyMessage is sent in response to a specific Billing Service
Standard Interface RequestMessage. For the Scheduled Billing Service (Push”) a
Billing Service Standard Interface ReplyMessage file is sent for each billing cycle
scheduled for delivery on that day to the LDC or its Billing Agent.
Register Read Billing Window: With the deployment of EnergyIP Release 7.1 the
notion of “Billing Window” is redefined as a “Register Read Billing Window”. The
Register Read Billing Window determines the range of time when a register reading
must occur to be considered an acceptable register reading to be used as the end
register reading in the billing quantity response.
For on-cycle billing requests the Register Read Billing Window is controlled by the
request ‘endTime’ and the following billing service properties set for each VEE
Service/Data Delivery Service:
• ‘AllowableReadAge’ – for example set to ‘1 Day, 23 Hours, 59 Minutes’
• ‘AllowableReadAgeType’ – for example set to ‘Calendar’ days
• ‘Read Window - Max’ – for example set to ‘0 Days’

• ‘Read Window Type’ – for example set to ‘Calendar’ days
For off-cycle billing requests the Register Read Billing Window is controlled by the
• ‘OffCycleAllowableReadAge’ – for example set to ‘0 Days’
• ‘AllowableReadAgeType’ – for example set to ‘Calendar’ days
• ‘OffCycle Read Window - Max’ – for example set to ‘0 Days’
• ‘OffCycle Read Window Type’ – for example set to ‘Calendar’ days
Execution Window: With the deployment of EnergyIP Release 7.1 the notion of “Billing
Window” is replaced by a new billing request “Execution Window”. The Execution
Window determines the range of time during which a billing request remains active.
For on-cycle billing requests the billing request Execution Window is controlled by the
• ‘LatestReportDays’ – for example set to ‘3 Days’
• ‘LatestReportDaysType’ – for example set to ‘Business’ days
• ‘TriggerAfterDays’ – for example set to ‘2 Days’
• ‘TriggerAfterDaysType’ – for example set to ‘Calendar’ days
For off-cycle billing requests the billing request Execution Window is controlled by the
• ‘OffCycleLatestReportDays’ – for example set to ’10 Minutes’
• ‘LatestReportDaysType’ – for example set to ‘Business’ days
• ‘OffCycleTriggerAfterDays’ – for example set to ‘1 Minute’
• ‘TriggerAfterDaysType’ – for example set to ‘Calendar’ days
All related VEE Service/Data Delivery Service billing service properties will be specified
in the “MDM/R VEE Standard for the Ontario Smart Metering System”.
During the Execution Window billing requests (“Push” or “Pull”, on-cycle or off-cycle)
remain active if complete framed usage data or interval data for any day or if required
start or end register readings are not available, or for which the Validation Status is
NVE. A ‘noData’ reply is returned for all unfulfilled requests no later than 08:00 EST on
the calendar day after an Execution Window closes.
The Execution Window can be partially of fully determined by use of the request
‘processStartDate’ and ‘processEndDate’. Use of these request attributes can be used
to override the configured billing service properties and to provide ODEST at any date
or time after the Execution Window would normally close as determined by the billing
service properties configuration for each VEE Service/Data Delivery Service.
Timing:
The Billing Quantity Response process will launch and process the off-cycle requests
when initially received. On-cycle requests and Scheduled PUSH requests (as well as
off-cycle requests that remain active after initial processing) will be processed on the

regularly scheduled run of the Billing Quantity Response process. This process is
configured to run at certain times during the day. This process will run every three
hours each day between the hours of 08:00 EST and 23:00 EST. Experience gained
during testing and initial production operations of the MDM/R has affirmed the efficacy
of this schedule in meeting operational requirements.
Initially, scheduled PUSH (Request Type ‘S’) for the current day will be loaded at 07:30
EST. This schedule may be modified to meet operational requirements.
The Billing Service Standard Reply Files are closed and moved to the appropriate
FTS/AS2 delivery directories on the following conditions;
i. the billing quantity processing has not written to the file for more than
BillingExportAdapter.FileIdle seconds, or;
ii. the number of records written to the currently open file exceeds
BillingExportAdapter.MaxRecords.
Service Levels:
The Billing Service Standard Reply File is provided within the following timeframes,
based on the Billing Service Global Parameters of AllowableReadAge of 0 calendar
days and LatestReportDays of 3 business days:
§ For the Scheduled Billing Service - Billing Quantity data will be provided by
21:05 through the third business day after Day N for all SDPs that have
successfully completed the VEE process by 15:00 on any subsequent day
through the third business day after Day N.
§ For the Request-Response Billing Service - Billing Quantity data will be
provided within six hours of the timestamp of the receipt of the Billing Quantity
Request for all SDPs that have successfully completed the VEE process by
that time. Where the Billing Quantity Request includes Request Daily Read
Period End Dates that are in the future, the Billing Quantity data will be
provided within six hours of the Request Daily Read Period End Date based on
the Billing Quantity process runs on the Request Daily Read Period End Date.
For SDPs that complete the VEE process after the Request Daily Read Period
End Date, the Billing Quantity Response will be provided on any subsequent
day through the third business day after Day N (the exclusive end date for the
Billing Quantity Request).
§ In both cases, Scheduled Billing Service and Request-Response Billing Service,
if the process is unable to provide a Billing Quantity response by the end of the
billing window (being the exclusive end date plus the LatestReport Days) then
on the first run of the Billing Quantity processing after the close of the billing
window a “no data available” Billing Quantity response record will be delivered
for each SDP for which Billing Quantity values can not be produced.
2.5.8 File Format

2.5.8.1 File Name Record for the Billing Quantity ReplyMessage File

Table 2.5.1 FILE NAME RECORD FOR THE BILLING QUANTITY REPLY MESSAGE FILE

<FTSFN>
</FTSFN>

2.5.8.2 Reply Message

The ReplyMessage portion of the EnergyIP standard billing service interface includes
the three elements listed below. Refer to the diagram that follows for an XML schema
view of these elements.
§ Header – Contains descriptive information about the message.
§ Reply – Contains the details regarding the reply.
§ MeterReadings
Table 2.5.2 REPLY MESSAGE HEADER – ReplyMessage/Header
Data Type/
Length
<?xml version=“1.0” encoding=“UTF-8”?>
<XML declaration> Specific Usage: Y Defines the XML version and
<?xml version=“1.0” the character encoding used in
encoding=“UTF-8”?> the document
<tns:ReplyMessage>
<tns:ReplyMessage> Specific Usage: Y Location of the xml name space
xmlns=“http:/www.
emeter.com/energyip/
readsforbillinginterface
2”

Data Type/
Length
<tns:Header>
<tns:verb> String Specific Usage: Y Always will be the literal “reply.”
“reply”
<tns:noun> String Specific Usage” Y Main subject of message.
One of: Set to the literal
“ReadsForBilling” “ReadsForBilling”
or or
“ReadsForBilling “ReadsForBilling Informational”
Informational” if request was for information.
<tns:revision> String Specific Usage: Y Revision level of message type.
“2” The version of the reply
message xml.
Currently revision of the xml
specification is set to “2”.
<tns:dateTime> Date/Time Standard XML N The date/time when this
ISO8601 Date format response was generated in EST Comment [MS3]:
with full timezone How is the equivalent “Response File Created Date
qualification will be Time” in the MDM/R custom BQI provided in the
used: Standard Billing XML?
YYYY-MM-
DDTHH:MI:SS.sss[[+|- 17 Sept 2010: IESO follow-up – We still need to
]TZH:TZM] know if the date/time at which the response FILE is
Example: created will be returned in the XML reply.
“2008-04-31T12:00:00-
05:00” 23 Sept 2010: eMeter response – “The date/time at
which the response FILE is created is not returned in
<tns:source> Varchar (100) Example: Y This value is populated from the the XML reply.
“ABC8642” ‘LAST_UPD_BY’ field of
‘billing_request’ table.
This is the value provided for
the <source> attribute in the
RequestMessage / Header. Comment [MS4]: To be confirmed by testing.
</tns:Header>
Table 2.5.3 REPLY MESSAGE – ReplyMessage/Reply
Data Type/
Length
<tns:Reply>
<tns:correlationId> Varchar (30) General: N Populated with the
AAAAAAAAAAA <messageId> in
RequestMessage/Header if one
was provided.
This is the unique request
identifier assigned by the LDC
or its Billing Agent (the Comment [MS5]:
‘EXTNL_BILLING_REQUEST_I How is the external file identifier (currently provided
D’ from the ‘billing_request’ by the MDM/R BQ request/response and stored as
table). the ‘EXTNL_BATCH_ID’) presented in the
For Scheduled PUSH billing Standard XML reply?
service this attribute will not be
present in the replyMessage. 17 Sept 2010: IESO follow-up – Restating the
question: How is the ‘EXTNL_BATCH_ID’
<tns:replyCode> String General: Y Populated with 0 for success addressed by both the Standard XML request and
NN and non zero for an error reply?
Specific usage: response. Codes and values
One of “0”, “1”, “2”, “8”, include: 23 Sept 2010: eMeter response –
“9” “10”, “12”, “15’, · 0 – Successful read “EXNTL_BATCH_ID is not passed in either the
[xml] billing request or the billing response.”

Data Type/
Length
“16”, “17”, “18” · 1 – Lookup failure, for example
invalid SDP ID in the request
· 2 – Reads failure (billing
window expired)
· 8 – Requesting organization
does not match active Billing
Agent for the SDP Comment [MS6]: eMeter to resolve validation of
· 9 – Invalid billing determinant the SDP to Billing Agent Relationship for the
for a hold request Standard XML request.
· 10 – Missing or invalid DDs
15 Sept 2010: eMeter has acknowledged that this is
parameter (configuration error)
being addressed as a functional gap.
· 11 – Validation failure
(Disabled for the MDM/R)
· 12 – Meter not found for
segment or bill period
· 13 – Cycle ID not found for the
SDP to process the ByCycle
request
· 14 – Missing Route Cycle ID
· 15 – Request was cancelled
· 16 – No measurement
attached to Measurement Profile
or Measurement Profile name is
null in the DDS
· 17 – Invalid primary billing
determinants
· 18 – Symbol not found for
calculative read determinant
<tns:requestId> Number (50) Y The internal EnergyIP billing
request identifier (the
‘BILLING_REQUEST_ID’ field
from the ‘billing_request’ table).
This identifier will be present in
the replyMessage for both
Request-Response and
Scheduled PUSH billing
services.
<tns:offcycle> String Specific usage Y Indicates the response is for an

For off-cycle requests: off-cycle billing request.
“true” For off-cycle requests value will
For on-cycle requests: be “true”.
“false” For on-cycle requests or
For ‘ReadsForBilling Scheduled PUSH requests
Informational’ requests value will be “false”. Comment [MS8]: To be confirmed by testing.
(both on-cycle and off- The EnergyIP GUI ‘Request
cycle): Message’ screen displays the 15 Sept 2010: eMeter response – Values of “B” =
following values in the ‘Off offcycle and “P” = oncycle are stored in the
“true”
Cycle’ field: ‘billing_request’ table.
For off-cycle ‘ReadsForBilling’
Comment [MS7]: To be confirmed by testing.
requests: value = “B”
For on-cycle ‘ReadsForBilling’
requests: value = “P”
For off-cycle and on-cycle
‘ReadsForBilling Informational’
requests: value = “I”
</tns:Reply>

Table 2.5.4 REPLY MESSAGE – ReplyMessage/MeterReadings
Data Type/
Length
<tns:MeterReadings>
<tns:startTime> Date/Time Standard XML Y Start date and time for billing
ISO8601 Date format period provided in the billing
with full timezone reply in EST.
qualification will be If no prior completed billing
used: exists this startTime may differ
YYYY-MM- from the requested billing period
DDTHH:MI:SS.sss[[+|- startTime as determined by the
]TZH:TZM] date/time of an actual register
For example: reading closest to the requested
“2010-05-14T00:00:00- startTime and within the ‘Start
Read Tolerance’ parameter of
05:00”
the billing data delivery service
assigned to the SDP.
<tns:endTime> Date/Time Standard XML Y End date and time for the billing
ISO8601 Date format period provided in the billing
with full timezone reply in EST.
qualification will be This is the exclusive end date
used: for a given request. It
YYYY-MM- represents the first date/time
DDTHH:MI:SS.sss[[+|- that will NOT be included in
]TZH:TZM] quantities for the SDP
associated with the request.
2007-05-01T05:00:00.000-05:00
30, 2007)
This endTime may differ from
the requested billing period
endTime as determined by the
date/time of an actual register
reading closest to the requested
endTime and within the “register
reading billing window”
permitted by the parameter
settings for the billing data
delivery service assigned to the
SDP, specifically.
For on-cycle requests:
‘AllowableReadAge’ and ‘Read
Window - Max’’
For off-cycle requests:
‘OffCycleAllowableReadAge’
and OffCycle Read Window -
Max’ for off-cycle requests.
<tns:MeterReading>

Data Type/
Length
<tns:ServicePoint>
<tns:id> Fixed Number General: Y This is the Universal SDP ID.
(8) NNNNNNNN (Physical or Virtual)
Example:
‘00037483
<tns:idType> String Specific usage: Y Object ID Type.
‘SDP_X_UNIVERSAL_ For Universal SDP ID
ID’ Value =
‘SDP_X_UNIVERSAL_ID’ Comment [MS9]:
</tns:ServicePoint> 08 Sept 2010: eMeter response –
Current Standard Billing XML reply only “returns
<tns:Meter> SDP_X_UDC_ASSET_ID (i.e. the SDP ID), not
<tns:id> Varchar (50) No format prescribed Y The identifier of the currently SDP_X_UNIVERSAL_ID.”
installed meter and must be
unique within an LDC. This is IESO: The SDP_X_UDC_ASSET_ID is the SDP ID.
the ‘Meter ID’ submitted in the The MDM/R requires that the Universal SDP ID is
Asset Data File of the returned with the billing quantity response.
Synchronization file set.
15 Sept 2010: eMeter has acknowledged that this is
<tns:idType> String Specific usage: Y Object ID Type. being addressed as a functional gap.
‘METER_X_UNIVERS For Meter ID
AL_ID’ Value =
‘METER_X_UNIVERSAL_ID’
</tns:Meter>
<tns:Premise>
<tns:id> String General: Y The MDM/R Synchronization
NNNNNNNN Staging Table Loader populates
Example: the Premise ID with the
‘00037483 Universal SDP ID on the
creation of the Premise master
data records.
‘X_CLIENT_PRMSE_I For Premise ID
D’ Value =
‘X_CLIENT_PRMSE_ID’
</tns:Premise>
<tns:CustomerAccount>
<tns:id> String No format prescribed Y This is the currently in-effect
Account ID value as submitted
in the ‘Object 2’ field
‘Relationship Identifier 2’ =
‘ACCOUNT’ in the Relationship
Data File of the Synchronization
file set.
For periods for which no
Account is in-effect the
<CustomerAccount> record will
return the <tns:id> = “0” Comment [MS10]: To be confirmed by testing.
‘X_UDC_ACCNT_ID’ For CustomerAccount ID
Value = ‘X_UDC_ACCNT_ID’
</tns:CustomerAccount>

Data Type/
Length
<tns:Reading>
The <Reading> reply records are organized into the following repeating blocks for TOU or Periodic billing quantities
and related Start and End Register Readings
<tns:startTime> Date/Time Standard XML N The startTime attribute will not
ISO8601 Date format be present for TOU, Periodic, or
with full timezone Demand billing quantities.
qualification will be The startTime attribute will be
used: not be present for related Start
YYYY-MM- or End Register Readings.
]TZH:TZM]
For example:
“2010-05-14T00:00:00-
05:00”
<tns:endTime> Date/Time Standard XML N The endTime attribute will not
ISO8601 Date format be present for TOU, Periodic, or
with full timezone Demand billing quantities.
qualification will be The endTime attribute will be
used: present for the related Start or
YYYY-MM- End Register Readings.
]TZH:TZM]
For example:
“2010-05-14T00:00:00-
05:00”
<tns:value> Number (12,5) General: N The quantity value related to the
NNNNNNNNNNN.NN <readingTypeId>
For example:
“924.06135”
<tns:measurementSourc String General: N This is EnergyIP application that
e> AAAAAAA is the internal source of the
Specific usage: billing quantity value.
For TOU/CPP, For TOU/CPP and Periodic
Periodic and Demand: billing quantities the value is:
‘Framer’ ‘Framer’
For Meter Reads For Demand billing quantities
Interfaces: the value is:
One of ‘Framer’
‘MAS’, For Register Reads received via
‘SENSUS’, the Meter Reads Interfaces,
‘SmartSynch’, values are:
‘Tantalus’, Elster = ‘MAS’
‘Trilliant’ Sensus = ‘SENSUS’
For estimated Register SmartSynch = ‘SmartSynch’
Reads: Tantalus = ‘Tantalus’
‘eMeter’ Trilliant = ‘Trilliant’
For estimated interval Note: The values for the Meter
data ‘KWH Est Usage’: Read Interfaces are established
‘eMeter’ by the ‘AMCC Type’ specified
for the ‘Communication Module’
as part of the Asset Data File
Detail Record using the
Synchronization processes.
For estimated Register Reads
value is: ‘eMeter’
For estimated interval data
‘KWH Est Usage’, value is
‘eMeter’ Comment [MS11]: To be confirmed by testing.

Data Type/
Length
<tns:readingTypeId> Varchar (50) General: N This code identifies the
AAAAAAA measurement that defines the
Specific usage for data used for the billing
TOU/CPP: quantities being calculated.
‘KWH On Peak Usage (From the
BC’ ‘MEAS_EXTENSION_CODE’ of
‘KWH Mid Peak Usage the ‘billing_detail’ table.)
BC’
For TOU/CPP (EST) and
‘KWH Off Peak Usage
TOU/CPP (CST), values are:
BC’
‘KWH On Peak Usage BC’
Specific usage for ‘KWH Mid Peak Usage BC’
Periodic: ‘KWH Off Peak Usage BC’
‘KWH Usage BC’ For Periodic, value is:
Specific usage for ‘KWH Usage BC’
demand:
For Demand Billing Quantities,
‘Peak KW BC’
values are:
‘Peak KVA BC’
‘Peak KW BC’
‘Peak KW77 BC’
‘Peak KW77 BC’
‘Peak KVA77 BC’
‘Peak KVA BC’
‘Coincident KW
‘Peak KVA77 BC’
Demand BC’
‘Coincident KW Demand BC’
‘Coincident KVA
‘Coincident KVA Demand BC’
Demand BC’ ‘Coincident Rolling KW
‘Coincident Rolling KW
Demand BC’
Demand BC’
‘Coincident Rolling KVA
‘Coincident Rolling
Demand BC’
KVA Demand BC’
For Start Register Readings,
Specific usage for value is:
Register Readings:
Start Read ‘TBD’ [TBD]
End Read ‘TBD’ For End Register Readings,
value is:
Specific usage for
Estimated Interval [TBD] Comment [MS12]: Values to be assigned as part
Data total kWh: For estimated interval data total of the Measurement Canada register read Universal
‘KWH Est Usage’ kWh, value is : ‘KWH Est Usage’ Solution deployment.
<tns:validationCode> String AAAAAAAA N Data delivery service validation
Specific usage: failure reason. Codes and
One of: values include:
‘6’, · 1 – HiLo warn occurred
‘7’ · 2 – HiLo fail occurred
· 3 – HiLo No threshold basis
found
· 4 – Consecutive estimation
check failed
· 5 – Span length failed
· 6 – Sum check failed
· 7 – Sum check skipped
Note: Codes 1, 2, 3, 4, and 5 not
used by the MDM/R.
The <validationCode> attribute
will not be present if there is not
a data delivery service validation
failure.
When there is a data delivery
service validation failure and
billing determininants are
delivered:
• the <validationCode>
attribute will be present for
for <readingTypeId> = “KWH

Data Type/
Length
Est Usage” Comment [MS13]: To be confirmed by testing.
• the <validationCode>
attribute will not be present
for register readings
associated with usage
determinants
<tns:demandPeakTime> Date/Time Standard XML N Demand peak time. Applicable
ISO8601 Date format to demand measurement only.
with full timezone
used:
YYYY-MM-
]TZH:TZM]
<tns:Quality>
<tns:versionTime> Date/Time Standard XML N This is the latest insert date time
ISO8601 Date format of the set of data used for billing
with full timezone quantity calculations.
qualification will be This date time is prior to the
used: billing quantity response data
YYYY-MM- being written into the billing
DDTHH:MI:SS.sss[[+|- quantity response file that is
]TZH:TZM] transferred to organization
assigned to the Data Delivery
Service associated with the
SDP.
NOTE: For a billing quantity
reply consisting of multiple
measurements (for example
three TOU quantities and a start
and end register reading) each
measurement can have differing
version date times. The
maximum version date time from
all the response measurements
should be used as the
RequestMessage / Request
<versionTime> to produce the
original billing quantity
response.
<tns:noData> Boolean Specific usage N Flag indicating the no data is
For a no data available for this billing
condition: determinant.
‘true’ The <noData> attribute will not
be present when the required
measurement data is available.
<tns:validationStatus> String Specific usage: N EST for estimated readings; Comment [MS14]: eMeter to provide description
One of: VAL for others. for setting ‘EST’ status for TOU usage.
‘VAL’
‘EST’ Note: For <readingTypeId> =
“KWH Est Usage” the <Quality>
attributes will be present and will
come from the associated usage
record. Comment [MS15]: To be confirmed by testing.
</tns:Quality>
</tns:Reading>
<tns:IntervalBlock>
<IntervalBlock> reply records provide the response for Hourly Billing Quantities
<tns:readingTypeId> Varchar (50) General: N This code identifies the
measurement that defines the

Data Type/
Length
AAAAAAA data used for the billing
quantities being calculated.
Specific usage for (From the
Hourly: ‘MEAS_EXTENSION_CODE’ of
‘KWH Interval 60 the ‘billing_detail’ table.)
Minutes’
For Hourly, value is:
‘KWH Interval 60 Minutes’
<tns:IReading>
The <IRreading> reply records are organized into the following repeating blocks for Hourly Billing Quantities.
Note: Start Register Readings and End Register Readings associated with each Hourly reply will be found in the
<Reading> block of the reply message.
<tns:startTime> Date/Time Standard XML N The startTime attribute will not
ISO8601 Date format be present for Hourly billing
with full timezone quantities.
used:
YYYY-MM-
]TZH:TZM]
For example:
“2010-05-14T00:00:00-
05:00”
<tns:endTime> Date/Time Standard XML N The endTime attribute will be
ISO8601 Date format present for each Hoully billing
with full timezone quantity.
qualification will be For Hourly billing quantity values
used: aggregated from interval data of
YYYY-MM- interval length less than 60
DDTHH:MI:SS.sss[[+|- minutes, the endTime will be the
]TZH:TZM] maximum ‘local_interval_time’
For example: from the the ‘lp_interval’ records
making up the reading (i.e. the
“2010-05-14T00:00:00-
end date/time of the interval
05:00”
ending at the top of the hour).
<tns:intervalLength> Integer Specific usage: N Interval length, in seconds, if
For Hourly billing applicable to measurement.
quantities always Value will always be ‘3600’ for
‘3600” SDPs for which the Framing
Structure is “Hourly”.
<tns:value> Number (12,5) General: N The quantity value related to the
NNNNNNNNNNN.NN <readingTypeId>
For example:
“924.06135”
<tns:demandPeakTime> Date/Time Standard XML N Demand peak time. Applicable
ISO8601 Date format to demand measurement only.
with full timezone
used:
YYYY-MM-
]TZH:TZM]
<tns:measurementSourc String General: N This is EnergyIP application that
e> AAAAAAA is the internal source of the
Specific usage: billing quantity value.
For Hourly quantities For Hourly billing quantity data
from 60 minute data, comprised of 60 minute interval
data, values are:
One of
Elster = ‘MAS’
‘MAS’,
Sensus = ‘SENSUS’
‘SENSUS’,

Data Type/
Length
‘SmartSynch’, SmartSynch = ‘SmartSynch’
‘Tantalus’, Tantalus = ‘Tantalus’
‘Trilliant’ Trilliant = ‘Trilliant’
For aggregated Hourly Note: The values for interval
quantities: data are established by the
‘BSRP’ ‘AMCC Type’ specified for the
For estimated interval ‘Communication Module’ as part
data: of the Asset Data File Detail
‘eMeter’ Record using the
Synchronization processes.
For Hourly billing quantity data
aggregated from interval data of
interval length less than 60
minutes the value is:
‘BSRP’ Comment [MS16]: To be confirmed by testing.
For estimated interval data
value is:
‘eMeter’ Comment [MS17]: To be confirmed by testing.
<tns:Quality>
<tns:versionTime> Date/Time Standard XML N This is the latest insert date time
ISO8601 Date format of the set of data used for billing
with full timezone quantity calculations.
qualification will be This date time is prior to the
used: billing quantity response data
YYYY-MM- being written into the billing
DDTHH:MI:SS.sss[[+|- quantity response file that is
]TZH:TZM] transferred to organization
assigned to the Data Delivery
Service associated with the
SDP.
<tns:validationStatus> String Specific usage: N Validation status of the interval
One of: read.
‘VAL’ For Hourly billing quantity data
‘NV’ aggregated from interval data of
interval length less than 60
‘EST’
minutes the <validationStatus>
value is the worst-case status
set by a hierarchy of interval
validation status values ranked
from best-case = 1 to worst-
case = 3 for which:
1 = ‘VAL’ (Validated)
2 = ‘NV’ (Not Validated)
3 = ‘EST’ (Estimated)
Comment [MS19]: Need to address this status
<tns:noData> Boolean Specific usage N Flag indicating the no data is when the underlying interval data is say 15 minute
For a no data available for this billing interval length for an Hourly billing quantity
condition: determinant. response.
‘true’ The <noData> attribute will not eMeter to confirm.
be present when the required
Comment [MS18]: eMeter to confirm allowed
measurement data is available.
value(s).
<tns:locked> Boolean Specific usage N/A Indicates if the interval data is 08 Sept 2010: eMeter response – ““true” or “false”.
‘true’ locked from any further updates. If tag is not there assume false.”
</tns:Quality> IESO:Follow-up – This response is questionable.
</tns:IReading> Where does the ‘true’ or ‘false’ value come from?
Why does anything need to be “assumed”?
<tns:validationCode> String AAAAAAAA N Data delivery service validation Also will this flag be used by the MDM/R?
Specific usage: failure reason. Codes and
One of: values include: 15 Sept 2010: eMeter response – “… believe this
‘6’, · 1 – HiLo warn occurred will never be returned. In progress getting
confirmation.”

Data Type/
Length
‘7’ · 2 – HiLo fail occurred
· 3 – HiLo No threshold basis
found
· 4 – Consecutive estimation
check failed
· 5 – Span length failed
· 6 – Sum check failed
· 7 – Sum check skipped
Note: Codes 1, 2, 3, 4, and 5 not
used by the MDM/R.
The <validationCode> attribute
will not be present if there is not
a data delivery service validation
failure.
</tns:IntervalBlock>
<tns:segmentType> String Specific usage, one of: N For billing replies that are not
‘Price Change’ segmented this attribute will not
be persent.
‘Meter Installed’
For segmented replies, values
‘Meter Removed’
are:
‘Move Out’
‘Price Change’ – indicating a
‘New Transformer Global Price Change event
Ratio’
‘Rate Change’ – indicating a
‘Rate Change’ Framing Structure Change
event
‘Meter Installed’ indicating a
Meter Change event
‘Meter Removed’ indicating a
Meter Change event
‘Move Out’ indicating an
Account Change event
‘New Transformer Ratio’
indicating a CT/PT Multiplier
Change event Comment [MS20]: To be confirmed by testing.
<tns:startTime> Date/Time Standard XML Y Start date and time for the
ISO8601 Date format segmented billing period
with full timezone provided in the billing reply in
qualification will be EST.
used: For a billing reply that is not
YYYY-MM- segmented this startTime will be
DDTHH:MI:SS.sss[[+|- equal to the
]TZH:TZM] MeterReadings/startTime for the
For example: reply billing period.
“2010-05-14T00:00:00-
05:00”
<tns:endTime> Date/Time Standard XML Y End date and time for the
ISO8601 Date format segmented billing period
with full timezone provided in the billing reply in
qualification will be EST.
used: This endTime may differ from
YYYY-MM- the requested billing period
DDTHH:MI:SS.sss[[+|- endTime as determined by the
]TZH:TZM] date/time of an actual register
reading closest to the requested
endTime and within the
“ register reading billing window”
permitted by the parameter
settings for the billing data
delivery service assigned to the

Data Type/
Length
SDP, specifically.
For on-cycle requests:
‘AllowableReadAge’ and ‘Read
Window - Max’’
For off-cycle requests:
‘OffCycleAllowableReadAge’
and OffCycle Read Window -
Max’ for off-cycle requests.
For a billing reply that is not
segmented this endTime will be
equal to the
MeterReadings/endTime for the
reply billing period. Comment [MS21]: To be confirmed by testing.
<tns:transformerRatio> String For example: N CT/PT Multiplier
‘1.0’
<tns:retailerId> String For example: N Identification for the retailer.
‘ORG98364’ This is the Organization ID for
Relationship Data records
submitted as ‘Relationship 2’ =
‘ENERGY SERVICE
PROVIDER’
</tns:MeterReading>
</tns:MeterReadings>
</tns:ReplyMessage>
2.5.8.2.1 Sample ReplyMessage

<FTSFN>ORG12345.ORG12345.6500.00.20100820093117</FTSFN>
<tns:ReplyMessage xmlns:tns="http://www.emeter.com/energyip/readsforbillinginterface2">
<tns:Header>
<tns:verb>reply</tns:verb>
<tns:noun>ReadsForBilling</tns:noun>
<tns:revision>2</revision>
<tns:dateTime>2010-08-20T09:30:15-05:00</tns:dateTime>
<tns:source>ABC8642</tns:source>
</tns:Header>
<tns:Reply>
<tns:correlationId>6888281</tns:correlationId>
<tns:replyCode>0</tns:replyCode>
<tns:requestId>3090238</tns:requestId>
<tns:offcycle>true</tns:offcycle>
</tns:Reply>
<tns:MeterReadings>
<tns:MeterReading>
<tns:ServicePoint>
<tns:id>12345678</tns:id>
<tns:idType>SDP_X_UNIVERSAL_ID</tns:idType>
</tns:ServicePoint>
<tns:Meter>
<tns:id>Meter654321</tns:id>
<tns:idType>METER_X_UNIVERSAL_ID</tns:idType>

</tns:Meter>
<tns:Premise>
<tns:id>12345678</tns:id>
<tns:idType>X_CLIENT_PRMSE_ID</tns:idType>
</tns:Premise>
<tns:CustomerAccount>
<tns:id>ACCOUNT87654321</tns:id>
<tns:idType>X_UDC_ACCNT_ID</tns:idType>
</tns:CustomerAccount>
<tns:Reading>
<tns:value>718.69357</value>
<tns:measurementSource>Framer</tns:measurementSource>
<tns:readingType>KW H Off Peak Usage BC</tns:readingType>
<tns:validationCode>7</tns:validationCode>
<tns:Quality>
<tns:versionTime>2010-07-01T04:11:26.000-05:00</tns:versionTime>
<tns:validationStatus>EST</tns:validationStatus>
</tns:Quality>
</tns:Reading>
<tns:Reading>
<tns:value>196.54579</tns:value>
<tns:readingType>KW H On Peak Usage BC</tns:readingType>
<tns:Quality>
</tns:Quality>
</tns:Reading>
<tns:Reading>
<tns:readingType>KW H Mid Peak Usage BC</tns:readingType>
<tns:Quality>
</tns:Quality>
</tns:Reading>
<tns:Reading>3
<tns:measurementSource>eMeter</tns:measurementSource>
<tns:readingType>KW H Est Usage</tns:readingType>
<tns:Quality>
</tns:Quality>
</tns:Reading>
<tns:transformerRatio>1.0</tns:transformerRatio >
</tns:MeterReading>
</tns:MeterReadings>
</tns:ReplyMessage>

2.6 Billing Quantity Request
2.6.1 Description
The purpose of this interface is for the LDC or their Billing Agent to submit requests to
the MDM/R for Billing Quantity data. The request is made either by the LDC or by the
Billing Agent on behalf of the LDC. The Billing Quantity Request interface file contains
a number of Universal SDP IDs together with date(s) that define the date range for
which the billing quantities are needed. These requests are satisfied using the Billing
Quantity Response Interface that is described in Section 15.7 of the MDM/R Detailed
Design Document, Billing Quantity Response Interface.
or their billing agents. The LDC or their billing agent may choose to use one or the
other method based on their operational requirements:
SDP data required to properly prepare the billing quantities has been
synchronized by the LDC or their billing agents with the MDM/R. The Billing
Quantity Request Interface is not required to be used by this method.
Billing Quantity data in response to a request from the LDC or their billing
agents using this Billing Quantity Request Interface. This method is used for
requesting Billing Quantity data for both on-cycle and off-cycle billing.
2.6.2 Integration
LDC or their Billing Agent to the MDM/R
files.

1. The following checks are performed:
a. The Billing Quantity Request must be submitted by the organization
(either the LDC or its Billing Agent) associated with the Billing Service for
the SDP. The SDP to BILLING AGENT Relationship must be the in-
effect relationship for the submitting organization for each SDP as
submitted in the Relationship Data file of the Synchronization file set..
b. The Billing Quantity Request File must have a valid Request Daily Read
Period End Date for each Universal SDP ID Billing Quantity Detail record
c. If the Billing Quantity Request File has a Request Daily Read Period Start
Date for a Universal SDP ID, the Request Daily Read Period Start Date, if
populated, must be prior to the Request Daily Read Period End Date.

2. The MDM/R will determine the duration of the billing window for the Billing
Quantity data in one of two ways:
a. The LDC or their Billing Agent will include a Request Daily Read Period
Start Date and a Request Daily Read Period End Date in the Billing
Request Detail Record. The start dates in Billing Quantity Request Detail
Records are inclusive, and end dates are exclusive.
b. The LDC or their Billing Agent will include only the Request Daily Read
Period End Date in the Billing Request Detail Record. In this case the first
Daily Read Period date that will be included in the response to this Billing
Quantity Request is the previous Billing Quantity Response Daily Read
Period End Date.
3. The validated Billing Quantity Request File is passed to the Billing Quantity
engine
4. The processed Billing Quantity Request File is placed in the Processed
Directory by MDM/R.
a. The MDM/R Billing Quantity Request Adapter detects exceptions in
regards to invalid pipe (|) delimited file formats and data type errors.
b. The MDM/R detects exceptions when the LDC ID or Universal SDP
ID values are not known by the system.
c. The MDM/R detects exceptions when, in the file, the Universal SDP
ID is associated with an LDC ID and SDP ID for which that Universal
SDP ID was not originally assigned.
d. The MDM/R detects exceptions when the LDC or their Billing Agent is
not associated with the Billing Service for the SDP during the
requested date range.
e. The MDM/R detects exceptions when, in the file, the Universal SDP
ID does not have a Request Daily Read Period End Date.
f. The MDM/R detects exceptions when, in the file, the Universal SDP
ID has a Request Daily Read Period Start Date that is greater than
the Request Daily Read Period End Date.
g. The MDM/R detects exceptions when Billing Quantities are requested
for a Universal SDP ID that is not active during the requested date
range. Required attributes for active SDPs are described in detail in
Section 3.4 of the MDM/R Detailed Design Document, SDP Attributes
of this document.
h. The MDM/R detects exceptions when, in the file, a Request Version
Date Time field is populated for a Universal SDP but the Request
Type is not “O”
6. The following Billing Quantity Request exception report is created:
§ The Billing Request Detailed Exception Report has error message(s)
for each rejected record explaining the reason. (Refer to Report IR08
in Section 2.4.10 of the MDM/R Reports Technical Specifications).

storage location for the File Transfer Services (FTS) transfer to the LDC or
Billing Agent.
§ The LDC has requested and received Universal SDP IDs for each SDP ID.
§ The Billing Agent is enrolled and has an Organization ID assigned.
§ The Universal SDP ID is associated with the LDC or Billing Agent.
§ The Universal SDP ID has a data delivery service for that LDC or Billing
Agent.
§ The Universal SDP ID is “created” with the corresponding attributes in the
MDM/R Master Directory through the synchronization process.
§ The Universal SDP ID must have an Energy Purchase Service with a
Framing Structure identified.
§ The Universal SDP ID must have a VEE service.
§ Valid Billing Quantity requests are passed to the Billing Quantity engine.
§ The LDC and/or their Billing Agent receives Report IR08: Billing Request
Detailed Exception Report via File Transfer Services.
2.6.6 Assumptions
None

Frequency: This interface is triggered by the submission of a Billing Quantity Request
File from the LDC or their Billing Agent.
Timing: None
2.6.8 File Format

2.6.8.1 File Name Record for the Billing Quantity Request File

Table 2.6.1 FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE

<FTSFN>
</FTSFN>

2.6.8.2 Billing Quantity Request File Header Record

Table 2.6.2 BILLING QUANTITY REQUEST HEADER RECORD
Data
Field Format Required Description
Type/Length
Record Type Char(2) General: Y To indicate that this record is
Identifier AA “Request Header” record in the
Specific Usage: LDC or Billing Agent’s Billing
RH Quantity Request file.
Value must be: “RH”
Request File Fixed Number(2) General: Y The version of the request file to
Format Version NN allow for migration from one format
Specific Usage: to the next as formats change.
“00” Recommended that no more than 2
or 3 are supported.
LDC Char(8) General : Y The identifier assigned to the LDC
Organization AAAAAAAA during the MDM/R
Identifier Example : Registration/Enrollment process.
ORG83462 The LDC creates SDPs and thus
owns those Service Delivery Points
and controls the Data Delivery
Service associated with each of
their SDPs.
Data Delivery Char(8) General : Y The identifier assigned to the
Service AAAAAAAA Organization during the MDM/R
Organization Example : Registration/Enrollment process,
Identifier ORG83462 that is providing Billing Services for
the LDC (this can be the LDC
itself).
This is the Organization that is
submitting the Billing Quantity
Request File for those SDPs.
If the LDC is providing its own
Billing Services then the LDC’s
Organization Identifier would be
placed in both fields.
Request File Varchar (30) AAAAAAAAAAA Y To allow the LDC or Billing Agent to
Identifier specify a unique identifier related to
the request file. This identifier will
be associated with each Billing

Data
Type/Length
Quantity Request Detail Record as
it is stored for processing within the
MDM/R.
2.6.8.3 Billing Quantity Request Detail Record

Table 2.6.3 BILLING QUANTITY REQUEST DETAIL RECORDS
Data
Type/Length
Identifier AA “Request Detail” record in the LDC
Specific Usage: or Billing Agent’s Billing Quantity
RD Data Delivery Request file.
Value must be: “RD”
Request Detail Varchar(30) AAAAAA N To allow the LDC or Billing Agent to
Identifier specify a unique identifier related to
the Request Detail Record. This
identifier would be returned in the
Response File(s) and could be
used to tie the response to the
request.
This identifier can be used to create
any form of compound identifier to
uniquely identify each request
within a batch of requests. The
identifier could be made up of a
date (yyyymmdd) + set ID (AA) +
sequence number (NNNNNNN)
(e.g. 20070214aa1234567)
Request Daily Date yyyyMMdd N The first Daily Read Period date to
Read Period be included in the Billing Quantity
Start Date Response file for this request detail
(Optional on record.
PULL Request) If this date is not supplied then the
MDM/R – EnergyIP will use as the
start date the Billing Quantity
Response Daily Read Period End
Date from the previous Billing
Quantity Response for each SDP.
The MDM/R – EnergyIP manages
the previous end date from the
previous Billing Quantity Response
for each SDP.
NOTE: Special Off-Cycle Billing
Quantity Requests:
If the intent of the request is to
validate or rebuild a previously
reported Billing Quantity Response,
then this date must be the same as
the reported start date of the
original response. If this date
differs, then the Billing Quantity
response will start from this
requested date.

Data
Type/Length
Request Daily Date yyyyMMdd Y This is the exclusive end date for a
Read Period End given billing request. It represents
Date the first date that will NOT be
included in billing quantities for the
SDP associated with the request.
The end date is an exclusive end
date. It is treated as the beginning
of the Request Daily Read Period
End Date (midnight (00:00:00)
which is the beginning of the day)
NOTE: Special Off-Cycle Billing
Quantity Requests:
the reported end date of the original
response (i.e. the “Response Daily
Read Period End Date”). If this date
differs, then the Billing Quantity
response will end with this
requested date.
If the request end date is later than
the Request Version Date Time
then the request can not be
satisfied for the purpose of
rebuilding a previous Billing
Quantity response.
Universal SDP Fixed Number General: Y The LDC/Billing Agent must provide
ID (8) NNNNNNNN the specific Universal SDP IDs that
Example: are to be reported on by the Billing
‘00037482’ Data Interface.
Request Type Char(1) General : Y This field is used to inform the

A MDM/R if this is an On-Cycle
Specific : Request and Off-Cycle Request.
P,O, or S Values:
“P” – Requested PULL – On Cycle
“O” – Requested PULL – Off Cycle
“S” – Scheduled PUSH – On Cycle
(this code is not applicable in this
request format)
Request Version Date/Time yyyyMMddHHmmss N Allows the requestor to request the
Date Time calculation of Billing Quantities over
a specified period but only using
Meter and Usage data up to the
Request Version Date Time. This is
a date time other than the current
date time. This time must be
reported in EST
the Response Version Date Time of
the original response.
The Request Type must be set to
“O” – Requested PULL – Off Cycle,
when this field is specified in the
request otherwise the request will
be rejected.

2.7 Billing Quantity Response
Note: Version 00 of each Billing Quantity response file type (File ID 6000, 6100, and
6200) will be replaced upon the deployment of EnergyIP Release 7.0 with Version 01
for each file type incorporating a file integrity enhancement consisting of an End-Of-File
(EOF) record. Please see Section 2.7.17 for changes to the File Name Record
specifications and the addition of the EOF record specification.
2.7.1 Description – Energy Billing Quantities: TOU/CPP, Periodic, Hourly

The purpose of this interface is to prepare the file with Billing Quantity data and send
the file to the LDC or authorized Billing Agent based on either a scheduled Billing Cycle
Schedule or as a result of processing a Billing Quantity Request File.
or their Billing Agents. The LDC or their Billing Agents may choose one method or the
other based on its operational requirements.
SDP data required to properly prepare the Billing Quantity data has been
synchronized by the LDC or their billing agents with the MDM/R.
§ Request-Response Billing Data Service (request-response) method which
delivers Billing Quantity data in response to a request from the LDC or their
Billing Agents using this Billing Quantity Request Interface. This method can
be used for requesting Billing Quantity data for both on-cycle and off-cycle
billing.
Section 7 of the MDM/R Detailed Design Document, Framing of Billing Quantities
discusses the framing of Billing Quantity data. Section 8 of the MDM/R Detailed
Design Document, Billing Quantity Processing, discusses the delivery of Billing
Quantity data. Section 2.5 of the Technical Interface Specifications provides the
technical details of this interface.
2.7.2 Integration
2.7.2.1 Direction
MDM/R to the LDC or their Billing Agent
This is a batch process involving the transfer of pipe (|) delimited text files.

1. In MDM/R, Billing Quantity data are computed based on the Read Date
identified in the Billing Cycle Schedule or the Request Daily Read Period End
Date specified in the Billing Quantity Request Detail record.
2. The Billing Quantity Response File is generated in the appropriate format.
3. Multiple Billing Quantity Responses may be provided for a single Billing
Quantity Request (or push) if the following conditions occur:

a. A season change (i.e. a global RPP price change event) occurred
during the period being requested. For any SDP for which the
Framing Structure is TOU/CPP or Periodic the billing service looks
for a global price change event that falls within the billing period
and delivers Billing Quantities for each sub-period defined by one
or more global price change events. The global RPP price change
events are defined in the Energy Purchase Service Calendar
associated with the Framing Structure assigned to each SDP
b. The framing structure for an SDP changed during the period being
requested.
c. An Account to SDP relationship changed during the period being
requested. The billing service looks for an Account to SDP
relationship change that falls within the billing period and delivers
Billing Quantities for each sub-period defined by one or more
Account to SDP relationship change events.
a. The MDM/R is unable to produce a Billing Quantity Response since
there was no meter associated with the SDP in the required period.
b. The MDM/R is unable to produce a Billing Quantity Response due
to missing intervals in the required period.
c. The MDM/R is unable to produce a Billing Quantity Response since
the SDP is not active during the billing period.
d. One or more intervals have the VEE outcome of “NVE”
The following must exist for the input file to be processed through the interface
§ A Billing Quantity Request File has been submitted and has been processed
by the Billing Quantity Request Interface for PULL requests.
§ A Billing Quantity Response File has been sent to the Organization
associated with the Data Delivery Service.
2.7.6 Assumptions
None

Frequency: For the Request-Response Billing Service (“Pull”) a Billing Quantity
Response file is sent in response to a specific Billing Quantity Request. For the
Scheduled Billing Service (Push”) a Billing Quantity Response file is sent for each
billing cycle scheduled for delivery on that day to the LDC or its Billing Agent.
Billing Window: Both “Push” and “Pull” billing services are controlled by global billing
service properties that establish a billing window of three business days.
• ‘AllowableReadAge’ / ‘AllowableRead AgeType’ is set to ‘0’ / ‘Calendar’ days –
this global configuration provides that a requested billing period will not be
foreshortened, that is, all days requested in a billing period must be included in
each Billing Quantity response.
• ‘LatestReportDays’ / ‘LatestReportDaysType’ is set to ‘3’ / ‘Business’ days – this
global configuration provides a period of three business days after the last day of
a billing period to allow time for the LDC or its authorized agent to provide
necessary interval data that may be missing or requires verification or edit.
• All related global billing service properties are specified in the “MDM/R VEE
Standard for the Ontario Smart Metering System”.
During the billing window Billing Quantity requests (“Push” or “Pull”, On-Cycle or Off-
Cycle) remain active if complete framed usage data or interval data for any day are not
available or for which the Validation Status is NVE. A ‘no data available’ response is
returned for all unfulfilled requests at 08:00 EST on the calendar day after a billing
window closes.
Billing Quantity requests submitted after the billing window is closed (i.e. submitted
more than three business days after the ‘Request Daily Read Period End Date’) will be
processed once with a Billing Quantity response returned immediately (with or without
a Billing Quantity value dependent on the ‘Transaction Status’ of the response).
Timing:
The Billing Quantity Response process will launch and process the Off-Cycle requests
(Request Type ‘O’) when initially received. On Cycle PULL requests (Request Type
‘P’) and On Cycle Scheduled PUSH (Request Type ‘S’) will be processed on the
regularly scheduled run of the Billing Quantity Response process. This process is
configured to run at certain times during the day. Initially this process will run every
three hours each day between the hours of 08:00 EST and 23:00 EST. Based on
experience gained during the testing and initial operations of the MDM/R, this schedule
may be modified to meet operational requirements.
Initially, scheduled PUSH (Request Type ‘S’) for the current day will be loaded at 07:30
EST. This schedule may be modified to meet operational requirements
The Billing Quantity Response Files are closed and moved to the appropriate FTS/AS2
delivery directories on the following conditions;
i. the billing quantity processing has not written to the file for more
than BillingExportAdapter.FileIdle seconds, or;
ii. the number of records written to the currently open file exceeds
BillingExportAdapter.MaxRecords.

Initially, the Billing Service Global Parameters of FileIdle and MaxRecords are set to 60
seconds and 10,000 records. Based on experienced gained during initial operations of
the MDM/R, these parameters may be modified to meet operational requirements.
Service Levels:
The Billing Quantity Response File is provided within the following timeframes, based
on the Billing Service Global Parameters of AllowableReadAge of 0 calendar days and
LatestReportDays of 3 business days:
§ For the Scheduled Billing Service - Billing Quantity data will be provided by
21:05 through the third business day after Day N for all SDPs that have
successfully completed the VEE process by 15:00 on any subsequent day
through the third business day after Day N.
§ For the Request-Response Billing Service - Billing Quantity data will be
provided within six hours of the timestamp of the receipt of the Billing
Quantity Request for all SDPs that have successfully completed the VEE
process by that time. Where the Billing Quantity Request includes Request
Daily Read Period End Dates that are in the future, the Billing Quantity data
will be provided within six hours of the Request Daily Read Period End Date
based on the Billing Quantity process runs on the Request Daily Read Period
End Date. For SDPs that complete the VEE process after the Request Daily
Read Period End Date, the Billing Quantity Response will be provided on any
subsequent day through the third business day after Day N (the exclusive
end date for the Billing Quantity Request).
§ In both cases, Scheduled Billing Service and Request-Response Billing
Service, if the process is unable to provide a Billing Quantity response by the
end of the billing window (being the exclusive end date plus the LatestReport
Days) then on the first run of the Billing Quantity processing after the close of
the billing window a “no data available” Billing Quantity response record will
be delivered for each SDP for which Billing Quantity values can not be
produced.
2.7.8 File Format

2.7.8.1 TOU/CPP & Periodic Billing Quantity Response File
2.7.8.1.1 File Name Record for the TOU/CPP & Periodic Billing Quantity Response File
Table 2.7.1 FILE NAME RECORD FOR THE TOU/CPP & PERIODIC BILLING QUANTITY
RESPONSE FILE

<FTSFN>

</FTSFN>
An example of this record Version 00 would be:

2.7.8.1.2 TOU/CPP & Periodic Billing Quantity Response File Header Record
Table 2.7.2 TOU/CPP & PERIODIC BILLING QUANTITY RESPONSE FILE HEADER RECORD
Data Type /
Length
Record Type Char(2) General: Y To indicate that this record is the
Identifier AA “Header of the Response” in the LDC
or Billing Agent’s Billing Quantity
Specific Usage:
Response file.
HR
Value must be: “HR”
Response File Char(2) AA Y The version of the response file to
Format Version allow for migration from one format to
the next as formats change.
Recommended that no more than 2
or 3 versions are supported.
LDC Char(8) General : Y This field contains the LDC that owns
Organization AAAAAAAA the SDPs in this response file.
Identifier The identifier is assigned to the LDC
Example :
ORG82357 during the MDM/R
Registration/Enrollment process. The
LDC creates SDPs and thus owns
those Service Delivery Points.
Service AAAAAAAA Organization that is providing Billing
Organization Services for the LDC (this may be the
Example :
Identifier LDC itself).
ORG82357
Billing Quantities are only provided to
the Organization that is associated
with each SDP as providing Billing
Services in the MMD.
Response File Date/Time yyyyMMddHHm Y Provides the date time when the
Created Date mss Response File was created by the
Time MDM/R – EnergyIP. This is not the
date time of the delivery.
2.7.8.1.3 TOU/CPP & Periodic Billing Quantity Response Detail Record

Table 2.7.3 TOU/CPP BILLING QUANTITY RESPONSE DETAIL RECORD
Data Type /
Length
Record Type Char(2) General: Y To indicate that this record is TOU
Identifier AA Response Detail record in the LDC or
Billing Agent’s Billing Quantity

Data Type /
Length
Response file.
Specific Usage:
TR Value must be: “TR”
Request File Varchar (30) AAAAAAAAAA For PULL Billing To feedback the unique identifier that
Identifier Quantities, Y if the LDC or Billing Agent had supplied
supplied in the Request Header Record
associated with the Request Detail
For PUSH Billing records. This identifier is returned to
Quantities, N link the response to the request.
Request Detail Varchar (30) AAAAAAAAAA For PULL Billing To feedback the unique identifier that
supplied in the Request Detail Record. This
identifier is returned to link the
For PUSH Billing response to the request.
Quantities, N
Response Daily Date yyyyMMdd Y The first Daily Read Period date
Read Period included in the TOU/CPP Billing
Start Date Quantity Response Record for the
requested or scheduled SDPs.
This date could be different than the
Requested Daily Read Period Start
Date if there has been a Move
Out/Move In at the SDP subsequent
to the requested start date during the
requested period or if a Season
Change related to the TOU Framing
has occurred during the requested
period.
Response Daily Date yyyyMMdd Y This is the exclusive end date for a
Read Period End given billing quantity response. It
Date represents the first date that is NOT
SDP.
date. It is treated as the beginning of
the Response Daily Read Period End
Date (midnight (00:00:00) which is
the beginning of the day)
Billing Cycle Varchar(3) AAA N Scheduled “PUSH” responses will
Identifier provide the Billing Cycle Identifier
(for PUSH only) associated with the SDP in the MMD.
Requested “PULL” responses will
contain a null value in this field.
Route Identifier Varchar(11) AAAAAAAAAA N Scheduled “PUSH” responses will
(for PUSH only) A provide the Route Identifier
associated with the SDP in the MMD.
This value will be equal to the LDC’s
Organization ID+the Billing Cycle ID.
Universal SDP Fixed Number NNNNNNNNNN Y The Universal SDP ID that is
ID (8) associated with the Billing Quantity.
Framing Varchar (12) General: Y The Framing Structure associated
Structure AAAAAAAAA with the Service Delivery Point.
In this field the value will be:
Specific:
“TOU/CPP(EST)” for SDPs in
TOU/CPP(EST) Eastern Standard Time.
Or “TOU/CPP (CST)” for SDPs in
TOU/CPP(CST) Central Standard Time.
Request Type Char(1) General: Y This field indicates if this was a

Data Type /
Length
A response to an On-Cycle Request
and Off-Cycle Request.
Specific:
Values:
P, O, or S
Request Version Date/Time yyyyMMddHHm For PULL Billing To feedback the Request Version
Date Time mss Quantities, Y if Date Time if provided by the LDC or
supplied Billing Agent as part of a Special Off-
Cycle Billing Quantity Request.
For PUSH Billing
Quantities, N
Response Detail Varchar (30) AAAAAAAAAA Y To feedback an MDM/R unique
Identifier identifier that is used within MDM/R
for the Billing Quantities reported in
this response.
Response Date/Time yyyyMMddHHm Y This is the latest insert date time of
Version Date mss the set of data used for billing
Time quantity calculations
This date time is prior to the Billing
Quantity Response data being
written into the Billing Quantity
Response file that is transferred to
the Data Delivery Service
Organization.
Transaction Fixed General: Y Provides the status of the request
Status Number(2) NN transaction. Values include:
00 = Response Completed
Successfully
For EnergyIP
Release 6.3 01 = unable to process the request –
and 7.0, general configuration error.
One of 02 = no data available, billing window
“00”, “01”, “02”, expired.
“06”, “07”, “08”, 06 = Billing Validation Sum Check
“09”, “10”, “12”, failed
“15”, “16”, “17”, 07 = Billing Validation Sum Check
“18” skipped
08 = Billing Quantity value is not
provided in the response
09 = Invalid Billing Determinant
10 = Missing DDS Parameter
11 = Validation Failed, Data Delivery
Service Hi-Low Check and
Consecutive Estimation Check
(disabled for the MDM/R)
12 = Meter Gap – Events Handling
13 = No Dates In Data Delivery
Cycles Table
14 = Missing Route Cycle ID
15 = Request Cancelled
16 = Invalid Measurement Profile
17 = Missing Primary Measurement
for a Demand Billing Quantity
18 = Reference not found for a
calculated billing determinant
See Table 2.7.4 for descriptions of
the Transaction Status codes and the

Data Type /
Length
billing service process conditions or
root causes of the exceptions
indicated by these codes.
Unit of Measure Varchar General: Y Provides the Unit of Measure
UOM (15) AAAAAAA applicable to the Billing Quantities
Specific Usage being provided in this response
for TOU/CPP: record.
“KWH” Valid values for energy:
KWH
Estimated Number NNNNNNNNNN Y Provides that portion of the total
Energy (12,2) NN.NN energy consumption reported over
Consumption the period defined from the
Response Daily Read Period Start
Date to the Response Daily Read
Period End Date that has been
estimated.
0.00 value if there is no estimated
energy consumption
NULL if “No Response” – No Billing
Quantity value is provided for
Transaction Status Codes: 01, 02,
08, 09, 10, 13, 14, 15, 16, 17, or 18.
Billing Quantity value is provided for
Transaction Status Codes 06 and 07
when the Billing Validation Sum
Check “BillingSumCheckFailAction”
parameter is set to ‘Value’
Number of Billing Numeric(3) NNN Y The number of Billing Quantity
Quantity Pairs Identifier and Billing Quantity pairs
with this response record. For
TOU/CPP this should be a minimum
of 3 based on the present structure of
TOU buckets. Each CPP Event
Billing Quantity to be reported will
increase the number of pairs by 1.
Multiple CPP events with the same
price will be summarized into a single
CPP event pair for the billing period.
For example, a TOU/CPP Response
with 2 CPP Events to be reported
would result in this field containing
the value 5.
The design maximum is 10 pairs.
Billing Quantity 1 Varchar(9) General: Y To identify the associated Billing
Identifier AAAAAAA Quantity.
Values:
Example:
On Peak
On Peak
Mid Peak
Off Peak
Billing Quantity 1 Number NNNNNNNNNN Y To hold the Billing Quantity related to
(12,2) NN.NN the associated “Billing Quantity
Identifier”
Values:
Example:
On Peak
Mid Peak
Mid Peak
Off Peak

Data Type /
Length
Identifier”
Values:
Example:
On Peak
Off Peak
Mid Peak
Off Peak
Identifier”
Values:
Example:
On Peak
CPP-08.90
Mid Peak
Off Peak
Or to identify the specific CPP Event
by its pricing. E.g. “CPP-xx.xx” where
“xx.xx” would identify the CPP Event
Pricing.
Identifier”
Values:
Example :
On Peak
CPP-08.92
Mid Peak
Off Peak
Pricing.
Identifier”
Values:
Example:
On Peak
CPP-08.94
Mid Peak
Off Peak
Pricing.
Identifier”
Values:
Example :
On Peak
CPP-08.96
Mid Peak
Off Peak

Data Type /
Length
Pricing.
Identifier”
Values:
Example:
On Peak
CPP-08.98
Mid Peak
Off Peak
Pricing.
Identifier”
Values:
Example:
On Peak
CPP-90.00
Mid Peak
Off Peak
Pricing.
Identifier”
Billing Quantity Varchar(9) General: Y To identify the associated Billing
10 Identifier AAAAAAA Quantity.
Values:
Example:
On Peak
CPP-09.02
Mid Peak
Off Peak
Pricing.
Billing Quantity Number NNNNNNNNNN Y To hold the Billing Quantity related to
10 (12,2) NN.NN the associated “Billing Quantity
Identifier”
Table 2.7.4 provides descriptions of the Transaction Status codes reported in each
Billing Quantity response and also in Report BR04 – Billing Delivery Detail Report.
The billing service process condition and/or the root causes of exceptions are also
described. This table also indicates the EnergyIP Releases which support each code.

Table 2.7.4 Billing Quantity Response Transaction Status and Exceptions
EnergyIP
Code Transaction Status / Report BR04 Error Message Billing Service Condition / Cause of Exception
Release
Billing Service successfully processed the Billing
00 Response completed successfully All
Quantity Request
This may occur when:
§ SDP Not active during billing period
§ No meter associated with SDP during billing
period
Unable to process the request – general configuration
01 § Invalid SDP ID All
error
§ The Billing Quantity Request has a
‘Request Daily Read Period Start Date’ that
is greater than the ‘Request Daily Read
Period End Date’
This may occur when:
§ There are missing intervals in the billing
02 No data available, billing window expired. period All
§ One or more intervals in the billing period
has a VEE outcome of NVE
Billing Validation Sum Check failed – ‘ThresholdValue’ ‘ThresholdValue’ was exceeded for the VEE
06 6.3, 7.0
exceeded Service applied to the SDP
Register readings not found within
‘MaxRegisterRange’ for the VEE Service applied
to the SDP. This may occur when:
§ Register readings not found within
‘MaxRegisterRange relative to the ‘Request
Daily Read Period Start Date’ or ‘Request
Daily Read Period End Date.
§ A Meter Change event occurred during the
billing period and register reads not found
within MaxRegisterRange as applicable to
the end of the old meter or the start of the
07 Billing Validation Sum Check skipped – new meter. 6.3, 7.0
- Register Read for the old meter must
be found between the old SDP-Meter
Relationship End Date/Time minus
MaxRegisterRange to old SDP-Meter
Relationship End Date/Time minus one
second.
- Register Read for the new meter must
be found between the new SDP-Meter
Relationship Start Date/Time and the
new SDP-Meter Start Date/Time plus
MaxRegisterRange.
Requesting organization does not match active
08 Billing Quantity value is not provided in the response 6.3, 7.0
Billing Agent
09 Invalid Billing Determinant Billing Quantity Request placed on HOLD 6.3, 7.0
Configuration Error - a Data Delivery Service
10 Missing DDS Parameter 6.3, 7.0
parameter is missing
Validation Failed, Data Delivery Service Hi-Low
11 (Disabled for the MDM/R) n/a
Check and Consecutive Estimation Check
12 Meter Gap – Events Handling Meter not found for a segment or billing period 6.3, 7.0
13 No Dates In Data Delivery Cycles Table (Disabled for the MDM/R) n/a
14 Missing Route Cycle ID (Disabled for the MDM/R) n/a
15 Request Cancelled Billing Quantity Request cancelled via the GUI 6.3, 7.0
Configuration error –
16 Invalid Measurement Profile 6.3, 7.0
§ No measurement attached to the

EnergyIP
Code Transaction Status / Report BR04 Error Message Billing Service Condition / Cause of Exception
Release
Measurement Profile, or
§ Measurement Profile Name is null in the
Data Delivery Service
• Primary measurement referenced by a
Coincident Peak Demand measurement is
Missing Primary Measurement for a Demand Billing missing, or
17 6.3, 7.0
Quantity • When using tie breaking to determine the
peak demand, the coincident peak demand
is missing
Reference for symbol in a calculative billing
determinant cannot be found. For example, in the
Reference not found for a calculated billing expression (CAL1|*25), the value “CAL1|” should
18 6.3, 7.0
determinant reference a DDS product parameter or a
measurement symbol value but the referenced
value is not available.
Table 2.7.5 PERIODIC BILLING QUANTITY RESPONSE DETAIL RECORD
Data Type /
Length
Identifier AA Periodic Billing Quantity Response
Detail record in the LDC or Billing
Specific Usage: Agent’s Billing Quantity Data Delivery
PR Response file.
Value must be: “PR”
Quantities, N
Read Period included in the PERIODIC Billing
requested period.
SDP.

Data Type /
Length
This field will contain a null value for
Requested “PULL” responses.
Route Identifier Varchar(11) AAAAAAAAAAA N Scheduled “PUSH” responses will
(for PUSH only) provide the Route Identifier
Organization ID+the Billing Cycle ID
Universal Fixed Number NNNNNNNNNN Y The Universal SDP ID that is
SDP ID (8) associated with the Billing Quantity.
Framing Varchar(12) General: Y The Framing Structure associated
Structure AAAAAAA with the Service Delivery Point.
In this record the value should
Specific Usage: indicate “PERIODIC”
PERIODIC
Request Type Char(1) A Y This field indicates if this was a
response to an On-Cycle Request
Values:
For PUSH Billing
Quantities, N
this response.
Organization.
Status Number(2) NN transaction.
Values include:
For EnergyIP 00 = Response Completed
Release 6.3, Successfully
and 7.0 01 = unable to process the request –
One of general configuration error.
“00”, “01”, “02”, 02 = no data available, billing window
“06”, “07”, “08”, expired.
“09”, “10”, “12”, 06 = billing validation sum check
“15”, “16”, “17”, failed
“18”
07 = billing validation sum check
skipped

Data Type /
Length
Cycles Table
18 = Reference not fopund for a
Billing Service process conditions or
UOM (15) AAAAAAA applicable to the Billing Quantities
for Periodic: record.
KWH
Estimated Numeric NNNNNNNNNN Y Provides that portion of the total
Energy (12,2) NN.NN energy consumption reported over
Consumption the period defined from the
Response Daily Read Period Start
Date to the Response Daily Read
Period End Date that has been
estimated.
energy consumption
Transaction Status Codes 01, 02, 08,
09, 10, 13, 14, 15, 16, 17, or 18.
Check “BillingSumCheckFailAction”
parameter is set to ‘Value’
Periodic Billing Numeric NNNNNNNNNN Y To hold the single Billing Quantity for
Quantity (12,2) NN.NN the period.

2.7.8.2 Hourly Billing Quantity Response File
2.7.8.2.1 File Name Record for Hourly Billing Quantity Response

Table 2.7.6 FILE NAME RECORD FOR THE HOURLY BILLING QUANTITY RESPONSE FILE

<FTSFN>
</FTSFN>

2.7.8.2.2 Hourly Billing Quantity Response File Header Record

Table 2.7.7 HOURLY BILLING QUANTITY RESPONSE FILE HEADER RECORD
Data Type /
Length
Specific Usage: Response file.
HR Value must be: “HR”
Example : during the MDM/R
ORG82357 Registration/Enrollment process. The

Data Type /
Length
Identifier Example : LDC itself).
ORG82357 Billing Quantities are only provided to
2.7.8.2.3 Hourly Billing Quantity Response Detail Record

Table 2.7.8 HOURLY BILLING QUANTITY RESPONSE DETAIL RECORD
Data Type /
Length
Record Type Char(2) General: Y To indicate that this record is Hourly
Identifier AA Billing Quantity Response Detail
record in the LDC or Billing Agent’s
Specific Usage: Billing Quantity Data Delivery
SR Response file.
Value must be: “SR”
Quantities, N
Response Daily Date yyyyMMdd Y The Response Daily Read Period
Read Period date for this specific HOURLY Billing
Date Quantity Response Record for the
requested SDP.
Organization ID+the Billing Cycle ID
Universal SDP Fixed Number NNNNNNNN Y The Universal SDP ID that is
Structure AAAAAA with the Service Delivery Point.
In this record the value should

Data Type /
Length
Specific: indicate “HOURLY”
HOURLY
Request Type Char(1) General : Y This field indicates if this was a
Specific : Values:
P, O, or S “P” – Requested PULL – On Cycle
For PUSH Billing
Quantities, N
this response.
Organization.
Status Number(2) NN transaction.
Values include:
For EnergyIP 00 = Response Completed
Release 6.3, and Successfully
7.0 01 = unable to process the request –
“00”, “01”, “02”, 02 = no data available, billing window
“06”, “07”, “08”, expired.
“09”, “10”, “12”, 06 = billing sum validation check
“15”, “16”, “17”, failed
”18” 07 = billing validation sum check
skipped
Cycles Table

Data Type /
Length
UOM (15) AAAAAAAA applicable to the Billing Quantities
for Hourly: record.
KWH
Estimated Numeric NNNNNNNNNN N Provides that portion of the total
Energy (12,2) NN.NN energy consumption reported for the
Consumption Response Daily Read Period Date
that has been estimated.
energy consumption
Transaction Status Codes 01, 02, 08,
09, 10, 13, 14, 15, 16, 17, or 18.
Check parameter
“BillingSumCheckFailAction” is set to
‘Value’
Billing Quantity Numeric NNNNNNNNNN N The Billing Quantity for the Hour
Hour Ending 01 (12,2) NN.NN Ending 01:00:00 EST on the
Response Daily Read Period Date.

Data Type /
Length
Response Daily Read Period Date +
1 (also known as Hour Ending 24 on
the Response Daily Read Period
Date).

2.7.9 Description – Demand Billing Quantities
The purpose of this interface is to prepare demand Billing Quantity response data and
transmit this data to the LDC or authorized Billing Agent based on either a scheduled
Billing Cycle Schedule or as a result of processing a Billing Quantity request.
The demand Billing Quantity response record will supplement the corresponding
energy related Billing Quantity response record for the same SDP. Demand Billing
Quantity data will be available to supplement TOU/CPP, Periodic and Hourly Framing
Structures as determined by the demand Framing Structure associated with the SDP.
2.7.10 Integration
2.7.10.1 Direction
MDM/R to the LDC or their Billing Agent
This is a batch process involving the transfer of pipe (|) delimited text files.

A) General Meter Read Data
1. The physical meters for the SDP or the meters contributing to the SDP must
be delivering Meter Read data to the MDM/R to be processed as required to
populate the configured interval data channels.
2. The Meter Read data from physical meters and calculated interval data for
virtual channels must be complete for all intervals for all days of the billing
period and the latest versions of this data must be used.
i. kW calculations and the determination of Peak kW Demand related
Billing Quantity data must not be performed if any of the kWh intervals
within billing period has a Validation Status of “NVE”.
ii. kVA calculations and the determination of Peak kVA Demand related
Billing Quantity data must not be performed if any of the kVAh or
kVARh intervals within billing period has a Validation Status of “NVE”.
iii. Neither kWh energy nor kW or kVA demand Billing Quantity responses
will be delivered if any of the related kWh, kVAh or kVARh interval data
within a billing period has a Validation Status of “NVE”.
3. Intervals used in all demand calculations must be calculated from interval
data within the billing period (defined as intervals with end date/times greater
than the Request Daily Read Period Start Date and less than or equal to the
Request Daily Read Period End Date).
4. All derived quantity and peak demand determinations, except calculation of
kW77 Peak Demand, will be performed for the billing period in EST for all
SDPs throughout Ontario.
5. The SDP must have a Framing Structure that specifies the framing of interval
data into derived kW and kVA quantities in addition to TOU/CPP, Periodic or
Hourly kWh energy quantities. The applicable Framing Structures (as
specified in the Technical Interface Specifications, Section 2.2.8, Table
2.2.13) that provide such framing are listed below.

For the Eastern Time Zone:
§ TOU/CPP 15 minute Block (EST)
§ TOU/CPP 60 minute Block (EST)
§ TOU/CPP 15 minute Rolling (EST)
§ TOU/CPP 60 minute Rolling (EST)
§ Periodic 15 minute Block (EST)
§ Periodic 60 minute Block (EST)
§ Periodic 15 minute Rolling (EST)
§ Periodic 60 minute Rolling (EST)
§ Hourly 15 minute Block (EST)
§ Hourly 60 minute Block (EST)
§ Hourly 15 minute Rolling (EST)
§ Hourly 60 minute Rolling (EST)
For the Central Time Zone:

§ TOU/CPP 15 minute Block (CST)
§ TOU/CPP 60 minute Block (CST)
§ TOU/CPP 15 minute Rolling (CST)
§ TOU/CPP 60 minute Rolling (CST)
§ Hourly 15 minute Block (CST)
§ Hourly 60 minute Rolling (CST)
§ Hourly 15 minute Rolling (CST)
§ Hourly 60 minute Block (CST)
§ Periodic 15 minute Block (CST)
§ Periodic 60 minute Block (CST)
§ Periodic 15 minute Rolling (CST)
§ Periodic 60 minute Rolling (CST)
6. Meter Read data or calculated data for the kWh or kVAh interval channels
must have been framed (according to the rules associated with the Framing
Structure for the SDP for the billing period) into the appropriate derived kW or
kVA quantities before the determination of the kW or kVA Demand related
Billing Quantities.
7. Derived kW and kVA quantities will not be stored. Underlying versions of
kWh, kVAh and kVARh interval data will support Billing Quantity version
traceability.
B) kW Demand Determinations
The following MMD master data condition must exist for the calculation of kW demand
quantities:

The SDP must have a physical or virtual meter configured with a Channel
Configuration Set that supports the derivation of kW demand quantities. These
would be Channel Configuration Sets as specified in the Technical Interface
Specifications, Section 2.2.10, Table 2.2.28 – specifically, one of:
§ ‘01’ – Physical Meter, Physical Channels (establishing Interval Channels
for Physical kWh), or
for Physical kWh, Physical kVARh, derived kVAh), or
§ ’03’ – Physical Meter, Physical Channels (establishing Interval Channels
for Physical kWh, Physical kVAh), or
§ ‘04’ - Physical Meter, Physical Channels (establishing Interval Channels
for Physical kWh, Physical kVARh, Physical kVAh), or
§ ‘05’ – Virtual SDP, Virtual Meter, Virtual Channels (establishing Interval
Channels for Virtual kWh), or
Channels for Virtual kWh, Virtual kVARh, derived Virtual kVAh).
C) kVA Demand Determinations

The following MMD master data condition must exist for the calculation of kVA related
demand quantities:
The SDP must have a physical or virtual meter configured with a Channel
Configuration Set that supports the derivation of kVA demand quantities. These
would be Channel Configuration Sets as specified in the Technical Interface
Specifications, Section 2.2.10, Table 2.2.28 – specifically, one of:
for Physical kWh, Physical kVARh, derived kVAh), or
§ ’03’ – Physical Meter, Physical Channels (establishing Interval Channels
for Physical kWh, Physical kVAh), or
§ ‘04’ - Physical Meter, Physical Channels (establishing Interval Channels
for Physical kWh, Physical kVARh, Physical kVAh), or
Channels for Virtual kWh, Virtual kVARh, derived Virtual kVAh).
D) Block kW and kVA Derived Quantities

1. Block 60 minute kW derived quantities will be calculated for each clock hour
at the end of the hour (e.g. 01:00, 02:00, 03:00) based on the energy (kWh)
consumed during each hour for all hours of the day.
2. Block 60 minute kVA derived quantities will be calculated on the each clock
hour at the end of the hour (e.g. 01:00, 02:00, 03:00) based on the volt-
ampere hours (kVAh) or var hours (kVARh) consumed during each hour for
all hours of the day.
3. Block 15 minute kW derived quantities will be calculated on the quarter hour
at the end of each quarter hour (e.g. 01:15, 01:30, 01:45, 02:00) based on
the energy (kWh) consumed during each quarter hour for all hours of the day.

4. Block 15 minute kVA derived quantities will be calculated on the quarter hour
at the end of each quarter hour (e.g. 01:15, 01:30, 01:45, 02:00) based on
the volt-ampere hours (kVAh) or var hours (kVARh) consumed during each
quarter hour for all hours of the day.
5. Block 60 minute derived quantities can be based on 5, 10, 15, 30 or 60
minute interval data ending wholly within each clock hour.
6. Block 15 minute derived quantities can be based on 5 or 15 minute interval
data ending wholly within each quarter hour.
7. Billing Period Block kW and kVA derived quantities will only be calculated
from interval data within the Billing Period (defined as intervals with end
date/times greater than the Request Daily Read Period Start Date and less
than or equal to the Request Daily Read Period End Date).
8. kW77 Block kW and kVA derived quantities for use in the kW77 Peak kW
and kVA demand determination must be based on interval data within the
period between 7:00 a.m. & 7:00 p.m. prevailing time. The kW77 period is
defined as follows:
i. For the Eastern time zone is the period between 0700 hours to 1900
hours Eastern Standard Time during winter (i.e. during Standard Time)
and 0600 hours to 1800 hours Eastern Standard Time during summer (i.e.
during Daylight Savings Time) on weekdays that are not statutory
holidays.
ii. For the Central time zone is the period between 0800 hours to 2000
during Daylight Savings Time) on weekdays that are not statutory
holidays.
E) Rolling kW and kVA Derived Quantities

1. Rolling 60 minute kW derived quantities are based on calculations from sub-
intervals over a rolling period of 60 minutes. These derived quantities are
calculated at the end of each sub-interval based on the energy (kWh)
consumed during the rolling 60 minute period.
2. Rolling 60 minute kVA derived quantities are based on calculations from sub-
calculated at the end of each sub-interval based on the volt-ampere hours
(kVAh) or var hours (kVARh) consumed during the rolling 60 minute period.
3. Rolling 15 minute kW derived quantities are based on calculations from sub-
calculated at the end of each sub-interval based on the energy (kWh)
consumed during the rolling 15 minute period.
4. Rolling 15 minute kVA derived quantities are based on calculations from sub-
calculated at the end of each sub-interval based on the volt-ampere hours
(kVAh) or var hours (kVARh) consumed during the rolling 15 minute period.
5. Supported sub-interval lengths for rolling 60 minute periods are 5,10,15 and
30 minute.

6. Supported sub-interval lengths for rolling 15 minute periods is 5 minutes.
7. Billing Period Rolling kW and kVA derived quantities will only be calculated
from interval data within the Billing Period (defined as intervals with end
date/times greater than the Request Daily Read Period Start Date and less
than or equal to the Request Daily Read Period End Date).
8. kW77 Rolling kW and kVA derived quantities for use in the kW77 Peak kW
and kVA demand determination must be based on interval data within the
period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that are
not statutory holidays. The kW77 period is defined as follows:
i. For the Eastern time zone is the period between 0700 hours to 1900
during Daylight Savings Time).
ii. For the Central time zone is the period between 0800 hours to 2000
during Daylight Savings Time).
F) Peak Demand Determination and Coincident Quantity

The following rules will be used to determine the Peak kW and Peak kVA Demand and
associated Coincident kVA and kW Billing Quantities.
1. Peak kW Demand is the maximum kW demand quantity in any period within
the billing period using the derived kW data. The derived data can be:
i. One of “15 minute” or “60 minute” and one of “Block” or “Rolling” as
specified by the Framing Structure in effect during the billing period.
2. The Coincident kVA Quantity associated with the Peak kW Demand will be the
highest coincident kVA quantity subject to the following tie breaking rules:
i. In the event that there are multiple occurrences of a maximum kW
demand quantity in the billing period, the maximum kW demand quantity
with the highest coincident kVA quantity will be selected.
ii. If there are multiple occurrences of a maximum kW demand quantity with
the same highest coincident kVA quantity in the billing period, the most
recent maximum kW demand quantity and highest coincident kVA
quantity will be selected.
3. Peak kVA Demand is the maximum kVA demand quantity in any period within
the billing period using the derived kVA data. The derived data can be:
4. The Coincident kW Quantity associated with the Peak kVA Demand will be the
highest coincident kW quantity subject to the following tie breaking rules:
i. In the event that there are multiple occurrences of a maximum kVA
demand quantity in the billing period, the maximum kVA demand quantity
with the highest coincident kW quantity will be selected.
ii. If there are multiple occurrences of a maximum kVA demand quantity
with the same highest coincident kW quantity in the billing period, the

most recent maximum kVA demand quantity and highest coincident kW
quantity will be selected.
G) kW77 Peak Demand Determination and Coincident Quantity

The following rules will be used to determine the kW77 Peak kW and kW77 Peak kVA
Demand and associated Coincident kVA and kW Billing Quantities.
1. Peak kW77 Demand is the maximum kW demand quantity in any kW77 period
(the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that
are not statutory holidays) within the billing period using the kW77 related
derived kW data. The derived data can be:
2. The Coincident kVA Quantity associated with the Peak kW77 Demand will be
the highest coincident kVA quantity subject to the following tie breaking rules:
i. In the event that there are multiple occurrences of a maximum kW
demand quantity in all kW77 periods in the billing period, the maximum
kW demand quantity with the highest coincident kVA quantity will be
selected.
ii. If there are multiple occurrences of a maximum kW demand quantity with
the same highest coincident kVA quantity in all kW77 periods in the
billing period, the most recent maximum kW demand quantity and highest
coincident kVA quantity will be selected.
3. Peak kVA77 Demand is the maximum kVA demand quantity in any kW77
period (the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays
that are not statutory holidays) within the billing period using the kW77 related
derived kVA data. The derived data can be:
4. The Coincident kW Quantity associated with the Peak kVA77 Demand will be
the highest coincident kW quantity subject to the following tie breaking rules:
i. In the event that there are multiple occurrences of a maximum kVA
demand quantity in all kW77 periods in the billing period, the maximum
kVA demand quantity with the highest coincident kW quantity will be
selected.
ii. If there are multiple occurrences of a maximum kVA demand quantity
with the same highest coincident kW quantity in all kW77 periods in the
billing period, the most recent maximum kVA demand quantity and
highest coincident kW quantity will be selected.
The following must exist for Billing Quantity requests processed through the interface:
§ A Billing Quantity Request File has been submitted and has been processed
by the Billing Quantity Request Interface for PULL requests.

The following outcome results from Billing Quantity requests processed through the
interface:
§ Demand related and Energy related Billing Quantity Response files have
been sent to the Organization associated with the Data Delivery Service.
2.7.14 Assumptions
None.

Frequency: The Demand Billing Quantity response is sent in response to a specific
Billing Quantity request. For the scheduled push method, a Billing Quantity response
is determined and sent for each SDP associated with billing cycles scheduled on each
day.
Timing:
The Demand Billing Quantity response is sent within the processing constraints of the
billing window.
2.7.16 File Format

2.7.16.1 Demand Billing Quantity Response File – Supplement to TOU/CPP, Periodic and
Hourly Energy Response
A demand Billing Quantity response record will supplement the corresponding energy
related Billing Quantity response record for SDP’s assigned a “Framing Structure ID”
code ‘05’ through ‘28’ in the synchronization process.
2.7.16.1.1 File Name Record for Demand Billing Quantity Response

Table 2.7.9 FILE NAME RECORD FOR THE DEMAND BILLING QUANTITY RESPONSE FILE

<FTSFN>

</FTSFN>

2.7.16.1.2 Demand Billing Quantity Response File Header Record

Table 2.7.10 DEMAND BILLING QUANTITY RESPONSE FILE HEADER RECORD
Data Type /
Length
Specific Usage: Response file.
HR Value must be: “HR”
Example : during the MDM/R
ORG82357 Registration/Enrollment process. The
Identifier Example : LDC itself).
ORG82357 Billing Quantities are only provided to
2.7.16.1.3 Demand Billing Quantity Response Detail Record

Table 2.7.11 DEMAND BILLING QUANTITY RESPONSE DETAIL RECORD
Data Type /
Length
Identifier AA Demand related Detail record in the

Data Type /
Length
Specific Usage: LDC or Billing Agent’s Billing
DR Quantity Response file.
Value must be: “DR”
For PUSH Billing associated with the Request Detail
Quantities, N records. This identifier is returned to
link the response to the request.
For PUSH Billing identifier is returned to link the
Quantities, N response to the request.
Read Period included in the demand related Billing
requested period or if a Season
Change related to the TOU Framing
has occurred during the requested
period.
SDP.
Organization ID+the Billing Cycle ID.
Universal SDP Fixed Number NNNNNNNNNN Y The Universal SDP ID that is
Structure AAAAAAAAA with the Service Delivery Point.
Specific Usage: In this field the value will be one of
One of the demand related framing
‘TOU/CPP 15 minute structures related to “Framing
Block (EST)’, or Structure ID” values ‘05’ through ‘28’
(reference Section 2.2.8, Table
‘TOU/CPP 60 minute
Block (EST)’, or 2.2.13).

Data Type /
Length
Rolling (EST)’, or
‘Hourly 15 minute
Block (EST)’, or
‘Hourly 60 minute
Block (EST)’, or
‘Hourly 15 minute
‘Hourly 60 minute
‘Periodic 15 minute
Block (EST)’, or
Block (EST)’, or
Block (CST)’, or
Block (CST)’, or
Rolling (CST)’, or
‘Hourly 15 minute
Block (CST)’, or
‘Hourly 60 minute
Block (CST)’, or
‘Hourly 15 minute
‘Hourly 60 minute
Block (CST)’, or
Block (CST)’, or
Rolling (CST)’
Request Type Char(1) General: Y This field indicates if this was a
Specific Usage: and Off-Cycle Request.
P, O, or S Values:
Request Version Date/Time yyyyMMddHHmmss For PULL Billing To feedback the Request Version
Date Time Quantities, Y if Date Time if provided by the LDC or
For PUSH Billing Cycle Billing Quantity Request.
Quantities, N
this response.

Data Type /
Length
Response Date/Time yyyyMMddHHmmss Y This is the latest insert date time of
Version Date the set of data used for billing
Quantity response data being written
into the Billing Quantity response file
that is transferred to the Data
Delivery Service Organization.
Status Number(2) NN transaction. Values include:
Specific Usage: 00 = Response Completed
For EnergyIP Successfully
Release 6.3, and 7.0 01 = unable to process the request –
“00”, “01”, “02”, “06”, 02 = no data available, billing window
“07”, “08”, “09”, “10”, expired.
“12”, “15”, “16”, “17”, 06 = billing validation sum check
“18” failed
07 = billing validation sum check
skipped
Cycles Table
Peak 1 Varchar (10) General: Y To identify the associated peak
Quantity AAAAAAA Demand Billing Quantity.
Identifier Specific Usage: Values:
One of Peak kW – the Peak kW Demand
‘Peak kW’, or Quantity in the Billing Period
‘Peak kVA’, or Peak kVA – the Peak kVA Demand
Quantity in the Billing Period
‘Peak kW77’, or
Peak kW77 – the Peak kW Demand
‘Peak kVA77’
Quantity in the Billing Period in
accordance with the kW77 daily
periods
Peak kVA77 – the Peak kVA
Demand Quantity in the Billing Period
in accordance with the kW77 daily

Data Type /
Length
periods
Peak 1 Number NNNNNNNNNNNN. Y This peak demand value will be 15
Quantity (12,2) NN minute or 60 minute; Block or Rolling;
and EST or CST based on the
Framing Structure associated with
the Service Delivery Point.
NOTE 1: kVA quantities for Peak
kVA and Peak kVA77 will only be
produced if the MMD master data
and meter data conditions for the
calculation of kVA demand quantities
exists – See Business Rules.
Peak 1 Number NNNNNNNNNNNN. Y The quantity that was coincident with
Coincident (12,2) NN the peak demand quantity in the
Quantity Billing Period.
For Peak kW and Peak kW77 this
quantity is the coincident kVA for the
same date time.
For Peak kVA and Peak kVA77 this
quantity is the coincident kW for the
same date time.
NOTE 2: Coincident kVA quantities
will only be produced if the MMD
master data and meter data
conditions for the calculation of kVA
demand quantities exists – See
Business Rules.
NOTE 3: Coincident kW quantities
can only be determined if the Peak
kVA Demand Quantity has been
determined.
Peak 1 Date/Time yyyyMMddHHmmss Y The date time of the peak
End Date Time kW/coincident kVA pair, or the peak
kVA/coincident kW pair.
This is the end date time in EST of
the 15 minute or 60 minute Block or
Rolling period in which the Peak kW
Demand Quantity occurred during
the Billing Period.
‘Peak kVA’ or Peak kVA – the Peak kVA Demand
‘Peak kW77’, or Quantity in the Billing Period
‘Peak kVA77’ Peak kW77 – the Peak kW Demand
periods
periods

Data Type /
Length
same date time.
same date time.
Business Rules.
determined.
the Billing Period.
‘Peak kW77’, or
‘Peak kVA77’ Peak kW77 – the Peak kW Demand
periods
periods

Data Type /
Length
same date time.
same date time.
Business Rules.
determined.
the Billing Period.
‘Peak kW77’, or
Peak kW77 – the Peak kW Demand
‘Peak kVA77’
periods
periods
same date time.
same date time.

Data Type /
Length
Business Rules.
determined.
the Billing Period.
2.7.17 File Format – Billing Quantity Response Version 01

Version 01 for all Billing Quantity response file types will involve only incrementing the
FTS file name File Version (element 4: FILE_VER) to a value of “01”, and the addition
of an End-Of-File record as the last record for each Billing Quantity response file.
All other file format specifications Response File Header records and Response File
Detail records specified for Version 00 will remain unchanged in Version 01.
The following provides the File Name Record specification and End-Of-File record
specification for Version 01 for all MDM/R Billing Quantity response types.
2.17.1 File Name Record – Version 01

The first record in the response interface file is used to store the name of the file as
specified in Section 1.8. This record is used in the event that the original file name is
modified during the transfer between the MDM/R and an Organization.
Table 2.7.12 FILE NAME RECORD FOR VERSION 01 BILLING QUANTITY RESPONSE FILES

<FTSFN>
</FTSFN>
2.17.1.1 File Name Record: TOU/CPP & Periodic Billing Quantity Response File

2.17.1.2 File Name Record: Hourly Billing Quantity Response File
2.17.1.3 File Name Record: Hourly Billing Quantity Response File

2.17.2 End-of-File Record – Version 01

The last record in each Billing Quantity response file will be an End-Of-File (EOF)
record as described in table 2.7.13. Other than the Record Type being set to ‘ER’, the
remaining fields in this record will contain the same values as found in the header
record of the file.
The EOF Record will be present in each Version 01 Billing Quantity response file for
the following FTS File Types:
• File ID 6000 Billing Quantity Response – TOU/CPP & Periodic
• File ID 6100 Billing Quantity Response – Hourly
• File ID 6200 Billing Quantity Response – Demand
Table 2.7.13 END-OF-FILE RECORD FOR VERSION 01 BILLING QUANTITY RESPONSE

FILES

Identifier AA record is the last or end-of-file
Specific usage: record of the response file.
‘ER’ Value must be ‘ER’
Response File Char(2) General: Y This field indicates that this
Format Version AA record is the last or end-of-file
Specific usage: record of the response file.
‘01’ Value must be ‘ER’
LDC Char(8) General: Y This field contains the
Organization AAAAAAAA Organization ID of the LDC
Number Example: that owns the SDPs in the
‘ORG23153’ response file.
This is the unique identifier
assigned to the LDC during
the registration/enrollment
process.
The LDC creates each SDP
and thus owns those SDPs.
Data Delivery Char(8) General : Y The Organization ID assigned
Service AAAAAAAA to the Organization that is
Organization Example : providing Billing Services for
Identifier ORG82357 the LDC (this may be the
LDC itself).
Billing Quantities are only

provided to the Organization
that is associated with each
SDP as providing Billing
Response File Date/Time yyyyMMddHHmmss Y Provides the date time when
Created Date the Response File was
Time created by the MDM/R –
EnergyIP. This is not the
Sample End-Of-File Record – Version 01 Billing Quantity Response Types: 6000,

6100, 6200
ER|01|ORG70000|ORG70000|20100910150721

2.8.1 Description
The purpose of this interface is for the LDCs to provide the information needed by the
MDM/R to maintain the Billing Cycle Schedule.
The LDCs use the Billing Cycle Schedule interface to inform the MDM/R of the billing
cycle schedule dates that map to each billing cycle. The Billing Cycle Schedule is
typically provided once per year by the LDC or Billing Agent however the LDC or Billing
Agent may provide updated Billing Cycle Schedules throughout the year. It is
transmitted to the MDM/R using the File Transfer Services, and the MDM/R updates
the Billing Cycle Schedule accordingly.
With options available to supply billing quantities to the LDC via the Request-Response
Billing Data Service, wherein the LDC can specify the Universal SDP IDs that it needs
Billing Quantity data for (see Section 15.6 of the MDM/R Detailed Design Document,
Billing Quantity Request Interface and Section 15.7 of the MDM/R Detailed Design
Document, Billing Quantity Response Interface), the MDM/R’s functionality is not
impeded if the system does not have access to the LDC’s Billing Cycle Schedule.
Hence, updating the MDM/R with Billing Cycle Schedule data is optional and is only
required when the Scheduled Billing Data Service is used to ‘push’ Billing Quantity
data to the LDC on the appropriate bill days for each SDP, rather than using the
Request-Response Billing Data Service.
Only files that have passed the initial file checks will be processed by this interface.
The Cycle Synchronization Adapter is executed by the MDM/R Administrator as a
manual process when a new cycle schedule file is sent by the LDC. The adapter has a
single configuration parameter, FutureDays, which initially will be set to 3 calendar
days allowing updates to the cycle schedule to be blocked for the current day and
following two calendar days. This will prevent any changes to Billing Cycles during an
open Billing Window (based on the LatestReportDays parameter for Billing Quantity
Processing). Based on experience gained during initial operations of the MDM/R, this
parameter may be modified to meet operational requirements. In order to ensure that
all changes to Billing Cycles are applied to the MDM/R, an LDC or Billing Agent must
submit their Billing Cycle Schedules no less than 3 business days before the first date
being updated to allow for adequate time to process the Billing Cycle Schedule, taking
into account weekends and holidays. For example, if the first date being updated is
June 1st, then the Billing Cycle Schedule must be submitted no later than 3 business
days prior to June 1st. Alternatively, if the June 1st Billing Cycle date is being changed
to May 29th, then the Billing Cycle Schedule must be submitted no later than 3
business days prior to May 29th.
Upon execution of the adapter, the application will examine all cycle dates beyond the
FutureDays setting, delete all of the calendar entries for all billing cycles for the LDC
beyond that date, and insert the calendar entries provided in the Billing Cycle Schedule
Interface File. Calendar dates within the FutureDays parameter will not be changed.
Failure to resubmit all future Billing Cycle Schedule data will result in future Billing
Cycle Schedules not being populated in the MDM/R (e.g.: if 2007 and 2008 Billing
Cycle Schedules have already been submitted and a change is required to the 2007

Schedule, then a single file containing both the 2007 and 2008 Billing Cycle Schedules
beyond the change date would need to be submitted.)
At the end of the process, the file is moved from the incoming directory to the
Processed/Utility/MRSchedule directory and a message is written to the Cycle
Synchronization log file which will show a message similar to the output below:
INFO - No. of Billing Cycles Not found in the No Change Time Frame: 0
INFO - No. of Extra Billing Cycles Not found in the No Change Time Frame: 0
INFO - No. of Reading Cycles Not found in the No Change Time Frame: 0
INFO - No. of Extra Reading Cycles Not found in the No Change Time Frame: 0
INFO - No. of Billing Cycle Records Inserted: 62
INFO - No. of Reading Cycle Records Inserted: 37
2.8.2 Integration
2.8.2.1 Direction
LDC to the MDM/R
files. The file will contain ALL LDC billing cycles and the dates associated with them.
(i.e.: only one file is required to update all billing cycles)

1. The MDM/R posts valid dates for each Billing Cycle ID in the file in MDM/R.
Valid dates are any dates that exist in a calendar year (i.e.: June 31st is an
invalid date, July 1st is a valid date)
2. Valid dates (for a given LDC Identifier and Billing Cycle ID) overwrite any
previous dates in MDM/R as long as the date is beyond the FutureDays
parameter.
3. Updates to a Billing Cycle records that are within the number of calendar
days specified by the FutureDays parameter are not processed and an
exception is created.
4. The processed Billing Cycle File sent by the LDC is placed in the Process
Directory in the MDM/R.
a. The MDM/R Billing Cycle Schedule Adapter detects exceptions in
regards to invalid file format and data type exceptions.
b. The MDM/R detects exceptions when the Billing Cycle date is in the
past or when the Billing Cycle record is within the number of calendar
days specified by the FutureDays parameter.
6. The Billing Cycle Schedule Interface Exceptions are reported via the
system’s standard output and written to the Cycle Synchronization log file.

A confirmation will be sent to the LDC in Report IR03, Billing Cycle Schedule
Exceptions Report, indicating a successful or failed load.
NOTE: In the event of a load failure, the pre-existing Billing Cycle Schedule may have
been corrupted and remedial action will need to be taken by the LDC and/or its
designated agents in association with the SME/OSP. As this corruption will effectively
remove all future Billing Cycle dates, the OSP will retain and reinstate the most recent
copy of the LDC’s Billing Cycle Schedule.
The following must exists for the input file to be processed through the interface:
§ The LDC is enrolled and has an LDC Identifier assigned.
§ The LDC has determined that Billing Quantity data shall be provided based
on the Billing Cycle Schedule. The LDCs shall provide a Billing Cycle ID for
each Universal SDP ID through the synchronization process that will be
processed according to this billing cycle.
The following outcomes result from the file being processed through the interface:
§ The EnergyIP calendar is populated with the LDC’s scheduled Billing Dates
for generating billing quantities.
§ The LDC has received the exceptions (if any) from the MDM/R
Administrator.
2.8.6 Assumptions
None

Frequency: The Billing Cycle Schedule File may be sent by the LDCs as often as
required. This file is typically sent once per year by LDCs.
Timing: The Billing Cycle Schedule File may be sent by the LDCs at any time. However,
an LDC or Billing Agent must submit their Billing Cycle Schedules no less than 3
business days before the first date being updated to allow for adequate time to process
the Billing Cycle Schedule, taking into account weekends and holidays.
2.8.8 File Format

2.8.8.1 File Name Record for the Billing Cycle Schedule File

Table 2.8.1 FILE NAME RECORD FOR THE BILLING CYCLE SCHEDULE FILE

<FTSFN>
</FTSFN>

2.8.8.2 Billing Cycle Schedule File

Table 2.8.2 BILLING CYCLE SCHEDULE FILE
Data
Type/Length
Read Date Date DDMMYYYY Y This is the exclusive end date
for a given billing period within
a billing cycle. It represents
the first date that will NOT be
framed into billing quantities
for SDP’s associated with this
billing cycle ID.
Note: The date format does

not conform to the Section 1.7
date format specification.
Day of week Varchar (3 ) General: Y This is the 3 character
AAA abbreviation for the day of the
week for the given cycle date
Examples: all in caps.
‘MON’
‘TUE’.
Billing Cycle ID Varchar (3) General: Y Each SDP may have a Billing
AAA Cycle ID defined as part of the
Periodic Audit or Incremental
Examples: Synchronization process (see
‘1’ sections 2.2 and 2.3 of this
‘C45’. document). The Billing Cycle
ID is the LDC’s identifier for a
group of SDP’s that have the
same billing period.

2.9 Aggregated Settlement Data
2.9.1 Description
The MDM/R supports the aggregation of interval consumption data on an hourly basis
for each LDC based on the Loss Factor Classifications for each SDP for a Daily Read
Period date.
These aggregations are provided to support LDC’s requirements for settlement in the
following areas:
• Net System Load Shape Calculations; and
• RPP Variance Account Management.
This aggregated data will be provided to the LDC as a scheduled production of a file on
a daily basis.
2.9.2 Integration
2.9.2.1 Direction
MDM/R to the LDC
The Data Aggregation file for a given LDC for a given Daily Read Period date (“N”) will
be delivered as a single file, encompassing all applicable loss factor classifications.
The Data Aggregation Contributors file for a given LDC for a given Daily Read Period
Date (“N”) may be delivered in multiple files.

1. Virtual SDPs will be ignored.
2. Only physical SDPs with a valid Loss Factor Classification of 01 through 12
will be considered in this process. SDPs without a Loss Factor Classification
will be ignored.
3. Only physical SDPs with a Framing Structure of “Hourly” or “TOU/CPP(xxx)”
will be considered in this process. SDPs with Framing Structure of “Periodic”
will be ignored.
4. At 00:00:00 on Daily Read Period date “N” + 1, Capture the SDP and
associated Loss Factor Classification for each LDC for all SDPs that have a
Loss Factor Classification associated on a given Daily Read Period date “N”.
5. On day “N” + 3 for all SDPs by Loss Factor Classification for day “N”, gather
all of the latest interval consumption data (validated) for each interval for all
meters associated with the SDPs. This interval consumption and related
meter data is required to ensure that the Data Aggregation File and the Data
Aggregation Contributors File are produced from the same data for auditing
purposes. (Based on experience gained in the initial operations of the
MDM/R, the number of days between the daily read period and aggregation
may be extended if more days are necessary to complete the VEE process to
ensure a high quality result of the Data Aggregations)

6. Using the gathered interval consumption data (from previous step) compute
the hour-by-hour aggregations for each Loss Factor Classification for each
LDC. Hour-by hour aggregations will include:
• Total Aggregated Consumption including intervals with Validation
Status VAL; NV; EST, and NVE
• Validated Aggregated Consumption including intervals with Validation
Status VAL (all Change Methods) and NV
• Estimated Aggregated Consumption including intervals with EST (all
Change Methods)
• NVE Aggregated Consumption including intervals with Validation
Status NVE
7. A daily Data Aggregations File is generated for each LDC for Daily Read
Period date “N” will include for each of the 24 hours of the Daily Read Period:
• Aggregation Version Date Time which is the latest insert time of the
interval data set used each hourly aggregation
• Loss Factor Classification
• The hour-by-hour aggregations specified in Item 6 above
• The actual SDP count for each hour-by-hour aggregation
• The actual interval count for each hour-by-hour aggregation specified
in Item 6 above
• The count of interval expected to contribute to each hour-by-hour
aggregation
8. A Data Aggregations Contributors File will be created with the following
detail:
• Universal SDP ID (all active Universal SDP IDs with the associated
Loss Factor Classification must be listed in the report even if they
don’t have a meter associated with them.)
• Loss Factor Classification (Aggregation Classification)
• For all Interval Consumption data related to the SDP for day “N”
includes the following details for each unique SDP_Ref, Channel_Ref,
Meter_Ref:
a. Meter ID (associated with the Meter_Ref)
b. Channel Ref
c. Interval Length
d. Number of intervals (number of intervals found with any validation
status)
e. Number of Validated Intervals (number of intervals with validation
status (‘NV’ or ‘VAL’)
f. Number of Estimated Intervals (number of intervals with validation
status (‘EST’)

g. Number of Needs Verification Editing Intervals (number of
intervals with validation status (‘NVE’)
The following must exist for the output file to be processed through the interface:
• The LDC is enrolled and has an Organization ID assigned.
• One or more SDPs with an assigned Loss Factor Classification.
• A Data Aggregation File and Data Aggregation Contributors File have been
sent to the LDC via File Transfer Services.
• The Data Aggregation File and the related Data Aggregation Contributors
File are retained within the MDM/R.
2.9.6 Assumptions
• Only kWh interval consumptions will be included in this data aggregation
process.

Frequency:
The Data Aggregation process is run daily.
Timing:
The Data Aggregation file and the related Data Aggregation Contributors File are
produced for each Daily Read Period date “N” on day “N” + 3 calendar days and sent
to the LDC.
2.9.8 File Format

2.9.8.1 Data Aggregation File
2.9.8.1.1 File Name Record for the Data Aggregation File

Table 2.9.1 FILE NAME RECORD FOR THE DATA AGGREGATION FILE
Field Data
Format Required Description
Name Type/Length
<FTSFN>
File Name Varchar (250) Refer to Y This field contains the name of the file
Section 1.8 on the originating system
</FTSFN>

2.9.8.1.2 Data Aggregation File Header Record

Table 2.9.2 Data Aggregation Header Record
Data Type /
Length
Record Type Char (1) A To indicate that this record is “Header” record in the
Identifier Data Aggregation file.
Value could shall be: “H”
File Format Char (2) NN The version of the file to allow for migration from one
Version format to the next as formats change. Recommended
that no more than 2 or 3 are supported at any one time.
LDC Char (8) NNNNN The identifier assigned to the LDC during the MDM/R
Organization ID Registration/Enrollment process. The LDC creates
Example: SDPs and thus owns those Service Delivery Points.
ORG82357
Daily Read Date yyyyMMdd The Daily Read Period date that is being processed
Period Date through the Data Aggregation process.
This is the 24-hour period including all intervals of the
hour ending 01:00:00 of the Daily Read Period date N
and extending through all intervals of the 24th hour
ending 00:00:00 on date N+1
Data Date/Time yyyyMMddHH The date time when the Data Aggregation process and
Aggregation End mmss Data Aggregation Contributors process ended. (In
Date Time EST)
2.9.8.1.3 Data Aggregation File Detail Records

There will be one detailed record per Loss Factor Classification as assigned to any SDP in a
Data Aggregation file for each LDC.
Table 2.9.3 Data Aggregation Detail Records
Data Type /
Length
Record Type Char(1) A To indicate that this record is “Detail” record in the
Identifier Data Aggregation file.
Value shall be: “D”
Aggregation Date/Time yyyyMMddHHmm This is the latest insert time of the set of intervals
Version Date ss underlying each hourly aggregation value
Time
Loss Factor Number (2) NN The Loss Factor Classification is an LDC supplied
Classification attribute for physical SDPs supplied via the
synchronization process.
Valid values: 01 through 12
Aggregated Date/Time yyyyMMddHHmm The end date time for each of the 24 hours ending
Consumption ss 01:00:00 EST through 00:00:00 EST of the Daily
Hour Ending Read Period.
Date/Time Note: Hour Ending 24 of the Daily Read Period N
is denoted as 00:00:00 on date N+1
Total Aggregated Numeric (12,2) NNNNNNNNNN. The sum of interval consumption values for
Consumption NN physical SDPs with a Framing Structure of

Data Type /
Length
Hour Ending HH “Hourly” or “TOU/CPP (EST) or “TOU/CPP (CST)
for Loss Factor Classification NN for all intervals
ending hour HH including validation status VAL;
NV: EST, and NVE
Intervals with validation status VAL will include
Change Methods: NULL and VER.
Intervals with validation status EST will include
Change Methods: NULL; ESA: ESB; ESC; ESD;
ESE; ESF; and EDT
Valid Aggregated Numeric (12,2) NNNNNNNNNN. The sum of interval consumption values for
ending hour HH including validation status VAL
and NV.
Change Methods: NULL and VER.
Estimated Numeric (12,2) NNNNNNNNNN. The sum of interval consumption values for
Aggregated NN physical SDPs with a Framing Structure of
Consumption “Hourly” or “TOU/CPP (EST) or “TOU/CPP (CST)
Hour Ending HH for Loss Factor Classification NN for all intervals
ending hour HH including validation status EST.
ESE; ESF; and EDT
NVE Aggregated Numeric (12,2) NNNNNNNNNN. The sum of interval consumption values for
ending hour HH including validation status NVE
SDP Count for Number (8) NNNNNNNN Actual count of physical SDPs contributing to the
Hour Ending HH Total Aggregated Consumption Hour Ending HH.
Total Interval Number (10) NNNNNNNNNN Actual count of intervals within hour ending HH
Count for Hour with validation status VAL; NV: EST, or NVE
Ending HH Intervals with validation status VAL will include
Change Methods: NULL or VER.
ESE; ESF; or EDT
Valid Interval Number (10) NNNNNNNNNN Actual count of intervals within hour ending HH
Count for Hour with validation status VAL and NV
Ending HH Intervals with validation status VAL will include
Estimated Interval Number (10) NNNNNNNNNN Actual count of intervals within hour ending HH
Count for Hour with validation status EST.
Ending HH Intervals with validation status EST will include
ESE; ESF; or EDT
NVE Interval Number (10) NNNNNNNNNN Actual count of intervals within hour ending HH
Count for Hour with validation status NVE.
Ending HH
Expected Interval Number (10) NNNNNNNNNN Count of intervals expected to contribute within
Count for Hour hour ending HH.
Ending HH For example an hourly channel is expected to
contribute 1 interval; a 15 minute channel is
expected to contribute 4 intervals.

2.9.8.2 Data Aggregation Contributors File
2.9.8.2.1 File Name Record for the Data Aggregation Contributors File
Table 2.9.4 FILE NAME RECORD FOR THE DATA AGGREGATION CONTRIBUTORS FILE
Field Data
Name Type/Length
<FTSFN>
File Name Varchar (250) Refer to Y This field contains the name of the file
Section 1.8 on the originating system
</FTSFN>

2.9.8.2.2 Data Aggregation Contributors File Header Record

This assumes that all data for a given LDC for a given Daily Read Period date (“N”) is all
selected (copied to a temporary table for this processing) at the same time. If the selection of
data is performed on a per LDC per Loss Factor Classification one at a time then this may
require multiple headers or multiple files.
Table 2.9.5 Data Aggregation Contributors Report Header Record
Data Type /
Length
Record Type Char (1) A To indicate that this record is “Header” record in the Data
Identifier Aggregations Contributors Report file.
Value shall be: “H”
File Format Char (2) NN The version of the file to allow for migration from one
Version format to the next as formats change. Recommended that
no more than 2 or 3 are supported at any one time.
LDC Char (8) NNNNN The identifier assigned to the LDC during the MDM/R
Organization Registration/Enrollment process. The LDC creates SDPs
Identifier Example: and thus owns those Service Delivery Points.
ORG82357
Daily Read Date yyyyMMdd The date of the Daily Read Period that is being processed
Period Date through the Settlement Aggregation process.
This is the 24-hour period including all intervals of the
hour ending 01:00:00 of the Daily Read Period date N
th
and extending through all intervals of the 24 hour ending
00:00:00 on date N+1
Data Date Time yyyyMMddH The date time when the Data Aggregation process and
Aggregation End Hmmss Data Aggregation Contributors Report process ended. (In
Date Time EST)

2.9.8.2.3 Data Aggregation Contributors File Detail Records
There will be one detailed record per SDP, Loss Factor Classification, Meter combination that
contributed to the aggregations in an LDC’s Data Aggregations file for the specified Daily Read
Period date.
Table 2.9.6 Data Aggregation Contributors File Detail Records
Data Type /
Length
Record Type Char(1) A To indicate that this record is “Detail” record in the
Identifier Data Aggregation Contributors Report file.
Value shall be: “D”
Universal SDP ID Number (8) NNNNNNNN The Ontario-wide unique identifier assigned by the
Universal SDP ID Assignment Request/Response
process.
Loss Factor Number (2) NN The Loss Factor Classification is an LDC supplied
Classification attribute for physical SDPs supplied via the
synchronization process.
Valid values: 01 through 12
SDP ID Varchar (50) No format This identifier is maintained in the LDC systems
prescribed and uniquely identifies the SDP.
For Universal SDP IDs with an associated Loss Factor Classification and No associated meter the following fields
will be empty.
Meter ID Varchar (50) No format This is an identifier of the installed meter that was
prescribed supplied by the LDC and must be unique within an
LDC.
Channel_Ref Varchar (15) NNNNNNNNNNN This is an internal system identifier within EnergyIP
NNNN for the channel associated with an SDP.
Interval Length Number (4) NNNN Channel interval length in seconds
Version Date Date/Time yyyyMMddHHmm This is the latest insert time of the set of intervals
Time ss for this meter channel on this Daily Read Period
date
Interval Count Number (4) NNNN Actual count of intervals found for this meter
channel on this Daily Read Period date with
validation status VAL; NV; EST, or NVE.
ESE; ESF; or EDT
Valid Interval Number (4) NNNN Actual count of intervals found for this meter
Count channel on this Daily Read Period date with a
Validation Status of either ‘No Validation (NV)’ or
‘Validated (VAL)’
Estimated Interval Number (4) NNNN Actual count of intervals found for this meter
Count channel on this Daily Read Period date with a
Validation Status of ‘Estimated (EST)’
ESE; ESF; or EDT
NVE Interval Number (4) NNNN Actual count of intervals found for this meter
Count channel on this Daily Read Period date with
Validation Status of ‘Needs Verification/Editing
(NVE)’

2.10 Web Services Request/Reply
2.10.1 Description
The purpose of this interface is to provide MDM/R users (LDCs, AMI Operators, Billing
Agents, Retailers, and other Customer contracted agents) with interval consumption
data and daily Billing Quantity data for a specified timeframe requested for one
Universal SDP ID at a time. This interface differs from the other interfaces specified in
this document in that it is not file based. The web services interface is a synchronous
interface between the MDM/R and LDCs, AMI Operators, Billing Agents, Retailers or
other Customer contracted agents. This interface may be used for web presentment,
and is also described in Section 13.1 of the MDM/R Detailed Design Document, Web
Services Interface.
2.10.2 Integration
2.10.2.1 Direction
MDM/R Users to the MDM/R
MDM/R to the MDM/R Users
The Web Services Request is a single request in an .xml file format
The Web Services Response is a single response in an .xml file format
2.10.2.3 Range of Data for Web Services Request/Response

Access to consumption data via web services provides the following data types in
combination as specified by the <measurementProfile> in each Web Services Request.
§ Total daily kWh consumption
§ Daily kWh Consumption by TOU/CPP Bin
§ kWh Consumption by Interval
Each single Web Services Request/Response is limited to a configurable maximum
number of days, which is currently set in the MDM/R to 100 days (this is meant to
cover the longest quarterly seasonal billing cycle of 92 calendar days).
If the range of data required is greater than the maximum number of days available
through a single Web Services Request, the user’s web presentment portal application
must be capable of issuing multiple web services calls to gather the required range of
data.

1. The LDC, AMI Operator, Billing Agent, Retailer, or other Customer Contracted
Agent, is authorized to receive web services.
a. Organizations utilizing Web-Services must be registered and setup as
an active organization in the MDM/R.
b. Self-signed certificates must be created and exchanged with the
MDM/R prior to use of Web-Services.

c. LDC access to Web-Services and all SDPs created by the LDC is
granted when each SDP is created using the synchronization process.
d. Using the synchronization processes the LDC grants read-only Web-
Services access for each SDP to it AMI Operator by establishing an
SDP to AMI Operator Relationship for each SDP.
e. Using the synchronization processes the LDC grants read-only Web-
Services access for each SDP to it Billing Agent by establishing an
SDP to Billing Relationship for each SDP.
f. Using the synchronization processes the LDC may grant read-only
Web-Services access for each SDP to Retailers by establishing an
SDP to Energy Service Provider Relationship for each SDP.
g. Using the synchronization processes the LDC may grant read-only
Web-Services access for each SDP to Customer Contracted Agents
(CCA) by establishing an SDP to CCA Service Provider Relationship
for each SDP.
2. The response message will contain zero data records in the following events:
a. the Universal SDP ID is not recognized by the MDM/R;
b. no data records are available between the request start time and end
time;
c. the measurementProfile is invalid. This may be due to the following
causes:
• The measurementProfile value requested is not MP01, MP02,
MP03, or MP04, as currently defined;
• The measurementProfile requested does not map to the Framing
Structure of the SDP.
3. Interval consumption data can be delivered for any SDP regardless of framing
structure.
4. Daily consumption data can be delivered for any SDP regardless of framing
structure.
5. Daily consumption values will only be delivered for requests of complete 24
hour periods that start at midnight and end at midnight of any subsequent day.
6. For SDPs that are framed as TOU/CPP, daily TOU Billing Quantity data and
Interval Consumption data will be returned, if requested and available.
7. For SDPs that are framed as Periodic or Hourly, Daily TOU Billing Quantity
data is not available.
8. For Virtual SDPs, interval data delivered will be summed data, including the
most restrictive data quality indicator, from the physical SDPs associated to
that Virtual SDP (e.g.: where an hourly interval of one child SDP has a
validation Status of ‘VAL’ and the same hourly interval from a second child has
a validation Status of ‘EST’, the most restrictive quality indicator is ‘EST’).

§ The AMI Operator, Billing Agent, Retailer, or other Customer contracted
agents has an Organization ID
§ The LDC has authorized access to the SDP to the AMI Operator, Billing
Agent, Retailer, or other Customer Contracted Agent.
The following outcome will result from the file being processed through the interface:
§ The requested interval consumption data or Billing Quantity data for the
identified Universal SDP ID for the specified date range has been
generated and delivered to the requesting LDC or Authorized Interested
Party.
§ The response message contains zero data records if:
– The Universal SDP ID is not recognized by the MDM/R
– No data records are available between the request start time and end
time.
– The measurementProfile is invalid.
2.10.6 Assumptions
Standard XML ISO8601 Date format with full timezone qualification will be used:
YYYY-MM-DDTHH:MI:SS.sss[[+|-]TZH:TZM]
Date/Time fields must always be expressed in Eastern Standard Time (EST)

Frequency: The requesting source may request this data at any time
Timing: To be determined.
2.10.8 File Format

2.10.8.1 Interval and Billing Quantity Request Message
Table 2.10.1 REQUEST MESSAGE TAGS
Data Type/
Field <Tag> Format Required Description
Length
XML declaration Specific Usage: Y Defines the XML version and
<?xml version=”1.0” the character encoding used
encoding=”UTF-8”?> in the document
</soapenv:Envelope>
</soapenv:Body>
<RequestMessage>
<RequestMessage> Specific Usage: Y Location of the xml name space
xmlns=“http:/www.
Emeter.com/energyip/

Data Type/
Length
Meterreadinterface”
<Header>
<verb> Specific Usage: Y The only value displayed under
“get” this Tag is “get”
<noun> Specific Usage” Y The only value displayed under
“MeterRead” this Tag is “MeterRead”
<revision> Specific Usage: Y This Tag indicates the version

“1” of the message
The only value is “1”
<dateTime> Date/ Time Standard XML Y The date/time of the request in
ISO8601 Date format EST
with full timezone
used:
YYYY-MM-
]TZH:TZM]
<messageID> Varchar (30) AAAAAAAAA N The unique ID for the message.
This will be populated as
<correlationId> in the response
if supplied in the request.
</Header>
<Request>
<startTime> Date/ Time Standard XML Y Start date/time for data
ISO8601 Date format requested.
with full timezone NOTE : When requesting daily
qualification will be Consumption or TOU data, the
used: startTime must be 00:00:00 of
YYYY-MM- the date being requested. If a
DDTHH:MI:SS.sss[[+|- time other than 00:00:00 is
]TZH:TZM] specified, no data will be
For example: returned. For Interval data, this
time may be any time during the
UTC – 5 (EST) would
day
be:
For example, a startTime of
1994-11-
05T08:15:30.000- 2007-04-01T05:00:00.000-05:00
05:00
after 00:00 EST on April 1, 2007
UTC would be:
If the requested start time is part
1994-11-05T13:15:30Z way though the reported interval
of the meter, the data set
returned will start with the next
interval reported.
For example, for a meter
reporting 15 minute intervals, a
startTime of 2007-04-
01T05:05:00.000-05:00 would
request data that occurs after
00:05 EST on April 1, 2007.
The first interval reported would
be the 15 minute interval ending
at 00:15 EST on April 1, 2007
<endTime> Date/ Time Standard XML Y End date/time for data
ISO8601 Date format requested.
with full timezone This is the exclusive end date
qualification will be for a given request. It
used: represents the first date that will
YYYY-MM- NOT be included in quantities
DDTHH:MI:SS.sss[[+|- for the Universal SDP ID

Data Type/
Length
]TZH:TZM] associated with the request.
NOTE : When requesting daily
Consumption or TOU data, the
endTime must be 00:00:00 of
the date being requested. If a
time other than 00:00:00 is
specified, no data will be
returned. For Interval data, this
time may be any time during the
day.
2007-05-01T05:00:00.000-05:00
30, 2007)
If the requested end time is part
way though the reported interval
of the meter, the data set
returned will end with the last
interval reported.
For example, for a meter
reporting 15 minute intervals, an
endTime of 2007-05-
01T10:05:00.000-05:00 would
request data that occurs after
05:05 EST on May 1, 2007. The
last interval reported would be
the complete 15 minute interval
ending at 05:00 EST on May 1,
2007
<versionTime> Date/Time Standard XML N Allows the requestor to Request
ISO8601 Date format Billing Quantity data or Interval
with full timezone Consumption data over a
qualification will be specified period but only using
used: Meter and Usage data up to the
YYYY-MM- Version Time. This is a date
DDTHH:MI:SS.sss[[+|- time other than the current date
]TZH:TZM] time.
validate or rebuild previously
delivered Billing Quantity data or
Interval Consumption data
underlying previously delivered
Billing Quantity data, then this
date must be the same as the
Response Version Date Time of
the delivered Billing Quantities
Response.
NOTE: If no versionTime
specified, the most current
version of data will be delivered.
<objectIdType> Varchar (30) General : AAAAAAAA Y This field should be hard-coded
Specific Usage: to indicate that
SDP_X_UNIVERSAL_ID will
SDP_X_UNIVERSAL_

Data Type/
Length
ID always be used
<objectId> Varchar (30) AAAAAAAA Y Universal SDP ID (Physical or

Virtual)
<measurement Varchar (30) AAAAAAAAA N Determines the type of data that
Profile> is returned through the Web
Services Response.
The following values can be
specified :
MP01 – Daily cumulative
consumption
MP02 – Daily TOU consumption
MP03 –Interval consumption
MP04 – Daily TOU and Interval
consumption
NOTE : If not submitted default
response will be MP01
<organisationCode> Varchar (30) General: AAAAAAAAA Y Organization ID of the
Example: requestor. Used for
authorization.
ORG12345
</Request>
</RequestMessage>
</soapenv:Body>
</soapenv:Envelope>
2.10.8.1.1 Sample Request Message

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<RequestMessage xmlns="http://www.emeter.com/energyip/meterreadinterface">
<Header>
<verb>get</verb>
<noun>MeterRead</noun>
<revision>1</revision>
<dateTime>2007-04-10T09:30:15-05:00</dateTime>
<messageID>TXN12345</messageID>
</Header>
<Request>
<startTime>2007-04-01T00:00:00-05:00</startTime>
<endTime>2007-04-03T00:00:00-05:00</endTime>


<objectIdType>SDP_X_UNIVERSAL_ID</objectIdType>
<objectId>1234567890</objectId>


<organisationCode>ORG12345</organisationCode>
</Request>
</RequestMessage>
</soapenv:Body>
</soapenv:Envelope>

2.10.8.2 Interval and Billing Quantity Response Message
The Interval and Billing Quantity Response messages are organized into following
structure of repeating blocks. The fields within each portion of the reply are found in
Table 2.7.2 Reply Message Tags (below).
<Reply> Start of Reply Identifiers

</Reply> End of Reply Identifiers
<Payload> Start of Reply Payload
<MeterReading> Start of Meter Reading block
<IntervalBlock> Start of Interval Block
<Ireading> Start of Interval Reading block
<Quality> Start of Quality flags for Interval Reading
</Quality> End of Quality flags for Interval Reading
</Ireading> End of Interval Reading block
</IntervalBlock> End of Interval Block
</MeterReading> End of Meter Reading block
</Payload> End of Reply Payload
Table 2.10.2 REPLY MESSAGE TAGS
Field Data Type/ Format Description

Length
<?xml version=”1.0” encoding=”http://schemas.xmlsoap.org/soap/envelope/”?>
XML declaration Specific Usage: Defines the XML version and the
<?xml version=”1.0” character encoding used in the document
encoding=”http://schema
s.xmlsoap.org/soap/env
elope/”?>
</soapenv:Envelope>
</soapenv:Header>
</soapenv:Body>
<ReplyMessage>
<ReplyMessage> Specific Usage: Location of the xml name space
xmlns=“http:/www.
Emeter.com/energyip/
Meterreadinterface”
<Header>
<verb> Specific Usage: The value displayed under this Tag is ‘reply’
“reply”
<noun> Specific Usage: The value displayed under this Tag is
“MeterRead” ‘MeterRead’
<revision> Specific Usage: This Tag indicates the version of the

“1” message
The only value is “1”
<dateTime> Date/Time Standard XML ISO8601 The date/time of the reply in EST
Date format with full
timezone qualification
will be used:
YYYY-MM-
]TZH:TZM]
</Header>

Data Type/
Length
<Reply>
<correlationId> Varchar (30) AAAAAAAAA The unique ID for the message. This will be
populated as <messageID> from the
request.
<replyCode> Varchar (2) General: Indicates the quality of the response.
AA replyCode possible values are:
Specific Usage 0 – SUCCESS
0, 1, 2, 3, -1 1 – SDP NOT FOUND
2 – UNAUTHORIZED
3 – INVALID REQUEST
-1 – Unexpected Java Runtime Exception
<replyText> Varchar (50) AAAAAAAAAAAAAAA The text error message associated with the
Specific Usage: replyCode
One of -
“SUCCESS”
“Sdp not found”
“Request not authorized”
“Invalid Request – [ ]
</Reply>
<Payload>
<MeterReading>
<IntervalBlock>
<readingTypeId> Varchar (50) AAAAAAAAAAAAAAA Identifier for the specific billing quantity
value. This is determined but the
measurementProfile requested in the
request, and is defined in table 2.7.3
<Ireading>
<startTime> Date Time Standard XML ISO8601 The start time and date in EST for the data
Date format with full within this data set. This is not provided with
timezone qualification interval data records
will be used:
YYYY-MM-
DDTHH:MI:SS[[+|-
]TZH:TZM]
<endTime> Date/Time Standard XML ISO8601 End date/time in EST of the data set.
Date format with full
timezone qualification
will be used:
YYYY-MM-
DDTHH:MI:SS[[+|-
]TZH:TZM]
<intervalLength> Number (10) NNNNNNNNNN Length in seconds of the data set. This field
(Ex. 3600 for 1 hour will only be populated if the readingTypeID
interval) field is populated with “KWH Interval”
<value> Number (12,5) AAAAAAAAAAAA.AA Value reported for the period
<Quality>
<versionTime> Date/Time Standard XML ISO8601 This is the insert date time of the latest
Date format with full version of data used for billing quantity
timezone qualification calculations
will be used: This date time is prior to the Billing Quantity
YYYY-MM- Response data being written into the Billing
DDTHH:MI:SS[[+|- Quantity Response file that is transferred to
]TZH:TZM] the Data Delivery Service Organization.

Data Type/
Length
<validationStatus> Varchar(3) AAA Can take the following values:
NV – No Validation performed
VAL – Interval has been Validated
EST – Interval has been Estimated or Edited
NVE – Interval requires Validation or Editing
<validationFailureR Number(4) NNNN If validationStatus is not ‘VAL’ then this field
easons> will be a hex-based bit-mapped flag,
delivered as an integer value indicating
validation and estimation failure types.
These codes can be found in table 2.10.4
<changeMethod> Varchar(30) AAAAAAA Supplementary information coming from
VEE
If validationStatus is VAL, valid
changeMethod is :
VER: Interval has been manually reviewed
and verified
If validationStatus is EST, valid
changeMethod are:
ESA: Interval value estimated using linear
interpolation
ESB: Interval value estimated using historic
estimation without register read scaling
ESC: Interval value estimated using
historical estimation with register read
scaling
ESD: Interval value estimated using Class
Load Profile estimation without register read
scaling
ESE: Interval value estimated using Class
Load Profile estimation scaled using
Average Daily Usage from register reads
ESF: Interval value estimated using Class
Load Profile estimation with register read
scaling
EDT: Interval value has been manually
edited.
EDC: Interval value estimated external to the
MDM/R, ‘DC_DATA_ESTIMATION’ flag set
based on data quality flag transmitted from
the AMCC.
<reverseRotation> Char (4) General: AAAA Indicates if energy flow was reversed during
Specific Usage: true the time frame of data set. If this condition
exists, then the value returned will be “true”.
If this conditions does not exist, then no
value is returned
This is applicable only where
ReadingTypeID = “KWH Usage”
<noData> Char(4) General: AAAA Indicates if there is no data for this data set.
Specific Usage: true If this condition exists, then the value
returned will be “true”. If this conditions does
not exist, then no value is returned
This is applicable for all values returned in
ReadingTypeID
<powerOff> Char(4) General: AAAA Indicates if there was a Power Off Flag
Specific Usage: true during the time frame of this data set. If this
condition exists, then the value returned will
be “true”. If this conditions does not exist,
then no value is returned
This is applicable only where

Data Type/
Length
ReadingTypeID = “KWH Interval”
<partialData> Char(4) General: AAAA Indicates that the source data for this period
Specific Usage: true was incomplete. If this condition exists, then
the value returned will be “true”. If this
conditions does not exist, then no value is
returned
This is only applicable if readingTypeID =
“KWH Usage”
</Quality>
</Ireading>
</IntervalBlock>
</MeterReading>
</Payload>
</ReplyMessage>
</soapenv:Body>
</soapenv:Envelope>
2.10.8.2.1 Sample Response Message

Sample MP01, MP02, MP03, and MP04 will be supplied on the SMSIP website.
Table 2.10.3 outlines the different Measurement Profiles and the information that will
be returned in the Reply message (in the readingTypeId and value elements)
Table 2.10.3 Measurement Profiles
measurementProfile readingTypeIds returned readingTypeId Description

MP01 KWH Usage Total daily KWH consumption
KWH Estimated Usage Total daily estimated KWH consumption
COUNT KWH Est Intervals Total number of estimated intervals in the day
TOU CPP 01 Total daily TOU CPP 1 consumption
MP03 KWH Interval 60 Minutes Interval data for the period

measurementProfile readingTypeIds returned readingTypeId Description
KWH Interval Interval data for the period
Table 2.10.4 validationFailureReason Codes
Integer Hex Description Failure

Value Value Flag
1 0x0001 Interval failed Spike Check validation. SPK
2 0x0002 Interval was part of a failed Message Sum Check validation. SUM
4 0x0004 Interval failed Missing Intervals Check validation. MIS
8 0x0008 Interval failed Pulse Overflow Check validation. OVF
16 0x0010 Interval failed Time Check validation. TIM
32 0x0020 Interval failed Test Mode Check validation. TST
64 0x0040 Interval failed Maximum Demand Check validation. DEM
128 0x0080 Interval failed Meter Diagnostic Check validation. RST
256 0x0100 Interval failed Reverse Energy Check validation. REV
Interval could not be estimated due to NO LIKE DAYS (no valid “same day of NLK
512 0x0200
week” or “like” reference days).
Interval could not be estimated because gap exceeded ’Maximum Estimation GAP
1024 0x0400
Days” that can be estimated.
Interval could not be estimated because no endpoints were available for a PTS
2048 0x0800
linear interpolation.
Interval could not be estimated because of an internal processing (typically ERR
4096 0x1000
configuration) error.
8192 0x2000 Interval was part of a failed Consecutive Zeros Check validation ZER
Interval was estimated but failed to scale with available register readings, SCL
16384 0x4000
resulting in a Validation Status of NVE and Change Method ESB
32768 0x8000 Interval failed cross-channel Watt-VAR Check validation WVF
65536 0x10000 Interval failed cross-channel Excessive Watt-VAR Check validation WVE
131072 0x20000 Interval is currently pending Watt-VAR validation WVP
262144 0x40000 Interval skipped Watt-VAR validation WVS
524288 0x80000 Class Load Profile data not found CLP
1048576 0x100000 Interval data estimated by external data collection system EDC
Interval failed due to data collection or reporting error in external AMI system. AMI
2097152 0x200000
(Note that this flag is only used for Elster MAS 6.x and MAS 5.7.)
If there are multiple validationFailureReason codes, the integer value returned will be a sum
of the associated integer values. For example, in the event of a Pulse Overflow and Reverse
Rotation, the integer value returned would be 264.

2.11 Meter Read Interface (Sensus)
2.11.1 Description
The purpose of this interface is to deliver Meter Read data for smart meters to the
MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It
uses specific adaptors that are built to support AMCC systems that are in use by LDCs
and/or AMI Operators. This section describes the technical specifications for the
Sensus AMCC Meter Read interface.
This interface processes both automated AMCC interface files (i.e. those that are
generated by the AMCC system) and files that may be produced by the LDC or its AMI
Operator in the AMCC format but that contain either manual Meter Reads and/or
updated Meter Reads. The files are processed in the order that they are received from
the AMCC. All files are processed by this interface in the same manner, no matter the
source of the data (i.e. automated or manual).
of the MDM/R Detailed Design Document, MDM/R File Transfer Services.
Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and
Processing, discusses Meter Data Collection.
2.11.2 Integration
2.11.2.1 Direction
AMCC to the MDM/R
This is a batch process involving the transfer and processing of CSV files.
Meter read data may be received from the AMCC for all meters that are associated to
SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the
Periodic Audit Synchronization or Incremental Synchronization integrations and c)
have all of the attributes associated with the Data Collection Service populated.
All meter read data (including all initial and subsequent transmissions of meter read
data) received from the AMCC shall contain:
§ A register read for the end of the Meter Transfer Block
§ A series of interval data
§ Data quality indicators
The above data will be sent in a single data transmission. The register read records
will precede the interval data records for each SDP in the file transmission. The
Sensus implementation will include both a register read at the beginning of the first
interval of the Meter Transfer Block and a register read at the end of the last interval of
the Meter Transfer Block. All register read records and interval data records will be
ordered within each file transmission in ascending date/time order.
The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’
value is limited to a maximum of 48 sets of data triplets per record (see Table 2.11.2 –
“Count”). This maximum establishes the longest Meter Transfer Block permissible

when using a CMEP interface and, if this maximum is used, requires a register read
record corresponding to the end of each interval data record of a maximum length of
48 interval data triplets.
It is recommended that interval data be transmitted in Meter Transfer Blocks no longer
than 24 hours long, and if possible, a Meter Transfer Block should end at midnight or
with one hour (plus or minus) of midnight to assure that the Billing Validation Sum
Check can be effectively performed.
2.11.2.3 Transmission of First and Last Register Readings

Register readings including the first register reading of a meter collected when the
meter is installed, and the last register reading of a meter collected when the meter is
exchanged, may be transmitted to the MDM/R either as part of a Meter Transfer Block
(i.e. a set of interval data with the register reading at the end of the set of interval data),
or as a Meter Read record consisting only of the register reading (i.e. a single value for
which the Units are ‘KWHREG’). Register readings are stored in the register read
table of the Meter Data Database and are available via the MDM/R GUI. kWh, kVAh,
and kVARh register readings are processed and stored only for physical register data
channels created by the “Channel Configuration Set” for a physical meter established
using the synchronization processes. For meters for which a non-unity ‘Scaling
Constant’ is provided in the synchronization process the register read data is multiplied
by the ‘Scaling Constant’ before being loaded into the Meter Data Database.
Register readings received as part of a Meter Transfer Block are available for Message
Sum Check validation, and Register Read Scaling of Historic and Class Load Profile
estimation. Register reading received as part of a Meter Transfer Block are also
available to the Billing Validation Sum Check if the Date/Time of the register reading is
within the ‘MaxRegisterRange’ hours of midnight.
Register readings received as a single ‘KWHREG’ value are only available to the
Billing Validation Sum Check if the Date/Time of the register reading is within the
‘MaxRegisterRange’ hours of midnight.

1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s
Organization ID for the Daily Read Period date being reported
2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all
associated to the same SDP, the MDM/R records the meter read data from
the inbound file against the Universal SDP ID and AMCD ID in the Meter
Data Database. If there is no Meter Read data in the record, no value is
recorded.
3. For residential meters not used for net metering, meters will be programmed
such that the sum of the absolute values of the energy delivered and the
energy received will be transmitted as the total delivered energy. This will
apply to both interval consumption data and register read data.
4. The processed Meter Read File is placed in the Processed Directory in the
MDM/R, which is an internal EnergyIP directory.
a. The MDM/R CMEP Adapter detects exceptions in regards to invalid
file format and data type exceptions.

b. The MDM/R detects exceptions when the LDC’s Organization ID
values are not known by the system.
c. The MDM/R detects exceptions when the AMCD ID values are not
known by the system.
d. The MDM/R detects exceptions when interval data of an unexpected
interval is received from the AMCC.
6. Meter Reads exception reports are created:
§ The Interim and Final AMCC Data Collection Summary Exception
Reports provide a summary of all exceptions at the meter level,
encountered during the processing of the Meter Read files delivered
from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7
and 2.2.11 of the MDM/R Reports Technical Specifications).
§ The Interim and Final AMCC Data Collection Detailed Exception
Reports list all exceptions at the meter level, encountered during the
processing of the Meter Read files delivered from the AMCCs (Refer
to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R
storage location for the File Transfer Services transfer to the LDC or its AMI
Operator.
Rules Affecting Meter Read Processing for SDPs Requiring Demand Determination
7. The SDP must be assigned a Channel Configuration Set through the
synchronization processes that establishes the data channels by unit of
measurement and type necessary to support the receipt of and processing of
interval consumption data and register read data for multiple units of
measurement as transmitted by the meter.
8. For meters not used for net metering and used for the determination of
demand, meters will be programmed such that the sum of the absolute
values of the energy delivered and the energy received will be transmitted as
the total delivered energy. This will apply to both interval consumption data
and register read data.
demand, if programmed to record kilovolt-ampere-reactive hours, meters will
be programmed to record active kVARh quantities delivered, Power Factor
lagging (inductive), transmitted as positive quantities. This will apply to both
interval consumption data and register read data.
demand, if programmed to record kilovolt-ampere hours, meters will be
programmed such that the sum of the values of the kilovolt-ampere hours
delivered and the kilovolt-ampere hours received will be transmitted as the
total delivered kilovolt-ampere hours. This will apply to both interval
consumption data and register read data.

§ The LDC has requested and received Universal SDP IDs for each SDP in
the Meter Read File.
§ The Universal SDP ID has a relationship with the corresponding AMCD ID
in the MMD for the Daily Read Period being reported.
§ All of the attributes associated with the Data Collection Service must be
populated.
§ Meter Read data for Universal SDP IDs and AMCD IDs are updated in the
Meter Data Database.
§ Meter Read data is not loaded into the Meter Data Database for records
with exceptions as described in Section 6 of the MDM/R Detailed Design
Document, VEE Processing.
§ The LDC and/or its designated agent (s) receive interim and final summary
and detailed exception reports as outlined in Section 2.11.3 via File
Transfer Services.
2.11.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.

Frequency: Meter Read data is supplied, at a minimum, once per day. The preference
is for Meter Read data to be supplied as frequently as possible with as little latency
between the read being collected from the field and being sent onto the MDM/R. The
LDCs will establish their frequency based on their operational requirements.
Timing: Meter Read data received by the MDM/R by 05:00 EST for the prior Daily
Read Period shall be available by 07:10 EST on the day following the Daily Read
Period.
2.11.8 File Format

2.11.8.1 File Name Record for the Sensus CMEP File

Table 2.11.1 FILE NAME RECORD FOR THE SENSUS CMEP FILE

<FTSFN>
</FTSFN>

2.11.8.2 Sensus CMEP Record

The data mapping definitions and the file format layout following the File Name Record
are based on the California Metering Exchange Protocol (CMEP) Version 1.20, with
some modifications made specific to the Ontario Smart Metering System
implementation. Other than the specific modifications described in this specification
data file transmissions should conform to the specifications of CMEP Version 1.20.
The CMEP files will contain only the following record types:
§ “MEPMD01” - Metering Data Type 1 - Interval Data
The CMEP files will not contain the following record types:
§ “MEPAD01” - Administrative Data Type 1 – DASR
§ “MEPAD02” - Administrative Data Type 2 - Credit Data
§ “MEPMD02” - Metering Data Type 2 - TOU Data
§ “MEPBD01” - Billing Data Type 1 - Billed Dollars
§ “MEPBD02” - Billing Data Type 2 - Interval Pricing Plan
§ “MEPBD03” - Billing Data Type 3 - TOU Pricing Plan
§ “MEPLF01” - Distribution Loss Factors – Electric
§ “MEPEC01” - Equipment Configuration Type 1
§ “MEPRR01” - Record Reject Type 1
Table 2.11.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SENSUS
CMEP Data
Field Name Type/Length
Record Type Varchar (7) General : Y This field will always contain
AAAAAAA “MEPMD01”
Specific Usage:
“MEPMD01”

CMEP Data
Record Date General: Y This field will contain the CMEP version
Version yyyyMMdd date. The current version being
supported is “19970819”
Specific Usage:
19970819
Sender ID Varchar (10) General: N This field will always contain “Sensus”.
AAAAAAAAAA NOTE: The function of this field has
Specific Usage: been replaced by use of the MDM/R
‘Sensus’ FTS file name. For Sensus: FILE ID =
7000
Sender Char (8) General: Y This field will contain The unique
Customer ID AAAAAAAA Organization identifier assigned to the
LDC during the registration/enrollment
Example: process.
‘ORG83729’
Receiver ID Char (8) General: Y This field will contain the unique
AAAAAAAA Organization identifier assigned to the
MDM/R
Specific Usage This field will always contain
The MDM/R will ORG29738
only recognize
‘ORG29738’
Receiver Fixed Number General: Y This field is populated with the assigned
Customer ID (8) NNNNNNNN Universal SDP ID that corresponds with
the Meter that this reads data is
Example: associated with.
‘00037482’
Time Stamp Date/Time yyyyMMddHHmm Y This field Is populated with the date and
time that this record was created. This
time must be reported in EST
Meter ID Varchar (50) No format Y This is the ID that is used as a key for
prescribed the integration between the MDM/R and
Sensus AMCC.
The same value is to be populated in
the AMCD ID field of the Meter
Synchronization Data Record
For Periodic Audit Synchronization
Version 01 and Incremental
Synchronization Version 00:
• see table 2.2.6 field “AMCD ID” of
the Asset Data File Detail Record
Purpose Varchar (8) General: Y Indicates the reason for this data
AAAAAAAA transmission. Defined values are:
‘OK’ – Normal transmission
Specific Usage:
‘Resend’ – Retransmission of
The MDM/R will previously sent data
only recognize
“OK”, “RESEND” ‘Summary” – Summary of SP totaled
data.
‘History’ – Archival account data
‘Profile’ – Account usage profile data
‘Template’ – Account usage template
data
‘Reject’ – Data is rejected and being
returned to sender

CMEP Data
Commodity Char(1) General: Y Describes what commodity type is
A being delivered
“E” – Electricity
Specific Usage:
“G” – Gas
The MDM/R will
“W” – Water
only recognize “E”
“S” - Steam
Units Char (6) General: Y The MDM/R will process interval data
AAAAAA and register read data where the unit of
measurement is consistent with the
Specific Usage:
interval data and register data channels
‘KWH’ and supported by the Channel Configuration
‘KWHREG’, Set assigned to the SDP.
This field will contain one of the
‘KVAH’ and following per record.
‘KVAHREG’, For energy valid values are:
“KWH” for records containing interval
‘KVARH’ and consumption data in kWh delivered.
‘KVARHREG’ ‘KWHREG” for records containing a
delivered kWh register read taken at the
end of the Meter Transfer Block.
For VA-hours valid values are:
“KVAH” for records containing interval
data in total kVAh delivered.
“KVAHREG” for records containing a
delivered kVAh register read taken at
the end of the Meter Transfer Block.
For VAR-hours valid values are:
“KVARH” for records containing interval
data in kVARh inductive (Power Factor
lagging) delivered.
“KVARHREG” for records containing a
register read for kVARh inductive
(Power Factor lagging) delivered taken
at the end of the Meter Transfer Block.
Calculation Number (1,0) General: Y The “Calculation Constant” will always
Constant N contain “1”. Units will always be
Specific Usage: delivered in kWh, kVAh, or kVARh
hence no calculation to engineering
‘1’ units will be required.
Interval Time Interval MMDDhhmm Y Describes the time interval between
readings. Metering data is transmitted
Example: as Date/Time and value pairs. In many
‘00000100’ cases the time intervals for the data
indicates a time values is so regular that Date/Time
interval of one information past the first reading is
hour essentially redundant. This field
minimizes the redundancy problem. If a
‘00000015’ Date/Time field, after the first reading in
indicates a time a line, is empty, it is calculated by
interval of 15 adding this interval to the Date/Time of
minutes the previous interval. The field is
ignored if no empty Date/Time fields are
encountered in the record.

CMEP Data
Count Number (2,0) General: Y Indicates the number of Date/Time,
NN flag, and value sets to follow.
Example: NOTE: The number of sets is limited to

If Units = a maximum of 48 sets per record in
‘KWHREG”, conformance with the maximum
Count = ‘2’ number of sets allowed as specified for
the MEPMD01 Record Type in the
If Units = ‘KWH’, California Metering Exchange Protocol.
Count = ‘12’ for a For Sensus specific implementations:
transmission of If the Units field is populated with
12 intervals. ‘KWHREG’, ‘KVAHREG’ or
‘KVARHREG’ then count will be 2,
indicating that register reads for the
beginning and end of the Meter
Transfer Block are being transmitted
If the Units field is populated with
‘KWH’, ‘KVAH’, or KVARH’ then the
count will be the number of intervals
that are included in the Meter Transfer
Block
Data Triplet – the following three fields repeat for each interval/register read provided in the file
Date/Time Date/Time yyyyMMddHHmm Y Per CMEP, the Date/Time field must be
supplied for the first record provided.
When the “Interval” field is supplied,
Date/Time fields after the first may be
left empty to be calculated when the
record is read.
For Ontario, a Date/Time must be
provided for every interval/ value
delivered. It must be the time at the
end of the interval. The Date/Time
must be in EST.
‘KWHREG’ and the value in the
Numeric Floating Point field is the
beginning read of the Meter Transfer
Block, then the Date/Time must be the
time at the beginning of the first interval
of the Meter Transfer Block. If it is the
ending read of the Meter Transfer
time at the end of the last interval of the
Meter Transfer Block.

CMEP Data
Protocol Text Char (7) General: Y This field is populated with the data
AAAAAAA quality information.
(7 characters The first character is either ‘R’, a raw
including a space reading as supplied from the AMCC
at the second and without validation, estimation or editing,
fifth character or ‘N’ indicating no value has been
position) supplied for this interval. The second
and third digits are an 8-bit hexadecimal
Examples: number from ‘00’ to ‘FF’. The 8-bits
For a simple code indicate the following quality conditions:
-
The Sensus FlexNet AMI can transmit
A raw interval the following simple Data Quality code
read for which a values:
power outage
R 00 00 (no Bit is set)
occurred during
the interval is ‘R R 00 01 (Bit 0)
00 02’. R 00 02 (Bit 1)
R 00 04 (Bit 2)
For a compound R 00 08 (Bit 3)
code - R 00 10 (Bit 4)
A raw interval N 00 20 (Bit 5) – Missing data will
read for which a always be accompanied by a
power outage Numeric floating point value of
occurred during “0.00”
daylight savings R 00 40 (Bit 6)
time would be ‘R R 00 80 (Bit 7)
00 42’
Table 2.11.3 provides the Sensus
descriptions of these simple Data
Quality Flags and the action taken by
the MDM/R for each flag for interval
consumption data.
The Data Quality Flags may also be
applied to register read data. Only
Power outage R 00 02 (Bit 1) will be
stored in the Meter Data Database
setting the EnergyIP POWER_OFF flag
and viewed in the GUI as Power Off.
Other valid flags will be ignored.
NOTE: The Sensus FlexNet AMI can
also transmit these simple codes in
combination as compound codes. See
Section 2.11.8.3 regarding treatment of
additive quality bit codes.
NOTE: The MDM/R supports simple
and compound hexadecimal code
values involving Bit 0 through Bit 7, and
does not support the Sensus 32 bit
Extended CMEP File Format.
Numeric Number (12,5) General: Y This field is populated with either the
floating point NNNNNNNNNNN register read (if the Units field is
NOTE: populated with KWHREG) or the
Transmitted N.NNNNN
interval consumption (if the Units field is
values Specific: populated with KWH)
exceeding (5)
123456789012.34
decimal places
will be rounded
and stored in the
Meter Data
Database to (5)
decimal places

Table 2.11.3 describes the action taken by the EnergyIP application in processing the
simple protocol text quality flags for interval consumption data provided for each data
triplet within the Sensus CMEP file, and the setting of EnergyIP flags as applicable.
The same protocol text quality flags are recognized and processed for KWH, KVARH,
and KVAH interval data.
Table 2.11.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus
Bit Sensus Data Quality Flag Description Required

Bit EnergyIP Flag
Value EnergyIP Action CMEP Flag
Sensus – Indicates an error free interval
00 00 R 00 00 null
No EnergyIP flag is set, data will be treated as normal data
Sensus – Communication failure (meter could not be read)
Bit 0 00 01 R 00 01 null
Sensus – Power outage
EnergyIP PwrFail flag is set in GUI, Missing Interval
Bit 1 00 02 R 00 02 POWER_OFF
Validation check NO_DATA flag is cleared, no estimation is
done
Sensus – Power restoral
EnergyIP PwrOn flag is set in GUI, Missing Interval Check
Bit 2 00 04 R 00 04 POWER_ON
NO_DATA flag is cleared, validation/estimation resumes on
subsequent interval data
Sensus – Voltage sag
Bit 3 00 08 R 00 08 null
Sensus – Voltage swell
Bit 4 00 10 R 00 10 null
Sensus – Missing data
Bit 5 00 20 EnergyIP NoData flag is set in GUI, data is subject to the N 00 20 NO_DATA
Missing Intervals Validation check
Sensus – Daylight savings in effect
Bit 6 00 40 R 00 40 null
Sensus – Meter was out of service
Bit 7 00 80 R 00 80 null
2.11.8.3 Addition of Hexadecimal Quality Flags

EnergyIP Release 6.3 and 7.0
The EnergyIP CMEP adaptor for Sensus will support the combination or addition of
multiple hexadecimal data quality flags up to the 256 hexadecimal code values
involving Bit 0 through Bit 7.

2.12 Meter Read Interface (Sensus2)
2.12.1 Description
Sensus2 AMCC Meter Read interface providing support for the Sensus FlexNet
extended CMEP file format.
2.12.2 Integration
2.12.2.1 Direction
AMCC to the MDM/R
All meter read data (including all initial and subsequent transmissions of meter read
data) received from the AMCC shall contain:
will precede the interval data records for each SDP in the file transmission. The
Sensus implementation will include both a register read at the beginning of the first
interval of the Meter Transfer Block and a register read at the end of the last interval of
the Meter Transfer Block. All register read records and interval data records will be
ordered within each file transmission in ascending date/time order.



recorded.

d. The MDM/R detects exceptions when interval data of an
unexpected interval is received from the AMCC.
from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7
Operator.

populated.
Transfer Services.
2.12.6 Assumptions

Period.
2.12.8 File Format

2.12.8.1 File Name Record for the Sensus2 CMEP File

Table 2.12.1 FILE NAME RECORD FOR THE SENSUS2 CMEP FILE

<FTSFN>
</FTSFN>

2.12.8.2 Sensus2 CMEP Record

are based on the California Metering Exchange Protocol (CMEP) Version 1.20 as
extended by Sensus, with some modifications made specific to the Ontario Smart
Metering System implementation. Other than the specific modifications described in
this specification data file transmissions should conform to the specifications of CMEP
Version 1.20.
§ “MEPMD01” - Metering Data Type 1 - Interval Data
§ “MEPAD01” - Administrative Data Type 1 – DASR
§ “MEPAD02” - Administrative Data Type 2 - Credit Data
§ “MEPMD02” - Metering Data Type 2 - TOU Data
§ “MEPBD01” - Billing Data Type 1 - Billed Dollars
§ “MEPBD02” - Billing Data Type 2 - Interval Pricing Plan
§ “MEPBD03” - Billing Data Type 3 - TOU Pricing Plan
§ “MEPLF01” - Distribution Loss Factors – Electric
§ “MEPEC01” - Equipment Configuration Type 1
§ “MEPRR01” - Record Reject Type 1

Table 2.12.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SENSUS2
CMEP Data
Record Type Varchar (7) General : Y The Sensus Extended CMEP File
AAAAAAA Format provides mapping to metering
data types MEPMD01 – Interval Data,
Specific Usage: and MEPMD02 – TOU Data.
“MEPMD01” The MDM/R is configured to support
The MDM/R will only interval data and reference register
load only reading data.
“MEPMD01” data. This field will always contain
“MEPMD01”
Record Date General: N This field will contain the CMEP version
Example: The Sensus2 adaptor will not validate
19970819 this field.
or The Record Version field may be “null”.
“null”
Sender ID Varchar (10) General: N This field will always contain “Sensus”.
AAAAAAAAAA
NOTE: The function of this field has
FTS file name. For Sensus2: FILE ID =
‘Sensus’
7001
Example: process.
‘ORG83729’
MDM/R
Specific Usage This field will always contain
only recognize
‘ORG29738’
‘00037482’
Time Stamp Date/Time yyyyMMddHHmm Y This field Is populated with the date and
time that this record was created. This
Sensus AMCC.
Synchronization Data Record.
§ see table 2.2.6 field “AMCD ID” of

CMEP Data
AAAAAAAA transmission. Defined values are:
Specific Usage:
only recognize
“OK”, “RESEND” ‘Summary” – Summary of SP totaled
data.
data
returned to sender
A being delivered
Specific Usage:
“G” – Gas
The MDM/R will
“W” – Water
only recognize “E”
“S” - Steam
Specific Usage:
interval data and register data channels
‘KVARH’ and consumption data in kWh delivered.
data in total kVAh delivered.
lagging) delivered.
delivered in kWh, kVAh, or kVARh
Specific Usage:
hence no calculation to engineering

CMEP Data

a maximum of 48 sets per record in
If Units =
conformance with the maximum
‘KWHREG”,
number of sets allowed as specified for
Count = ‘2’
Count = ‘12’ for a For Sensus specific implementations:
transmission of If the Units field is populated with
12 intervals. ‘KWHREG’, ‘KVAHREG’ or
indicating that register reads for the
beginning and end of the Meter
Transfer Block are being transmitted
Block
Date/Time Date/Time yyyyMMddHHmm Y Per CMEP, the Date/Time field must be
supplied for the first record provided.
record is read.
provided for every interval/ value
delivered. It must be the time at the
end of the interval. The Date/Time
must be in EST.
‘KWHREG’ and the value in the
Numeric Floating Point field is the
beginning read of the Meter Transfer
time at the beginning of the first interval
of the Meter Transfer Block. If it is the
ending read of the Meter Transfer
time at the end of the last interval of the
Meter Transfer Block.

CMEP Data
Protocol Text regex = General: Y This field is populated with the data
([R|N|A|E|][0-9] ANNN quality information.
{1,5}){0,1} The first character is either ‘R’, a raw
Examples: reading as supplied from the AMCC
For a simple code without validation, estimation or editing,
- or ‘N’ indicating no value has been
A raw interval supplied for this interval. The second
read for which a and third digits are an 8-bit hexadecimal
power outage number from ‘00’ to ‘FF’. The 8-bits
occurred during indicate the following quality conditions:
the interval is
The Sensus FlexNet AMI can transmit
‘R2’.
the following simple Data Quality code
values:
For a compound R0 (no Bit is set)
code - R1 (Bit 0)
A raw interval R2 (Bit 1)
read for which a R4 (Bit 2)
power outage
R8 (Bit 3)
occurred during
daylight savings R16 (Bit 4)
time would be N32 (Bit 5) – Missing data will
‘R66’ always be accompanied by a
Numeric floating point value of
“0.00”
R64 (Bit 6)
R128 (Bit 7)
R256 (Bit 8)
R512 (Bit 9)
R1024 (Bit 10)
R2048 (Bit 11)
R4096 (Bit 12)
R8192 (Bit 13)
R16384 (Bit 14)
R32768 (Bit 15)
Table 2.12.3 provides the Sensus
consumption data.
Power outage R2 (Bit 1) will be stored
in the Meter Data Database setting the
EnergyIP POWER_OFF flag and
viewed in the GUI as Power Off. Other
valid flags will be ignored.
NOTE: The Sensus FlexNet AMI can

CMEP Data
floating point NNNNNNNNNNN register read (if the Units field is
Transmitted N.NNNNN
exceeding (5)
123456789012.34
decimal places
will be rounded
and stored in the
Meter Data
Database to (5)
decimal places
triplet within the Sensus2 CMEP file, and the setting of EnergyIP flags as applicable.
Table 2.12.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus2

Bit EnergyIP Flag
Sensus – Indicates an error free interval
00 00 No EnergyIP flag is set, data will be treated as normal R0 null
data
Sensus – Communication failure (meter could not be
read)
Bit 0 00 01 R1 null
No EnergyIP flag is set, data will be treated as normal
data
Sensus – Power outage
Bit 1 00 02 R2 POWER_OFF
Validation check NO_DATA flag is cleared, no
estimation is done
Sensus – Power restoral
EnergyIP PwrOn flag is set in GUI, Missing Interval
Bit 2 00 04 R4 POWER_ON
Check NO_DATA flag is cleared, validation/estimation
resumes on subsequent interval data
Sensus – Voltage sag
Bit 3 00 08 No EnergyIP flag is set, data will be treated as normal R8 null
data
Sensus – Voltage swell Not used
Bit 4 00 10 No EnergyIP flag is set, data will be treated as normal for interval null
data data
Sensus – Missing data
Bit 5 00 20 EnergyIP NoData flag is set in GUI, data is subject to N32 NO_DATA
the Missing Intervals Validation check
Sensus – Daylight savings in effect
Bit 6 00 40 No EnergyIP flag is set, data will be treated as normal R64 null
data
Sensus – Meter was out of service
Bit 7 00 80 No EnergyIP flag is set, data will be treated as normal Not used null
data
Sensus – Time Adjustment (direction unspecified)
Bit 8 01 00 EnergyIP flag TimeChg is set in GUI, data is subject to R256 TIME_CHANGE
the Time Change Validation check

Bit EnergyIP Flag
Sensus – Overflow
Bit 9 02 00 EnergyIP Overflow flag is set in GUI, data is subject to R512 PULSE_OVERFLOW
Pulse Overflow Validation check
Sensus – Long interval
Bit 10 04 00 EnergyIP LongInt flag is set in GUI, data will be treated R1024 LONG_INTERVAL
as normal data
Sensus – Short interval
Bit 11 08 00 EnergyIP ShortInt flag is set in GUI, data will be treated R2048 SHORT_INTERVAL
as normal data
Sensus – Test mode
Bit 12 10 00 EnergyIP TestMode flag is set in GUI, data is subject to R4096 TEST_MODE
Test Mode Validation check
Sensus – Register rollover detected Not used
data data
Sensus – Register reset detected Not used
data data
Sensus – Clock out of sync
Bit 15 80 00 EnergyIP flag TimeChg is set in GUI, data is subject to R32768 TIME_CHANGE
the Time Change Validation check

The Sensus2 EnergyIP CMEP adaptor will support the combination or addition of

2.13 Meter Read Interface (Elster)
2.13.1 Description
and/or AMI Operators. This section describes the technical specifications for the Elster
AMCC Meter Read interface.
generated by the AMCC system) and files that may be produced by the LDC in the
AMCC format but that contain either manual Meter Reads and/or updated Meter Reads.
The files are processed in the order that they are received from the AMCC. All files are
processed by this interface in the same manner, no matter the source of the data (i.e.
automated or manual).
2.13.2 Integration
2.13.2.1 Direction
AMCC to the MDM/R
This is a batch process involving the transfer and processing of XML files.
All meter read data received from the AMCC shall contain:
§ A register read within or at the end of the Meter Transfer Block
All Scheduled Read and On Request transmissions will include interval data
accompanied by the associated register read in a single data transmission. It is
preferred to have the register read occur as close to the end of the Meter Transfer
Block as possible. For REX Meter deployments that support the collection of the
meter’s end of interval register snapshot value with the collected interval data, the
Elster MAS /EA_MS system should be configured to export the End Of Interval
Snapshot (EOI Snapshot) register readings.


(i.e. a set of interval data with the register reading at or near the end of the set of
interval data), or as a Meter Read record consisting only of the register reading (i.e. a
single value for ‘ConsumptionData’ or EOI Snapshot register value). Register readings
are stored in the register read table of the Meter Data Database and are available via
the MDM/R GUI. kWh, kVAh, and kVARh register readings are processed and stored
only for physical register data channels created by the “Channel Configuration Set” for
a physical meter established using the synchronization processes. For meters for
which a non-unity ‘Scaling Constant’ is provided in the synchronization process the
register read data is multiplied by the ‘Scaling Constant’ before being loaded into the
Register readings received as a single ‘ConsumptionData’ value are only available to
the Billing Validation Sum Check if the Date/Time of the register reading is within the

Organization ID for the Daily Read Period date being reported.
recorded.
3. For residential meters not used for net metering, meters may be programmed
to provide the energy delivered, or programmed to provide the sum of the
absolute values of the energy delivered and the energy received. This will
4. The values reported in the AMRDEF file for both register reads and interval
data are the result of converting the units stored in the meter to engineering
units by applying the meter multiplier. The values are reported as the actual
number of kWh that have passed through the meter.
a. Use of a Scaling Constant will support certain types of meters that
transmit register read data bare of the meter multiplier while
transmitting interval consumption data multiplied by the meter
multiplier. For meters for which a Scaling Constant is provided in the
synchronization process, the register read data is multiplied by the
Scaling Constant before being loaded into the Meter Data Database.
b. For meters for which a Scaling Constant is not provided, the
synchronization Staging Table Loader will default a value of “1.00’ for
this meter parameter, and register read data will be stored “as-
received” in the Meter Data Database.

a. The MDM/R Elster MAS Adapter detects exceptions in regards to
invalid file format and data type exceptions.
d. The MDM/R detects exceptions when interval data of an unexpected
interval is received from the AMCC.
Reports provide a summary of all exceptions at the meter level
from the AMCCs (Refer to Report DC06 and DC16 in Section 2.2.7
Reports Technical Specifications),
storage location for the File Transfer Services transfer to the LDC.
measurement and type necessary to support the receipt of interval
consumption data and register read data transmitted by the meter.
be programmed to measure active kVARh quantities delivered, Power Factor

populated.
§ The LDC and/or its designated agent(s) receive interim and final summary
Transfer Services.
2.13.6 Assumptions

Period.
2.13.8 File Format

2.13.8.1 File Name Record for the Elster File
The first element in this interface file is used to store the name of the file as specified in
Section 1.8. This element is used in the event that the original file name is modified
The first element of the interface file contains the following data:
Table 2.13.1 FILE NAME RECORD FOR THE ELSTER FILE

<FTSFN>

</FTSFN>

2.13.8.2 Elster EnergyAxis Management System (EA_MS) AMRDEF Export File

The data mapping definitions and the file format layout are as defined for the AMRDEF
Export Format in the EnergyAxis® Management System (formerly branded as the
Elster EnergyAxis® Metering Automation Server) AMRDEF Reference Release 7.0.
The AMR Data Exchange Format (AMRDEF) export files may contain all the element
and attributes as defined in the Elster EnergyAxis® Management System AMRDEF
Reference Release 7.0 document. The MDM/R will only load and process the
elements and attributes as outlined in the following tables 2.13.2 and 2.13.3 and 2.13.4.
The Element/Attribute naming convention in the following tables 2.13.2, 2.13.3 and
2.13.4 are as follows.
General form:
{element name}[{element separator}{element name}]{element separator}{attribute
name}
Examples:
AMRDEF.MeterReadings.CollectionTime
AMRDEF.MeterReadings.Meter.SerialNumber
The AMRDEF Reference Release 7.0 – AMRDEF Export Format is used to supply the
MDM/R with consumption read data (i.e. register read data) as follows in table 2.13.2.
TABLE 2.13.2 CONSUMPTION DATA ELEMENTS AND ATTRIBUTES (REGISTER READ DATA)
AMRDEF Reference
Data
(Release 6.0) Format Required Description
Type/Length
Element/Attribute Name
<MeterReadings>
<attributes>
AMRDEF. Date As per AMRDEF Export Y Date and time that the data was
MeterReadings. Format: collected. This is to be delivered in
CollectionTime yyyy-mmdd hh24:mi:ss EST

AMRDEF Reference
Data
Type/Length
<MeterReadings>
<Meter>
AMRDEF. Varchar (50) No format prescribed Y This is the LDC’s unique identifier for
MeterReadings. the AMCD (the AMCD ID in the
Meter. synchronization file). This is the ID
MeterName that is used as a key for the
integration between the MDM/R and
the Elster MAS AMCC. The same
value is to be populated in the AMCD
ID field of the Meter Synchronization
Data Record.
AMRDEF. Varchar (15) General: Y This is the type of meter installed at
MeterReadings. AAAAAAAAAAAAAA this SDP. The following are the
Meter. values that will be recognized by the
Specific Usage:
MeterType MDM/R
One of
“A3” – A3 ALPHA Meter
“A3”,
“A3_ILN” – A3 ALPHA Node
“A3_ILN”,
“A3_Collector” – A3 ALPHA Meter
“A3_Collector” or with option board
“REX” “REX” – REX Meter
AMRDEF. Fixed Number General: Y This field is populated with the
MeterReadings. (8) NNNNNNNN assigned Universal SDP ID.
Meter.
Example:
SdpIdent
‘00037482’
<MeterReadings>
<ConsumptionData>
<ConsumptionSpec>
AMRDEF. Varchar (10) General: Y The MDM/R will process register
MeterReadings. AAAAAAAAAA read values (the “AMRDEF.
MeterReadings.ConsumptionData.Re
ConsumptionData. Specific Usage:
ading.Value” attribute) where this unit
ConsumptionSpec. Domain of values as per of measurement is consistent with
UOM AMRDEF Export the register data channels supported
Format. by the Channel Configuration Set
The MDM/R will load assigned to the SDP.
values: For energy valid values are:
“KWH” or “kWh”, delivered “KWH” or “kWh”.
“KVARH” or “kVARh” For VAR-hours valid values are:
“KVAH” or “kVAh” inductive (Power Factor lagging)
delivered “KVARH” or “kVARh”
delivered “KVAH” or “kVAh”

AMRDEF Reference
Data
Type/Length
AMRDEF. Varchar (9) ‘General: N This field indicates power flow
MeterReadings. AAAAAAAAA direction. ‘Delivered’ indicates that
ConsumptionData. Specific Usage: the quantity has been delivered to
meter location. ‘Received’ indicates
ConsumptionSpec. Domain of values as per that the quantity has been received
Direction AMRDEF Export from the meter location. ‘Sum’
Format. indicates that the value is the sum of
The MDM/R only the absolute values of the energy
recognizes and loads delivered and the energy received.
‘Sum’ or ‘Delivered’ The quantity is the value in the
values. “AMRDEF.MeterReadings.
ConsumptionData.Reading.Value”
attribute.
If “Received”, no data will be
processed or reported upon
AMRDEF. Varchar (5) General: N The MDM/R recognizes values (the
MeterReadings. AAAAA “AMRDEF.MeterReadings.
ConsumptionData.Reading.Value”
ConsumptionData. Specific Usage:
attribute) where the TOU bucket is:
ConsumptionSpec. Domain of values as per
‘Total’ indicating that the value is the
TouBucket AMRDEF Export
sum of all TOU buckets as from the
Format.
kWh register of the meter.
The MDM/R only
recognizes and loads
‘Total’ values.
AMRDEF. Varchar (24) General: N The MDM/R recognizes values (the
MeterReadings. AAAAAAAAAAAAAAAA “AMRDEF.MeterReadings.
AAAAAAAA ConsumptionData.Reading.Value”
ConsumptionData.
attribute) where the Measurement
ConsumptionSpec. Specific Usage:
Period is:
MeasurementPeriod Domain of values as per
‘Current’ indicating that the usage
AMRDEF Export
Format. The MDM/R data is from the current period rather
than historical data from the previous
only recognizes and
billing period or previous season.
loads ‘Current’ values.
‘EndOfIntervalSnapshot’ indicating
the end of interval snapshot register
value taken just before the end of the
last interval of a block of interval data
per collector reading of interval data
(normally configured for 6 hours).3
<MeterReadings>
<ConsumptionData>
<Reading>
AMRDEF. Date/Time As per AMRDEF Export Y Date and time this reading was taken
MeterReadings. Format: from the meter.
ConsumptionData. yyyy-mm-dd hh24:mi:ss This time must be in EST
Reading.
Timestamp
3
Processing of ‘EndOfIntervalSnapshot’ register values will be available with the deployment of
EnergyIP Release 7.0 into the MDM/R Production and testing environments.

AMRDEF Reference
Data
Type/Length
AMRDEF. Number General: Y The reading value. As per the
MeterReadings. (12,5) NNNNNNNNNNNN.NN “AMRDEF.MeterReadings.
ConsumptionData. NNN ConsumptionData.
Reading. NOTE: ConsumptionSpec.UOM” attribute.
Transmitted Specific:
Value
values Examples:
exceeding (5) ‘7659’
decimal ‘765434.56’
places will be
rounded and
stored in the
Meter Data
Database to
(5) decimal
places
MDM/R with interval data as follows in table 2.13.3.
TABLE 2.13.3 INTERVAL DATA ELEMENTS AND ATTRIBUTES
AMRDEF Reference
Data
Type/Length
<MeterReadings>
<attributes>
AMRDEF. Date/Time As per AMRDEF Export Y Date and time that the data was
MeterReadings. Format: collected. This is to be delivered in
CollectionTime yyyy-mm-dd hh24:mi:ss EST
<MeterReadings>
<Meter>
AMRDEF. Varchar (50) No format prescribed Y This is the LDC’s unique identifier for
MeterReadings. the AMCD (the AMCD ID in the
Meter. synchronization file). This is the ID
MeterName that is used as a key for the
integration between the MDM/R and
the Elster MAS AMCC. The same
value is to be populated in the AMCD
ID field of the Meter Synchronization
Data Record.
AMRDEF. Varchar (15) General: Y This is the type of meter installed at
MeterReadings. AAAAAAAAAAAAAAA this SDP. The following are the
Meter. Specific Usage:
values that will be recognized by the
MeterType MDM/R
One of
“A3” – A3 ALPHA Meter
“A3”,
“A3_ILN” – A3 ALPHA Node
“A3_ILN”,
“A3_Collector” – A3 ALPHA Meter
“A3_Collector” or with option board
“REX” “REX” – REX Meter
AMRDEF. Fixed Number General: Y This field is populated with the
MeterReadings. (8) NNNNNNNN assigned Universal SDP ID.
MetersRead.
Example:
Meter.

AMRDEF Reference
Data
Type/Length
SdpIdent ‘00037482’
<MeterReadings>
<IntervalData>
<IntervalSpec>
AMRDEF. Varchar (10) General: Y The MDM/R will process interval data
MeterReadings. AAAAAAAAAA values (the “AMRDEF.
IntervalData. MeterReadings.IntervalData.
Specific Usage:
IntervalSpec. Reading.RawReading” attribute)
UOM Domain of values as per where this unit of measurement is
AMRDEF Export consistent with the interval data
Format. channels supported by the Channel
The MDM/R will load Configuration Set assigned to the
values: SDP.
“KWH” or “kWh”, For energy valid values are:
“KVARH” or “kVARh” delivered “KWH” or “kWh”.
“KVAH” or “kVAh” For VAR-hours valid values are:
inductive (Power Factor lagging)
delivered “KVARH” or “kVARh”
delivered “KVAH” or “kVAh”.
AMRDEF. Varchar (9) ‘General: N This field indicates power flow
MeterReadings AAAAAAAAA direction. ‘Delivered’ indicates that
IntervalData. the quantity has been delivered to
Specific Usage:
IntervalSpec. meter location. ‘Received’ indicates
Direction Domain of values as per that the quantity has been received
AMRDEF Export from the meter location. ‘Sum’
Format. indicates that the value is the sum of
The MDM/R only the absolute values of the energy
recognizes and loads delivered and the energy received.
‘Sum’ or ‘Delivered’ The quantity is the value in the
values “AMRDEF.MeterReadings.
IntervalData.Reading.RawReading”
attribute.
If “Received”, no data will be
processed or reported upon
AMRDEF. Number (3) General: Y Interval in minutes at which interval
MeterReadings. NNN data is collected.
IntervalData.
Example:
IntervalSpec.
Interval ‘60’
‘15’
<MeterReadings>
<IntervalData>
<Reading>
AMRDEF. Date/Time As per AMRDEF Export Y Date and time this reading was taken
MeterReadings. Format: from the meter.
IntervalData. yyyy-mm dd hh24:mi:ss The interval end time.
Reading.
This must be in EST
TimeStamp

AMRDEF Reference
Data
Type/Length
AMRDEF. Number General: N The reading value per the
MeterReadings. (12,5) NNNNNNNNNNNN.NN “AMRDEF.MeterReadings.
IntervalData. NNN IntervalData.IntervalSpec.UOM”
Reading. NOTE: attribute for load profile interval as
Transmitted Examples:
RawReading identified by the “AMRDEF.
values ‘7659’ MeterReadings.IntervalData.
exceeding (5) ‘765434.56’ Reading.TimeStamp”.
decimal
places will be
rounded and
stored in the
Meter Data
Database to
(5) decimal
places
<MeterReadings>
<IntervalData>
<Reading>
<QualityFlags>
AMRDEF. Number (1,0) General: N The meter’s time was changed
MeterReadings. N during the period represented by the
IntervalData. Specific Usage:
data. If this condition occurs, then
Reading. this value will be 1. If this condition
QualityFlags. 1 does not exist, this element will not
TimeChanged be present in the file.
Upon receipt of a TimeChanged flag,
the EnergyIP TimeChg flag is set in
the GUI, the database
TIME_CHANGE Flag is set, data is
subject to the Time Change
Validation Check.
AMRDEF. Number (1,0) General: N The meter’s clock was set backward
MeterReadings. N during the interval. If this condition
occurs, then this value will be 1. If
Reading. this condition does not exist, this
QualityFlags. 1 element will not be present in the file.
ClockSetBackward Upon receipt of a ClockSetBackward
flag, the EnergyIP TimeChg flag is
set in the GUI, the database
Validation Check.
AMRDEF. Number (1,0) General: N The interval was longer than
MeterReadings. N expected. If this condition occurs,
IntervalData. then this value will be 1. If this
Specific Usage:
Reading. condition does not exist, this element
QualityFlags. 1 will not be present in the file.
LongInterval Upon receipt of a LongInterval flag,
the EnergyIP LongInt flag is set in the
GUI, the database
LONG_INTERVAL Flag is set, data is
treated as normal data.

AMRDEF Reference
Data
Type/Length
AMRDEF. Number (1,0) General: N The meter’s clock was set forward
MeterReadings. N during the interval. If this condition
IntervalData. occurs, then this value will be 1. If
Specific Usage:
Reading. this condition does not exist, this
QualityFlags. 1 element will not be present in the file.
ClockSetForward Upon receipt of a ClockSetForward
flag, the EnergyIP TimeChg flag is
Validation Check.
AMRDEF. Number (1,0) General: N The interval was shorter than
MeterReadings. N expected. If this condition occurs,
IntervalData. Specific Usage: then this value will be 1. If this
PartialInterval Upon receipt of a PartialInterval flag,
the EnergyIP Partial flag is set in the
GUI, the database
PARTIAL_INTERVAL Flag is set,
data is treated as normal data.
AMRDEF. Number (1,0) General: N The InvalidTime tag indicates that the
MeterReadings. N TimeStamp associated with the
interval data reading is invalid. If this
Reading. condition occurs, then this value will
QualityFlags. 1 be 1. If this condition does not exist,
InvalidTime this element will not be present in the
file.
NOTE 1: EnergyIP will not load any
interval data from a Meter Transfer
Block with interval data readings
marked with the InvalidTime tag.
Such intervals will be treated as
4
missing data.
NOTE 2: EnergyIP will not load any
interval data from a Meter Transfer
Block with interval data readings
where the <TimeStamp> of the last
interval of the Meter Transfer block is
later than the system time at which
EnergyIP processes the Meter Read
data.
NOTE 3: Multiple duplicate interval
data readings received for the same
interval (i.e. same TimeStamp) in the
same data transmission and not
differentiated by the InvalidTime tag
will NOT be loaded.
AMRDEF. Number (1,0) General: N The interval was skipped by the
MeterReadings. N meter. If this condition occurs, then
IntervalData. this value will be 1. If this condition
Specific Usage:
Reading. does not exist, this element will not
QualityFlags. 1 be present in the file.
SkippedInterval Upon receipt of the SkippedInterval
flag, the EnergyIP NoData flag is set
in the GUI, the database NO_DATA
4
For EnergyIP Release 6.3 and Release 7.0 the MAS Meter Reads Adaptor is configured for the
MDM/R to reject interval data for which the InvalidTime data quality flag is set.

AMRDEF Reference
Data
Type/Length
flag is set, data is subject to the
Missing Intervals Validation check.5
AMRDEF. Number (1,0) General: N The meter experienced an outage (all

MeterReadings. N phases). If this condition occurs,
IntervalData. Specific Usage: then this value will be 1. If this
CompleteOutage Upon receipt of a CompleteOutage
flag, the EnergyIP PwrFail flag is set
in the GUI, Missing Interval
Validation check NO_DATA flag is
cleared, the database POWER_OFF
Flag is set, no estimation is done.
AMRDEF. Number (1,0) General: N The register overflowed. If this
MeterReadings. N condition occurs, then this value will
be 1. If this condition does not exist,
Reading. this element will not be present in the
QualityFlags. 1 file.
PulseOverflow Upon receipt of the PulseOverflow
flag, the EnergyIP Overflow flag is
PULSE_OVERFLOW flag is set, data
is subject to the Pulse Overflow
Validation Check.
AMRDEF. Number (1,0) General: N The meter was in test mode during
MeterReadings. N the interval. If this condition occurs,
Specific Usage:
TestMode Upon receipt of a TestMode flag, the
EnergyIP TestMode flag is set in the
GUI, the database TEST_MODE
Flag is set, data is subject to the Test
Mode Validation Check
AMRDEF. Number (1,0) General: N At lease one phase lost power during
MeterReadings. N the interval. If this condition occurs,
Specific Usage:
PartialOutage Upon receipt of a PartialOutage flag,
the EnergyIP PwrFail flag is set in the
GUI, Missing Interval Validation
check NO_DATA flag is cleared, the
database POWER_OFF Flag is set,
no estimation done.
5
As of September 2007 the “SkippedInterval” flag is not produced by any Elster meter deployed in
Ontario. Elster’s provision of this quality flag is to accompdate possible future deployment of meter
types that may provide this flag.

AMRDEF Reference
Data
Type/Length
AMRDEF. Number (1,0) General: N An outage may have occurred, but
MeterReadings. N there was not enough evidence to
IntervalData. say for sure. If this condition occurs,
Specific Usage:
Reading. then this value will be 1. If this
QualityFlags. 1 condition does not exist, this element
SuspectedOutage will not be present in the file.
Upon receipt of a SuspectedOutage
flag, the EnergyIP PwrFail flag is set
in the GUI, Missing Interval
Validation check NO_DATA flag is
cleared, the database POWER_OFF
Flag is set, no estimation done.
AMRDEF. Number (1,0) General: N Power was restored to the meter. If
MeterReadings. N this condition occurs, then this value
IntervalData. Specific Usage: will be 1. If this condition does not
Reading. exist, this element will not be present
QualityFlags. 1 in the file.
Restoration Upon receipt of a Restoration flag the
EnergyIP PwrOn flag is set in the
GUI, Missing Interval Check
NO_DATA flag is cleared in the
database, database POWER_ON
flag is set, estimation resumes on
subsequent interval data.
MDM/R with meter diagnostic data as follows in table 2.13.4.
TABLE 2.13.4 METER READINGS READING QUALITY INDICATOR AND STATUSES
AMRDEF Reference
Data
Type/Length
<MeterReadings>
<ReadingQualityIndicator>
AMRDEF. Varchar (12) General: N This indicates that the data read
MeterReadings. AAAAAAAAAAA from the meter may be suspect.
ReadingQualityIndicator. The only valid entries are “Tamper
Name Specific Usage : Alert” and “Meter Health”
“Tamper Alert”
OR
“Meter Health”
AMRDEF. Varchar (5) General: N If True, the meter reported a
MeterReadings. AAAAA condition that affects the meter’s
ReadingQualityIndicator. health.
Value Specific Usage :
“True”
OR
“False”
<MeterReadings>
<Statuses>
AMRDEF. Varchar (N) NN N The Statuses tag will be present
MeterReadings. only where there is an abnormal
Statuses. value reported by the meter.
Status There will be one Status tag for
each meter status reported in the
reading.

EnergyIP captures the ReadingQualityIndicator.Name and for every Status that has a
Status.Category = ReadingQualityIndicator.Name and ReadingQualityIndicator.Value =
True, the EnergyIP METER_RESET flag is set for each Status.Name designated in
Tables 2.13.5, 2.13.6, and 2.13.7. These tables outline the Status elements
designated by Elster to identify Meter Read data that should not be used for billing.
Table 2.13.5 lists the Status elements specific to A3 ALPHA meters. Table 2.13.6 lists
the Status elements specific to A3 ALPHA Node meters. Table 2.13.7 lists the Status
elements specific to REX meters.
Table 2.13.5 A3 ALPHA Meter Status indicating Data that Should Not be used for Billing
(MeterType = “A3” and “A3_Collector”)
“ID” “Category” “Name” EnergyIP Action

2 Meter Health Configuration error EnergyIP MtrDiagError/METER_RESET Flag is set, data
is subject to the Meter Diagnostic Validation check.
4 Meter Health RAM failure EnergyIP MtrDiagError/METER_RESET Flag is set, data

6 Meter Health Registered memory error EnergyIP MtrDiagError/METER_RESET Flag is set, data
7 Meter Health Clock error EnergyIP MtrDiagError/METER_RESET Flag is set, data
15 Meter Health Crystal oscillator error EnergyIP MtrDiagError/METER_RESET Flag is set, data
21 Meter Health EEPROM access error EnergyIP MtrDiagError/METER_RESET Flag is set, data
22 Meter Health Internal Communication /IC2 error EnergyIP MtrDiagError/METER_RESET Flag is set, data
23 Meter Health Tariff EE write error EnergyIP MtrDiagError/METER_RESET Flag is set, data
24 Meter Health Tariff EE read error EnergyIP MtrDiagError/METER_RESET Flag is set, data
25 Meter Health DSP download error EnergyIP MtrDiagError/METER_RESET Flag is set, data
26 Meter Health Table CRC Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
91 Meter Health Internal meter warning (latched) EnergyIP MtrDiagError/METER_RESET Flag is set, data
Table 2.13.6 A3 ALPHA Node Status indicating Data that Should Not be used for Billing
(MeterType = “A3_ILN”)

16 Meter Health ILC Configuration Error EnergyIP MtrDiagError/METER_RESET is set, data is
subject to the Meter Diagnostic Validation check.
19 Meter Health Meter Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
20 Meter Health Configuration Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
21 Meter Health RAM Failure EnergyIP MtrDiagError/METER_RESET Flag is set, data
22 Meter Health ROM Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
23 Meter Health Registered Memory Error EnergyIP MtrDiagError/METER_RESET Flag is set, data

24 Meter Health Clock Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
28 Meter Health EEPROM Access Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
29 Meter Health Internal Communication /I2C EnergyIP MtrDiagError/METER_RESET is set, data is
Error subject to the Meter Diagnostic Validation check.
30 Meter Health Tariff EE Write Error EnergyIP MtrDiagError/METER_RESET is set, data is
31 Meter Health Tariff EE Read Error EnergyIP MtrDiagError/METER_RESET is set, data is
32 Meter Health Crystal Oscillator Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
34 Meter Health DSP Download Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
38 Meter Health Internal Meter Warning EnergyIP MtrDiagError/METER_RESET Flag is set, data
40 Meter Health ILC Shared Memory Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
41 Meter Health ILC Power Fail Save Fail EnergyIP MtrDiagError/METER_RESET Flag is set, data
Table 2.13.7 REX Meter Status indicating Data that Should Not be used for Billing
(MeterType = “REX”)

29 Meter Health ROM Checksum Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
30 Meter Health Registered Memory Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
31 Meter Health Configuration Error EnergyIP MtrDiagError/METER_RESET Flag is set, data

33 Meter Health EEPROM Access Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
34 Meter Health Meter Chip Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
72 Meter Health Radio Config Error EnergyIP MtrDiagError/METER_RESET Flag is set, data

2.14 Meter Read Interface (Trilliant)
2.14.1 Description
Trilliant AMCC Meter Read interface.
2.14.2 Integration
2.14.2.1 Direction
AMCC to the MDM/R
will precede the interval data records for each SDP in the file transmission. All register
read records and interval data records will be ordered within each file transmission in
ascending date/time order.



associated to the same SDP, the MDM/R records the meter read data from the
inbound file against the Universal SDP ID and AMCD ID in the Meter Data
Database. If there is no Meter Read data in the record, no value is recorded.

Operator.
8. For meters not used for net metering and used for the determination of demand,
meters will be programmed such that the sum of the absolute values of the
energy delivered and the energy received will be transmitted as the total
delivered energy. This will apply to both interval consumption data and register
read data.
if programmed to record kilovolt-ampere-reactive hours, meters will be
programmed to record active kVARh quantities delivered, Power Factor lagging
(inductive), transmitted as positive quantities. This will apply to both interval
if programmed to record kilovolt-ampere hours, meters will be programmed
such that the sum of the values of the kilovolt-ampere hours delivered and the
kilovolt-ampere hours received will be transmitted as the total delivered kilovolt-
ampere hours. This will apply to both interval consumption data and register
read data.

in the MMD for the Daily Read Period being reported
populated.
§ The LDC and/or its designated agents receive interim and final summary
Transfer Services.
2.14.6 Assumptions

Period.
2.14.8 File Format

2.14.8.1 File Name Record for the Trilliant CMEP File
Table 2.14.1 FILE NAME RECORD FOR THE TRILLIANT CMEP FILE

<FTSFN>
</FTSFN>

2.14.8.2 Trilliant CMEP File

§ "MEPMD01" - Metering Data Type 1 - Interval Data
§ “MEPAD01" - Administrative Data Type 1 – DASR
§ "MEPAD02" - Administrative Data Type 2 - Credit Data
§ "MEPMD02" - Metering Data Type 2 - TOU Data
§ "MEPBD01" - Billing Data Type 1 - Billed Dollars
§ "MEPBD02" - Billing Data Type 2 - Interval Pricing Plan
§ "MEPBD03" - Billing Data Type 3 - TOU Pricing Plan
§ "MEPLF01" - Distribution Loss Factors – Electric
§ "MEPEC01" - Equipment Configuration Type 1
§ "MEPRR01" - Record Reject Type 1
Table 2.14.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TRILLIANT
CMEP Data
Specific Usage:
“MEPMD01”
Specific Usage:
19970819
Sender ID Varchar (10) General: N This field will always contain “Trilliant”.
AAAAAAAAAA
FTS file name. For Trilliant: FILE ID =
‘Trilliant’
7200

CMEP Data
Example: process.
‘ORG83729’
MDM/R
Specific Usage: This field will always contain
only recognize
‘ORG29738”
‘00037482’
Time Stamp Date/Time yyyyMMddHHm Y This field Is populated with the date and
m time that this record was created. This
Trilliant AMCC.
AAAAAAAA transmission. Defined values are :
Specific Usage:
only recognize
‘Summary” – Summary of SP totaled
“OK”, “RESEND"
data.
data
returned to sender
A being delivered
Specific Usage:
“G” – Gas
The MDM/R will
“W” – Water
only recognize
“E” “S” - Steam

CMEP Data
Specific Usage: interval data and register data channels
data in kWh delivered.
‘KVARH’ and
data in kVAh delivered.
lagging) delivered.
Specific Usage: hence no calculation to engineering

CMEP Data

Count = ‘12’ for a If the Units field is populated with
transmission of ‘KWHREG’, ‘KVAHREG’ or
12 intervals. ‘KVARHREG’ then count will be 1,
indicating that a register read for the
end of the Meter Transfer Block is being
transmitted
Block
Date/Time Date/Time yyyyMMddHHm Y Per CMEP, the Date/Time field must be
m supplied for the first record provided.
record is read.
provided for every interval/register
value delivered. It must be the time at
the end of the interval. The Date/Time
must be in EST.

CMEP Data
including a reading as supplied from the AMCC
space at the without validation, estimation or editing,
second and fifth or ‘N’ indicating no value has been
character supplied for this interval. The second
position) and third digits are a 10-bit hexadecimal
number from ‘00’ to ‘03 FF’. The 10-
Examples: bits indicate the following quality
conditions:
For a simple
code - The Trilliant SerViewCom AMI can
A raw interval transmit the following simple Data
read for which a Quality code values:
power outage R 00 00 (no Bit is set)
occurred during R 00 01 (Bit 0)
the interval is ‘R
00 40’. R 00 02 (Bit 1)
N 00 04 (Bit 2) – Missing data will
always be accompanied by a
For a compound Numeric floating point value of “0”.
code -
R 00 08 (Bit 3)
A raw interval
read for which a R 00 10 (Bit 4)
power outage R 00 20 (Bit 5)
occurred R 00 40 (Bit 6)
concurrent with a R 00 80 (Bit 7)
RAM error would
R 01 00 (Bit 8)
be ‘R 02 40’
R 02 00 (Bit 9)
Table 2.14.3 provides the Trilliant
consumption data.
NOTE: The Trilliant SerViewCom AMI
can also transmit these simple codes in
floating point NNNNNNNNNN register read (if the Units field is
NN.NNNNN
Transmitted interval consumption (if the Units field is
exceeding (5) 123456789012.3
decimal places 4
will be rounded
and stored in the
Meter Data
Database to (5)
decimal places

triplet within the Trilliant CMEP file, and the setting of EnergyIP flags as applicable.
Table 2.14.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Trilliant
Bit Trilliant Data Quality Flag Description Required

Bit EnergyIP Flag
Trilliant – No data quality problems
00 00 R 00 00 null
Trilliant – Manually entered or modified
Bit 0 00 01 EnergyIP DCEstimated flag is set in GUI, Validation status R 00 01 DC_DATA_ESTIMATION
set to ‘EST’, Change Method set to ‘EDC’
Trilliant – Automatically estimated
Trilliant – Missing data for this interval
Trilliant – Overflow: Consumption is more than the
MeshReader can record
Bit 3 00 08 R 00 08 PULSE_OVERFLOW
EnergyIP Overflow flag is set in GUI, data is subject to the
Trilliant – Partial interval is on: When set this status
indicates the effective interval duration was shortened
Bit 4 00 10 R 00 10 SHORT_INTERVAL
EnergyIP ShortInt flag is set in GUI, data will be treated as
normal data
Trilliant – Too full: Indicates too much pulse content,
happens when the clock is adjusted
Bit 5 00 20 R 00 20 LONG_INTERVAL
EnergyIP LongInt flag is set in GUI, data is treated as
normal data
Trilliant – Power outage: Indicates start of power outage
done
Trilliant – Power restore: Indicates power was restored
EnergyIP PwrOn flag is set in GUI, Missing Intervals
Bit 7 00 80 R 00 80 POWER_ON
validation check NO_DATA flag is cleared,
validation/estimation resumes on subsequent interval data
Trilliant – Clock error: Clock time was messed up
Bit 8 01 00 EnergyIP TimeChg flag is set in GUI, data is subject to the R 01 00 TIME_CHANGE
Time Change Validation check
Trilliant – Diagnostic error: RAM or memory error
Bit 9 02 00 EnergyIP MtrDiagError flag is set in GUI, data is subject to R 02 00 METER_RESET
the Meter Diagnostic Validation check

The EnergyIP CMEP adaptor for Trilliant will support the combination or addition of

2.15 Meter Read Transformation for Transmission via Trilliant
CMEP Interface
2.15.1 Description
The use of a CMEP file format to transmit Meter Read data sourced from AMI systems
other than the source AMI system is possible. LDCs may elect to transform Meter
Read data as retrieved by the source Advanced Metering Control Computer (AMCC) to
a CMEP format when correction of Meter Read data in the past is required, or to utilize
the interval data Data Collection Estimation data quality flag available only via the
Trilliant Meter Read Interface.
LDCs electing to transform Meter Read data to a CMEP format must transmit such
transformed data in the Trilliant CMEP format. The Trilliant CMEP format provides the
greatest parity regarding transmission of interval data, register read data, and related
data quality flags available from other AMI systems deployed as part of the Ontario
Smart Metering System.
The purpose of this specification is to define the requirements for data transformations
applied to Meter Read data collected by non-Trilliant AMI Advanced Metering Control
Computers (AMCC) and transformed by an LDC’s meter read translator prior to
transmission to the MDM/R via the Trilliant Meter Read Interface.
This specification anticipates that such data transformations may be used to process
data on an exception basis for Meter Read data correction, or may be used for daily
production transmission of Meter Read data to the MDM/R for each Daily Read Period
for an LDC’s entire smart meter population.
2.15.2 Integration
2.15.2.1 Direction
AMCC to Meter Read Translator to the MDM/R Trilliant Meter Read Interface
Meter read data may be received from the AMCC and transformed by the LDC’s meter
read translator for all meters that are associated to SDP’s that a) have been assigned
a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or
Incremental Synchronization integrations and c) have all of the attributes associated
with the Data Collection Service populated.
All meter read data received from the Meter Read Translator will contain:
§ A register read for each Meter Transfer Block subject to the requirements of
sub-section 2.15.2.3 below.
readings will have a date/time inside the date/time range of the interval data set. All
register read records and interval data records will be ordered within each file
transmission in ascending date/time order.

Subject to the limitation for the maximum number of data triplets per record described
above, interval data will be transmitted in Meter Transfer Blocks for an entire day or
days, with the Meter Transfer Block beginning and ending at midnight whenever
possible to do so. Transmission of partial day interval data should be avoided. At
least one register reading should be transmitted to the MDM/R for each Daily Read
Period. Hovever, interval data for an entire day may be transmitted without an
associated register reading if an associated register reading has not been collected by
the source AMCC.
2.15.2.3 Transmission of Register Readings

Register readings transmitted to the MDM/R will be cumulative values established from
meter readings approved and verified by Measurement Canada as registered and
transmitted by the meter and assigned engineering units and date/time values by the
source Advanced Metering Control Computer (AMCC) that retrieves the register
readings. Quantity values and date/time stamps assigned by the AMCC to register
readings will not be altered in any way when transmitted to the MDM/R.
Estimated register readings in terms of altered quantity value or altered date/time
stamp will be not transmitted to the MDM/R using the Trilliant Meter Read Interface.
Such externally estimated register readings may be transmitted to the MDM/R
indicating such register readings as estimated using the (future) Universal Meter Read
Interface.

The latest register reading received as part of a Meter Transfer Block is available for
Message Sum Check validation, and Register Read Scaling of Historic and Class Load
Profile estimation. Register readings received as part of a Meter Transfer Block are
also available to the Billing Validation Sum Check if the Date/Time of the register
reading is within the ‘MaxRegisterRange’ hours of the billing period start date/time or
billing period end date/time.

‘MaxRegisterRange’ hours of the billing period start date/time or billing period end
date/time.

In addition to the Business Rules specified in Section 2.14.3 the following rules apply
to data transformations utilizing the Trilliant Meter Read interface.
A) Rules Affecting Synchronization

The ‘AMCC Type’ is used by the MDM/R Register Read Monitor as the key for
several Data Collection reports that provide reporting against each AMI technology.
This includes Reports DC01, DC02 and DC05. The ‘AMCC Type’ also is used as
the basis of the <measurementSource> attribute in the Billing Service Standard
Interface Reply.
1. When establishing each ‘Communication Module’ asset as part of the Asset
Data File Detail Record the ‘AMCC Type’ will be specified as the actual AMI
technology used for each meter.
a. For all Elster meters, ‘AMCC Type’ must equal “01”
b. For all Sensus meters, ‘AMCC Type’ must equal “02”
c. For all Tantalus meters, ‘AMCC Type’ must equal “04”
B) Rules Affecting File Transfer Services (FTS)

1. If the LDC elects to transmit Meter Read data sourced from a non-Trilliant AMI
system, the LDC or its AMI Operator must be registered to transmit FTS files of
File Type 7200 – Meter Read Interface (Trilliant)
2. Meter Read data sourced from non-Trilliant meters and transmitted using a
Trilliant CMEP format must be sent as a FILE ID “7200”.
C) Rules Affecting Meter Read Data sourced from the Elster AMCC
Register read data from REX meters and transmitted in the MAS AMRDEF Export
XML as <ConsumptionData> is collected predominantly at mid-interval and does
not coincide with the end date/time of any interval data block. LDC’s deploying
REX2 (R2S) Meters or REX1 (R1S) Meters with firmware 4.1 or higher and
operating EnergyAxis Metering Automation Server (MAS) Release 6.2 or
EnergyAxis Management System (EA_MS) Release 7.0 can expect the AMRDEF
Export XML interval data records to be accompanied by an
<EndOfIntervalSnapshot> record. This “End Of Interval Snapshot” is a register
read coinciding with the end date/time of each collected interval data block.
1. Register readings included in each Meter Transfer Block should be sourced
from the “End Of Interval Snapshot” if available and should be at the end of the
Meter Transfer Block or as late as possible within the date/time range of the
interval data set.
2. Register readings included in each Meter Transfer Block sourced from
“Consumption Data” should be as late possible within the date/time range of
the interval data set.
Please see Section 2.14.4 – Pre-Conditions for the Meter Read Interface (Trilliant).

Please see Section 2.14.5 – Post-Conditions for the Meter Read Interface (Trilliant).
2.15.6 Assumptions
Please see Section 2.14.6 – Assumptions for the Meter Read Interface (Trilliant).

is for Meter Read data to be supplied in midnight ti midnight Meter Transfer Blocks
whenever possible to do so. The LDCs will establish their frequency based on their
operational requirements.
Period.
2.15.8 File Format

Please see Section 2.14.8 – File Format for the Meter Read Interface (Trilliant).
2.15.9 Translation of Data Quality Flags

2.15.9.1 Translation of Elster <QualityFlags> and <Statuses> to Trilliant CMEP
The Elster MAS AMRDEF provides data quality information using two differing tag
types namely the <QualityFlags> tags and <Statuses> tags. These data quality
indicators should map to the Trilliant CMEP Protocol Text flags as specified in Table
2.15.1.
Table 2.15.1 Mapping of Elster Quality Flags to Trilliant Protocol Text Codes
Trilliant Data Quality Required

Elster Tag EnergyIP Flag
Flag Description CMEP Flag
Note 1.
(not available) No data quality problems R 00 00 null
(not available) Manually entered or R 00 01 DC_DATA_ESTIMATION
modified
(not available) Automatically estimated R 00 02 DC_DATA_ESTIMATION
Note 2.
<QualityFlags.SkippedInterval> Missing data for the N 00 04 NO_DATA
interval
<QualityFlags.PulseOverflow> Overflow consumption R 00 08 PULSE_OVERFLOW
<QualityFlags.PartialInterval> Partial data in the interval R 00 10 PARTIAL_INTERVAL
<QualityFlags.LongInterval> Too much pulse content R 00 20 LONG_INTERVAL
<QualityFlags.CompleteOutage> Start of power outage R 00 40 POWER_OFF
<QualityFlags.PartialOutage>
<QualityFlags.SuspectedOutage>
<QualityFlags.Restoration> Power is restored R 00 80 POWER_ON
<QualityFlags.TimeChanged> Clock error R 01 00 TIME_CHANGE
<QualityFlags.ClockSetBackward>
<QualityFlags.ClockSetForward>
<ReadingQualityIndicator> Diagnostic error, Ram or R 02 00 METER_RESET
<Statuses><Status.Name> memory error
For A3 ALPHA Meter see Table 2.13.5

For A3 ALPHA NODE see Table 2.13.6
For REX Meters see Table 2.13.7
Note 3.
<QualityFlags.InvalidTime> (not available) N 00 04 NO_DATA
Note 4.
<QualityFlags.TestMode> (not available) - TEST_MODE
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will
be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in
the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
Note 1: Interval data submitted for which there are no data quality problems must be
submitted in the CMEP format with the Protocol Text code of “R 00 00”.
Note 2: The <SkippedInterval> tag is not produced by any Elster Energy Axis AMI
system deployed in Ontario and the AMRDEF Export XML does not include
records for missing interval data. Elster’s specification of the “Skipped Interval”
data quality flag is to accommodate possible future deployment of meter types
that may provide this flag. Missing intervals from Elster meters transmitted in
the Trilliant CMEP format should include the “N 00 04” Protocol text code.
Note 3: EnergyIP Release 6.3 and Release 7.0 as deployed for the MDM/R will not
load interval data readings marked with the <InvalidTime> tag. Multiple interval
data readings received for the same interval (i.e. same <TimeStamp>) and not
differentiated by the <InvalidTime> tag will not be loaded by the MDM/R.
<InvalidTime> intervals from Elster meters transmitted in the Trilliant CMEP
format should include the “N 00 04” Protocol Text code. (Please see “Invalid
Time” discussion below.)
Note 4: The Elster <TestMode> is not supported by the Trilliant CMEP format and thus
the MDM/R Test Mode validation test will not be available to Elster Meter Read
data transmitted using the Trilliant Meter Read Interface.
Invalid Time
The EnergyAxis MAS system does retrieve enough information to reliably assign a
timestamp to interval data under certain power outage conditions as well as expected
routine time synchronization events during normal power conditions. These conditions
apply to both Elster REX (R1S) and REX2 (R2S) Meters when processed by either
EnergyAxis MAS Release 6.2 or EnergyAxis MS Release 7.0. Data transmitted in the
AMRDEF Export XML file contains less information than is available in the EnergyAxis
system (e.g. ISN record identifiers, Date Records, and Time Stamp Records are not
transmitted in the AMRDEF Export XML), and thus downstream systems such as ODS
or MDM systems are not likely to be able to correct the date-time stamps of interval
data and power outage or power restoration flags without input from other systems
(such as outage management systems) or by human interpretation.
Meter Diagnostics
The EnergyAxis MAS system identifies meter diagnostic problems by the presence of
each of the specific tag elements for the <Status.Name> tag. The MDM/R sets the
METER_RESET flag indicating a meter diagnostic error only for those <Status.Name>
tag elements specified in Section 2.13, Table 2.13.4 and Tables 2.13.5, 2.13.6, and
2.13.7. Intervals in the same MAS Export file for which the <ReadingQualityIndicator>
and <Status.Name> tags are set as defined in these tables and transformed to the
Trilliant CMEP format should include the “R 02 00” Protocol text code.

Multiple Elster Data Quality Problems
The Elster AMRDEF Export XML indicates multiple data quality problems by setting
each <QualityFlag> to a value of “1” if the condition occurs and also by setting the
<ReadingQualityIndicator> and <Status.Name> tags in the same data transmission.
The equivalent Trilliant function is accomplished by the use of compound hexadecimal
codes.
The Trilliant Meter Read Interface supports the combination of multiple data quality
flags up to the possible 1024 code values resulting from the hexadecimal addition of
the CMEP codes.
If your proposed translation of Elster meter read data is intended to provide the Data
Collection Estimation codes (i.e. “Manually entered or modified”, or “Automatically
estimated”) we recommend that these simple codes be used for any combination data
quality condition corrected by manual editing or automatic estimation.
2.15.9.2 Translation of Sensus CMEP to Trilliant CMEP

Transformation of the Sensus CMEP Protocol Text flags should map to the Trilliant
CMEP Protocol Text flags as specified in Table 2.15.2.
Table 2.15.2 Mapping of Sensus Protocol Text Codes to Trilliant Protocol Text Codes
Sensus Data Quality Flag Sensus Trilliant Data Quality Flag Required
EnergyIP Flag
Description CMEP Flag Description CMEP Flag
Error free interval R 00 00 No data quality problems R 00 00 null
(not available) - Manually entered or modified R 00 01 DC_DATA_ESTIMATION
(not available) - Automatically estimated R 00 02 DC_DATA_ESTIMATION
Missing data N 00 20 Missing data for the interval N 00 04 NO_DATA
(not available) - Overflow consumption R 00 08 PULSE_OVERFLOW
(not available) - Partial data in the interval R 00 10 PARTIAL_INTERVAL
(not available) - Too much pulse content R 00 20 LONG_INTERVAL
Power outage R 00 02 Start of power outage R 00 40 POWER_OFF
Power restoral R 00 04 Power is restored R 00 80 POWER_ON
(not available) - Clock error R 01 00 TIME_CHANGE
(not available) - Diagnostic error, Ram or R 02 00 METER_RESET
memory error
Communication failure R 00 01 (not available) - null
Voltage sag R 00 08 (not available) - null
Voltage swell R 00 10 (not available) - null
Daylight savings in effect R 00 40 (not available) - null
Meter was out of service R 00 80 (not available) - null
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will be
stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the
GUI as Power Off. Other valid flags assigned to register read data will be ignored.

2.15.9.3 Translation of Sensus2 CMEP to Trilliant CMEP
Transformation of the Sensus FlexNet extended file CMEP format Protocol Text flags
should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.3.
Table 2.15.3 Mapping of Sensus2 Protocol Text Codes to Trilliant Protocol Text Codes
Sensus2 Data Quality Flag Sensus2 Trilliant Data Quality Flag Required
EnergyIP Flag
Error free interval R0 No data quality problems R 00 00 null
Missing data N32 Missing data for the interval N 00 04 NO_DATA
Overflow R512 Overflow consumption R 00 08 PULSE_OVERFLOW
Long interval R1024 Too much pulse content R 00 20 LONG_INTERVAL
Short interval R2048 (not available) - SHORT_INTERVAL
Power outage R2 Start of power outage R 00 40 POWER_OFF
Power restoral R4 Power is restored R 00 80 POWER_ON
Time Adjustment R256 Clock error R 01 00 TIME_CHANGE
(not available) - Diagnostic error, Ram or R 02 00 METER_RESET
memory error
Communication failure R1 (not available) - null
Voltage sag R8 (not available) - null
Voltage swell Not used (not available) - null
Daylight savings in effect R64 (not available) - null
Meter was out of service Not used (not available) - null
Test mode R4096 (not available) - TEST_MODE
Register rollover detected Not used (not available) - null
Clock out of sync R32768 Clock error R 01 00 TIME_CHANGE
2.15.9.4 Translation of Tantalus CMEP to Trilliant CMEP

Transformation of the Tantalus CMEP Protocol Text flags should map to the Trilliant
CMEP Protocol Text flags as specified in Table 2.15.4.
Table 2.15.4 Mapping of Tantalus Protocol Text Codes to Trilliant Protocol Text Codes
Tantalus Data Quality Flag Sensus2 Trilliant Data Quality Flag Required
EnergyIP Flag
Normal raw data R 00 00 No data quality problems R 00 00 null
Consumption reading missing N 00 20 Missing data for the interval N 00 04 NO_DATA
for this interval
(not available) - Overflow consumption R 00 08 PULSE_OVERFLOW
(not available) - Too much pulse content R 00 20 LONG_INTERVAL
Power was out for all or part R 00 02 Start of power outage R 00 40 POWER_OFF

of the interval
Power was restored during R 00 04 Power is restored R 00 80 POWER_ON
this interval
(not available) - Clock error R 01 00 TIME_CHANGE
The meter has failed R 01 00 Diagnostic error, Ram or R 02 00 METER_RESET
memory error
Communication failure within R 00 01 (not available) - null
the meter
Voltage sag was in effect for R 00 08 (not available) - null
all or part of the interval
Voltage swell was in effect for R 00 10 (not available) - null
Daylight savings was in effect R 00 40 (not available) - null
Meter was out of service for R 00 80 (not available) - Null
Meter was unavailable due to R 02 00 (not available) - null
maintenance by the utility

2.16 Meter Read Interface (Tantalus)
2.16.1 Description
Tantalus AMCC Meter Read interface.
2.16.2 Integration
2.16.2.1 Direction
AMCC to the MDM/R


Register reading received as part of a Meter Transfer Block are available for Message

Organization ID for the Daily Read Period date being reported.

Operator.

populated.
Transfer Services.
2.16.6 Assumptions

Period.
2.16.8 File Format

2.16.8.1 File Name Record for the Tantalus CMEP file
Table 2.16.1 FILE NAME RECORD FOR THE TANTALUS CMEP FILE

<FTSFN>
</FTSFN>

2.16.8.2 Tantalus CMEP File

Table 2.16.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TANTALUS
CMEP Data
Specific Usage:
“MEPMD01”
Specific Usage:
19970819
Sender ID Varchar (10) General: N This field will always contain “Tantalus”.
AAAAAAAAAA
FTS file name. For Tantalus: FILE ID =
‘Tantalus’
7300

CMEP Data
Example: process.
‘ORG83729’
MDM/R
only recognize
‘ORG29738”
‘00037482’
Tantalus AMCC.
Specific Usage:
only recognize
data.
data
returned to sender
A being delivered
Specific Usage:
“G” – Gas
The MDM/R will
“W” – Water
only recognize
“E” “S” – Steam

CMEP Data
‘KVARH’ and
lagging) delivered.
Interval Time Interval MMDDHHMM Y Describes the time interval between

CMEP Data
If Units = ‘KWH’, the MEPMD01 Record Type in the
Count = ‘12’ for a California Metering Exchange Protocol.
transmission of
12 intervals.
‘KWHREG’, ‘KVAHREG’ or
transmitted
Block
record is read.
must be in EST.
‘KWHREG’, then count will be 1,
transmitted.
‘KWH’, then the count will be the
number of intervals that are included in
the Meter Transfer Block.

CMEP Data
The first digit is either ‘R’, a raw reading
Examples: as supplied from the AMCC without
For a simple validation, estimation or editing, or ‘N’
code - indicating no value has been supplied
for this interval. The second and third
A raw interval
digits are an 10-bit hexadecimal
read for which a
number from ‘00’ to ’03 FF’. The 10-
power outage
bits indicate the following quality
occurred during
conditions:
00 02’. The Tantalus TUNet AMI can transmit
the following simple Data Quality code
For a compound values:
code - R 00 00 (no Bit is set)
A raw interval R 00 01 (Bit 0)
occurred during
daylight savings R 00 08 (Bit 3)
time would be ‘R R 00 10 (Bit 4)
00 42’ N 00 20 (Bit 5) – Missing data will
(7 characters always be accompanied by a
including a Numeric floating point value of
space at the “0.00”.
second and fifth R 00 40 (Bit 6)
character R 00 80 (Bit 7)
position)
R 01 00 (Bit 8)
R 02 00 (Bit 9)
Bits 10-15 are currently not defined
but may be so in the future
Table 2.16.3 provides the Tantalus
consumption data.
NOTE: The Tantalus TUNet AMI can
Transmitted NN.NNNNN
exceeding (5)
123456789012.3
decimal places 4
will be rounded
and stored in the
Meter Data
Database to (5)
decimal places

Table 2.16.3 describes the action taken by EnergyIP application in processing the
triplet within the Tantalus CMEP file, and the setting of EnergyIP flags as applicable.
Table 2.16.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Tantalus
Bit Tantalus Data Quality Flag Description Required

Bit EnergyIP Flag
Tantalus – Normal raw data
00 00 R 00 00 null
Tantalus – Communication failure within the meter
Bit 0 00 01 R 00 01 null
Tantalus – Power was out for all or part of the interval
done
Tantalus – Power was restored during this interval
EnergyIP PwrOn flag is set in GUI, Missing Interval Check
Bit 2 00 04 R 00 04 POWER_ON
NO_DATA flag is cleared, validation/estimation resumes on
subsequent interval data
Tantalus – A voltage sag was in effect for all or part of the
Bit 3 00 08 interval R 00 08 null
Tantalus – A voltage swell was in effect for all or part of the
Tantalus – Consumption reading was missing for this
interval
Bit 5 00 20 N 00 20 NO_DATA
EnergyIP NoData flag is set in GUI, data is subject to the
Tantalus – Daylight Savings Time was in effect
Bit 6 00 40 R 00 40 null
Tantalus – The meter was out of service for all or part of the
Tantalus – The meter has failed
Tantalus – The meter unavailable due to maintenance by
Bit 9 02 00 the utility R 02 00 null

The EnergyIP CMEP adaptor for Tantalus will support the combination or addition of

2.17 Meter Read Interface (SmartSynch)
2.17.1 Description
SmartSynch Transaction Management System (TMS) AMCC Meter Read interface.
2.17.2 Integration
2.17.2.1 Direction
AMCC to the MDM/R




Operator.

populated.
§ The LDC and/or its designated agents receive interim and final summary
Transfer Services.
2.17.6 Assumptions

Period.
2.17.8 File Format

2.17.8.1 File Name Record for the SmartSynch CMEP File
Table 2.17.1 FILE NAME RECORD FOR THE SMARTSYNCH CMEP FILE

<FTSFN>
</FTSFN>

2.17.8.2 SmartSynch CMEP File

Table 2.17.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SMARTSYNCH
CMEP Data
Record Type Varchar (7) General : Y The SmartSynch CMEP File Format
AAAAAAA provides mapping to metering data
types MEPMD01 – Interval Data, and
Specific Usage: MEPMD02 – TOU Data.
“MEPMD01” The MDM/R is configured to support
only interval data and reference register
reading data.
This field will always contain
“MEPMD01”
Record Date General: N This field will contain the CMEP version
Example: The SmartSynch adaptor will not
19970819 validate this field.
or The Record Version field may be “null”.
“null”

CMEP Data
Sender ID Varchar (10) General: N This field will always contain
AAAAAAAAAA “SmartSynch”.
Specific Usage: NOTE: The function of this field has

‘SmartSynch’ been replaced by use of the MDM/R
FTS file name. For SmartSynch: FILE
ID = 7400
Example: process.
‘ORG83729’
MDM/R
only recognize
‘ORG29738”
‘00037482’
the SmartSynch TMS AMCC.
Specific Usage:
only recognize
data.
data
returned to sender
A being delivered
Specific Usage:
“G” – Gas
The MDM/R will
“W” – Water
only recognize
“E” “S” - Steam

CMEP Data
‘KVARH’ and
lagging) delivered.

CMEP Data

Count = ‘12’ for a If the Units field is populated with
transmission of ‘KWHREG’, ‘KVAHREG’ or
12 intervals. ‘KVARHREG’ then count will be 1,
transmitted
Block
record is read.
must be in EST.

CMEP Data
including a reading as supplied from the AMCC
space at the without validation, estimation or editing,
second and fifth or ‘N’ indicating no value has been
character supplied for this interval. The second
position) and third digits are a 10-bit hexadecimal
number from ‘00’ to ‘03 FF’. The 10-
Examples: bits indicate the following quality
conditions:
For a simple
code - The SmartSynch TMS can transmit the
A raw interval following simple Data Quality code
read for which a values:
power outage R 00 00 (no Bit is set)
occurred during R 00 01 (Bit 0)
00 40’. R 00 02 (Bit 1)
N 00 04 (Bit 2) – Missing data will
always be accompanied by a
For a compound Numeric floating point value of “0”.
code -
R 00 08 (Bit 3)
A raw interval
occurred R 00 40 (Bit 6)
concurrent with a R 00 80 (Bit 7)
RAM error would
R 01 00 (Bit 8)
be ‘R 02 40’
R 02 00 (Bit 9)
Table 2.17.3 provides the SmartSynch
consumption data.
NOTE: The SmartSynch TMS AMCC
can also transmit these simple codes in
NN.NNNNN
Transmitted interval consumption (if the Units field is
exceeding (5) 123456789012.3
decimal places 4
will be rounded
and stored in the
Meter Data
Database to (5)
decimal places

triplet within the SmartSynch TMS CMEP file, and the setting of EnergyIP flags as
applicable. The same protocol text quality flags are recognized and processed for
KWH, KVARH, and KVAH interval data.
Table 2.17.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for
SmartSynch TMS
Bit SmartSynch Data Quality Flag Description Required

Bit EnergyIP Flag
SmartSynch – No data quality problems
00 00 R 00 00 null
SmartSynch – Manually entered or modified
SmartSynch – Automatically estimated
Bit 1 00 02 EnergyIP DCEstimated flag is set in GUI, Validation status Not used DC_DATA_ESTIMATION
SmartSynch – Missing data for this interval
SmartSynch – Overflow: Consumption is more than the
meter can record
Bit 3 00 08 R 00 08 PULSE_OVERFLOW
EnergyIP Overflow flag is set in GUI, data is subject to the
SmartSynch – Partial: Indicates partial data in the interval.
TMS Partial (short interval) flag is set
Bit 4 00 10 R 00 10 SHORT_INTERVAL
EnergyIP ShortInt flag is set in GUI, data will be treated as
normal data
SmartSynch – Too full: Indicates too much pulse content,
happens when the clock is adjusted backwards
Bit 5 00 20 R 00 20 LONG_INTERVAL
EnergyIP LongInt flag is set in GUI, data is treated as
normal data
SmartSynch – Power outage: Indicates start of power
outage
Bit 6 00 40 EnergyIP PwrFail flag is set in GUI, Missing Interval R 00 40 POWER_OFF
done
SmartSynch – Power restore: Indicates power was restored
EnergyIP PwrOn flag is set in GUI, Missing Intervals
Bit 7 00 80 R 00 80 POWER_ON
validation check NO_DATA flag is cleared,
validation/estimation resumes on subsequent interval data
SmartSynch – Clock error: The meter clock was corrected
due as a result of being outside allowable drift tolerances
Bit 8 01 00 R 01 00 TIME_CHANGE
EnergyIP TimeChg flag is set in GUI, data is subject to the
Time Change Validation check
SmartSynch – Diagnostic error: RAM or memory error

The EnergyIP CMEP adaptor for SmartSynch will support the combination or addition
of multiple hexadecimal data quality flags up to the 1024 hexadecimal code values

2.18 Universal Meter Read Interface (Future)
2.17.1 Description
The purpose of this interface will be to provide a file based mechanism for submission
of estimated or valid manual register readings.
This interface will be based on a version of the EnergyIP Generic or Universal data
import adapter modified to recognize data quality flags applied to register readings.
This interface will be developed and deployed to support the MDM/R Universal
Solution for verification and reconciliation of billing quantities based on Measurement
Canada approved merter registrations.
– End of Document –

MDMR Technical Interface Spec v3 0 20100924 CLEAN

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MDMR Technical Interface Spec v3 0 20100924 CLEAN

Încărcat de

Drepturi de autor:

Formate disponibile

IESO_SPEC_9027

Meter Data Management and

Status of these Specifications

The following elements of this specification are affected:

Version 3.0 – September 24, 2010 § i

Version 3.0 – September 24, 2010 ii

Document Title Issue Date

SME_SPEC_0001: MDM/R V1.0 Reports Technical Specifications – 29 April 2010

Measurement Canada General Bulletin: GEN-25-E, Policy on the Date: 2000-06-26

Version 3.0 – September 24, 2010 iii

Version 3.0 – September 24, 2010 iv

Version 3.0 – September 24, 2010 v

Version 3.0 – September 24, 2010 vi

Version 3.0 – September 24, 2010 vii

Version 3.0 – September 24, 2010 viii

Version 3.0 – September 24, 2010 ix

1.2 Document Scope

1.3 Assumptions and Limitations

Version 3.0 – September 24, 2010 1

1.4 Definition of Terms

Version 3.0 – September 24, 2010 2

Version 3.0 – September 24, 2010 3

Version 3.0 – September 24, 2010 4

1.4.1 Integration Terminology

1.5 Organization of this Document

Version 3.0 – September 24, 2010 5

1.6 Document Relationships

Version 3.0 – September 24, 2010 6

Version 3.0 – September 24, 2010 7

MDM/R Specification Document Series

MDM/R V1.0 Technical MDM/R V1.0 Reports

MDM/R File Transfer

Design and Functional

MDM/R Document Library for Design, Functions, and Technical Interfaces

1.6.2 Subject Cross-reference: MDM/R Design and Functionality to

Version 3.0 – September 24, 2010 8

MDM/R Master Data (MMD) 2.2 Periodic Audit Synchronization

Interface Functional Specification –

Interface Functional Specification –

Version 3.0 – September 24, 2010 9

Interface Functional Specification – 2.5 Billing Service Standard Interface – Reply

1.7 Conventions for Data Field Formats

Data Fixed Number (X) or Time

Version 3.0 – September 24, 2010 10

1.8 MDM/R FTS Use of File Names

1.8.1 Structure of MDM/R file names

Version 3.0 – September 24, 2010 11

1.8.2 File name elements common to all files

Version 3.0 – September 24, 2010 12

FILE ID File Type Comments

Version 3.0 – September 24, 2010 13

Element 4: FILE_VER (File Version)

1.8.3 File name elements specific to individual interface files

File ID 2000 – Universal SDP ID Assignment Response – Version 00

File ID 2000 – Universal SDP ID Assignment Response – Version 01

File ID 3000 – Periodic Audit Synchronization – Version 00

Version 3.0 – September 24, 2010 14

File ID 4000 – Incremental Synchronization – Version 00

Version 3.0 – September 24, 2010 15

File ID 5000 – Billing Quantities Request

File ID 5500 – Billing Service Standard Interface – Request

File ID 6000 – Billing Quantities Response (TOU/CPP & Periodic)

File ID 6100 – Billing Quantities Response (Hourly)