Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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
Related Documents
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
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
Reference
Description of Change
(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.
§ Business Rules – Rule No. 10
• 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
Reference
Description of Change
(Section and Page)
§ Business Rules – Rule No. 12
• 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
Section 2.2.8, Table Periodic Audit Synchronization Interface
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
Section 2.2.8, Table Periodic Audit Synchronization Interface
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
Section 2.2.8, Table Periodic Audit Synchronization Interface
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’
Section 2.2.8, Table Periodic Audit Synchronization Interface
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
Section 2.2.8, Table Periodic Audit Synchronization Interface
2.2.21, pages 66-67 § Relationship Data File Detail Record
• Updated description for End Date Time indicating
restriction to end date/time for Periodic Audit
Synchronization
Section 2.2.8, Table Periodic Audit Synchronization Interface
2.2.25, page 72 § Component SDP Channel to Formula Data File Detail Record
• Updated description for End Date Time indicating
restriction to end date/time for Periodic Audit
Synchronization
Section 2.3.1, page 77 Incremental Synchronization Interface
Reference
Description of Change
(Section and Page)
§ Updated Description to delete reference to the EnergyIP GUI as a
means to update master attribute data.
Section 2.3.2, page 79 Incremental Synchronization Interface
§ 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
§ Business Rules – Rule No. 12
• Revised conditions for submission of Current State
attribute values
§ Business Rules – Rule No. 15
• Revised conditions for submission of Current State
attribute values
Section 2.3.9, page 86 Incremental Synchronization Interface
§ 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
Reference
Description of Change
(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
Reference
Description of Change
(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
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)
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
IESO_SPEC_9027 SME_SPEC_0001
MDM/R V1.0– Detailed
Design
SME_DES_9001
SME_MAN_9001
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
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
Figure 1.9.1 MDM/R Timeline for Last Daily Read Period “N” included in a Billing Period
Advanced Metering
Regional Collectors Advanced Metering
Smart Meters – including (AMRCs) Control Computer Meter Data
Advanced Metering (AMCC) Management Repository
Communication Device (MDM/R)
(AMCD)
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
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).
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
described in tables 2.1.4 to 2.1.6.
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
2.1.8.2.1 File Name Record for the Universal SDP ID Assignment Response 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.4 File Name Record for the Universal SDP ID Assignment Response File
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.10.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.7 to 2.1.9.
The Universal SDP ID Assignment Response File contains all of the information
described in tables 2.1.10 to 2.1.13.
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.16.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.7 File Name Record for the Universal SDP ID Assignment Request File
2.1.16.2.1 File Name Record for the Universal SDP ID Assignment Response 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:
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.2.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text
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.
1
These threshold checks are disabled during initial loading of the synchronization and initial testing.
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>
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.01.02.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.01.02.DAT</FTSFN>
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.02.01.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.02.01.DAT</FTSFN>
2.2.8.4.1 File Name Record for the Service Agreement Data 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.2.10 FILE NAME RECORD FOR THE SERVICE AGREEMENT DATA FILE
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.03.01.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.03.01.DAT</FTSFN>
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)"
"Energy Purchase Service, Periodic 15 minute Block "MP Periodic 15 minute Block
“06” Periodic kWh and 15 minute Block Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"Periodic 60 minute Block (EST)"
"Energy Purchase Service, Periodic 60 minute Block "MP Periodic 60 minute Block
“07” Periodic kWh and 60 minute Block Demand calculations (EST)" Billing Quantities"
(EST) with kW77 Peak Demand (EST)
"Periodic 60 minute Block (CST)"
"Energy Purchase Service, Periodic 60 minute Block "MP Periodic 60 minute Block
“08” Periodic kWh and 60 minute Block Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"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)"
"Energy Purchase Service, Periodic 15 minute Rolling "MP Periodic 15 minute Rolling
“10” Periodic kWh and 15 minute Rolling Demand (CST)" Billing Quantities"
calculations (EST) with kW77 Peak Demand (CST)
"Periodic 60 minute Rolling (EST)"
"Energy Purchase Service, Periodic 60 minute Rolling "MP Periodic 60 minute Rolling
“11” Periodic kWh and 60 minute Rolling Demand (EST)" Billing Quantities"
calculations (EST) with kW77 Peak Demand (EST)
"Periodic 60 minute Rolling (CST)"
"Energy Purchase Service, Periodic 60 minute Rolling "MP Periodic 60 minute Rolling
“12” Periodic kWh and 60 minute Rolling Demand (CST)" Billing Quantities"
calculations (EST) with kW77 Peak Demand (CST)
"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"
(EST) with kW77 Peak Demand (EST)
"Hourly 15 minute Block (CST)"
"Energy Purchase Service, Hourly 15 minute Block "MP Hourly 15 minute Block
“14” Hourly kWh and 15 minute Block Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"Hourly 60 minute Block (EST)"
"Energy Purchase Service, Hourly 60 minute Block "MP Hourly 60 minute Block
“15” Hourly kWh and 60 minute Block Demand calculations (EST)" Billing Quantities"
(EST) with kW77 Peak Demand (EST)
"Hourly 60 minute Block (CST)"
"Energy Purchase Service, Hourly 60 minute Block "MP Hourly 60 minute Block
“16” Hourly kWh and 60 minute Block Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"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"
(EST) with kW77 Peak Demand (EST)
"Hourly 15 minute Rolling (CST)"
"Energy Purchase Service, Hourly 15 minute Rolling "MP Hourly 15 minute Rolling
“18” Hourly kWh and 15 minute Rolling Demand calculations (CST)" Billing Quantities"
(EST) with kW77 Peak Demand (CST)
"Hourly 60 minute Rolling (EST)"
"Energy Purchase Service, Hourly 60 minute Rolling "MP Hourly 60 minute Rolling
“19” Hourly kWh and 60 minute Rolling Demand calculations (EST)" Billing Quantities"
(EST) with kW77 Peak Demand (EST)
"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"
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.04.01.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.04.01.DAT</FTSFN>
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
prescribed MDM/R for informational purposes only.
Meter Phases Varchar (20) No format N N Phase of the Meter. Supplied to the
prescribed MDM/R for informational purposes only.
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.
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.05.01.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.05.01.DAT</FTSFN>
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
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.2.22 FILE NAME RECORD FOR THE COMPONENT SDP CHANNEL TO CHANNEL &
CHANNEL TO FORMULA DATA FILE
An example of this record for a Version 01 Periodic Audit Synchronization file would
be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcdef.07.02.DAT</FTSFN>
or
For a Version 00 Incremental Synchronization file:
<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.07. 02.DAT</FTSFN>
SDP Service
SDP Attributes SDP Life Cycle SDP Processing Services
Providers
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
SDP Service
SDP Attributes SDP Life Cycle SDP Processing Services
Providers
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
Dem-firm#2 YES NA NA O O O O O O O O O O O O O
Dem-firm#3 YES NA NA O O O O O O O O O O O O O
Dem-firm#4 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 - -
SDP Service
SDP Attributes SDP Life Cycle SDP Processing Services
Providers
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 - -
(physical or virtual SDP)
Member Interval Length
YES NA NA O O O - O - MV O MV O MV - -
(physical or virtual SDP)
Member Alias
YES NA NA O O O - O - MV O MV O MV - -
(physical or virtual SDP)
Formula Type
YES NA NA O O O - O - MV O MV O MV - -
(Target virtual channel)
Formula Expression
YES NA NA O O O - O - MV O MV O MV - -
(Target virtual channel)
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.2 Integration
2.3.2.1 Direction
LDC to the MDM/R
2.3.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text
files.
2.3.4 Pre-conditions
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 has requested and has been assigned a Universal SDP ID for
each SDP in the Incremental Synchronization File.
2.3.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.
Part 2: (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.)
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.)
Part 3: (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.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.
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
2.4.2.1 File Direction
LDC or their Billing Agent to the MDM/R
2.4.2.2 Characteristics
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.4 Pre-conditions
The following must exist for the input file to be processed through the interface:
§ 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.
2.4.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.
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/
<Attribute> Format Required Description
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.
<FTSFN>ORG12345.ORG12345.5500.00.20100819233017</FTSFN>
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.
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.
Section 7 of the MDM/R Detailed Design Document, Framing of Billing Quantities
discusses the framing of Billing Quantity data.
2.5.2 Integration
2.5.2.1 File Direction
MDM/R to the LDC or Billing Agent
2.5.2.2 Characteristics
This is a batch process involving the transfer and processing of the EnergyIP Billing
Service Standard Interface ReplyMessage files in an .xml file format.
2.5.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.
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:ReplyMessage>
<tns:ReplyMessage> Specific Usage: Y Location of the xml name space
xmlns=“http:/www.
emeter.com/energyip/
readsforbillinginterface
2”
Data Type/
<Attribute> Format Required Description
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/
<Attribute> Format Required Description
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.
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)
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>
2.6.2 Integration
2.6.2.1 File Direction
LDC or their Billing Agent to the MDM/R
2.6.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text
files.
2.6.4 Pre-conditions
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 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.
2.6.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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
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
Field Format Required Description
Type/Length
Record Type Char(2) General: Y To indicate that this record is
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.
2.7.2 Integration
2.7.2.1 Direction
MDM/R to the LDC or their Billing Agent
2.7.2.2 Characteristics
This is a batch process involving the transfer of pipe (|) delimited text files.
2.7.4 Pre-conditions
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.
§ 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.
2.7.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ A Billing Quantity Response File has been sent to the Organization
associated with the Data Delivery Service.
§ 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.
2.7.6 Assumptions
None
2.7.8.1.1 File Name Record for the TOU/CPP & Periodic Billing Quantity Response 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.7.1 FILE NAME RECORD FOR THE TOU/CPP & PERIODIC BILLING QUANTITY
RESPONSE FILE
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 /
Field Format Required Description
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.
Data Delivery Char(8) General : Y The identifier assigned to the
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.
Data Type /
Field Format Required Description
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
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.
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
Data Type /
Field Format Required Description
Length
Record Type Char(2) General: Y To indicate that this record is
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”
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
Identifier Quantities, Y if the LDC or Billing Agent had supplied
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 PERIODIC 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.
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
included in billing quantities for the
SDP.
The end date is an exclusive end
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
Table 2.7.6 FILE NAME RECORD FOR THE HOURLY BILLING QUANTITY RESPONSE FILE
Data Type /
Field Format Required Description
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 : during the MDM/R
ORG82357 Registration/Enrollment process. The
LDC creates SDPs and thus owns
those Service Delivery Points.
Data Type /
Field Format Required Description
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”
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
Identifier Quantities, Y if the LDC or Billing Agent had supplied
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 Response Daily Read Period
Read Period date for this specific HOURLY Billing
Date Quantity Response Record for the
requested SDP.
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.
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
associated with the SDP in the MMD.
This value will be equal to the LDC’s
Organization ID+the Billing Cycle ID
This field will contain a null value for
Requested “PULL” responses.
Universal SDP Fixed Number NNNNNNNN Y The Universal SDP ID that is
ID (8) associated with the Billing Quantity.
Framing Varchar (12) General: Y The Framing Structure associated
Structure AAAAAA with the Service Delivery Point.
In this record the value should
2.7.10 Integration
2.7.10.1 Direction
MDM/R to the LDC or their Billing Agent
2.7.10.2 Characteristics
This is a batch process involving the transfer of pipe (|) delimited text files.
B) kW Demand Determinations
The following MMD master data condition must exist for the calculation of kW demand
quantities:
2.7.12 Pre-conditions
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.
§ For PUSH requests, the LDC or Billing Agent has provided the MDM/R with a
Billing Cycle Schedule.
2.7.13 Post-conditions
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.
§ 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.
2.7.14 Assumptions
None.
Table 2.7.9 FILE NAME RECORD FOR THE DEMAND BILLING QUANTITY RESPONSE FILE
Data Type /
Field Format Required Description
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 : during the MDM/R
ORG82357 Registration/Enrollment process. The
LDC creates SDPs and thus owns
those Service Delivery Points.
Data Delivery Char(8) General : Y The identifier assigned to the
Service AAAAAAAA Organization that is providing Billing
Organization Services for the LDC (this may be the
Identifier Example : 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.
Data Type /
Field Format Required Description
Length
Record Type Char(2) General: Y To indicate that this record is
Identifier AA Demand related Detail record in the
2.17.1.1 File Name Record: TOU/CPP & Periodic Billing Quantity Response File
An example of this record Version 01 would be:
<FTSFN>ORG11111.ORG22222.6000.01.20070214221345.DAT</FTSFN>
NOTE: Please reference Section 1.8.2 for use of file format version number.
2.8.2 Integration
2.8.2.1 Direction
LDC to the MDM/R
2.8.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text
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)
2.8.4 Pre-conditions
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.
2.8.5 Post-conditions
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
Data
Field Format Required Description
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.
2.9.2 Integration
2.9.2.1 Direction
MDM/R to the LDC
2.9.2.2 Characteristics
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.
2.9.4 Pre-conditions
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.
2.9.5 Post-conditions
The following outcome results from the file being processed through the interface:
• 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.
Field Data
Format Required Description
Name Type/Length
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 file
Section 1.8 on the originating system
Suffix Char (8) Specific Y This field always contains the record
Usage: type “</FTSFN>”
</FTSFN>
2.9.8.2.1 File Name Record for the Data Aggregation Contributors 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.9.4 FILE NAME RECORD FOR THE DATA AGGREGATION CONTRIBUTORS FILE
Field Data
Format Required Description
Name Type/Length
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 file
Section 1.8 on the originating system
Suffix Char (8) Specific Y This field always contains the record
Usage: type “</FTSFN>”
</FTSFN>
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.
Intervals with validation status VAL will include
Change Methods: NULL or VER.
Intervals with validation status EST will include
Change Methods: NULL; ESA: ESB; ESC; ESD;
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)’
Intervals with validation status VAL will include
Change Methods: NULL or VER.
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)’
Intervals with validation status EST will include
Change Methods: NULL; ESA: ESB; ESC; ESD;
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.2 Integration
2.10.2.1 Direction
MDM/R Users to the MDM/R
MDM/R to the MDM/R Users
2.10.2.2 Characteristics
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.5 Post-conditions
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)
Data Type/
Field <Tag> 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
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/
</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.
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
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.2 Integration
2.11.2.1 Direction
AMCC to the MDM/R
2.11.2.2 Characteristics
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
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.
9. For meters not used for net metering and used for the determination of
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.
10. For meters not used for net metering and used for the determination of
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.
2.11.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.
Table 2.11.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SENSUS
CMEP Data
Format Required Description
Field Name Type/Length
Record Type Varchar (7) General : Y This field will always contain
AAAAAAA “MEPMD01”
Specific Usage:
“MEPMD01”
Table 2.11.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus
2.12.2 Integration
2.12.2.1 Direction
AMCC to the MDM/R
2.12.2.2 Characteristics
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.12.2 –
“Count”). This maximum establishes the longest Meter Transfer Block permissible
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.
9. For meters not used for net metering and used for the determination of
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.
10. For meters not used for net metering and used for the determination of
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.
2.12.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.12.3 via File
Transfer Services.
2.12.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.
CMEP Data
Format Required Description
Field Name Type/Length
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
Version yyyyMMdd date. The current version being
supported is “20080130”
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
Specific Usage: been replaced by use of the MDM/R
FTS file name. For Sensus2: FILE ID =
‘Sensus’
7001
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
Table 2.12.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 Sensus2 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.12.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus2
2.13.2 Integration
2.13.2.1 Direction
AMCC to the MDM/R
2.13.2.2 Characteristics
This is a batch process involving the transfer and processing of XML 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 received from the AMCC shall contain:
§ A series of interval data
§ A register read within or at the end of the Meter Transfer Block
§ Data quality indicators
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.
Rules Affecting Meter Read Processing for SDPs Requiring Demand Determination
8. 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 interval
consumption data and register read data transmitted by the meter.
9. 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.
10. For meters not used for net metering and used for the determination of
demand, if programmed to record kilovolt-ampere-reactive hours, meters will
be programmed to measure active kVARh quantities delivered, Power Factor
lagging (inductive), transmitted as positive quantities. This will apply to both
interval consumption data and register read data.
11. For meters not used for net metering and used for the determination of
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.
2.13.4 Pre-conditions
The following must exist for the input file to be processed through the interface:
2.13.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.13.3 via File
Transfer Services.
2.13.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.
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
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.
The AMRDEF Reference Release 6.0 – AMRDEF Export Format is used to supply the
MDM/R with interval data as follows in table 2.13.3.
TABLE 2.13.3 INTERVAL DATA ELEMENTS AND ATTRIBUTES
AMRDEF Reference
Data
(Release 6.0) Format Required Description
Type/Length
Element/Attribute Name
<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.
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
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.
<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”
For VA-hours valid values are:
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
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.
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.
The AMRDEF Reference Release 6.0 – AMRDEF Export Format is used to supply the
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
(Release 5.7) Format Required Description
Type/Length
Element/Attribute Name
<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.
Table 2.13.5 A3 ALPHA Meter Status indicating Data that Should Not be used for Billing
(MeterType = “A3” and “A3_Collector”)
Table 2.13.6 A3 ALPHA Node Status indicating Data that Should Not be used for Billing
(MeterType = “A3_ILN”)
Table 2.13.7 REX Meter Status indicating Data that Should Not be used for Billing
(MeterType = “REX”)
30 Meter Health Registered Memory Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
is subject to the Meter Diagnostic Validation check.
33 Meter Health EEPROM Access Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
is subject to the Meter Diagnostic Validation check.
34 Meter Health Meter Chip Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
is subject to the Meter Diagnostic Validation check.
72 Meter Health Radio Config Error EnergyIP MtrDiagError/METER_RESET Flag is set, data
is subject to the Meter Diagnostic Validation check.
2.14.2 Integration
2.14.2.1 Direction
AMCC to the MDM/R
2.14.2.2 Characteristics
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 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. 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.14.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.
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.
9. For meters not used for net metering and used for the determination of 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.
10. For meters not used for net metering and used for the determination of 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.
2.14.4 Pre-conditions
The following must exist for the input file to be processed through the interface:
§ The LDC is enrolled and has an Organization ID assigned.
§ The LDC has requested and received Universal SDP IDs for each SDP in
the Meter Read File.
2.14.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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 agents receive interim and final summary
and detailed exception reports as outlined in Section 2.14.3 via File
Transfer Services.
2.14.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.
Table 2.14.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TRILLIANT
CMEP Data
Format Required Description
Field Name Type/Length
Record Type Varchar (7) General : Y This field will always contain
AAAAAAA “MEPMD01”
Specific Usage:
“MEPMD01”
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 “Trilliant”.
AAAAAAAAAA
NOTE: The function of this field has
Specific Usage: been replaced by use of the MDM/R
FTS file name. For Trilliant: FILE ID =
‘Trilliant’
7200
Table 2.14.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
Table 2.14.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Trilliant
2.15.2 Integration
2.15.2.1 Direction
AMCC to Meter Read Translator to the MDM/R Trilliant Meter Read Interface
2.15.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files.
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.
§ 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. All register
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.
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.
2.15.4 Pre-conditions
Please see Section 2.14.4 – Pre-Conditions for the Meter Read Interface (Trilliant).
2.15.6 Assumptions
Please see Section 2.14.6 – Assumptions for the Meter Read Interface (Trilliant).
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.
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.
Sensus2 Data Quality Flag Sensus2 Trilliant Data Quality Flag Required
EnergyIP Flag
Description CMEP Flag Description CMEP Flag
Error free interval R0 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 N32 Missing data for the interval N 00 04 NO_DATA
Overflow R512 Overflow consumption R 00 08 PULSE_OVERFLOW
(not available) - Partial data in the interval R 00 10 PARTIAL_INTERVAL
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
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.
Tantalus Data Quality Flag Sensus2 Trilliant Data Quality Flag Required
EnergyIP Flag
Description CMEP Flag Description CMEP Flag
Normal raw data 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
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) - Partial data in the interval R 00 10 PARTIAL_INTERVAL
(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
2.16.2 Integration
2.16.2.1 Direction
AMCC to the MDM/R
2.16.2.2 Characteristics
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 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. 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.16.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.
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.
9. For meters not used for net metering and used for the determination of
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.
10. For meters not used for net metering and used for the determination of
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.
2.16.4 Pre-conditions
The following must exist for the input file to be processed through the interface:
§ The LDC is enrolled and has an Organization ID assigned.
§ The LDC has requested and received Universal SDP IDs for each SDP in
the Meter Read File.
2.16.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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.16.3 via File
Transfer Services.
2.16.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.
Table 2.16.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TANTALUS
CMEP Data
Format Required Description
Field Name Type/Length
Record Type Varchar (7) General : Y This field will always contain
AAAAAAA “MEPMD01”
Specific Usage:
“MEPMD01”
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 “Tantalus”.
AAAAAAAAAA
NOTE: The function of this field has
Specific Usage: been replaced by use of the MDM/R
FTS file name. For Tantalus: FILE ID =
‘Tantalus’
7300
Table 2.16.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Tantalus
2.17.2 Integration
2.17.2.1 Direction
AMCC to the MDM/R
2.17.2.2 Characteristics
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 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. 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.17.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.
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.
9. For meters not used for net metering and used for the determination of
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.
10. For meters not used for net metering and used for the determination of
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.
2.17.4 Pre-conditions
The following must exist for the input file to be processed through the interface:
§ The LDC is enrolled and has an Organization ID assigned.
§ The LDC has requested and received Universal SDP IDs for each SDP in
the Meter Read File.
2.17.5 Post-conditions
The following outcome results from the file being processed through the interface:
§ 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 agents receive interim and final summary
and detailed exception reports as outlined in Section 2.17.3 via File
Transfer Services.
2.17.6 Assumptions
§ MDM/R will only process Meter Read data that is related to smart meters.
Table 2.17.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SMARTSYNCH
CMEP Data
Format Required Description
Field Name Type/Length
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
Version yyyyMMdd date. The current version being
supported is “19970819”
Example: The SmartSynch adaptor will not
19970819 validate this field.
or The Record Version field may be “null”.
“null”
Table 2.17.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
Table 2.17.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for
SmartSynch TMS
– End of Document –