Meter Data Management and
Repository
MDM/R
Technical Interface Specifications
Version 3.3
07 July 2011
Version 3.3 – July 7, 2011 § i
Disclaimer
The posting of documents on this Web site is subject to the terms and conditions posted on the
SMSIP Web site. Please be advised that, while the IESO-SMSIP attempts to have all posted
documents conform to the original, changes can result from the original, including changes
resulting from the programs used to format the documents for posting on the Web site as well as
from the programs used by the viewer to download and read the documents. The IESO-SMSIP
makes no representation or warranty, express or implied, that the documents on this Web site
are exact reproductions of the original documents listed. In addition, the documents and
information posted on this Web site are subject to change. The IESO-SMSIP may revise,
withdraw or make final these materials at any time at its sole discretion without further notice. It
is solely your responsibility to ensure that you are using up-to-date documents and information.
Status of these Specifications
This document was put under formal change control on July 31, 2007. As of Version 3.3 specific
elements of Section 2.4 have been placed in a status of “design review”. These elements have
been highlighted in “yellow” indicating that active review and verification activities are underway,
and these elements may be subject to revision. The following elements are affected:
Section 2.4 – Billing Service Standard Interface Request
•
Table 2.4.3 <RequestMessage> / <Header> / <Source>. This element currently enables
the SDP to Billing Agent Relationship without providing a positive control mechanism.
Version 3.3 – July 7, 2011 ii
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 ... 126
2.6
Billing Quantity Request ... 150
2.7
Billing Quantity Response ... 156
2.8
Billing Cycle Schedule Interface... 191
2.9
Aggregated Settlement Data ... 195
2.10
Meter Reads Retrieval Web Services Request/Reply ... 202
2.11
Meter Read Interface (Sensus) ... 214
2.12
Meter Read Interface (Sensus2) ... 225
2.13
Meter Read Interface (Elster) ... 236
2.14
Meter Read Interface (Trilliant) ... 251
2.15
Meter Read Transformation for Transmission via Trilliant CMEP Interface ... 261
2.16
Meter Read Interface (Tantalus) ... 269
2.17
Meter Read Interface (SmartSynch) ... 280
Version 3.3 – July 7, 2011 iii
Related Documents
Document Title
Issue Date
IESO_DES_9001: MDM/R V1.0 Detailed Design – Version 2.0
30 April 2008
SME_SPEC_0001: MDM/R V1.0 Reports Technical Specifications –
Version 3.0
29 April 2010
IESO_STD_0078: MDM/R VEE Standard for the Ontario Smart
Metering System – Issue 4.1
March 1, 2011
SME_MAN_0005: MDM/R Meter Data Management and Repository
(MDM/R) TOU Schedule and Calendar Manual – Issue 2.0
December 19, 2008
MDM/R File Transfer Services and Web Services Configuration
Workbook – Version 1.0
October 15, 2008
MDM/R Service and Performance Levels
Issue 2.0, December 14, 2006
MDM/R Business Process Descriptions
Issue 2.0, December 14, 2006
Ontario Regulation 440/07: Functional Specifications for an
Advanced Metering Infrastructure, Version 2
July 5, 2007
Ontario Regulation 233/08: Designation of Smart Metering Entity
Made: June 17, 2008
Measurement Canada General Bulletin: GEN-25-E, Policy on the
Approval, Initial Verification, and Reverification for Electricity and
Gas Meters: Legal Units of Measurement and Functions used for
Billing
Date: 2000-06-26
Measurement Canada General Bulletin: GEN-31-E (rev.1), Policy
on Multirate Register Metering
Issue Date: 2010-02-10
Effective Date: 2010-04-01
California Metering Exchange Protocol Version 1.20 – Update for
EDI DASR compatibility
March 7, 2000
Elster EnergyAxis® Management System
AMR Data Exchange Format Reference Release 7.0
2010 January 5
Sensus Meter Systems
Extended CMEP File Format, Version 0.87
July 28, 2008
SmartSynch – IESO Interface – MDM/R Interface Specification
SSI Document # RQ-062009-0006, Revision 2
Version 3.3 – July 7, 2011 iv
Table of Changes
The following is a summary of changes to this document from version 3.2 dated 2 June 2011.
Reference
(Section and Page)
Description of Change
Section 2.4, Section
2.4.3, page 116
Billing Service Standard Interface – Request Business Rules
§ Added new Business Rule 8. – Rules Affecting Register Reading
Changes in Prior Billing Periods.
Section 2.5, Section
2.5.3, pages 128
Billing Service Standard Interface – Reply Business Rules
§ Business Rule 3.d, Minor edit of logical meter change defined, for
clarity
Section 2.5, Section
2.5.8.2, pages 139,
140, 141-142, 147-149
Billing Service Standard Interface – Reply Output File
§ Table 2.5.5 – ReplyMessage/MeterReadings
•
Updated <MeterReading> / <Reading> /
<measurementSource>
§ Deleted ‘KWH Est Usage’ specific usage from
Format and Description.
•
Updated <MeterReading> / <Reading> / <readingTypeId>
§ Added ‘KWH Usage BC’ to the Measurements that
will be returned with TOU Billing Quantities and
Hourly Billing Quantities.
§ Deleted ‘KWH Est Usage’ as a Measurement
returned in each Reply, adding a note that the
estimated interval data total kWh will be returned
for each usage reading as a <Quality>
<estimatedUsage> attribute. To be delivered as
part of EnergyIP R7.2 SP7.
•
Updated <MeterReading> / <Reading> / <validationCode>
Description to indicate presence of this attribute for ‘KWH
Usage BC’.
•
Updated <MeterReading> / <Reading> / <validationStatus>
Description delete reference to Hourly measurement..
•
Updated <MeterReading> / <Reading> / <Quality>
§ Added new <estimateUsage> attribute which will
provide the total kWh quantity of estimated interval
data associated with each usage reading.
§ Added new attributes <numEstIntervals> and
<numIntervals> indicating these attributes a
reserved for future use.
•
Updated description of the <IReading> element adding
Note 2 indicating provision of ‘KWH Usage BC’ and
<estimatedUsage> associated with each Hourly reply in the
<Reading> block of the reply message.
§ Sample Request Message File-based Output
•
Updated sample to add <estimatedUsage> attribute.
Version 3.3 – July 7, 2011 v
Reference
(Section and Page)
Description of Change
•
Updated sample to delete ‘KWH Est Usage’ reading.
Section 2.10, Section
2.10.8, page 212
Meter Reads Retrieval Web Services Request/Reply
§ Table 2.10.3 – Measurement Profiles MP01, MP02, MP04
•
Updated ‘readingTypeIds’ to correct Measurement literal
returned for ‘KWH Est Usage’.
Version 3.3 – July 7, 2011 1
1 Introduction
1.1
Purpose
This document defines the technical interface specifications for the Meter Data
Management and Repository (“MDM/R”). The specifications in this document provide
the detailed format of the interfaces associated with the integration of the MDM/R with
various external systems.
The specifications in this document will be used to complete the required integration of
various external systems with the MDM/R including those belonging to Local
Distribution Companies, and other Interested Parties.
1.2
Document Scope
The scope of this document is limited to the integration specifications between the
MDM/R and various external data systems, including:
§ The specific file formats of the integrations
§ Specific web service definitions that provide external interface into the
MDM/R.
This document does not define the overall design and the internal behaviour of the
MDM/R itself or the technical design and configuration of the File Transfers Services
described in Section 11, File Transfer Services of the MDM/R Detailed Design
Document.
1.3
Assumptions and Limitations
This specification assumes:
1. MDM/R will process Meter Read data that is produced by smart meters that
conform to the criteria described in the Functional Specification for an
Advanced Metering Infrastructure.
2. Meter Reads for Small Volume Consumers where there is no requirement to
meter demand will be transmitted as hourly data taken at the end of each
hour.
3. Meter Reads for Commercial & Industrial Consumers where metering of
demand is required will be transmitted as one of 5, 15, or 60 minute data
taken at the end of each interval.
4. The LDC will ensure that the Smart Meter is providing correct data through
the AMI to the MDM/R.
5. The LDC will determine when a meter is ready for billing. The use of Billing
Quantity data provided by the MDM/R to the LDC for the purpose of billing is
entirely under the control of the LDC.
6. The MDM/R will process Meter Read files that are in any of the AMCC
formats deployed in Ontario in a uniform format for each AMCC technology.
7. Meter Read data received from meters for which no relationship to a SDP
has been established in the MDM/R Master Directory (MMD) will be rejected
and must be re-transmitted by the LDC after the Meter ID to SDP relationship
Version 3.3 – July 7, 2011 2
has been established in the MMD using either the synchronization interface
or by direct entry using the EnergyIP Graphical User Interface.
8. Daily framing of Billing Quantities will only occur within complete calendar
(EST) days.
9. Billing quantities will be inclusive of the first interval of the first Daily Read
Period through the last interval of the last Daily Read Period included in any
Billing Quantity Response.
10. The majority of SDPs for any LDC are expected to be framed as TOU/CPP
with Billing Quantity data delivered as TOU/CPP consumption for the period.
11. SDPs framed as Hourly by any LDC for the purpose of spot pricing are
expected to be a small percentage of the total SDPs. Billing Quantity data
will be delivered as Hourly consumption data for each day.
12. SDPs for Retailer Customers are expected to be initially framed as Periodic
with Billing Quantity data delivered as consumption for the period. Migration
of SDPs for Retailer Customers to Hourly Framing is expected to rise over
time to the number of Customers currently enrolled with Retailers across the
province of Ontario.
13. References to “future delivery” are not included within the scope of the initial
delivery of the MDM/R solution.
1.4
Definition of Terms
Terms used within this document have been defined in Table 1.4.1 below.
Table 1.4.1 – Definitions
TERM
Description
AMCC
AMCC means the Advanced Metering Control Computer that is
used to retrieve or receive and temporarily store Meter Reads
before or as they are being transmitted to the MDM/R. The
information stored in the AMCC is available to log maintenance
and transmission faults and issue reports on the overall health of
the AMI to the LDC.
AMI
AMI means the Advanced Metering Infrastructure, it includes the
meter, Advanced Metering Communication Device (AMCD), Local
Area Network (LAN), Advanced Metering Regional Collector
(AMRC), Advanced Metering Control Computer (AMCC), Wide
Area Network (WAN), and related hardware, software, and
connectivity required for a fully functioning data collection system.
An AMI does not include the MDM/R.
API
API means an Application Program Interface, which is the interface
(calling conventions) application program used for accessing
services provided by another module.
AS2
AS2 means Applicability Statement 2 and is a specification of the
Electronic Data Interchange over the Internet (EDIINT) working
group of the Internet Engineering Task Force (IETF).
Billing Quantity
Refers to consumption data that has been through VEE and
Framing and is ready for use in billing.
Block Demand
Calculated kVA and/or kW demand based on a time period with
fixed boundaries, such as one hour (e.g. 16:00 to 17:00)
Version 3.3 – July 7, 2011 3
TERM
Description
CIS
The Customer Information System, in which Customer account
information is held.
CST
Central Standard Time
Consumer or
Customer
Refers to residential or small general service consumers where the
metering of demand is not required.
CPP
Refers to specific rate structures called Critical Peak Pricing.
Under these structures, the price of electricity is variable. Such an
occurrence will typically occur when wholesale prices for electricity
are very high due to constrained supply. One or more of the TOU
rating periods will be used to track a Consumer’s electricity
consumption during CPP events.
Daily Read Period
Means the 24-hour period for collecting Meter Reads, subject to
the two periods during which changes to and from Daylight
Savings Time take place. The Daily Read Period commences at
12:00 midnight each day.
EnergyIP
Rebranding of the PIPe product name. The Meter Data
Management system developed by eMeter Inc that forms the
foundation for the MDM/R solution. (Please see the definition of
PIPe below.)
EST
Eastern Standard Time
File Transfer
Service or FTS
The service which manages the transfer of files between the
MDM/R and LDCs and/or the LDC’s authorized agents.
Firmographic
/Demographic
Basic profiling information about business organizations and
individuals, respectively. Firmographic data is more relevant for
business-to-business transactions involving automated electronic
data exchange between businesses or trading partners; they do
not typically involve Customers.
Framing
The process by which interval data is assembled into Billing
Quantities.
Framing Structure
Framing Structure means a parameter that denotes the method by
which Meter Reads are assembled into Billing Quantities by the
MDM/R.
GUI
Graphical User Interface. The most commonly used type of
computer interface, exemplified by Microsoft Windows and MacOS.
Typical elements of a GUI are a mouse interface and a system of
visual directories that look like file folders.
Interested Party
Those entities that are authorized to access specific data from the
MDM/R.
IVR
Interactive Voice Response - A computerized system that allows a
person, typically a telephone caller, to select an option from a voice
menu and otherwise interface with a computer system.
kVAh
Kilovolt-ampere hour
kVARh
Kilovolt-ampere-reactive hour
kWh
Kilowatt hour
kW77 Peak
Demand
Calculated kVA and/or kW demand in the period between 7:00
a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory
holidays within a billing period.
Version 3.3 – July 7, 2011 4
TERM
Description
LDC
Means a Local Distribution Company, which is an LDC, as defined
in the Ontario Energy Board Act, 1998
Meter Read
Is a number generated by a meter that reflects cumulative
electricity consumption at a specific point in time. (The Meter Read
and related data will be reported to the MDM/R at a specific
Service Delivery Point.)
Meter Read Block
Meter Read Block is used by the MDM/R for validation and
estimation purposes. All validation and estimation functions are
based on acting upon a set of contiguous intervals bounded by a
start register read and a stop register read. In some instances a
Meter Read Block may span two or more Meter Transfer Blocks.
For a Meter Transfer Block consisting of interval consumption data
with a register reading at the end of a set of interval consumption
data, the start register read for the Meter Read Block will be the
immediately preceding (contiguous) stop register read
Meter Transfer
Block
Meter Transfer Block is a set of data transferred from an AMCC (or
other system) to the MDM/R relating to Meter Reads for a specific
Universal SDP ID. A Meter Transfer Block is a set of interval
consumption data with a register reading at the end of the set of
interval data, or a set of interval register reads for a number of
contiguous intervals.
MDM/R
Means the meter data management and meter data repository
functions within which Meter Reads are processed to produce
Billing Quantity data and the storage of data for future use.
MDM/R
Administrator
An administrator of the MDM/R system. This may be a person
from the OSP or the Smart Meter Entity (SME) depending on the
task involved.
MMD
Means the MDM/R Master Directory, which is a portion of the
MDM/R that contains the data relationship among the Meter Read
data received from the AMCC and the Service Delivery Point.
Organization ID
A unique Identifier for an organization that will be assigned within
the MDM/R during the registration process. Examples of
organizations include LDC, billing agents, AMI operators and
Retailers.
OSP
Operational Service Provider.
Rolling Demand
Calculated kVA and/or kW demand based on calculations from
sub-interval data over a rolling period such as 60 minutes.
PIPe
Power Information Platform by eMeter - The Meter Data
Management system developed by eMeter Inc that will form the
foundation for the MDM/R solution. (See also EnergyIP)
RPP
Regulated Price Plan (RPP) for Consumers that sets out the prices
per kWh that local electricity utilities charge for electricity use.
SDP
Service Delivery Point means the point at which delivery is
metered or calculated. The SDP is the point at which billing occurs
based on input from one or more smart meters.
SDP ID
Service Delivery Point Identifier - The LDC supplied and controlled
identifier that relates to the SDP. It can be an existing identifier (or
combination of identifiers) that is unique within the LDC’s systems
and relates to the SDP within the MDM/R.
Version 3.3 – July 7, 2011 5
TERM
Description
SDP REF
Service Delivery Point Reference - The unique EnergyIP internal
identifier for each Service Delivery Point. It is assigned by the
EnergyIP system as a Service Delivery Point is created for the first
time.
SSL
Secure Sockets Layer - A cryptographic protocol which provides
secure communications on the Internet.
SOAP
Simple Object Access Protocol – A protocol for exchanging XML
based messages over computer networks normally using Http.
TOU
Time of Use - The sale of electricity based on rates established for
certain times of day, days of week, and/or season of year. For
billing purposes, Hourly Meter Reads are grouped into a number of
rating periods, in accordance with the rate structure, to enable the
recording of consumption at certain times of the day, week, or
year.
Universal SDP ID
Universal Service Delivery Point Identifier – The MDM/R unique
identifier by which authorized Parties interact with the Service
Delivery Point. This identifier will be provided to the LDC in the
“Universal SDP ID Assignment Response” file. The Universal SDP
ID is unique across the province.
VEE
Means Validation, Estimating and Editing of Meter Reads to
identify and account for missed and inaccurate Meter Reads to
derive billing data. The algorithm to complete VEE identifies gaps
in Meter Reads and rebuilds consumption based on historical
trending and averaging.
WPG
WebSphere Partner Gateway - provides the platform for the
MDM/R to manage the business to business (B2B) transactions for
file transfer and translations
1.4.1
Integration Terminology
TERM
Description
Request/Response
An asynchronous pair of related data flows
Request/Reply
A synchronous pair of related data flows
Send
An asynchronous one-way flow of data
1.5
Organization of this Document
The Technical Interface Specifications Document is comprised of individual sections
that lay out the technical interface specifications for each interface.
The following interfaces are defined in this document:
•
Section 2.1: Universal SDP ID Assignment Request/Response Interface
•
Section 2.2: Periodic Audit Synchronization Interface
•
Section 2.3: Incremental Synchronization Interface
•
Section 2.4: Billing Service Standard Interface – Request
•
Section 2.5: Billing Service Standard Interface – Reply
Version 3.3 – July 7, 2011 6
•
Section 2.7: Billing Quantity Response
•
Section 2.8: Billing Cycle Schedule Interface
•
Section 2.9: Aggregated Settlement Data
•
Section 2.10: Web Services Request/Reply
•
Section 2.11: Meter Read Interface (Sensus)
•
Section 2.12: Meter Read Interface (Sensus2)
•
Section 2.13: Meter Read Interface (Elster)
•
Section 2.14: Meter Read Interface (Trilliant)
•
Section 2.15: Meter Read Transformation for Transmission via Trilliant CMEP
Interface
•
Section 2.16: Meter Read Interface (Tantalus)
•
Section 2.17: Meter Read Interface (SmartSynch)
•
Section 2.18: Universal Meter Read Interface
Each interface section has a common layout, as follows:
•
Description
•
Integration
•
Business Rules
•
Pre-conditions
•
Post-conditions
•
Assumptions
•
Frequency and Timing
•
File Formats
1.6
Document Relationships
1.6.1
Related Documents Overview
This document is part of a library that specifies the design, functions and technical
interfaces belonging to the Meter Data Management/Repository (MDM/R). This library
is comprised of the following documents:
1) Meter Data Management and Repository MDM/R V1.0 Detailed Design
(the “Detailed Design”): This document sets out the design of the MDM/R
in accordance with the MDM/R Functional Specification that forms part of the
“MDM/R Specification” document series (described below).
2) Meter Data Management and Repository MDM/R V1.0 Technical
Interface Specifications (the “Technical Interface Specification”): This
document describes the format and content of all file-based technical
interfaces between the MDM/R and various authorized, interested parties.
The Technical Specifications for reports are included in item 4 below.
3) MDM/R File Transfer Services and Web Services Configuration
Workbook: This document is an aide to assist Organizations with their AS2
configurations for file transfers to and from the MDM/R.
4) Meter Data Management and Repository MDM/R V1.0 Reports Technical
Specifications: This document describes the format and content of MDM/R
generated standard and exception reports.
Version 3.3 – July 7, 2011 7
The documents in this library were preceded by the publication of the “MDM/R
Specification” document series, produced by the IESO’s Smart Metering System
Implementation Program (SMSIP). The MDM/R Specification, is a series of documents
developed for the procurement and functional specification of the MDM/R, and includes
the following documents:
1) MDM/R Functional Specification – IESO_SPEC_0241: This document
sets out the functional description of the Meter Data Management and
Repository functions.
2) MDM/R Business Process Description – IESO_SPEC_0240: This
document contains a high-level view of the major business process areas
identified in the, “MDM/R Functional Specification”
3) MDM/R Logical Application and Data Architecture (LADA) –
IESO_ARCH_0008: This document sets out an overview of a logical
architecture for the applications, data and inter-dependencies related to the
Smart Metering System (in general) and the Meter Data Management
Repository (specifically).
4) MDM/R Service and Performance Levels – IESO_SPEC_0239: This
document sets out the volumetric projections, and corresponding
expectations for service and performance for the MDM/R.
The MDM/R Specification document series is available from the SMSIP website
(
http://www.smi-ieso.ca
). The interrelationships between these various documents are
Version 3.3 – July 7, 2011 8
Figure 1.6.1 – Interrelationships between MDM/R Documents
MDM/R Document Library for Design, Functions, and Technical Interfaces
MDM/R V1.0– Detailed Design
SME_DES_9001
MDM/R Specification Document Series
(authored by IESO for MDM/R Procurement)
MDM/R V1.0 Technical Interface Specifications Document
IESO_SPEC_9027
Design and Functional
Description Technical Interface Description
MDM/R V1.0 Reports Technical Specifications SME_SPEC_0001 MDM/R Logical Applications and Data Architecture IESO_ARCH_0008 MDM/R Service and Performance Levels IESO_SPEC_0239 Functional Description to be accommodated by the MDM/R design MDM/R Functional Specification IESO_SPEC_0241 Functions to be accommodated Business Processes to be Logically supported by the MDM/R solution space MDM/R Business Process Description IESO_SPEC_0240 Business Processes to be supported by the MDM/R solution MDM/R File Transfer Services and Web Services Configuration Workbook
SME_MAN_9001
1.6.2
Subject Cross-reference: MDM/R Design and Functionality to
Technical Interfaces
As described earlier, the Detailed Design provides a functional overview to the design,
including each of the information flows that are supported by an MDM/R Technical
Interface. All technical interfaces are described from a functional standpoint in section
15 of the Detailed Design. Most of these MDM/R Technical Interfaces are supported by
the form and content of file-based transfers which are described in the Technical
Interface Specifications.
Table 1.6.1 below cross-references the major subjects described in the Detailed
Design with the Technical Interface Specifications.
Version 3.3 – July 7, 2011 9
Table 1.6.1: Cross Reference between Detailed Design subject matter, the Technical Interface
Specifications
Meter Data Management and Repository
Detailed Design
Meter Data Management and Repository
Technical Interface Specifications
Section Subject Matter Section Subject Matter3 Service Delivery Point
2.1 Universal SDP ID Assignment Request Response Interface
2.2 Periodic Audit Synchronization 2.3 Incremental Synchronization 4 MDM/R Master Data (MMD)
Synchronization
2.2 Periodic Audit Synchronization 2.3 Incremental Synchronization
5 Meter Data Collection and Processing
2.11 Meter Reads Interface – Sensus 2.12 Meter Reads Interface – Sensus2 2.13 Meter Reads Interface – Elster 2.14 Meter Reads Interface – Trilliant 2.16 Meter Reads Interface – Tantalus 2.17 Meter Reads Interface – SmartSynch 2.18 Universal Meter Read Interface (Future)
6 VEE Processing n/a n/a
7 Framing of Billing Quantities n/a See Section 8 below
8 Billing Quantity Processing
2.4 Billing Service Standard Interface – Request 2.5 Billing Service Standard Interface – Reply 2.6 Billing Quantity Request Interface 2.7 Billing Quantity Response Interface 2.8 Billing Cycle Schedule Interface 2.9 Aggregated Settlements Data
9 Reporting n/a n/a
10 Security n/a n/a
11 MDM/R File Transfer Services n/a n/a
12 Direct Access GUI n/a n/a
13 Customer Presentment -
Web Services Interface 2.10 Web Services Interface
14 MDM/R Administration n/a n/a
15
Interface Functional Specification – Universal SDP ID Assignment Request and Response
2.1 Universal SDP ID Assignment Request/ Response Interface
Interface Functional Specification –
Periodic Audit Synchronization 2.2 Periodic Audit Synchronization Interface Interface Functional Specification –
Incremental Synchronization. 2.3 Incremental Synchronization Interface
Interface Functional Specification – Meter Reads Interface
2.11 Meter Reads Interface – Sensus 2.12 Meter Reads Interface – Sensus2 2.13 Meter Reads Interface – Elster 2.14 Meter Reads Interface – Trilliant
2.15 Meter Read Transformation to Trilliant CMEP 2.16 Meter Reads Interface – Tantalus
Version 3.3 – July 7, 2011 10
Meter Data Management and Repository
Detailed Design
Meter Data Management and Repository
Technical Interface Specifications
Section Subject Matter Section Subject Matter2.18 Universal Meter Read Interface (FUTURE) Interface Functional Specification –
Billing Quantity Request Interface
2.4 2.6
Billing Service Standard Interface – Request Billing Quantity Request Interface
Interface Functional Specification – Billing Quantity Response Interface
2.5 2.7
Billing Service Standard Interface – Reply Billing Quantity Response Interface Interface Functional Specification –
Billing Cycle Schedule 2.8 Billing Cycle Schedule Interface Interface Functional Specification –
Web Services Interface 2.10 Web Services Interface Aggregation for Settlement 2.9 Aggregated Settlement Data
1.7
Conventions for Data Field Formats
The conventions used for the data fields in the files contained within this document are
as follows.
Table 1.7.1
Data Field Formats
Data
Type
Char(X)
Varchar(X)
Fixed
Number (X)
Number (X) or
Number (X,Y)
Date/Time
Time
Interval
Description A fixed length alphanumer ic field with a defined length of “X” A variable length alphanumeric field with a maximum length of “X” A fixed length numeric field with a defined length of “X” A floating numeric field with a maximum of “X” digits to the left of the decimal and a maximum of “Y” digits to the right of the decimal (if existing). A Date/Time or Date field. A length of time as indicated in months, days, hours and minutes.Format AAAAA AAAAA NNNNN NNNNN.NN
yyyyMMddHH mmss or yyyyMMdd MMDDhhmm Special Instructions Includes the full ASCII character set, with the exception of the Pipe (|) character Character count must always be the defined length. Padding is not acceptable or required Includes the full ASCII character set, with the exception of the Pipe (|) character All Meter Read Interface files: The optional Segment Number file name element is limited to alpha and number characters. Special characters of the ASCII Fields of this type must be padded to the left with zeros.
Date/Time fields must always be expressed in Eastern Standard Time (EST) yyyy – Year MM – Month dd – Day HH – Hour, in 24 hour format mm – Minutes ss – Seconds CMEP Meter Data files provide Date/Time as: yyyyMMddHH mm MM – Month DD – Day hh – Hour, in 24 hour format mm – Minutes
Version 3.3 – July 7, 2011 11
Data
Type
Char(X)
Varchar(X)
Fixed
Number (X)
Number (X) or
Number (X,Y)
Date/Time
Time
Interval
character set must not be used. Elster Meter Data files provide Date/Time as: yyyy-mmdd hh24:mi:ss Web Services provides Date/Time as: YYYY-MM-DDTHH:MI:SS .sss[[+|-]TZH:TZM] Format example Char(6) AB123C Varchar(10) AB123C ABC123DEFG Fixed Number (3) 123 045 Number (5,2) 123 12345.67 Date/Time 20070220 130703 Date 20070220 Time Interval 00000100 indicating 1 hour intervals1.8
MDM/R FTS Use of File Names
The MDM/R FTS refers to each registered organization as a Community Participant.
The value assigned to the Community Participant is used in two places.
•
The first is in the configuration of the Community Participant AS2 client. The
AS2 client will add the AS2 ID to the AS2 protocol headers attached to each
file that it sends to the MDM/R.
•
The second is in the list of Community Participants and their associated
Organization ID’s. This list is part of the MDM/R FTS configuration files and is
maintained by the MDM/R Administrator.
Each file that is sent by a Community Participant to the MDM/R or by the MDM/R to a
Community Participant has a file name that meets the specifications in this section.
MDM/R FTS depends on the file name specification to direct incoming files into the
appropriate directory for processing by the target application such as EnergyIP or
MDM/R Staging Table Loader without looking into the content of the file. Likewise, the
Community Participant is able to rely on the names of files received from the MDM/R.
1.8.1
Structure of MDM/R file names
The file names used by MDM/R are structured into two groups of elements.
The first group of elements is common to all file names and each element must always
be present and in the order in which they are specified in the next section.
The second group of elements is dependent upon the file type being named. If an
element is specified for a file type then it must be present and it must be in the order in
which it is specified.
File name elements are separated by a period (.).
File name elements may contain letters (A-Z, a-z) and numbers (0-9). Other than
letters, numbers and the separator character, no other characters are permitted in the
file name elements.
Version 3.3 – July 7, 2011 12
The file name ends with the extension .DAT.
The file name specification does not speak to the manner in which data in the file is
organized. Files containing delimited data and files containing XML encoded data will
both have a .DAT extension.
The general syntax for the file name is:
<ORG_ID_1>.<ORG_ID_2>.<FILE_ID>.<FILE_VER>.<DATE_TIME>{.request
specific element n}.DAT
The specific elements of the file name are described in the following sections.
1.8.2
File name elements common to all files
The first five elements described below are common to all file names.
Element 1: ORG_ID_1 (Organization ID)
This mandatory element is the 8 character Organization ID, beginning with ORG, that
identifies the Community Participant on whose behalf the file has been submitted for or
received on behalf of.
The Organization ID must be a valid Organization ID that is already known to the
MDM/R FTS.
In the situation where a Community Participant is submitting its own files the
Organization ID and the Agent Organization ID will be identical.
The relationship of Organization ID to Agent Organization ID must be known to the
MDM/R FTS at the time the relationship is asserted through an incoming file name.
This information is captured when the relationship is established. It is maintained by
the MDM/R Administrator in MDM/R FTS configuration files.
Agent Organization ID is used in situations where one organization is acting on behalf
of another organization. An example of such a relationship is a third party AMI operator
submitting meter read data on behalf of the LDC with which it has a contract.
Element 2: ORG_ID_2 (Agent Organization ID)
This mandatory element is the 8 character Organization ID, beginning with ORG, that
identifies the Community Participant that is acting as the agent for the Community
Participant on whose behalf the file has been submitted for or received on behalf of.
The Agent Organization ID must be a valid Organization ID that is already known to the
MDM/R FTS.
In the situation where a Community Participant is submitting its own files the
Organization ID and the Agent Organization ID will be identical.
The relationship of Organization ID to Agent Organization ID must be known to the
MDM/R FTS at the time the relationship is asserted through an incoming file name.
This information is captured when the relationship is established. It is maintained by
the MDM/R Administrator in MDM/R FTS configuration files.
Agent Organization ID is used in situations where one organization is acting on behalf
of another organization. An example of such a relationship is a third party AMI operator
submitting meter read data on behalf of the LDC with which it has a contract.
Element 3: FILE_ID (FILE ID)
Version 3.3 – July 7, 2011 13
FILE ID comes from the list of valid files that can be sent to the MDM/R. This list is
maintained by the MDM/R Administrator and is part of the MDM/R FTS configuration
files. This list only changes when a new type of file is introduced or retired.
The MDM/R Technical Interface Specifications document contains the list of valid
files and the specification of each. The MDM/R Reports Technical Specifications
document contains the list of valid reports and the specification of each.
Table 1.8.1: Valid file types
FILE ID
File Type
Comments
1000
Universal SDP ID
Assignment Request
Request for the assignment of one or more Universal
Service Delivery Points
2000
Universal SDP ID
Assignment Response
Response containing the requested assignment of
Universal Service Delivery Points.
3000
Periodic Audit
Synchronization
Process a complete synchronization of the MDM/R
Master Directory with the LDC Data Source(s)
4000
Incremental
Synchronization
Update the MDM/R Master Directory as SDP
attributes and relationships changes are supplied by
the LDC to the MDM/R, based on changes in LDC
Data Source(s)
5000
Billing Quantity Request
Requests to the MDM/R for Billing Quantity data
5500
Billing Service Standard
Interface – Request
EnergyIP standard XML requests to the MDM/R for
Billing Quantity data
6000
Billing Quantity Response
– TOU/CPP & Periodic
Response from the MDM/R for TOU/Periodic Billing
Quantity data
6100
Billing Quantity Response
– Hourly
Response from the MDM/R for Hourly Billing Quantity
data
6200
Billing Quantity Response
– Demand
Response from the MDM/R for Peak Demand
Quantities and Coincident Quantities data
6500
Billing Service Standard
Interface – Reply
EnergyIP standard XML reply from the MDM/R for
Billing Quantity data – TOU, Periodic, Hourly
7000
Meter Read Interface
(Sensus)
Deliver Meter Read data for smart meters to the
MDM/R
7001
Meter Read Interface
(Sensus2)
Deliver Meter Read data for smart meters to the
MDM/R
7100
Meter Read Interface
(Elster)
Deliver Meter Read data for smart meters to the
MDM/R
7200
Meter Read Interface
(Trilliant)
Deliver Meter Read data for smart meters to the
MDM/R
7300
Meter Read Interface
(Tantalus)
Deliver Meter Read data for smart meters to the
MDM/R
7400
Meter Read Interface
(SmartSynch)
Deliver Meter Read data for smart meters to the
MDM/R
7500
Universal Meter Read
Interface (FUTURE)
Deliver externally estimated register read data to the
MDM/R
8000
Billing Cycle Schedule
Inform the MDM/R of the billing cycle schedule dates
that map to each billing cycle
9000
Data Aggregation File
The daily Aggregated Settlement data provided to
LDCs
Version 3.3 – July 7, 2011 14
FILE ID
File Type
Comments
9100
Data Aggregation
Contributors File
The daily listing of SDP, Loss Factor Classification,
and Meter combinations contributing to the daily
Aggregated Settlement data
Element 4: FILE_VER (File Version)
This mandatory element is a fixed two digit value that identifies the format version of
the file.
The file format version starts at 00 and increases as new versions of each file format
are introduced.
File format version is provided to allow multiple format versions of the same file type to
co-exist. This is of use in situations where the MDM/R is migrating to a new format
version of a file but must maintain the previous version long enough for each
Community Participant to migrate to the new format.
The MDM/R Technical Interface Specifications documents the valid request
versions.
Element 5: DATE_TIME (Date and Time)
This mandatory element is a 14 digit value that identifies the date and time of the file.
The format of the field is yyyyMMddHHmmss where yyyy is the year, MM is the month,
dd is the day, HH is the hour in 24 hour clock format, mm is the minutes and ss is the
seconds. All positions must be numeric and meet the standard validity tests of date
and time.
The value in this field is set by the sender. The value in this field should not be
assumed to be the file creation date and time. The business meaning of this field is
further defined in the specification of the individual request types.
Where a request is made up of multiple files e.g. Periodic Audit Synchronization
Request each file in the set must have the same value for DATE_TIME.
1.8.3
File name elements specific to individual interface files
File ID 1000 – Universal SDP ID Assignment Request
This file does not have any additional file name elements.
File ID 2000 – Universal SDP ID Assignment Response – Version 00
Version 00 will be retired upon deployment of response version 01.
File ID 2000 – Universal SDP ID Assignment Response – Version 01
This file does not have any additional file name elements.
File ID 3000 – Periodic Audit Synchronization – Version 00
Version 3.3 – July 7, 2011 15
File ID 3000 – Periodic Audit Synchronization – Version 01
Version 01 of the Periodic Audit Synchronization interface is a single file set made up
of a set of 7 related files. The additional file name elements in the file name link these
files such that the MDM/R is able to determine which files belong to any given
submission and when the complete set (all 7 files) has been received.
Element 6 – TX_ID (Transaction Identifier)
This mandatory element is a fixed 6 character value that relates all 7 files in this file
type. The same value must be present in this element position for each file that makes
up the synchronization file set.
The value that is placed in this element is defined by the sender. The value is used to
group a given file set together and as a reference for the sender.
Element 7 – FILE_NO (File Number)
This mandatory element is a 2 digit value that identifies which of the 7 files that make
up a Periodic Audit Synchronization file set the particular file is.
00. Manifest File
01. Asset Data File
02. Premise Data File
03. Service Agreement Data File
04. Parameter Data File
05. Relationship Data File
06. (Not Used)
07. Component SDP Channel to Channel & Channel to Formula Data File
Element 8 – SEGMENT_NO (Segment Number)
This mandatory element is a fixed 2 digit value that represents the file segment number.
The purpose of this is to allow an LDC to break up a large synchronization file into
smaller synchronization files.
For example, if you are submitting three Asset files, the segment numbers will be 01,
02, and 03.
If a file is sent as a single segment the value for the Segment Number element must be
01.
File ID 4000 – Incremental Synchronization – Version 00
Version 00 of the Incremental Synchronization is conceptually a single file but it is
made up of a set of 7 related files in the same way as Version 01 of the Periodic Audit
Synchronization.
Element 6 – TX_ID (Transaction Identifier)
This mandatory element is a fixed 6 character value that relates all 7 files in this file
type. The same value must be present in this element position for each file that makes
up the synchronization file set.
The value that is placed in this element is defined by the sender. The value is used to
group a given file set together and as a reference for the sender.
Version 3.3 – July 7, 2011 16
Element 7 – FILE_NO (File Number)
This mandatory element is a 2 digit value that identifies which of the 7 files that make
up an Incremental Synchronization file set the particular file is.
00. Manifest File
01. Asset Data File
02. Premise Data File
03. Service Agreement Data File
04. Parameter Data File
05. Relationship Data File
06. (Not Used)
07. Component SDP Channel to Channel & Channel to Formula Data File
Element 8 – SEGMENT_NO (Segment Number)
This mandatory element is a fixed 2 digit value that represents the file segment number.
The purpose of this is to allow an LDC to break up a large synchronization file into
smaller synchronization files.
For example, if you are submitting three Asset files, the segment numbers will be 01,
02, and 03.
If a file is sent as a single segment the value for the Segment Number element must be
01.
File ID 5000 – Billing Quantities Request
This file does not have any additional file name elements.
File ID 5500 – Billing Service Standard Interface – Request
This file does not have any additional file name elements.
File ID 6000 – Billing Quantities Response (TOU/CPP & Periodic)
This file does not have any additional file name elements.
File ID 6100 – Billing Quantities Response (Hourly)
This file does not have any additional file name elements.
File ID 6200 – Billing Quantities Response (Demand)
This file does not have any additional file name elements.
File ID 6500 – Billing Service Standard Interface – Reply
This file does not have any additional file name elements.
File ID 7000 – Meter Read Interface (Sensus)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
Version 3.3 – July 7, 2011 17
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7001 – Meter Read Interface (Sensus2)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters integers (0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7100 – Meter Read Interface (Elster)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7200 – Meter Read Interface (Trilliant)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7300 – Meter Read Interface (Tantalus)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
Version 3.3 – July 7, 2011 18
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7400 – Meter Read Interface (SmartSynch)
Element 6 – SEGMENT_NO (Segment Number)
This optional element is a Varchar(10) value that represents a file segment number.
The purpose of this element is to allow an LDC to break down a large Meter Read data
transmission for the same DATE_TIME into multiple Meter Read data files. The
segment numbers for multiple files for the same DATE_TIME may take any
alphanumeric value without relationship to each other.
NOTE: Characters used in this optional file name element are limited to the alpha
(upper and lower case letters) and number characters (integers 0 through 9) of the
ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all
others).
File ID 7500 – Universal Meter Read Interface (FUTURE)
(Future)
File ID 8000 – Billing Cycle Schedule
This file does not have any additional file name elements.
File ID 9000 – Data Aggregation
This file does not have any additional file name elements.
File ID 9100 – Data Aggregation Contributors
This file does not have any additional file name elements.
1.8.4
File Name Record
Different AS2 clients have different ways of treating filenames. While some will retain
the original file name when transferring the file from one AS2 system to another, others
will change the name. To ensure that the file names are retained regardless of what
AS2 client an Organization chooses to install, the file name is the first record of every
inbound file from an Organization to the MDM/R and every outbound file from the
MDM/R to an Organization.
1.8.5
MDM/R File Name Examples
The following examples illustrate the naming of files exchanged with the MDM/R.
Assume that the following organizations or Community Participants have been enrolled
with the MDM/R and assigned Organization ID’s (ORG_ID):
§ ORG11111 is Acme Hydro (a fictitious utility)
§ ORG22222 is Ace AMI Operations Limited (a fictitious AMI operations
company)
Version 3.3 – July 7, 2011 19
Further assume that Acme Hydro has outsourced its AMI operations to Ace AMI
Operations Limited. This business relationship has been registered with the MDM/R
and the MDM/R Operator has updated the necessary configuration files.
The general syntax from the sections above is:
<ORG_ID_1>.<ORG_ID_2>.<FILE_ID>.<REQ_VER>.<DATE_TIME>{.request
specific element n}.DAT
Table 1.8.2
Examples of File Names
Transaction description
File Name
A version 01 Universal
SDP ID Assignment
Request file is sent by
Acme Hydro to the
MDM/R.
ORG11111.ORG11111.1000.01.20070214221345.DAT
The MDM/R processes
the work in the example
above and sends back a
version 01 Universal SDP
ID Assignment Response
file to Acme Hydro.
ORG11111.ORG11111.2000.01.20070214221345.DAT
Ace AMI Operations
Limited sends a version
01 file of meter data from
the Acme Hydro Elster
AMI system to the
MDM/R.
ORG11111.ORG22222.7100.01.20070214221345.DAT
Ace AMI Operations
Limited sends a version
00 file of meter data from
the Acme Hydro Sensus
AMI system to the MDM/R
consisting of four
segments on May 4,
2008.
ORG11111.ORG22222.7000.00.20080504221345.OL 53590.DAT
ORG11111.ORG22222.7000.00.20080504221345.OL 54900.DAT
ORG11111.ORG22222.7000.00.20080504221345.OL 54627.DAT
ORG11111.ORG22222.7000.00.20080504221345.OL 75439.DAT
Acme Hydro sends a
version 00 Periodic Audit
Synchronization file set to
the MDM/R. In this
example, the unique
identifier assigned by
Acme Hydro to this
specific request is
‘ababab’.
ORG11111.ORG11111.3000.00.20070214221345.ababab.01.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.02.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.03.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.04.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.05.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.06.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.07.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.08.DAT
ORG11111.ORG11111.3000.00.20070214221345.ababab.09.DAT
Version 3.3 – July 7, 2011 20
Transaction description
File Name
Acme Hydro sends a
version 01 Periodic Audit
Synchronization file set to
the MDM/R. In this
example, the unique
identifier assigned by
Acme Hydro to this
specific request is
‘cdcdcd’.
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.00.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.01.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.02.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.03.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.04.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.05.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.cdcdcd.07.01.DAT
Acme Hydro sends a
version 01 Periodic Audit
Synchronization file set to
the MDM/R. Acme Hydro
chooses to split their
Asset file into 3 separate
files. In this example, the
unique identifier assigned
by Acme Hydro to this
specific request is ‘efefef’.
ORG11111.ORG11111.3000.01.20070214221345.efefef.00.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.01.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.01.02.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.01.03.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.02.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.03.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.04.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.05.01.DAT
ORG11111.ORG11111.3000.01.20070214221345.efefef.07.01.DAT
Acme Hydro sends a
version 00 Incremental
Synchronization file set to
the MDM/R. In this
example, the unique
identifier assigned by
Acme Hydro to this
specific request is
‘J39x82’.
ORG11111.ORG11111.4000.00.20070214221345.J39x82.00.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.01.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.02.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.03.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.04.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.05.01.DAT
ORG11111.ORG11111.4000.00.20070214221345.J39x82.07.01.DAT
Version 3.3 – July 7, 2011 21
1.9
Timelines
Figure 1.9.1 depicts the typical processes involved in the daily receipt of Meter Read
and MMD update data and the daily production of Billing Quantities for the last Daily
Read Period included in any billing period.
This figure illustrates the timing for file transfer of synchronization data, meter read
data and billing quantity data. Please note that meter read data may be supplied at a
minimum once per day. The preference is for meter read data to be provided as
frequently as possible with as little latency between the data collection from the field
and the data being sent onto the MDM/R.
Frequency and timing for each individual file transfer are specified in the later sections
of this document.
Version 3.3 – July 7, 2011 22