MDMR Technical Interface Spec v3.3 20110707 CLEAN

IESO_SPEC_9027
Meter Data Management and Repository

MDM/R Technical Interface Specifications
Version 3.3 07 July 2011
MDM/R Technical Interface Specifications IESO_SPEC_9027
Disclaimer
The posting of documents on this Web site is subject to the terms and conditions posted on the SMSIP Web site. Please be advised that, while the IESO-SMSIP attempts to have all posted documents conform to the original, changes can result from the original, including changes resulting from the programs used to format the documents for posting on the Web site as well as from the programs used by the viewer to download and read the documents. The IESO-SMSIP makes no representation or warranty, express or implied, that the documents on this Web site are exact reproductions of the original documents listed. In addition, the documents and information posted on this Web site are subject to change. The IESO-SMSIP may revise, withdraw or make final these materials at any time at its sole discretion without further notice. It is solely your responsibility to ensure that you are using up-to-date documents and information.
Status of these Specifications

This document was put under formal change control on July 31, 2007. As of Version 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
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 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 2.18 Universal Meter Read Interface (Future) ..................................................................... 290
ii
Related Documents
Document Title IESO_DES_9001: MDM/R V1.0 Detailed Design Version 2.0 SME_SPEC_0001: MDM/R V1.0 Reports Technical Specifications Version 3.0 IESO_STD_0078: MDM/R VEE Standard for the Ontario Smart Metering System Issue 4.1 SME_MAN_0005: MDM/R Meter Data Management and Repository (MDM/R) TOU Schedule and Calendar Manual Issue 2.0 MDM/R File Transfer Services and Web Services Configuration Workbook Version 1.0 MDM/R Service and Performance Levels MDM/R Business Process Descriptions Ontario Regulation 440/07: Functional Specifications for an Advanced Metering Infrastructure, Version 2 Ontario Regulation 233/08: Designation of Smart Metering Entity 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 Measurement Canada General Bulletin: GEN-31-E (rev.1), Policy on Multirate Register Metering California Metering Exchange Protocol Version 1.20 Update for EDI DASR compatibility Elster EnergyAxis Management System AMR Data Exchange Format Reference Release 7.0 Sensus Meter Systems Extended CMEP File Format, Version 0.87 SmartSynch IESO Interface MDM/R Interface Specification SSI Document # RQ-062009-0006, Revision 2 Issue Date 30 April 2008 29 April 2010 March 1, 2011 December 19, 2008 October 15, 2008 Issue 2.0, December 14, 2006 Issue 2.0, December 14, 2006 July 5, 2007 Made: June 17, 2008 Date: 2000-06-26
Issue Date: 2010-02-10 Effective Date: 2010-04-01 March 7, 2000 2010 January 5 July 28, 2008 06-29-2009
iii
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) Section 2.4, Section 2.4.3, page 116 Section 2.5, Section 2.5.3, pages 128 Section 2.5, Section 2.5.8.2, pages 139, 140, 141-142, 147-149 Description of Change Billing Service Standard Interface Request Business Rules Added new Business Rule 8. Rules Affecting Register Reading Changes in Prior Billing Periods. Billing Service Standard Interface Reply Business Rules Business Rule 3.d, Minor edit of logical meter change defined, for clarity 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. Updated sample to add Start and End register readings.
iv
Reference (Section and Page) Section 2.10, Section 2.10.8, page 212
Description of Change Updated sample to delete KWH Est Usage reading.
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.
End of Table of Changes
1
1.1
Introduction
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
8. 9.
10. 11.
12.
13.
has been established in the MMD using either the synchronization interface or by direct entry using the EnergyIP Graphical User Interface. Daily framing of Billing Quantities will only occur within complete calendar (EST) days. 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. 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. 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. 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. 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 AMCC
Description 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 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 means an Application Program Interface, which is the interface (calling conventions) application program used for accessing services provided by another module. 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). Refers to consumption data that has been through VEE and Framing and is ready for use in billing. 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)
AMI
API
AS2
Billing Quantity Block Demand
TERM CIS CST Consumer or Customer CPP
Description The Customer Information System, in which Customer account information is held. Central Standard Time Refers to residential or small general service consumers where the metering of demand is not required. 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 Consumers electricity consumption during CPP events. 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. 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.) Eastern Standard Time The service which manages the transfer of files between the MDM/R and LDCs and/or the LDCs authorized agents. 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. The process by which interval data is assembled into Billing Quantities. Framing Structure means a parameter that denotes the method by which Meter Reads are assembled into Billing Quantities by the MDM/R. 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. Those entities that are authorized to access specific data from the MDM/R. 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. Kilovolt-ampere hour Kilovolt-ampere-reactive hour Kilowatt hour 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.
Daily Read Period
EnergyIP
EST File Transfer Service or FTS Firmographic /Demographic
Framing Framing Structure
GUI
Interested Party IVR
kVAh kVARh kWh kW77 Peak Demand
TERM LDC Meter Read
Description Means a Local Distribution Company, which is an LDC, as defined in the Ontario Energy Board Act, 1998 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 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 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. 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. 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. 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. 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. Operational Service Provider. Calculated kVA and/or kW demand based on calculations from sub-interval data over a rolling period such as 60 minutes. 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) Regulated Price Plan (RPP) for Consumers that sets out the prices per kWh that local electricity utilities charge for electricity use. 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. 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 LDCs systems and relates to the SDP within the MDM/R.
Meter Read Block
Meter Transfer Block
MDM/R
MDM/R Administrator MMD
Organization ID
OSP Rolling Demand PIPe
RPP SDP
SDP ID
TERM SDP REF
Description 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. Secure Sockets Layer - A cryptographic protocol which provides secure communications on the Internet. Simple Object Access Protocol A protocol for exchanging XML based messages over computer networks normally using Http. 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 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. 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. WebSphere Partner Gateway - provides the platform for the MDM/R to manage the business to business (B2B) transactions for file transfer and translations
SSL SOAP TOU
Universal SDP ID
VEE
WPG
1.4.1
Integration Terminology
TERM Request/Response Request/Reply Send Description An asynchronous pair of related data flows A synchronous pair of related data flows An asynchronous one-way flow of data
1.5
Organization of this Document

The Technical Interface Specifications Document is comprised of individual sections that lay out the technical interface specifications for each interface. The following interfaces are defined in this document: Section 2.1: Universal SDP ID Assignment Request/Response Interface Section 2.2: Periodic Audit Synchronization Interface Section 2.3: Incremental Synchronization Interface Section 2.4: Billing Service Standard Interface Request Section 2.5: Billing Service Standard Interface Reply Section 2.6: Billing Quantity Request
Section 2.7: Billing Quantity Response Section 2.8: Billing Cycle Schedule Interface Section 2.9: Aggregated Settlement Data Section 2.10: Web Services Request/Reply Section 2.11: Meter Read Interface (Sensus) Section 2.12: Meter Read Interface (Sensus2) Section 2.13: Meter Read Interface (Elster) Section 2.14: Meter Read Interface (Trilliant) Section 2.15: Meter Read Transformation for Transmission via Trilliant CMEP Interface Section 2.16: Meter Read Interface (Tantalus) Section 2.17: Meter Read Interface (SmartSynch) Section 2.18: Universal Meter Read Interface
Each interface section has a common layout, as follows: Description Integration Business Rules Pre-conditions Post-conditions Assumptions Frequency and Timing File Formats
1.6
1.6.1
Document Relationships
Related Documents Overview
This document is part of a library that specifies the design, functions and technical interfaces belonging to the Meter Data Management/Repository (MDM/R). This library is comprised of the following documents: 1) Meter Data Management and Repository MDM/R V1.0 Detailed Design (the Detailed Design): This document sets out the design of the MDM/R in accordance with the MDM/R Functional Specification that forms part of the MDM/R Specification document series (described below). 2) Meter Data Management and Repository MDM/R V1.0 Technical Interface Specifications (the Technical Interface Specification): This document describes the format and content of all file-based technical interfaces between the MDM/R and various authorized, interested parties. The Technical Specifications for reports are included in item 4 below. 3) MDM/R File Transfer Services and Web Services Configuration Workbook: This document is an aide to assist Organizations with their AS2 configurations for file transfers to and from the MDM/R. 4) Meter Data Management and Repository MDM/R V1.0 Reports Technical Specifications: This document describes the format and content of MDM/R generated standard and exception reports.
The documents in this library were preceded by the publication of the MDM/R Specification document series, produced by the IESOs Smart Metering System Implementation Program (SMSIP). The MDM/R Specification, is a series of documents developed for the procurement and functional specification of the MDM/R, and includes the following documents: 1) MDM/R Functional Specification IESO_SPEC_0241: This document sets out the functional description of the Meter Data Management and Repository functions. 2) MDM/R Business Process Description IESO_SPEC_0240: This document contains a high-level view of the major business process areas identified in the, MDM/R Functional Specification 3) MDM/R Logical Application and Data Architecture (LADA) IESO_ARCH_0008: This document sets out an overview of a logical architecture for the applications, data and inter-dependencies related to the Smart Metering System (in general) and the Meter Data Management Repository (specifically). 4) MDM/R Service and Performance Levels IESO_SPEC_0239: This document sets out the volumetric projections, and corresponding expectations for service and performance for the MDM/R. The MDM/R Specification document series is available from the SMSIP website (http://www.smi-ieso.ca). The interrelationships between these various documents are depicted in Figure 1.6.1.
Figure 1.6.1 Interrelationships between MDM/R Documents

MDM/R Specification Document Series
(authored by IESO for MDM/R Procurement)
Business Processes to be Logically supported by the MDM/R solution space
MDM/R Logical Applications and Data Architecture

IESO_ARCH_0008
MDM/R Functional Specification

IESO_SPEC_0241
MDM/R Business Process Description

IESO_SPEC_0240 Functions to be accommodated
MDM/R Service and Performance Levels

Business Processes to be supported by the MDM/R solution IESO_SPEC_0239
Functional Description to be accommodated by the MDM/R design
MDM/R V1.0 Technical Interface Specifications Document MDM/R V1.0 Detailed Design SME_DES_9001 MDM/R File Transfer Services and Web Services Configuration Workbook SME_MAN_9001 Design and Functional Description IESO_SPEC_9027
MDM/R V1.0 Reports Technical Specifications SME_SPEC_0001
Technical Interface Description
MDM/R Document Library for Design, Functions, and Technical Interfaces
1.6.2
Subject Cross-reference: MDM/R Design and Functionality to Technical Interfaces

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

Section Subject Matter
Meter Data Management and Repository Technical Interface Specifications

Section 2.1 Subject Matter Universal SDP ID Assignment Request Response Interface Periodic Audit Synchronization Incremental Synchronization Periodic Audit Synchronization Incremental Synchronization Meter Reads Interface Sensus Meter Reads Interface Sensus2 Meter Reads Interface Elster Meter Reads Interface Trilliant Meter Reads Interface Tantalus Meter Reads Interface SmartSynch Universal Meter Read Interface (Future) n/a See Section 8 below Billing Service Standard Interface Request Billing Service Standard Interface Reply Billing Quantity Request Interface Billing Quantity Response Interface Billing Cycle Schedule Interface Aggregated Settlements Data n/a n/a n/a n/a Web Services Interface n/a Universal SDP ID Assignment Request/ Response Interface Periodic Audit Synchronization Interface Incremental Synchronization Interface Meter Reads Interface Sensus Meter Reads Interface Sensus2 Meter Reads Interface Elster Meter Reads Interface Trilliant Meter Read Transformation to Trilliant CMEP Meter Reads Interface Tantalus Meter Reads Interface SmartSynch
Service Delivery Point
2.2 2.3
MDM/R Master Data (MMD) Synchronization
2.2 2.3 2.11 2.12 2.13
Meter Data Collection and Processing
2.14 2.16 2.17 2.18
6 7
VEE Processing Framing of Billing Quantities
n/a n/a 2.4 2.5
Billing Quantity Processing
2.6 2.7 2.8 2.9
9 10 11 12 13 14
Reporting Security MDM/R File Transfer Services Direct Access GUI Customer Presentment Web Services Interface MDM/R Administration Interface Functional Specification Universal SDP ID Assignment Request and Response Interface Functional Specification Periodic Audit Synchronization Interface Functional Specification Incremental Synchronization.
n/a n/a n/a n/a 2.10 n/a 2.1
2.2 2.3 2.11 2.12 2.13
15
Interface Functional Specification Meter Reads Interface
2.14 2.15 2.16 2.17
Meter Data Management and Repository Detailed Design

Section Subject Matter
Meter Data Management and Repository Technical Interface Specifications

Section 2.18 Subject Matter Universal Meter Read Interface (FUTURE) Billing Service Standard Interface Request Billing Quantity Request Interface Billing Service Standard Interface Reply Billing Quantity Response Interface Billing Cycle Schedule Interface Web Services Interface Aggregated Settlement Data
Interface Functional Specification Billing Quantity Request Interface Interface Functional Specification Billing Quantity Response Interface Interface Functional Specification Billing Cycle Schedule Interface Functional Specification Web Services Interface Aggregation for Settlement
2.4 2.6 2.5 2.7 2.8 2.10 2.9
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)

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).
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 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 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
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.
MM Month DD Day hh Hour, in 24 hour format mm Minutes
10
Data Type
Char(X)
Varchar(X)
character set must not be used.
Fixed Number (X)
Number (X) or Number (X,Y)
Date/Time
Elster Meter Data files provide Date/Time as: yyyy-mmdd hh24:mi:ss Web Services provides Date/Time as: YYYY-MMDDTHH:MI:SS .sss[[+|]TZH:TZM]
Time Interval
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 intervals
1.8
MDM/R FTS Use of File Names

The MDM/R FTS refers to each registered organization as a Community Participant. The value assigned to the Community Participant is used in two places. The first is in the configuration of the Community Participant AS2 client. The AS2 client will add the AS2 ID to the AS2 protocol headers attached to each file that it sends to the MDM/R. The second is in the list of Community Participants and their associated Organization IDs. 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.
11
The file name ends with the extension .DAT. The file name specification does not speak to the manner in which data in the file is organized. Files containing delimited data and files containing XML encoded data will both have a .DAT extension. The general syntax for the file name is: <ORG_ID_1>.<ORG_ID_2>.<FILE_ID>.<FILE_VER>.<DATE_TIME>{.request specific element n}.DAT The specific elements of the file name are described in the following sections.
1.8.2
File name elements common to all files

The first five elements described below are common to all file names. Element 1: ORG_ID_1 (Organization ID) This mandatory element is the 8 character Organization ID, beginning with ORG, that identifies the Community Participant on whose behalf the file has been submitted for or received on behalf of. The Organization ID must be a valid Organization ID that is already known to the MDM/R FTS. In the situation where a Community Participant is submitting its own files the Organization ID and the Agent Organization ID will be identical. The relationship of Organization ID to Agent Organization ID must be known to the MDM/R FTS at the time the relationship is asserted through an incoming file name. This information is captured when the relationship is established. It is maintained by the MDM/R Administrator in MDM/R FTS configuration files. Agent Organization ID is used in situations where one organization is acting on behalf of another organization. An example of such a relationship is a third party AMI operator submitting meter read data on behalf of the LDC with which it has a contract. Element 2: ORG_ID_2 (Agent Organization ID) This mandatory element is the 8 character Organization ID, beginning with ORG, that identifies the Community Participant that is acting as the agent for the Community Participant on whose behalf the file has been submitted for or received on behalf of. The Agent Organization ID must be a valid Organization ID that is already known to the MDM/R FTS. In the situation where a Community Participant is submitting its own files the Organization ID and the Agent Organization ID will be identical. The relationship of Organization ID to Agent Organization ID must be known to the MDM/R FTS at the time the relationship is asserted through an incoming file name. This information is captured when the relationship is established. It is maintained by the MDM/R Administrator in MDM/R FTS configuration files. Agent Organization ID is used in situations where one organization is acting on behalf of another organization. An example of such a relationship is a third party AMI operator submitting meter read data on behalf of the LDC with which it has a contract. Element 3: FILE_ID (FILE ID) This mandatory element is a four digit value that identifies the type of file.
12
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 1000 2000 3000 4000
File Type Universal SDP ID Assignment Request Universal SDP ID Assignment Response Periodic Audit Synchronization Incremental Synchronization
Comments Request for the assignment of one or more Universal Service Delivery Points Response containing the requested assignment of Universal Service Delivery Points. Process a complete synchronization of the MDM/R Master Directory with the LDC Data Source(s) 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) Requests to the MDM/R for Billing Quantity data EnergyIP standard XML requests to the MDM/R for Billing Quantity data Response from the MDM/R for TOU/Periodic Billing Quantity data Response from the MDM/R for Hourly Billing Quantity data Response from the MDM/R for Peak Demand Quantities and Coincident Quantities data EnergyIP standard XML reply from the MDM/R for Billing Quantity data TOU, Periodic, Hourly Deliver Meter Read data for smart meters to the MDM/R Deliver Meter Read data for smart meters to the MDM/R Deliver Meter Read data for smart meters to the MDM/R Deliver Meter Read data for smart meters to the MDM/R Deliver Meter Read data for smart meters to the MDM/R Deliver Meter Read data for smart meters to the MDM/R Deliver externally estimated register read data to the MDM/R Inform the MDM/R of the billing cycle schedule dates that map to each billing cycle The daily Aggregated Settlement data provided to LDCs
5000 5500 6000 6100 6200 6500 7000 7001 7100 7200 7300 7400 7500 8000 9000
Billing Quantity Request Billing Service Standard Interface Request Billing Quantity Response TOU/CPP & Periodic Billing Quantity Response Hourly Billing Quantity Response Demand Billing Service Standard Interface Reply Meter Read Interface (Sensus) Meter Read Interface (Sensus2) Meter Read Interface (Elster) Meter Read Interface (Trilliant) Meter Read Interface (Tantalus) Meter Read Interface (SmartSynch) Universal Meter Read Interface (FUTURE) Billing Cycle Schedule Data Aggregation File
13
FILE ID 9100
File Type Data Aggregation Contributors File
Comments 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 00 of the Periodic Audit Synchronization interface has been retired.
14
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.
15
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
16
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
17
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 IDs (ORG_ID): ORG11111 is Acme Hydro (a fictitious utility) ORG22222 is Ace AMI Operations Limited (a fictitious AMI operations company)
18
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 A version 01 Universal SDP ID Assignment Request file is sent by Acme Hydro to the MDM/R. 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. Ace AMI Operations Limited sends a version 01 file of meter data from the Acme Hydro Elster AMI system to the MDM/R. 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. 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.
File Name ORG11111.ORG11111.1000.01.20070214221345.DAT
ORG11111.ORG11111.2000.01.20070214221345.DAT
ORG11111.ORG22222.7100.01.20070214221345.DAT
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
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
19
Transaction description 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. 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. 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.
File Name 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 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 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
20
1.9
Timelines
Figure 1.9.1 depicts the typical processes involved in the daily receipt of Meter Read and MMD update data and the daily production of Billing Quantities for the last Daily Read Period included in any billing period. This figure illustrates the timing for file transfer of synchronization data, meter read data and billing quantity data. Please note that meter read data may be supplied at a minimum once per day. The preference is for meter read data to be provided as frequently as possible with as little latency between the data collection from the field and the data being sent onto the MDM/R. Frequency and timing for each individual file transfer are specified in the later sections of this document.
Figure 1.9.1
MDM/R Timeline for Last Daily Read Period N included in a Billing Period
21
1.10
Position Statement Meter Read Data Transformations

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

Ontario Regulation 440/07: Criteria and Requirements for meters and metering equipment systems and technology
MDM/R Position Statement:

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

State 0: Meter read data within the smart meter State 1: Meter read data as recorded by AMRC devices State 2: Meter read data as recorded by AMCC devices
State 2(b): Optional state transition: Meter read data altered from native AMCC format prior to transmission to MDM/R
State 3: Meter read data arriving at MDM/R interface in a format stipulated by the MDM/R Technical Interface Specifications
Figure 1.10.1 Contextual View of this Position Statement
Background State Transition of Meter Read Data: For the purposes of this MDM/R Position Statement, meter read data may described in terms of its transition through various states along its data flow path from the smart meter to the MDM/R. These states are depicted in figure A, and include:
State 0: In this state, the Meter Read data resides within the smart meter itself.
Key regulatory instruments governing Meter Read data in this state include the federal Electricity, Gas and Inspection Act (R.S.C. 1985, c. E-4) and associated regulations. This act also has various provisions governing the integrity of Meter Read data once it is extracted from the meter. State 1: Within the context of the Ontario smart metering system, Meter Read data is read from smart meters (AMCD) using a component of the Advanced Metering Infrastructure (AMI) known as the Advanced Metering Regional
23
Collector (AMRC). All components of the AMI (including the smart meters themselves) are subject to the functional specification set out in Ontario Regulation 440/07. This regulation also requires AMI components to comply with regulatory requirements established by Industry Canada, the Canadian Standards Association, the Ontario Energy Board and the Electrical Safety Authority. State 2: AMRCs feed Meter Read data to the Advanced Metering Control Computer (AMCC) for assembly into meter read files that must be transmitted to the MDM/R. AMCCs are also deemed to be a portion of the AMI infrastructure governed by Ontario Regulation 440/07. State 3: Meter Read data arriving at the MDM/R interface will be processed in accordance with these MDM/R V1.0 Technical Interface Specifications (IESO_SPEC_9027) and any applicable provisions or regulations made under the Electricity, Gas and Inspection Act (R.S.C. 1985, c. E-4). The technical interface specification document sets out the interface requirements that must be met by all Meter Read data. Presently this document and the associated MDM/R interface makes accommodation for different types of smart metering technology (see Meter Read Interface specifications in this document for further details). State 2 (b) Optional State Transition: Changes to the format or content of Meter Read data between State 2 and State 3 are the subject of this MDM/R Position statement. These changes may take place outside the scope of the AMI and its associated, governing instruments. However, Meter Read data is still subject to a number of applicable laws including various information privacy laws. It is the responsibility of the MDM/R service recipient to be informed of all applicable law governing such data and to adhere to it. As noted above, the IESO does not seek to restrict an MDM/R service recipient from carrying out such data transformations, so long as it is clearly understood that Meter Read data arriving at the MDM/R interface will be processed in accordance with these MDM/R V1.0 Technical Interface Specifications (IESO_SPEC_9027) and the MDM/R Validation Estimation and Editing Standard for the Ontario Smart Metering System (IESO_STD_0078).
24
2
2.1
Technical Interface Specifications

Universal SDP ID Assignment Request / Response Interface
Note: Version 00 of the Response interface will be retired and replaced by Version 01 with the deployment of EnergyIP Release 7.0 into the MDM/R Production environment. For the Version 01 specification see Sections 2.1.9 through 2.1.16.
2.1.1
Description Version 00
The purpose of this interface is to process requests from the LDC for Universal Service Delivery Point Identifiers (Universal SDP IDs) and to return the assigned Universal SDP IDs to the LDC. This interface meets a business requirement that a province-wide unique identifier be made available to the LDC in order to pair it with an LDC-specific Service Delivery Point ID (SDP ID) and to be able to uniquely identify itself to the MDM/R in future transactions. The LDC uses this interface to request one or more Universal SDP IDs at a time. The LDC sends a Universal SDP ID Assignment Request File with an LDC ID that uniquely identifies the LDC, along with LDC-generated SDP IDs to which the corresponding Universal SDP IDs is assigned to through this interface. SDP IDs are generated by the LDC, and are unique within the LDCs systems. The Universal SDP ID Assignment Response File is sent back to the LDC with a Universal SDP ID assigned against every SDP ID in the Universal SDP ID Assignment Request File. This interface uses the Universal SDP ID Generator features within the MDM/R system to manage the assignment of Universal SDP IDs. Universal SDP IDs and SDP IDs are described in detail in Section 3 of the MDM/R Detailed Design Document, Service Delivery Point.
2.1.2
2.1.2.1
Integration Version 00
File Direction
Universal SDP ID Assignment Request: LDC to the MDM/R Universal SDP ID Assignment Response: MDM/R to the LDC
2.1.2.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files. The Universal SDP ID Assignment Request File contains all of the information described in tables 2.1.1 to 2.1.3. The Universal SDP ID Assignment Response File contains all of the information described in tables 2.1.4 to 2.1.6.
25
Once the Universal SDP ID Assignment Request File is delivered to the MDM/R (see Section 11, File Transfer Services of the MDM/R Detailed Design) the Universal SDP ID Assignment process will process the request file and generate the response file.
2.1.3
Business Rules Version 00

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

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

Universal SDP ID Assignment Request File
2.1.8.1.1 File Name Record for the Universal SDP ID Assignment Request File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
Table 2.1.1 File Name Record for the Universal SDP ID Assignment Request File
Field Name
Prefix
Data Type/Length
Char (7)
Format
Specific Usage: <FTSFN> Refer to Section 1.8 Specific Usage: </FTSFN>
Required
Y
Description
This field always contains the record type <FTSFN> This field contains the name of the file on the originating system, as defined in Section 1.8 This field always contains the record type </FTSFN>
File Name
Varchar (250)
Suffix
Char (8)
An example of this record for Version 00 would be:

<FTSFN>ORG11111.ORG22222.1000.00.20070214221345.DAT</FTSFN>
NOTE: Please reference Section 1.8.2 for use of file format version number.
27
2.1.8.1.2 Universal SDP ID Assignment Request File Header Record
The second record will be a header record as described in table 2.1.2.

Table 2.1.2: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD
Data Element
Record Type
Data Type/Length
Char(1)
Format
General: A Specific: H General: AAAAAAAA Example: ORG30153 General: NNNNNNNN Example: 543 yyyyMMddHHmmss
Required
Y
Comments
This field indicates that this record is a header record. It must be H
LDC ID
Char (8)
The unique organization identifier assigned to the LDC during the registration/enrollment process. Populated with an LDC generated identifier for the request. Used to correlate the Universal SDP ID Assignment response with the request. The date and time the data in this file was produced.
Request ID
Number (8)
Request Date and Time
Date/Time
2.1.8.1.3 Universal SDP ID Assignment Request File Detail Record
The data records start after the header and will contain one line for each request of an individual Universal SDP ID as defined in table 2.1.3.
Table 2.1.3 UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD
Data Element
Record Type
Data Type/Length
Char (1)
Format
General: A Specific: D No format prescribed
Required
Y
Comments
This field indicates that this record is a detail record. It must be D
SDP ID
Varchar (50)
Either: a) A unique LDC Identifier for a SDP that will be associated with a smart meter. If the LDC does not have a unique value for each SDP, then one can potentially be derived (e.g. potentially combining the LDC premise # and socket # at that premise), or b) An LDC identifier for a virtual SDP (not any physical SDP but rather an aggregation other physical Universal SDP IDs) for which a Universal SDP ID needs to be assigned.
28
2.1.8.2
Universal SDP ID Assignment Response File
2.1.8.2.1 File Name Record for the Universal SDP ID Assignment Response File
Table 2.1.4 File Name Record for the Universal SDP ID Assignment Response File
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.1.8.2.2 Universal SDP ID Assignment Response File Header Record

Table 2.1.5 UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD
Data Element
Record Type
Data Type/Length
Char(1)
Format
General: A Specific: H General: AAAAAAAA Example: ORG23153 General: NNNNNNNN Example: 543 yyyyMMddHHmmss
Required
Y
Comments
This field indicates that this record is a header record. It must be H The unique organization identifier assigned to the LDC during the registration/enrollment process. Populated with the Request ID from the Universal SDP ID Assignment Request file. The date time the data in this file was produced.
LDC ID
Char(8)
Response ID
Number (8)
Response Time
Date/Time
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 IDs for which a Universal SDP ID cannot be assigned. The exception report described in Section 2.1.5 includes these SDP IDs and the reason for the exception.
29
2.1.8.2.3 Universal SDP ID Assignment Response File Detail Record

Table 2.1.6 UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD
Data Element
Data Type/Length
Format
General: A Specific: D No format prescribed General: NNNNNNNN Example: 00037482
Required
Comments
This field indicates that this record is a detail record. It must be D A unique LDC Identifier for a SDP that will be associated with a smart meter as provided in the request file.
Record Type
Char (1)
SDP ID
Varchar (50)
Universal SDP ID
Fixed Number (8)
This field is populated with the assigned Universal SDP ID. This field is populated with the transaction status. 00 Universal SDP ID assigned successfully 01 Invalid LDC ID 02 Universal SDP ID already assigned to SDP ID 03 Incomplete data request as submitted
Transaction Status
Fixed Number (2)
General: NN Example: 01
30
(NOTE: For Version 00 Specification see Sections 2.1.1 through 2.1.8)
2.1.9
The purpose of this interface is to process requests from the LDC for Universal Service Delivery Point Identifiers (Universal SDP IDs) and to return the assigned Universal SDP IDs to the LDC. This interface meets a business requirement that a province-wide unique identifier be made available to the LDC in order to pair it with an LDC-specific Service Delivery Point ID (SDP ID) and to be able to uniquely identify itself to the MDM/R in future transactions. The LDC uses this interface to request one or more Universal SDP IDs at a time. The LDC sends a Universal SDP ID Assignment Request File with an LDC ID that uniquely identifies the LDC, along with LDC-generated SDP IDs to which the corresponding Universal SDP IDs is assigned to through this interface. SDP IDs are generated by the LDC, and are unique within the LDCs systems. The file version number for the Universal SDP ID Assignment Request File version 01 remains unchanged at version 00. The Universal SDP ID Assignment Response File is sent back to the LDC with a Universal SDP ID assigned against every SDP ID in the Universal SDP ID Assignment Request File. The Universal SDP ID Assignment Response File for version 01 of this specification adds an End-Of-File (EOF) record and the response file version number is changed to 01. This interface uses the Universal SDP ID Generator features within the MDM/R system to manage the assignment of Universal SDP IDs. Universal SDP IDs and SDP IDs are described in detail in Section 3 of the MDM/R Detailed Design Document, Service Delivery Point.
2.1.10 Integration Version 01

2.1.10.1 File Direction
Universal SDP ID Assignment Request: LDC to the MDM/R Universal SDP ID Assignment Response: MDM/R to the LDC
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.
31
2.1.11 Business Rules Version 01

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

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

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

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

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

2.1.16.1 Universal SDP ID Assignment Request File Version 01 2.1.16.1.1 File Name Record for the Universal SDP ID Assignment Request File
Table 2.1.7 File Name Record for the Universal SDP ID Assignment Request File
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.1.16.1.2 Universal SDP ID Assignment Request File Header Record
33
Table 2.1.8: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD
Data Element
Record Type
Data Type/Length
Char(1)
Format
General: A Specific: H General: AAAAAAAA Example: ORG30153 General: NNNNNNNN Example: 543
Required
Y
Comments
This field indicates that this record is a header record. It must be H The unique organization identifier assigned to the LDC during the registration/enrollment process. Populated with an LDC generated identifier for the request. Used to correlate the Universal SDP ID Assignment response with the request. The date and time the data in this file was produced.
LDC ID
Char (8)
Request ID
Number (8)
Request Date and Time
Date/Time
yyyyMMddHHmmss
2.1.16.1.3 Universal SDP ID Assignment Request File Detail Record
The data records start after the header and will contain one line for each request of an individual Universal SDP ID as defined in table 2.1.9.
Table 2.1.9 UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD
Data Element
Record Type
Data Type/Length
Char (1)
Format
General: A Specific: D No format prescribed
Required
Y
Comments
This field indicates that this record is a detail record. It must be D Either: a) A unique LDC Identifier for a SDP that will be associated with a smart meter. If the LDC does not have a unique value for each SDP, then one can potentially be derived (e.g. potentially combining the LDC premise # and socket # at that premise), or b) An LDC identifier for a virtual SDP (not any physical SDP but rather an aggregation other physical Universal SDP IDs) for which a Universal SDP ID needs to be assigned.
SDP ID
Varchar (50)
2.1.16.2
Universal SDP ID Assignment Response File Version 01
2.1.16.2.1 File Name Record for the Universal SDP ID Assignment Response File
34
Table 2.1.10
File Name Record for the Universal SDP ID Assignment Response File
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.1.16.2.2 Universal SDP ID Assignment Response File Header Record

Table 2.1.11 UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD
Data Element
Record Type
Data Type/Length
Char(1)
Format
General: A Specific usage: H General: AAAAAAAA Example: ORG23153 General: NNNNNNNN Example: 543 yyyyMMddHHmmss
Required
Y
Comments
This field indicates that this record is a header record. Value must be H The unique organization identifier assigned to the LDC during the registration/enrollment process. Populated with the Request ID from the Universal SDP ID Assignment Request file. The date time the data in this file was produced.
LDC ID
Char(8)
Response ID
Number (8)
Response Time
Date/Time
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 IDs for which a Universal SDP ID cannot be assigned. The exception report described in Section 2.1.13 includes these SDP IDs and the reason for the exception.
2.1.16.2.3 Universal SDP ID Assignment Response File Detail Record

Table 2.1.12 UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD
Data Element
Data Type/Length
Format
General: A Specific: D
Required
Comments
This field indicates that this record is a detail record. It must be D
Record Type
Char (1)
35
Data Element
SDP ID
Data Type/Length
Varchar (50)
Format
No format prescribed General: NNNNNNNN Example: 00037482
Required
Y
Comments
A unique LDC Identifier for a SDP that will be associated with a smart meter as provided in the request file.
Universal SDP ID
Fixed Number (8)
This field is populated with the assigned Universal SDP ID. This field is populated with the transaction status. 00 Universal SDP ID assigned successfully 01 Invalid LDC ID 02 Universal SDP ID already assigned to SDP ID 03 Incomplete data request as submitted
Transaction Status
Fixed Number (2)
General: NN Example: 01
2.1.16.2.4 Universal SDP ID Assignment Response File EOF Record
The last record in the response file will be an End of File (EOF) record as described in table 2.1.13. Other than the Record Type being set to E, the remaining fields in this record will contain the same values as found in the header record of the file.
Table 2.1.13 UNIVERSAL SDP ID ASSIGNMENT RESPONSE EOF RECORD
Data Element
Record Type
Data Type/Length
Char(1)
Format
General: A Specific usage: E General: AAAAAAAA Example: ORG23153 General: NNNNNNNN Example: 543 yyyyMMddHHmmss
Required
Y
Comments
This field indicates that this record is the last or end-of-file record of the response file. Value must be E The unique organization identifier assigned to the LDC during the registration/enrollment process. Populated with the Request ID from the Universal SDP ID Assignment Request file.
LDC ID
Char(8)
Response ID
Number (8)
Response Time
Date/Time
The date time the data in this file was produced.
36
2.2
2.2.1
Periodic Audit Synchronization Interface

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

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.
37
File No. 01 One or more Asset Data Files that describes the primary attributes associated with an SDP, a Meter, and a Communication Module File No. 02 One or more Premise Data Files that describes the premise related attributes (e.g. physical address) associated with an SDP File No. 03 One or more Service Agreement Data Files that describe the Framing Structure and Commodity Type associated with an SDP File No. 04 One or more Parameter Data Files that describes additional attributes of an SDP or a Meter. File No. 05 One or more Relationship Data Files that describes the relationship between two assets or an asset and an organization. File No. 06 Not Used (NOTE: The Meter Read Data file has been eliminated from the Version 01 Periodic Audit Synchronization file set. File Number 06 should not be submitted, and if submitted will not be processed by the MDM/R. First and last register readings can be submitted using the Meter Read Interface.) File No. 07 One or more Component SDP Data Files that describes Channel to Channel and Channel to Formula relationships between virtual and physical SDPs for all existing and new Virtual Service Delivery Points.
For Periodic Audit Synchronization Version 01, File Numbers 00, 01, 02, 03, 04 and 05 are mandatory and must be submitted as part of the sync file set. Periodic Audit Synchronization Detail Records are required for each SDP that has either already been created in the MDM/R or is to be created (reference TIS Section 2.2.1). The data contained in the Periodic Audit Synchronization file set must represent a consistent data set for each SDP. In order to allow for the efficient transmission of Synchronization data file sets, synchronization data files can be split or segmented into multiple smaller files. All records in a segmented file must be complete. File segmentation can only be between complete records. Partial records will result in exceptions. For example, an LDC submitting 1000 records for an Asset Data File could submit a single file with 1000 records, or 10 files with 100 records. These file segments must be appropriately named (as described in Section 1.8.3 of this document) and the name of each file submitted in the single Manifest File for the synchronization submission. The Staging Table Loader (STL) will process each segmented file as submitted in the Manifest File for Periodic Audit Synchronization Version 01. The segment numbers of any one file of the file set must include the value 01 but may have gaps and do not need to be sequential. The STL does load the data for each of the mandatory files of the sync file set (i.e. files 01, 02, 03, 04 and 05) in a particular order but does not consider order when loading the data from any one segmented file. A file sent as one segment must have the SEGMENT_NO value set to 01. The Incomplete Synchronization File Set Report informs the LDC that their synchronization file set was not accepted by the MDM/R, The following cases would result in this condition: All files for a particular synchronization file set have not been received after an allowed length of time and has been rejected; The synchronization file set was received out of sequence and is being held, awaiting for the missing synchronization file set(s) to be submitted;
Version 3.3 July 7, 2011 38
The synchronization file set was received out of sequence, the missing synchronization file set(s) have not been received after an allowed length of time, and the file set has been rejected.
The Synchronization Staging Table Loader Exception Report provides exceptions for problems encountered during the staging table loading process which precedes the synchronization process. Any errors encountered other than errors designated as Warning in the report will result in the termination of the loading of the synchronization files.
2.2.2.3 Synchronization File Set Sequencing
The Sequence Number provided as a mandatory element in the Manifest File Header Record defines the processing sequence for both Version 01 Periodic Audit Synchronization and Version 00 Incremental Synchronization file sets. Thus the Sequence Number must be incremented by the LDC for any Periodic or Incremental file set transmission in the sequence that the LDC intends each Periodic Audit Synchronization Version 01 and Incremental Synchronization Version 00 file set to be processed. The Extracted Date Time of each sequential synchronization file set must be greater than or equal to the maximum Extracted Date Time from all previously submitted and successfully processed synchronization file sets. The Extracted Date Time must be the same in each file of the same synchronization file set. Periodic and Incremental Synchronization file sets will be processed in numeric sequence. In the event that an LDC requires a Periodic or Incremental synchronization file set to be processed out of sequence (that is, process a synchronization file set that is not the next file set in sequence), the LDC must communicate to the MDM/R Operator the Sequence Number (i.e. the value of the Sequence Number field in the Manifest File Header Record) of that synchronization file set. The MDM/R Operator will manually set the Sequence Number in the MDM/R. Once this is completed, the LDC can submit the synchronization file set. NOTE: Once the MDM/R operator manually sets the new Sequence Number, the LDC cannot submit a synchronization file set with a Sequence Number less than the new Sequence Number. If the LDC requires a synchronization file set to be processed with a Sequence Number less than the new Sequence Number, the LDC must follow the same process described above. For example, if the most recent Sequence Number is 003726 and the LDC requires that the next synchronization file set to be processed is 003744, the LDC must provide this Sequence Number to the MDM/R Operator. The MDM/R Operator will change the last Sequence Number provided to the MDM/R from 003726 to 003743. When this is done, the LDC would be able to submit the next synchronization file set with the Sequence Number 003744. However, the LDC would not be able to submit synchronization file sets with Sequence Numbers 003727 through 003743 unless they follow the same process to reset the sequence number. The synchronization file set Sequence Number will be updated by the MDM/R upon successful completion of the synchronization process. In the event that the synchronization process (e.g.: file set reported on IR10, file set reported on IR14 as not successfully loaded, or threshold checks are exceeded) does not complete successfully the synchronization file set Sequence Number will not be updated by the MDM/R.
39
2.2.3
Business Rules Version 01

1. Periodic Audit Synchronization supports the submission of records providing the current and future state attribute values describing assets and related attributes. a. With the deployment of EnergyIP Release 6.1+, Periodic Audit Synchronization supports the submission of current and future state attribute values. The Asset Data File and Premise Data File includes one record per asset and premise. The Service Agreement Data File, Parameter Data File, Relationship Data File, and Component SDP Data File can contain multiple records that describe the current state or current and future state of attribute values related to the provided assets. The record provided must only describe the current in effect record (i.e.: the record must have a start date and no end date associated with it) or the current in effect record (i.e.: the record must have a start date and a future end date associated with it) plus a record that will take effect in the future (i.e.: the record must have a future start date and no end date associated with it). Use of end dates prior to the Extracted Date/Time of the synchronization file set is NOT supported in Periodic Audit Synchronization, as Periodic Audit Synchronization is a point in time snapshot. 2. Where an asset or premise exists in the MDM/R and no record is provided in the Periodic Audit Synchronization for that asset or premise then the asset or premise that existed within the MDM/R will be inactivated. Where an service agreement, parameter or relationship exists in the MDM/R and no record is provided in the Periodic Audit Synchronization for that service agreement, parameter or relationship, then the service agreement, parameter or relationship that existed within the MDM/R will be ended with an end date/time equal to the Extracted Date/Time of the synchronization file set submitted in the synchronization process. 3. Where a new attribute value with a start date/time prior to the Extracted Date/Time in the header records of the synchronization files is submitted via Periodic Audit Synchronization, the currently in effect attribute value will be inactivated with an end date/time equal to the submitted start date/time of the new attribute value. a. With the deployment of EnergyIP Release 6.1+, a new attribute value with a start date/time greater than the Extracted Date/Time of the synchronization file set can also be submitted via Periodic Audit Synchronization. This future state record may have an end date/time that is greater than its start date time or have no end date/time. If there is a currently in effect attribute value then it must be provided with an end date/time equal or less than the start date/time of the new submitted future state attribute value. b. The new attribute value start date/time must be greater than or equal to the existing in-effect attribute value start date/time 4. Where the end date of the previous attribute value needs to be prior to the start date of the current relationship for business purposes (e.g. a period of time in which no meter or no account is associated with an SDP), the
40
Incremental Synchronization interface must be used to submit the end date transaction. 5. Three threshold checks are conducted to determine the number of updates.1 Thresholds for these checks are defined with the LDC during Enrollment but may be updated based upon operational and business requirements. These three checks are performed sequentially. Checks 1 and 2 are performed prior to making any updates to the MMD. If either of these checks fail, no updates to the MMD will be made. Check 3 is performed during the synchronization process. Failure of check 3 allows for MMD updates to be made up to the point in the synchronization process at which the check fails but terminates the synchronization process preventing further MMD updates. The three checks are: Critical Tables Check Check 1 Upon submission of the synchronization file set the synchronization staging tables will be populated based on the information contained in the synchronization files. Once the synchronization staging tables have been populated, a check will be performed to ensure that there is at least 1 record in each of a sub-set of the synchronization staging tables. The selection of synchronization staging tables used for this check is configured globally. If each synchronization staging table used for the Critical Tables Check does not contain at least one record, this check has failed. Failure of Check 1 will result in the following: Termination of the synchronization process and creation of a system error notification to the OSP. Notification of the failure is not captured in any of the MDM/R reports provided to the LDC. The OSP will initiate communication of the failure through the Service Management process. No updates will be made to the MMD.
Validate Minimum Records Percentage Check 2 The number of records populated in a larger set of the synchronization staging tables as the result of the current synchronization is compared to the number of records populated in the same set of synchronization staging tables from the previous synchronization. The selection of synchronization staging tables used for this check is configured globally. The defined threshold percentage used for the Validate Minimum Records Percentage Check is configured for each LDC and applies to all selected tables. The comparison is performed on each synchronization staging table and if the difference is less than a defined percentage on any table, this check has failed. The same configured percentage is used on each table. For example, if this threshold is set to 60% and in the previous synchronization there were 10 records, then synchronization will abort if the current synchronization contains less than 6 records in the same synchronization staging table. This check is to prevent erroneously inactivating a large number of SDPs by inadvertently submitting partial files. Failure of this check will result in the following:
These threshold checks are disabled during initial loading of the synchronization and initial testing.
41
Termination of the synchronization process and creation of a system error notification to the OSP. Notification of the failure is not captured in any of the MDM/R reports provided to the MDM/R service recipient. The OSP will initiate communication of the failure through the Service Management process. No updates will be made to the MMD.
Max Compare_Max Publish Check 3 This check is performed during the synchronization process on an expanded set of the synchronization staging tables. For each table, the synchronization process performs a compare to determine the required updates and then performs a publish to make the required updates to the database. The compare and publish steps are performed sequentially on each table. Some tables will require these steps to be performed multiple times. For each table this check is performed in two parts: a. Max Compare Failure During the compare, the number of updates required is compared to a defined value. If the number of updates exceeds this value this check has failed, the synchronization process is terminated, and no updates will be published for the affected compare step. All updates published for previous tables will not be reversed in the MMD. b. Max Publish Failure During the publish the number of exceptions incurred is compared to a defined value. If the number of exceptions exceeds this value this check has failed at the table for which its defined value was exceeded, and the synchronization process will terminate. All updates previously published on the affected publish step and all updates published on prior tables will not be reversed in the MMD. The defined values used for the Max Compare Failure and the Max Publish Failure are configured for each table for each LDC. Failure of either check will result in the following: Termination of the synchronization process and creation of a system error notification to the OSP. Notification of the failure is not captured in any of the MDM/R reports provided to the LDC. The OSP will initiate communication of the failure through the Service Management process. The MMD updates performed and exceptions incurred prior to the failure of the check will be returned in the IR06 and IR07 reports.
6. For SDPs that exist in the MDM/R Master Directory data and in the Periodic Audit Synchronization File set, the MDM/R compares and updates the existing SDP attributes in the MDM/R for which changes have been detected with the respective attributes and relationships provided for the SDPs in the Periodic Audit Synchronization File set. 7. For SDPs that do not exist in the MDM/R Master Directory Data but are in the Periodic Audit Synchronization File with valid LDC ID, SDP ID and an assigned Universal SDP ID, the MDM/R Master Directory data creates the SDP and associates any parameters, service agreements, and relationships that are provided in the Periodic Audit Synchronization File set.
42
8. The processed Periodic Audit Synchronization File sent by the LDC is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 9. The following are exception cases:
a. The MDM/R Synchronization Adapter detects exceptions in regards to invalid pipe (|) delimited file formats and data type errors. b. The MDM/R detects exceptions when the LDC Identifier or Universal SDP ID values are not known by the system. c.
The MDM/R detects exceptions when, in the file, the Universal SDP ID is associated with an LDC Identifier and SDP ID for which that Universal SDP ID was not originally assigned.
d. The MDM/R detects exceptions when a synchronization file does not contain data in a field that is required. e. The MDM/R detect exceptions when an asset (SDP ID, Meter ID, or AMCD ID) is provided in the Relationship Data file that does not exist in the MDM/R or in the submitted synchronization file set. f.
The MDM/R detects exceptions when a virtual SDP (Type field = V in the Asset Data File) is related to either a physical Meter or a CT/PT Multiplier.
g. The MDM/R detects exceptions when either of the following are true without the Relationship Start and End Dates being mutually exclusive:
i.
Multiple Meters are associated to a given SDP
ii. Multiple Accounts are associated to a given SDP iii. Multiple CT/PT Multipliers are associated to a given SDP iv. Multiple Framing Structures are associated to a given SDP v. Multiple VEE Services are associated to a given SDP vi. Multiple AMI Operators are associated to a given SDP vii. Multiple Billing Agents are associated to a given SDP viii. Multiple Energy Service providers are associated to a given SDP 10. Update and exception reports for the Periodic Audit Synchronization are created with the following detail: The Synchronization Updates Report provides a complete listing of the records that were updated via the Periodic Audit Synchronization process. (Reference Report IR06 in Sections 2.4.6 and 2.4.7 of the MDM/R Reports Technical Specifications). The Synchronization Exception Report provides a complete listing of the records that were not updated via the Periodic Audit Synchronization process because an error occurred. (Reference Report IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports Technical Specifications).
43
The interface creates the updates and exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC.
Rules Affecting Future and Retroactive Dating
The data contained in the synchronization file set represent the condition of the master data in LDCs source system(s) at a point in time. This point in time is identified in the header records of the synchronization file set as the Extracted Date Time. This is the date and time that the data in the synchronization file set was extracted from the source system(s). This time will likely be coincident with the time that the files were created. With the deployment of EnergyIP Release 6.1+, the synchronization file sets Extracted Date Time will provide the point in time against which all transactions are evaluated to determine if such transactions are intended to make changes in the past or in the future. Periodic Audit Synchronization will only support the submission of Current State and Future State attribute values. Incremental Synchronization must be used for Prior State attribute value changes and/or corrections. Incremental Synchronization supports the Current State, Future State and Retroactive Date synchronization functionality. Date effective changes are generally state changes related to three specific periods of time, namely Future State, Current State, and Prior State. Three types of value and/or date related changes/corrections can be accomplished using the synchronization process. These are: Future State Value Changes where the new attribute value is being supplied with a Start Date/Time that is after the Extracted Date Time. The Current State attribute value (i.e. the value currently in effect) is also supplied with its existing Start Date/Time and an End Date/Time that precedes or aligns with the Start Date/Time of the Future Date attribute value. The future dated attributes are not considered to be in effect until the future dated attribute value Start Date/Time has been reached. Current State Value Changes where the new attribute value is being supplied with a Start Date/Time that is equal to or after the Start Date/Time of the existing attribute value (i.e. the value currently in effect) in the MMD but starts before the Extracted Date Time provided in the synchronization file set. Once processed, the new attribute value would become the Current State attribute value with no End Date/Time and the previous attribute value is ended with an End Date/Time equal to the Start Date/Time of the supplied new attribute value. Prior State Value and/or Date Corrections where a series of attribute values are being supplied with start date/times that are before the Current State attribute value (i.e. the value currently in effect) already in the MMD and start before the Extracted Date Time provided in the synchronization file set. The processing of the new attribute values and dates is intended to: o Correct Prior State Values where previously submitted attribute values are being corrected but the dates over which these values were effective is remaining unchanged, or
44
Correct Prior State Dates where previously submitted attribute values are remaining unchanged (both value and order over time) but the dates over which they were effective is being corrected, or Correct Prior State Value and Date where both the previously submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules 11. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync V00. 12. The Future Dated Value Change must provide the Current State attribute value that is currently in effect as well as the attribute value that will start at a future date/time. a. The Current State attribute value Start Date/Time must be earlier than the Extracted Date Time. b. The Current State attribute value End Date/Time must be later than the Extracted Date Time, and c. The Current State attribute value End Date/Time must be earlier or equal to the Start Date/Time of the Future Date attribute value. d. If there is not a currently in effect attribute value the Future Date attribute value may be provided alone. 13. Subsequent synchronization file set submissions must include the Future Dated Value Change until it becomes the Current State for that attribute value. a. All subsequent P-Sync V01 submissions must include the pair of records until the Future Dated attribute value becomes the Current State attribute value (currently in effect). b. If the Future Dated attribute value is not provided in a subsequent P-Sync V01 submission then the future dated attribute value will be dropped from the MMD. c. Subsequent I-Sync V00 submissions only need to provide the pair of Future Dated Value Change records if there is a need to change the contents or effective dates of the Future Dated Value Change records. Current State Value Change Business Rules 14. Current State Value Changes can be submitted using P-Sync V01 and I-Sync V00. 15. To end the Current State attribute value (i.e. the value currently in effect) and start a new Attribute value (to become the value currently in effect): a. The P-Sync records may provide the new attribute value with a Start Date/Time that equals or is after the Start Date/Time of the existing attribute value. b. The Periodic Audit Synchronization process will end date the existing attribute value with an End Date/Time equal to the Start Date/Time of the new attribute in accordance with Business Rule No. 3.
45
16. To end the Current State attribute value (i.e. the value currently in effect) and NOT start a new attribute value a. The Incremental Synchronization process must be used to end an existing attribute value in accordance with Business Rule No. 1. Prior State Value and/or Date Corrections Business Rules Prior State Value and/or Date Corrections can ONLY be submitted using the Incremental Synchronization process in accordance with Business Rule No. 4.
2.2.4
Pre-conditions Version 01
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 Periodic Audit Synchronization File.
2.2.5
Post-conditions Version 01
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, associated attributes, and relationships are fully aligned in EnergyIP with data supplied from LDC data sources. The LDC has received the updates report and the exception Reports outlined in Section 2.2.3 via File Transfer Services.
2.2.6
Assumptions Version 01
Information in the Periodic Audit Synchronization File set 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 multichannel meter), multiple Interested Parties roles can be associated to a given SDP, and multiple SDPs can be related to a single account. With the synchronization file set, it may be defined that multiple Accounts can be related to a given SDP, multiple Meters can be related to a given SDP, multiple CT/PT Multipliers can be associated to a given SDP, multiple Framing Structures can be associated to a given SDP, multiple VEE services can be associated to a given SDP, multiple AMI operators can be related to a given SDP, and multiple Billing Agents can be related to a given SDP. These relationships and associations must have mutually exclusive start and end dates (please refer to Business Rule 1.a).
46
2.2.7
Frequency and Timing Version 01

Frequency: The Periodic Audit Synchronization File may be sent as frequently as once per day. The frequency of this synchronization process will be determined jointly between the MDM/R operator and the LDC based on the LDCs experience in keeping their master data consistent. Timing: To Be Determined
2.2.8
2.2.8.1
File Format Periodic Audit Synchronization Version 01 and Incremental Synchronization Version 00
Manifest File
2.2.8.1.1 File Name Record for the Manifest File
Table 2.2.1 FILE NAME RECORD FOR THE MANIFEST FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
An example of this record for a Version 01 Periodic Audit Synchronization file would be:
<FTSFN>ORG11111.ORG22222.3000.01.20070214221345.abcedf.00.01.DAT</FTSFN>
or For a Version 00 Incremental Synchronization file:

<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.00.01.DAT</FTSFN>
2.2.8.1.2 Manifest File Header Record
The second record will be a header record as described in table 2.2.2:

Table 2.2.2 MANIFEST FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General: A Specific: H
P Sync V01 Required

Y
I Sync V00 Required

Y
Description
47
Field
LDC ID
Data Type/Length
Char (8)
Format
General: AAAAAAAA Example: ORG25153 General: AAAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAAAAA A Specific Usage: Manifest yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required

Y
Description
The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with PeriodicAuditSync or IncrementalSync
Process Mode
Varchar (20)
Process Object
Char (20)
Always populated with Manifest
Extracted Date Time
Date/Time
The date and time the data in this synchronization file set was extracted from the source systems. This maybe coincident with the time that the creation of this synchronization file set was started. This mandatory element is a fixed 6 digit value that defines a sequence for Periodic and Incremental synchronization file sets. If an LDC submits a sequence number that is not the next sequential number, the file set will not be processed The value that is placed in this element will begin with 000001 and increment by 1 with every new Periodic Audit Synchronization file set or Incremental Synchronization file set. In the event that the maximum value is reached (999999) then the number will reset to 000001.
Sequence Number
Number (6)
General: AAAAAA Examples: 000001 007353 999999
2.2.8.1.3 Manifest File Detail Record
The Manifest File Detail Record provides a complete list of all of the files that are part of a single synchronization file set. At a minimum, this file must contain one of each file (including the manifest file itself), as defined in Section 1.8.3. If multiple files of the same type are submitted, then all of those file names must be provided in the manifest file.
Table 2.2.3 MANIFEST FILE DETAIL RECORD
Field
Filename
Data Type/Length
Varchar (250)
Format
P Sync V01 Required

Y
I Sync V00 Required

Y
Description
This is the full file name of each synchronization file being submitted as part of the synchronization file set, as described in section 1.8 of this document.
48
2.2.8.2
Asset Data File
2.2.8.2.1 File Name Record for the Asset Data File
Table 2.2.4 FILE NAME RECORD FOR THE ASSET DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.2.8.2.2 Asset Data File Header Record

Table 2.2.5 ASSET DATA FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General; A Specific: H General: AAAAAAAA Example: ORG25153
P Sync V01 Required

Y
I Sync V00 Required
Description
LDC ID
Char (8)
Process Mode
Varchar (20)
General: AAAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync
File Name Record and Header Record are required whether or not Detail Record data are required.
49
Field
Process Object
Data Type/Length
Char (20)
Format
General: AAAAAAAAAAAAA AA Specific Usage: Asset yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required
Description
Always populated with Asset
Extracted Date Time
Date/Time
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
The date and time the data in this synchronization file set was extracted from the source systems. This maybe coincident with the time that the creation of this synchronization file set was started.
2.2.8.2.3 Asset Data File Detail Record
The Asset Data File allows the LDC (or its designated agents) to create various assets within the MDM/R. The following are the different types of assets that are available within the MDM/R: SDP Meter Communication module
ASSET DATA FILE DETAIL RECORD
Table 2.2.6
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General: AAAAAAAA Specific Usage: One of the following SDP Meter Communication Module General: NNNNNNNN Example: 00037482
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. Acceptable values for Periodic Audit Sync and Incremental Synchronization are: SDP Meter Communication Module
Universal SDP ID
Fixed Number (8)
If Record Indicator is SDP, then Y If Record Indicator is not SDP, then N If Record Indicator is SDP, then Y If Record Indicator is not SDP, then N If Record Indicator is SDP or Meter, then Y
SDP ID
Varchar (50)
No format prescribed
The Ontario-wide unique identifier assigned by the Universal SDP ID Assignment Request/Response integration. This field will only be populated if the Record Indicator field is populated with SDP This identifier is maintained in the LDC systems and uniquely identifies the SDP This field will only be populated if the Record Indicator field is populated with SDP For SDPs, this indicates whether this is a physical or virtual service delivery point. P is for physical. V is for virtual. For Meters, this indicates whether this is a physical or virtual Meter. P is for
Type
Varchar (50)
General: A Specific Usage: ONE of the following
50
Field
Data Type/Length
Format
characters, P or V
P Sync V01 Required

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

If Record Indicator is Meter, then Y If Record Indicator is not Meter, then N
I Sync V00 Required
Description
This field is populated with the length of the interval in minutes that will be delivered from the meter that is related to the SDP. The SDP to Meter Relationship Start Date Time and End Date Time will be used in the Meter to Channel Relationships, Channel to Channel Relationships and Channel Parameters (for derived channels). This is the set identifier that will be used to control the creation of information channels into which Meter Read Data and related derived data will be stored. The SDP to Meter Relationship Start Date Time and End Date Time will be used in the Meter to Channel Relationships, Channel to Channel Relationships and Channel Parameters (for derived channels). NOTE: The synchronization process will use valid values provided in the Asset Data File. If a value is not provided then a default value of 01 will be created. Please refer to Section 2.2.10 Channel Configuration Sets. This is the factor that will be used to multiply the Register Readings received as part of the Meter Transfer Block. The Meter to Comm Module Relationship Start Date Time and End Date Time will be used for this Meter Parameter NOTE: The synchronization process will use valid values provided in the Asset Data File. If a value is not provided then a default value of 1.00 will be created for this Meter parameter.
Channel Configur ation Set
Number (2)
General: NN Specific Usage: One of the following 01 02 03 04 05 06
Scaling Constant
Number (20,10)
General: NNNNN.NN Examples: 1, 100, 130.33 and 99999.99
Asset Extra 1 Asset Extra 2 Asset Extra 3 Asset Extra 4 Asset Extra 5
Varchar (50) Varchar (50) Varchar (50) Varchar (50) Varchar (50)
No format prescribed No format prescribed No format prescribed No format prescribed No format prescribed
This field must be empty This field must be empty This field must be empty This field must be empty This field must be empty
This field must be empty This field must be empty This field must be empty This field must be empty This field must be empty
Reserved for future use Reserved for future use Reserved for future use Reserved for future use Reserved for future use
2.2.8.3
Premise Data File
2.2.8.3.1 File Name Record for the Premise Data File
52
Table 2.2.7
FILE NAME RECORD FOR THE PREMISE DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.2.8.3.2 Premise Data File Header Record

Table 2.2.8 PREMISE DATA FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General; A Specific: H General: AAAAAAAA Example: ORG25153 General: AAAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAAAA AA Specific Usage: Premise yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates that this record is a header record. It must be H The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with PeriodicAuditSync or IncrementalSync
LDC ID
Char (8)
Y File Name Record and Header Record are required whether or not Detail Record data are required. Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
Process Mode
Varchar (20)
Process Object
Char (20)
Always populated with Premise
Extracted Date Time
Date/Time
53
2.2.8.3.3 Premise Data File Detail Record
The Premise Data File Detail Record allows the LDC to provide premise related data to the MDM/R, such as address.
Table 2.2.9 PREMISE DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General: AAAAAAAAAA Specific Usage: Premise General: NNNNNNNN Example: 00037482 No format prescribed
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. For this file this will always be Premise This identifier is maintained in the LDC systems and uniquely identifies the SDP The physical address of the SDP. Alternatively, the LDC may provide the Premise ID or other value as may be determined by the LDC.
Universal SDP ID
Fixed Number (8)
Premise Address
Varchar (100)
City
Varchar (20)
No format prescribed No format prescribed No format prescribed General: AAA Specific Usage: EST
Province
Varchar (20)
Postal Code Time Zone
Varchar (10)
This is the city in which the SDP exists or other value as may be determined by the LDC. This is the province in which the SDP exists or other value as may be determined by the LDC. This is the postal code associated with the SDP or other value as may be determined by the LDC. This is the time zone associated with Meter Read data as stored and presented in the MDM/R. Since all Meter Read data transmitted to the MDM/R must be in Eastern Standard Time (EST) for all premise locations, this value must always be EST. Meter Read data is stored with the Local Read Time = EST and presented in the EnergyIP GUI as Time = EST.
Char(3)
Premise Extra 1 Premise Extra 2 Premise Extra 3
Varchar (50) Varchar (50) Varchar (50)
No format prescribed No format prescribed No format prescribed
This field must be empty This field must be empty This field must be empty
Reserved for future use Reserved for future use Reserved for future use
2.2.8.4
Service Agreement Data File
2.2.8.4.1 File Name Record for the Service Agreement Data File
54
Table 2.2.10
FILE NAME RECORD FOR THE SERVICE AGREEMENT DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.2.8.4.2 Service Agreement File Header Record
The second record will be a header record as described in table 2.2.11

Table 2.2.11 SERVICE AGREEMENT FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General: A Specific: H General: AAAAAAAA Example: ORG83458 General: AAAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAA Specific Usage: Service Agreement yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required
Description
LDC ID
Char (8)
Process Mode
Varchar (20)
Process Object
Varchar (20)
Always populated with Service Agreement
Extracted Date Time
Date/Time
The date and time the data in this synchronization file set was extracted from the source systems. This may be coincident with the time that the creation of this synchronization file set was started.
55
2.2.8.4.3 Service Agreement Data File Detail Record
The Service Agreement Data File allows LDCs to associate Framing Structures to a particular SDP. The data records start after the header and will contain one line for each Service Agreement associated with each Universal SDP ID as defined in table 2.2.12.
Table 2.2.12 SERVICE AGREEMENT DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General: AAAAAAAAAA Specific Usage: Service Agreement General: A Specific Usage: ONE of the following characters, E, or G, or W General: AA Specific Usage: For energy one of 01, 02, 03 or 04 or for demand based framing: 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28. General: NNNNNNNN Example: 00037482 yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. For this file this will always be Service Agreement Always E for when the underlying commodity is electricity. Future placeholders of G for gas and W for water. From this framing structure ID attribute, the MDM/R determines the billing quantities that are to be delivered for the related Universal SDP ID. See Table 2.2.13 for Framing Structure ID code values and associated Framing Structures
Commodity
Char(1)
Framing Structure ID
Char (2)
Universal SDP ID
Fixed Number (8)
This identifier is maintained in the LDC systems and uniquely identifies the SDP This is the date/time for which the Framing Structure and Universal SDP ID relationship starts. This date/time is inclusive and considered to be the start of the day. EnergyIP performs a daily framing process that uses the Framing Structure that is in effect for each SDP at the start of each day. The start date/time should be submitted as the inclusive start of day (N) at time HHmmss = 000000 to assure that each entire day is processed using the same Framing Structure. This time must be reported in EST. NOTE: This date/time must be specified at midnight to support the EnergyIP
Universal SDP ID to Framing Structure Relationship Start Date
Date/Time
56
Field
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Release 7.2 Register Read Calculator process.
Universal SDP ID to Framing Structure Relationship End Date
Date/Time
yyyyMMddHHmmss
For P-Sync, (See note) For I-Sync, N
This is the date/time for which the Framing Structure and Universal SDP ID relationship ends. This date/time is exclusive and considered to be the first moment that the relationship is not in effect. EnergyIP performs a daily framing process that uses the Framing Structure that is in effect for each SDP at the start of each day. The end date/time should be submitted as the exclusive end of day (N + n) at time HHmmss = 000000 (where n 0 whole days) to assure that each entire day is processed using the same Framing Structure. This time must be reported in EST. NOTE 1: This date/time must be specified at midnight to support the EnergyIP Release 7.2 Register Read Calculator process. NOTE 2: For P-Sync this field must be null unless providing an end date/time that is later than the Extracted Date Time. Reserved for future use
Service Agreement Extra 1 Service Agreement Extra 2 Service Agreement Extra 3
Varchar (50)
No format prescribed No format prescribed No format prescribed
Varchar (50)
Reserved for future use
Varchar (50)
Reserved for future use
Table 2.2.13 provides a cross reference of the Framing Structure ID codes to associated Framing Structures together with a brief description of the resulting Billing Quantity data components and associated time reference for each Billing Quantity data component. This table also provides the resulting Energy Purchase Service service type names viewable in the EnergyIP GUI and reported in Report IR06: Synchronization Updates Report for each Framing Structure, together with the Measurement Profile attribute values as viewable in the EnergyIP GUI within the Data Delivery Service and used by EnergyIP to determine the type of Billing Quantity response.
57
Table 2.2.13 Cross Reference Framing Structure ID; Framing Structure; Energy Purchase Service and Measurement Profile Values
Framing Structure ID 01 Framing Structure Billing Quantity Data Components and Time Basis "TOU/CPP (EST)" TOU/CPP kWh (EST) "TOU/CPP (CST)" TOU/CPP kWh (CST) "Hourly" Hourly kWh (EST) "Periodic" Periodic kWh (EST) "Periodic 15 minute Block (EST)" 05 Periodic kWh and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "Periodic 15 minute Block (CST)" Periodic kWh and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) "Periodic 60 minute Block (EST)" Periodic kWh and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "Periodic 60 minute Block (CST)" 08 Periodic kWh and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) "Periodic 15 minute Rolling (EST)" Periodic kWh and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "Periodic 15 minute Rolling (CST)" 10 Periodic kWh and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST) "Periodic 60 minute Rolling (EST)" Periodic kWh and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "Periodic 60 minute Rolling (CST)" Periodic kWh and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST) "Hourly 15 minute Block (EST)" 13 Hourly kWh and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "Hourly 15 minute Block (CST)" Hourly kWh and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) "Hourly 60 minute Block (EST)" 15 Hourly kWh and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "Hourly 60 minute Block (CST)" Hourly kWh and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) "Hourly 15 minute Rolling (EST)" 17 Hourly kWh and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "Hourly 15 minute Rolling (CST)" Hourly kWh and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST) "Hourly 60 minute Rolling (EST)" Hourly kWh and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "Hourly 60 minute Rolling (CST)" 20 Hourly kWh and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST) "TOU/CPP 15 minute Block (EST)" TOU/CPP kWh (EST) and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "TOU/CPP 15 minute Block (CST)" 22 TOU/CPP kWh (CST) and 15 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) Energy Purchase Service Service Type Name Data Delivery Service Measurement Profile Attribute Values "MP TOU Billing Quantities"
"Energy Purchase Service, TOU/CPP (EST)"
02
"Energy Purchase Service, TOU/CPP (CST)"
"MP TOU Billing Quantities"
03
"Energy Purchase Service, Hourly"
"MP Hourly Billing Quantities"
04
"Energy Purchase Service, Periodic"
"MP Periodic Billing Quantities"
"Energy Purchase Service, Periodic 15 minute Block (EST)"
"MP Periodic 15 minute Block Billing Quantities"
06
"Energy Purchase Service, Periodic 15 minute Block (CST)"
07
"Energy Purchase Service, Periodic 60 minute Block (EST)"
"Energy Purchase Service, Periodic 60 minute Block (CST)"
09
"Energy Purchase Service, Periodic 15 minute Rolling (EST)"
"MP Periodic 15 minute Rolling Billing Quantities"
"Energy Purchase Service, Periodic 15 minute Rolling (CST)"
11
"Energy Purchase Service, Periodic 60 minute Rolling (EST)"
12
"Energy Purchase Service, Periodic 60 minute Rolling (CST)"
"Energy Purchase Service, Hourly 15 minute Block (EST)"
"MP Hourly 15 minute Block Billing Quantities"
14
"Energy Purchase Service, Hourly 15 minute Block (CST)"
"Energy Purchase Service, Hourly 60 minute Block (EST)"
16
"Energy Purchase Service, Hourly 60 minute Block (CST)"
"Energy Purchase Service, Hourly 15 minute Rolling (EST)"
"MP Hourly 15 minute Rolling Billing Quantities"
18
"Energy Purchase Service, Hourly 15 minute Rolling (CST)"
19
"Energy Purchase Service, Hourly 60 minute Rolling (EST)"
"Energy Purchase Service, Hourly 60 minute Rolling (CST)"
21
"Energy Purchase Service, TOU/CPP 15 minute Block (EST)"
"MP TOU 15 minute Block Billing Quantities"
"Energy Purchase Service, TOU/CPP 15 minute Block (CST)"
58
Framing Structure ID 23
Framing Structure Billing Quantity Data Components and Time Basis "TOU/CPP 60 minute Block (EST)" TOU/CPP kWh (EST) and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (EST) "TOU/CPP 60 minute Block (CST)" TOU/CPP kWh (CST) and 60 minute Block Demand calculations (EST) with kW77 Peak Demand (CST) "TOU/CPP 15 minute Rolling (EST)"
Energy Purchase Service Service Type Name
Data Delivery Service Measurement Profile Attribute Values "MP TOU 60 minute Block Billing Quantities"
"Energy Purchase Service, TOU/CPP 60 minute Block (EST)"
24
"Energy Purchase Service, TOU/CPP 60 minute Block (CST)"
25
TOU/CPP kWh (EST) and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "TOU/CPP 15 minute Rolling (CST)" TOU/CPP kWh (CST) and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST) "TOU/CPP 60 minute Rolling (EST)" TOU/CPP kWh (EST) and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST) "TOU/CPP 60 minute Rolling (CST)"
"Energy Purchase Service, TOU/CPP 15 minute Rolling (EST)"
"MP TOU 15 minute Rolling Billing Quantities"
26
"Energy Purchase Service, TOU/CPP 15 minute Rolling (CST)"
27
"Energy Purchase Service, TOU/CPP 60 minute Rolling (EST)"
28
TOU/CPP kWh (CST) and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST)
"Energy Purchase Service, TOU/CPP 60 minute Rolling (CST)"
2.2.8.5 Parameter Data File 2.2.8.5.1 File Name Record for the Parameter Data File
Table 2.2.14 FILE NAME RECORD FOR THE PARAMETER DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.2.8.5.2 Parameter Data File
The second record of the file will be a header record as described in table 2.2.15
59
Table 2.2.15
PARAMETER DATA FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General; A Specific: H General: AAAAAAAA Example: ORG47153 General: AAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAAA Specific Usage: Parameter yyyyMMddHHmmss
P Sync V00 Required

Y
I Sync V01 Required
Description
LDC ID
Char (8)
Process Mode
Varchar (20)
Process Object
Varchar (20)
Always populated with Parameter
Extracted Date Time
Date/Time
2.2.8.5.3 Parameter Data File Detail Record
The Parameter Data File Detail Record allows the LDC to associate different parameters with either a meter or an SDP. These parameters are outlined in Table 2.2.16 and 2.2.17.
Table 2.2.16 PARAMETER DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General: AAAAAAAAAA Specific Usage: Parameter General: AAAAAAAAAA Example; 984233 General: AAAAAAAAA
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. For this file this will always be Parameter
UDC ID
Varchar(50)
Param Name
Varchar(50)
Depending on what kind of parameter is being submitted, this value will be either the Universal SDP ID or the Meter ID that will be associated with the parameter. This defines the type of parameter that is being submitted. For UDC ID = Universal SDP ID, values are: Loss Factor Classification Service Volts Service Amps
60
Field
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Service Phases Service Form Dem-firm #1 Dem-firm #2 Dem-firm #3 Dem-firm #4 IVR PIN Billing Cycle ID CT/PT Multiplier VEE Service For UDC ID = Meter ID, Values are: Dials Meter Volts Meter Amps Meter Phases Meter Form This is the value that is associated with the parameter being submitted. Refer to Table 2.2.17 for descriptions of these data elements. This is the start date associated with the parameter. This date/time is inclusive and is considered the first moment that the parameter is active. This time must be reported in EST. This is the end date associated with the parameter. This date/time is exclusive and considered to be the first moment that the parameter is not in effect. This time must be reported in EST. NOTE: For P-Sync this field must be null unless providing an end date/time that is later than the Extracted Date Time.
Param Value
Refer to Table 2.2.17
Start Date Time
Date/Time
yyyyMMddHH mmss
End Date Time
Date/Time
yyyyMMddHH mmss
Table 2.2.17
Data Values for Param Value field
Param Value
Loss Factor Classification
Data Type/Length
Number (2)
Format
P Sync V01 Required

N
I Sync V00 Required

N
Description
If UDC ID = Universal SDP ID General: NN Valid Values: 01 through 12 This will be used to drive aggregation. For each LDC and for each loss factor classification, the MDM/R will produce a data set with 24 hourly totals that represent the aggregation for each hour across SDPs sharing the same loss factor classification. NOTE: This SDP Parameter will be displayed in the EnergyIP GUI with an Attribute Name of Loss Factor Volts of the service to the SDP. Supplied to the MDM/R for informational purposes only. Amps of the service to the SDP. Supplied to the MDM/R for informational purposes only.
Service Volts
Varchar (20)
No format prescribed No format prescribed
Service Amps
Varchar (20)
61
Param Value
Service Phases Service Form
Data Type/Length
Varchar (20)
Format
No format prescribed No format prescribed No format prescribed No format prescribed No format prescribed No format prescribed General: NNNN Examples: 0000 9999
P Sync V01 Required

N
I Sync V00 Required

N
Description
Phase of the service to the SDP. Supplied to the MDM/R for informational purposes only. Service wires i.e. 3 phase 4 wire, 3 phase 3 wire. Supplied to the MDM/R for informational purposes only. Placeholder for future demographic data. Placeholder for future demographic data. Placeholder for future demographic data. Placeholder for future demographic data. A number assigned by the LDC to permit the current Customers access to their meter read and Billing Quantity data via the IVR (see Section 13 of the MDM/R Detailed Design Document). NOTE: This SDP Parameter will be displayed in the EnergyIP GUI with an Attribute Name of IVR PIN This ID specifies the billing cycle that the MDM/R will use to deliver billing quantities for the Universal SDP ID in a scheduled push approach. See Section 2.6 for details. This SDP Parameter will be stored/displayed by EnergyIP GUI in the Route ID field with a value = ORG_ID + Billing Cycle ID. NOTE: The Start Date Time or End Date Time for this SDP parameter must NOT be later than the Extracted Date Time for the synchronization file set. The multiplier that should be applied to the metering data received from the AMCC. NOTE 1: This multiplier is the product of the meter multiplier and any applicable CT and PT ratios. If a unity value or no value is provided in a Periodic Audit Synchronization, the CT/PT Multiplier will not be applied to interval consumption data, effectively defaulting the value to 1 although values of 1 are not stored in the MMD. If no value is provided in an Incremental Synchronization, no change will be made to the existing data. Values = 0 are not processed by the MDM/R. This SDP Parameter will be stored/displayed in the EnergyIP GUI as CT-PT Multiplier with the value displayed in the form as entered by the MDM/R Administrator. See also specification for Report IR06, Version 01, SDP CTPT Detail Record
Varchar (20)
Dem-firm #1 Dem-firm #2 Dem-firm #3 Dem-firm #4 IVR PIN
Varchar (50) Varchar (50) Varchar (50) Varchar (50) Fixed Number (4)
N N N N N
N N N N N
Billing Cycle ID
Varchar (3)
General: AAA Examples: 1 C45
Y, if Scheduled PUSH is used for Billing Quantities N, if Request/ Response is used exclusively
Y, if Scheduled PUSH is used for Billing Quantities N, if Request/ Response is used exclusively
CT/PT Multiplier
Number (20,10)
General: NNNNN.N N Examples: 1, 100 130.33. and 99999.99
62
Param Value
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
in the MDM/R Reports Technical Specifications. NOTE 2: The Start Date Time or End Date Time for this SDP parameter must NOT be later than the Extracted Date Time for the synchronization file set. NOTE 3: Change to the CT/PT Multiplier must be accompanied by a corresponding actual or logical change to the SDP to Meter Relationship. A logical change to a SDP to Meter Relationship is defined as ending and starting the SDP to Meter Relationship for the same meter.
VEE Service
Char (2)
General : AA Example : 02
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario. If UDC ID = Meter ID
This defines the VEE rule set that applies to the Universal SDP ID defined below. Allowable values: 01, 02, 03, 04 30 Valid values will only include established VEE services.
Dials
Number (2)
General: NN Examples include: 6
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario. N N N N
This is the number of dials or in the case of solid state meters, the number of digits reported by the AMCC for this meter. NOTE 1: The meter Dials parameter value is used by the Dial Rollover Algorithm for both the Billing Validation Sum Check and the Register Read Calculator. Volts of the Meter. Supplied to the MDM/R for informational purposes only. Amps of the Meter. Supplied to the MDM/R for informational purposes only. Phase of the Meter. Supplied to the MDM/R for informational purposes only. This is the meter form factor for the SDP as defined by the ANSI C12.10 standard (i.e. 2S, 16S, etc). Supplied to the MDM/R for informational purposes only.
Meter Volts Meter Amps Meter Phases Meter Form
Varchar (20) Varchar (20) Varchar (20) Varchar (20)
No format prescribed No format prescribed No format prescribed No format prescribed
N N N N
2.2.8.6
Relationship Data File
2.2.8.6.1 File Name Record for the Relationship Data File
63
Table 2.2.18
FILE NAME RECORD FOR THE RELATIONSHIP DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)

2.2.8.6.2 Relationship Data File Header Record
Table 2.2.19 RELATIONSHIP DATA FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General; A Specific: H General: AAAAAAAA Example: ORG84153 General: AAAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAAAA AAA Specific Usage: Relationship yyyyMMddHHmms s
P Sync V01 Required

Y
I Sync V00 Required
Description
LDC ID
Char (8)
Process Mode
Varchar (20)
Process Object
Varchar (20)
Always populated with Relationship
Extracted Date Time
Date/Time
64
2.2.8.6.3 Relationship Data File Detail Record
The Relationship Data File Detail Record allows the LDC to define the relationship between assets and/or accounts in the MDM/R. The LDC or its designated agent must submit the relationships as defined in table 2.2.20
Table 2.2.20 DEFINED RELATIONSHIPS
Values Relationship Identifier 1

SDP SDP METER SDP SDP SDP SDP
Values Relationship Identifier 2

METER ACCOUNT COMMUNICATION MODULE BILLING AGENT AMI OPERATOR ENERGY SERVICE PROVIDER CCA SERVICE PROVIDER
Required Relationship
Required Optional Required Required Required Optional Optional
Future Dates
Not Allowed Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed
Table 2.2.21
RELATIONSHIP DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General: AAAAAAAAAA Specific Usage: Relationship
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. For this file this will always be Relationship Based on what is submitted in the Object 1 field, this value could be The Universal SDP ID The Meter ID
Object 1
If Relationship Identifier 1 is SDP - Fixed Number (8) METER Varchar (50) Varchar (50) General: AAAAAAAAAA Specific Usage SDP or METER
Relations hip Identifier 1
Y Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
This is the type of asset being submitted in the Relationship Identifier 1 field Acceptable values are defined in table 2.2.20
Object 2
If Relationship Identifier 2 is: METER Varchar (50) ACCOUNT Varchar(50) COMMUNICA TION MODULE Varchar(50) BILLING AGENT, AMI OPERATOR, ENERGY SERVICE PROVIDER, or CCA SERVICE PROVIDER
Y, if field is : METER, COMMUNICA TION MODULE, BILLING AGENT, AMI OPERATOR N, if field is: ACCOUNT, ENERGY SERVICE PROVIDER, CCA SERVICE PROVIDER
Based on what is submitted in the Object 2 field, this value could be The Meter ID The Account ID The AMCD ID The Billing Agent Organization ID The AMI Operator Organization ID The Energy Service Provider Organization ID The CCA Organization ID NOTE 1: The SDP to ACCOUNT relationship is used to track Customer move in/ move out actions. Account changes provide estimation services only against the current account, and also provide segmentation of Billing Quantity response for account change events. These services are not
65
Field
Data Type/Length
Char(8)
Format
P Sync V01 Required
I Sync V00 Required
Description
provided if an account is not provided. NOTE 2: The SDP-ACCOUNT relationship will be ended if an Account ID is not submitted for P Sync V01. NOTE 3: The SDP to BILLING AGENT relationship determines the organization to which Billing Quantity values are provided in each Billing Quantity response. NOTE 4: The SDP to AMI OPERATOR relationship determines the agent organization that may submit Meter Read data. Both an agent organization designated in this relationship and the LDC may each submit Meter Read data for the same SDP. NOTE 5: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. NOTE 6: The SDP to CCA SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to another organization registered with the MDM/R for which a customer contract relationship exists. This is the type of asset being submitted in the Object 2 field Acceptable values are defined in table 2.2.20
Relations hip Identifier 2
Varchar (50)
General: AAAAAAAAAA Specific Usage One of: METER ACCOUNT COMMUNICA TION MODULE BILLING AGENT AMI OPERATOR ENERGY SERVICE PROVIDER CCA SERVICE PROVIDER yyyyMMddHH mmss
Start Date Time
Date/Time
This is the start date of the relationship. This date/time is inclusive and is considered the first moment that the relationship is active. This time must be reported in EST. NOTE 1: This date/time if specified for the SDP to Account Relationship must be at midnight to support the EnergyIP Release 7.2 Register Read Calculator
66
Field
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
process. NOTE 2: The date/time specified for the SDP to Meter Relationship should reflect the actual time of the meter installation to allow processing of any first transmission of interval data or register read data.
End Date Time
Date/Time
yyyyMMddHH mmss
For P-Sync, (See note) For In-Sync, N
This is the end date of the relationship. This date/time is exclusive and considered to be the first moment that the relationship is not in effect. This time must be reported in EST. NOTE 1: This date/time if specified for the SDP to Account Relationship must be at midnight to support the EnergyIP Release 7.2 Register Read Calculator process. NOTE 2: The date/time specified for the SDP to Meter Relationship should reflect the actual time of the meter removal to allow processing of any final transmission of interval data or register read data. NOTE 3: For P-Sync this field must be null unless providing an end date/time that is later than the Extracted Date Time. Please refer to Table 2.2.20 for relationships that can use future dates.
2.2.8.7
Meter Reads Data File
This file will not be used as part of Periodic Audit Synchronization Version 01 or Incremental Synchronization Version 00. Synchronization File Number 06 should not be submitted as part of any synchronization file set. Any File Number 06 listed in a Manifest File will be ignored, all submitted records related to File Number 06 will not be processed, and no error message will be returned. NOTE: First and last register readings may be submitted using the Meter Read Interface.
2.2.8.8 Component SDP Channel to Channel & Channel to Formula Data File
2.2.8.8.1 File Name Record for the Component SDP Channel to Channel & Channel to Formula Data File
Table 2.2.22 FILE NAME RECORD FOR THE COMPONENT SDP CHANNEL TO CHANNEL & CHANNEL TO FORMULA DATA FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Specific Usage: <FTSFN>
Required
Y
Description
This field always contains the record type <FTSFN>
67
Field Name
File Name
Data Type/Length
Varchar (250)
Format
Refer to Section 1.8 Specific Usage: </FTSFN>
Required
Y
Description
This field contains the name of the file on the originating system, as defined in Section 1.8 This field always contains the record type </FTSFN>
Suffix
Char (8)

<FTSFN>ORG11111.ORG22222.4000.00.20070214221345.abcdef.07. 02.DAT</FTSFN>
2.2.8.8.2 Component SDP Channel to Channel & Channel to Formula Data File Header Record
Table 2.2.23 COMPONENT SDP CHANNEL to CHANNEL & CHANNEL to FORMULA DATA FILE HEADER RECORD
Field
Record Type
Data Type/Length
Char (1)
Format
General; A Specific: H General: AAAAAAAA Example: ORG88153 General: AAAAAAAAAAA Specific Usage: PeriodicAuditSync or IncrementalSync General: AAAAAAAAAAAA Specific Usage: ComponentSDP yyyyMMddHHmmss
P Sync V01 Required

Y
I Sync V00 Required
Description
LDC ID
Char (8)
Y File Name Record and Header Record are required if Detail Record data are required. Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
Process Mode
Varchar (20)
Process Object
Char (20)
Always populated with ComponentSDP
Extracted Date Time
Date/Time
2.2.8.8.3 Component SDP Channel to Channel Data File Detail Record
The Channel to Channel relationship data records start after the header and will contain one line for each contributing Member interval information channel associated
68
with a Parent interval information channel as defined in table 2.2.24. These records must be provided in conjunction with a related Channel to Formula record. NOTE: Until the Retroactive / Future Dated support is deployed in EnergyIP, Component SDP Data File records will not be processed into EnergyIP.
Table 2.2.24 COMPONENT SDP CHANNEL TO CHANNEL DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar (50)
Format
General; AAAAAAAA Specific Usage: Channel to Channel
P Sync V01 Required

Y
I Sync V00 Required
Description
This field indicates the type of record being submitted. For this file detail record this will always be Channel to Channel
Parent Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: 00098472
The Ontario-wide unique identifier assigned by the Universal SDP ID Assignment Request /Response integration. The Parent of the Channel to Channel Relationship must be a Virtual Interval Channel which can exist on a physical or virtual SDP depending on the specified Meter Asset Channel Configuration Set. This is the Parent Universal SDP ID associated with the contributing Member Universal SDP ID below. This is the unit of measurement for the Parent of the Channel to Channel Relationship. The Parent is always a Virtual Interval Channel. Acceptable values are: kWh, kVARh and kVAh This is the interval length for the Parent of the Channel to Channel Relationship. The Parent is always a Virtual Interval Channel. Acceptable values expressed in minutes are: 5, 10, 15, 30 and 60
Parent Unit of Measure ment
Varchar (15)
General: AAAAAAAAAA Specific Usage: One of kWh, kVAh, or kVARh
Parent Interval Length
Number (3)
General: NNN Specific Usage: One of 5, 10, 15, 30, or 60
69
Field
Member Universal SDP ID
Data Type/Length
Fixed Number (8)
Format
P Sync V01 Required

Y
I Sync V00 Required
Description
The Ontario-wide unique identifier assigned by the Universal SDP ID Assignment Request /Response integration. This is the contributing Member Universal SDP ID associated with the Parent Universal SDP ID above. The contributing Member of the Channel to Channel Relationship can be either a Physical Interval Channel which can exist on a physical SDP or a Virtual Interval Channel existing on a Physical SDP or Virtual SDP depending on the specified Meter Asset Channel Configuration Set. This is the unit of measurement for the contributing Member of the Channel to Channel Relationship. Acceptable values are: kWh, kVARh and kVAh This is the interval length for the contributing Member of the Channel to Channel Relationship. The contributing Member can be a Physical Interval Channel or a Virtual Interval Channel. Acceptable values expressed in minutes are: 5, 10, 15, 30 and 60 This is a symbolic name for the contributing Member of the Channel to Channel Relationship. The Alias is used in the Formula Expression provided in the related Channel to Formula record. This is the inclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship starts. This is the exclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship ends.
Member Unit of Measure ment
Varchar (15)
General: AAAAAAAAAA Specific Usage: One of kWh, kVAh, or kVARh General: NNN Specific Usage: One of 5, 10, 15, 30, or 60
Member Interval Length
Number (3)
Member Alias
Varchar (30)
General: AAAAAAAAAA
Channel to Channel Relations hip Start Date Channel to Channel Relations hip End Date
Date/Time
yyyyMMddHHm mss
Date/Time
yyyyMMddHHm mss
70
Field
Member Channel Type
Data Type/Length
Varchar (50)
Format
General: A Specific Usage: ONE of the following characters, P or V
P Sync V01 Required

Y
I Sync V00 Required

Description
This indicates whether the Member channel is a physical or virtual channel
2.2.8.8.4 Component SDP Channel to Formula Data File Detail Record
The Channel to Formula relationship data records start after the header and will contain one line for each Parent interval information channel as defined in table 2.2.25. These records must be provided in conjunction with related Channel to Channel records. NOTE: Until the Retroactive / Future Dated support is deployed in EIP, Component SDP Data File records will not be processed into EIP.
Table 2.2.25 COMPONENT SDP CHANNEL TO FORMULA DATA FILE DETAIL RECORD
Field
Record Indicator
Data Type/Length
Varchar 50
Format
General; AAAAAAAA Specific Usage: Channel to Formula General: NNNNNNNN Example: 00098472
P Sync V01 Required

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

Y
I Sync V00 Required
Description
This field identifies the type of calculation to be performed with the result stored in the identified Parent Interval Information Channel. Summator sums all contributing members with the result stored in the identified Parent Interval Information Channel. Expression evaluates the provided formula expression using the Alias identified contributing Members with the result stored in the identified Parent Interval Information Channel. This is the inclusive date/time for which the Parent Interval Channel to Formula relationship starts.
Channel to Formula Relations hip Start Date Channel to Formula Relations hip End Date Formula Expressi on
Date/Time
yyyyMMddHHm mss
Date/Time
yyyyMMddHHm mss
This is the exclusive date/time for which the Parent Interval Channel to Formula relationship ends. NOTE: For P-Sync this field must be null unless providing an end date/time that is later than the Extracted Date Time. This is the Formula Expression that will be evaluated when the Formula Type is specified as Expression. Note: Refer to Section 3 of the MDM/R Detailed Design Document for information on the valid operators that can be used when constructing the Formula Expression.
Varchar (2000)
General: AAAAAAAAAA
If Formula Type is specified as Expression then Y Otherwise N
72
2.2.9 SDP Activation and Services Relationships

Table 2.2.26 identifies all of the SDP attributes and which attributes are required throughout for the various SDP services.
Table 2.2.26 SDP ATTRIBUTES AND SERVICES
Effective Date Attributes
SDP Attributes
SDP Life Cycle
SDP Processing Services
SDP Service Providers
Universal SDP ID LDC ID SDP ID Premise Address City Province Postal Code Time Zone Service Status Load Status Type (Physical or Virtual) For SDP & Meter Loss Factor Classification Retailer Classification Billing Cycle (denotes the Data Delivery Service) Commodity Billing Agent ID AMI Operator ID ENERGY SERVICE PROVIDER ID Customer Contracted Agent ID Service Volts Service Amps Service Phases Service Form Number of Dials
NO NO NO NO NO NO NO NO NO NO NO
NA M M NA NA NA NA NA NA NA NA
MF MF MF NA NA NA NA NA NA NA NA
MF MF MF MO MO MO MO MP MP MP MF
MF MF MF MO MO MO MO O O O MF
MF MF MF MO MO MO MO MP M M MF
YES
NA
NA
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
This attribute is no longer used by EnergyIP YES YES YES YES YES YES YES YES YES YES YES NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA O M O O O O O O O O O O M M MP O O O O O O MP O M O O O O O O O O MP O M O O O O O O O O MP O M O MP O O O O O O MP O M O MP O O O O O O MP O M M O O O O O O O MP O M O O O O O O O O MP O M O O O O O O O O MP O M O M O O O O O O MP O M M O O O O O O O MP O M O O M O O O O O MP O M O O O M O O O O MP
73
CCA Service Provider
Data Delivery service
Virtual Channel Persistence Service
SDP Object Created
Energy Purchase Service
Generic Framing Service
Start/stop Dates Associated
Data Collection service
Data Collection Provider
Energy Service Provider
Billing Service Provider
Universal SDP Requested
Universal SDP Assigned
SDP Inactive
VEE Service
SDP Active
SDP Attributes
SDP Life Cycle
Dem-firm#1 Dem-firm#2 Dem-firm#3 Dem-firm#4 Meter ID AMCD ID Meter AMCC Type Related to data collection service Meter Volts Meter Amps Meter Phase Meter Form Last Register Read First Register Read Account ID CT/PT Multiplier IVR PIN Framing Structure (denotes the Energy Purchase Service) VEE Service (denotes the VEE service) Channel Configuration Set (Replaces Unit of Measurement) Interval Length Demand Reset Parent Universal SDP ID (virtual SDP only) Parent Unit of Measurement (virtual SDP only) Parent Interval Length (virtual SDP only) Member Universal SDP
YES YES YES YES YES YES
NA NA NA NA NA NA NA
NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
O O O O O O O O O O O O O O O O O
O O O O MP MP MP O O O O O O O O O M
O O O O O O O O O O O O O O O O O
O O O O MP MP MP O O O O O O O O O O
O O O O M MP MP O O O O O O O O O M
O O O O MP MP MP O O O O O O O O O M
O O O O M MP MP O O O O O O O O O M
O O O O M MP MP O O O O OP OP O OP O M
O O O O MV O O O O O OP O M
O O O O MP MP MP O O O O OP OP O OP O M
YES YES YES YES YES YES YES YES YES YES
NA NA NA NA NA NA NA NA NA NA
YES
NA
NA
MP
MP
MP
MP
MP
NO NO
NA NA
NA NA
O O
M MP
O O
MP MP
M M
MP MP
M M
M M
M MV
O MP
M M
O -
O -
This attribute is no longer used by EnergyIP YES NA NA O O O O MV O MV O MV -
YES
NA
NA
MV
MV
MV
YES YES
NA NA
NV NA
O O
O O
O O
O O
MV MV
O O
MV MV
O O
MV MV
74
CCA Service Provider -
SDP Object Created
SDP Inactive
VEE Service
SDP Active
SDP Attributes
SDP Life Cycle
ID (physical or virtual SDP) Member Unit of Measurement (physical or virtual SDP) Member Interval Length (physical or virtual SDP) Member Alias (physical or virtual SDP) Formula Type (Target virtual channel) Formula Expression (Target virtual channel) YES NA NA O O O O MV O MV O MV -
YES YES YES YES
NA NA NA NA
NA NA NA NA
O O O O
O O O O
O O O O
O O O O
MV MV MV MV
O O O O
MV MV MV MV
O O O O
MV MV MV MV
Table 2.2.27 SDP ATTRIBUTES AND SERVICES - Legend

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

Table 2.2.28 identifies all of the Channel Configuration Sets that are used to define which channels by Unit of Measurement and Type are required for a given meter (physical or virtual)
Table 2.2.28 CHANNEL CONFIGURATION SETS
Number
Classification
Type
Interval Data
Register Data
Derived Data (virtual Notes channel)

Derived data calculations controlled by specified SDP Framing Structure
Physical Meter 01 Default Configuration Physical Channels (kWh only) Physical Meter Physical C & I 02 Configuration Physical Channels (kWh, kVARh, derived kVAh & kVA) Physical Channel kWh Physical Channel kVARh Virtual Channel kVAh Physical Channel kWh Physical Channel kVAh Physical Channel kWh Physical Meter Physical C & I 04 Configuration Physical Channels (kWh, kVARh, kVAh) Physical Channel kVARh Physical Channel kVAh Virtual Channel kWh (with virtual channel formula) Virtual Channel kWh Virtual SDP Virtual Meter Virtual 06 Configuration Virtual Channels (kWh, kVARh, derived kVAh & kVA) (with virtual channel formula) Virtual Channel kVARh (with virtual channel formula) Virtual Channel kVAh (with virtual channel formula) Physical Derived Usage Channel kWh & kW Demand Physical Channel kVARh Derived Usage Derived Usage & kVA Demand Derived Usage Physical Channel kWh & kW Demand Physical Channel kVAh Derived Usage & kVA Demand Physical Channel kWh Derived Usage Physical Channel kWh & kW Demand
Derived data calculations controlled by specified SDP Framing Structure Virtual kVAh channel data derived from physical kWh & kVARh channel data
Physical Meter 03 Physical C & I Configuration Physical Channels (kWh, kVAh)
Derived data calculations controlled by specified SDP Framing Structure Derived data calculations controlled by specified SDP Framing Structure
Physical Derived Usage Channel kWh & kW Demand Physical Channel kVARh Physical Channel kVAh Derived Usage Derived Usage & kVA Demand Derived data calculations controlled by specified SDP Framing Structure Derived data calculations controlled by specified SDP Framing Structure
Virtual SDP 05 Virtual Configuration Virtual Meter Virtual Channels (kWh)
Derived Usage & kW Demand
Derived Usage & kW Demand Derived data calculations controlled by specified SDP Framing Structure Virtual kVAh channel data derived from virtual kWh & kVARh channel data
Derived Usage
Derived Usage & kVA Demand
76
2.3
2.3.1
Incremental Synchronization Interface

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

This is a batch process involving the transfer and processing of pipe (|) delimited text files.
77
An Incremental Synchronization File may contain information related to only those assets whose attributes or relationship data has changed since the last Incremental or Periodic Audit Synchronization File set. Version 00 of the Incremental Synchronization consists of the same set of seven files as Version 01 of the Periodic Audit Synchronization. The seven files are as follows: File No. 00 A Manifest File, listing each file that is included in the specific Periodic Audit Synchronization data set submission. File No. 01 One or more Asset Data Files that describes the primary attributes associated with an SDP, a Meter, and a Communication Module File No. 02 One or more Premise Data Files that describes the premise related attributes (e.g. physical address) associated with an SDP File No. 03 One or more Service Agreement Data Files that describe the Framing Structure and Commodity Type associated with an SDP File No. 04 One or more Parameter Data Files that describes additional attributes of an SDP or a Meter. File No. 05 One or more Relationship Data Files that describes the relationship between two assets or an asset and an organization. File No. 06 Not Used (NOTE: The Meter Read Data file has been eliminated from the Version 00 Incremental Synchronization file set. File Number 06 should not be submitted, and if submitted will not be processed by the MDM/R. First and last register readings can be submitted using the Meter Read Interface.) File No. 07 One or more Component SDP Data Files that describes relationships between virtual and physical SDPs for updates to Virtual Service Delivery Points.
For Incremental Synchronization Version 00, File Numbers 00, 01, 02, 03, 04 and 05 are mandatory and must be submitted as part of the Incremental Synchronization file set. These five files must contain a consistent data set for the updates being submitted, which for some updates may result in an empty file. Thus, not only can a file consisting of only a File Name Record and a File Header Record be submitted without any Detail Records, such a file for any one or more of the mandatory files must be submitted. In order to allow for the efficient transmission of Synchronization data file sets, synchronization data files can be split or segmented into multiple smaller files. All records in a segmented file must be complete. File segmentation can only be between complete records. Partial records will result in exceptions. For example, an LDC submitting 1000 records for an Asset Data File could submit a single file with 1000 records, or 10 files with 100 records. These file segments must be appropriately named (as described in Section 1.8.3 of this document) and the name of each file submitted in the single Manifest File for the synchronization submission. The Staging Table Loader (STL) will process each segmented file as submitted in the Manifest File for Incremental Synchronization Version 00. The segment numbers of any one file of the file set may have gaps and do not need to be sequential. The STL does load the data for each of the mandatory files of the sync file set (i.e. files 01, 02, 03, 04 and 05) in a particular order but does not consider order when loading the data from any one segmented file.
78
The Incomplete Synchronization File Set Report informs the LDC that their synchronization file set was not accepted by the MDM/R, The following cases would result in this condition: All files for a particular synchronization file set have not been received after an allowed length of time and has been rejected; The synchronization file set was received out of sequence and is being held, awaiting for the missing synchronization file set(s) to be submitted; The synchronization file set was received out of sequence, the missing synchronization file set(s) have not been received after an allowed length of time, and the file set has been rejected. The Synchronization Staging Table Loader Exception Report provides exceptions for problems encountered during the staging table loading process which precedes the synchronization process. Any errors encountered other than errors designated as Warning in the report will result in the termination of the loading of the synchronization files.
2.3.2.3 Synchronization File Set Sequencing
The Sequence Number provided as a mandatory element in the Manifest File Header Record defines the processing sequence for both Version 01 Periodic Audit Synchronization and Version 00 Incremental Synchronization file sets. Thus the Sequence Number must be incremented by the LDC for any Periodic or Incremental file set transmission in the sequence that the LDC intends each Periodic Audit Synchronization Version 01 and Incremental Synchronization Version 00 file set to be processed. The Extracted Date Time of each sequential synchronization file set must be greater than or equal to the maximum Extracted Date Time from all previously submitted and successfully processed synchronization file sets. The Extracted Date Time must be the same in each file of the same synchronization file set. Periodic and Incremental Synchronization file sets will be processed in numeric sequence. In the event that an LDC requires a Period or Incremental synchronization file set to be processed out of sequence (that is, process a synchronization file set that is not the next file set in sequence), the LDC must communicate to the MDM/R Operator the Sequence Number (i.e. the value of the Sequence Number field in the Manifest File Header Record) of that synchronization file set. The MDM/R Operator will manually set the transaction identifier in the MDM/R. Once this is completed, the LDC can submit the synchronization file set. NOTE: Once the MDM/R operator manually sets the new transaction identifier, the LDC cannot submit synchronization file sets with a sequence number less than the new transaction identifier. If the LDC requires a synchronization file set to be processed with a transaction identifier less than the new transaction identifier, the LDC must follow the same process described above. For example, if the most recent transaction Identifier is 003726 and the LDC requires that the next synchronization file set to be processed is 003744, the LDC must provide this transaction identifier to the MDM/R Operator. The MDM/R Operator will change the last transaction identifier provided to the MDM/R from 003726 to 003743. When this is done, the LDC would be able to submit synchronization file set transaction identifier 003744. However, the LDC would not be able to submit synchronization file sets with transaction identifier 003727 through 003743 unless they follow the same process to reset the sequence number.
79
The synchronization file set transaction identifier will be updated by the MDM/R upon successful completion of the synchronization process. In the event that the synchronization process (e.g. file set reported on IR10, file set reported on IR14 as not successfully loaded, or threshold checks are exceeded) does not complete successfully the synchronization file set sequence number will not be updated by the MDM/R.
2.3.3 Business Rules Version 00

1. The File Name Record, File Header Record and File Detail Records must be included for each of the synchronization files for which detail data are required. Necessary files will be listed in the Manifest File Detail Record. For each change, the affected detail records will be transmitted per the Business Scenarios for Incremental Synchronization specified in Section 2.3.9. If there is no change, no detail records will be transmitted. 2. The Max Compare_Max Publish Check is performed for each Incremental Synchronization. Thresholds for these checks are defined by the LDC during Enrollment but may be updated based upon operational and business requirements. Max Compare_Max Publish Check This check is performed during the synchronization process on an expanded set of the synchronization staging tables. For each table, the synchronization process performs a compare to determine the required updates and then performs a publish to make the required updates to the database. The compare and publish steps are performed sequentially on each table. Some tables will require these steps to be performed multiple times. For each table this is performed in two parts: a. Max Compare Failure During the compare the number of updates required is compared to a defined value. If the number of updates exceeds this value this check has failed, the synchronization process is terminated, and no updates will be published for the affected compare step. All updates published for previous steps will not be reversed in the MMD. b. Max Publish Failure During the publish the number of exceptions incurred is compared to a defined value. If the number of exceptions exceeds this value this check has failed at the table for which its defined value was exceeded and the synchronization process will terminate. All updates previously published on the affected publish step and all updates published on prior tables will not be reversed in the MMD. The defined values used for the Max Compare Failure and the Max Publish Failure are configured for each table for each LDC. (These defined values are configured separately for P-Sync and I-Sync.) Failure of either check for any table will result in the following: Termination of the synchronization process and creation of a system error notification to the OSP. Notification of the failure is not captured in any of the MDM/R reports provided to the MDM/R service recipient. The OSP will initiate communication of the failure through the Service Management process.
80
The MMD updates performed and exceptions incurred prior to the failure of the check will be returned in the IR06 and IR07 reports.
3. For SDPs that exists in the MDM/R Master Directory and in the Incremental Synchronization File, the MDM/R replaces the SDP attributes in the MDM/R with the attributes and relationships for the Universal SDP IDs in the Incremental Synchronization File. 4. For SDPs that do not exist in the MDM/R Master Directory but are in the Incremental Synchronization File with valid LDC ID, SDP ID and an assigned Universal SDP ID, the MDM/R creates the SDP and associates any parameters, service agreements, and relationships that are provided in the Incremental Synchronization File set. 5. The processed Incremental Synchronization File sent by the LDC is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 6. The following are exception cases: a. The MDM/R Synchronization Adapter detects exceptions in regards to invalid pipe (|) delimited file formats and data type errors. b. The MDM/R detects exceptions when the LDC Identifier or Universal SDP ID values are not known by the system. c. The MDM/R detects exceptions when, in the file, the Universal SDP ID is associated with an LDC Identifier and SDP ID for which that Universal SDP ID was not originally assigned. d. The MDM/R detects exceptions when a Parent interval information channel within the Component SDP Data format is not a virtual interval information channel. e. The MDM/R detects exceptions when a virtual SDP (Type field = V in the Asset Data File) is related to either a physical Meter or a CT/PT Multiplier. f. The MDM/R detects exceptions when a synchronization file does not contain data in a field that is required.
g. The MDM/R detect exceptions when an asset (SDP ID, Meter ID, or AMCD ID) is provided in the Relationship Data file that does not exist in the MDM/R or the submitted synchronization file set. h. The MDM/R detects exceptions when either of the following are true without the Relationship Start and End Dates being mutually exclusive: i. ii. iii. iv. v. vi. vii.
Multiple Meters are associated to a given SDP Multiple Accounts are associated to a given SDP Multiple CT/PT Multipliers are associated to a given SDP Multiple Framing Structures are associated to a given SDP Multiple VEE Services are associated to a given SDP Multiple AMI Operators are associated to a given SDP Multiple Billing Agents are associated to a given SDP
81
viii.
Multiple Energy Service providers are associated to a given SDP
7. Update and exception reports for the Incremental Synchronization are created with the following detail. The Synchronization Updates Report provides a complete listing of the records, that were updated via the Incremental Synchronization process (Refer to Report IR06 in Sections 2.4.6 and 2.4.7 of the MDM/R Reports Technical Specifications). The Synchronization Exception Report provides a complete listing of the records that were not updated via the Incremental Synchronization process because an error occurred (Refer to Report IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports Technical Specifications).
The interface creates exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC.
Rules Affecting Future and Retroactive Dating
The data contained in the synchronization file set represent the condition of the master data in LDCs source system(s) at a point in time. This point in time is identified in the header records of the synchronization file set as the Extracted Date Time. This is the date and time that the data in the synchronization file set was extracted from the source system(s). This time will likely be coincident with the time that the synchronization file set was created. With the deployment of EnergyIP Release 6.1+ the synchronization file sets Extracted Date Time will provide the point in time against which all transactions are evaluated to determine if such transactions are intended to make changes in the past or in the future. Periodic Audit Synchronization will only support the submission of Current State and Future State attribute values. Incremental Synchronization must be used for Prior State attribute value changes and/or corrections. Incremental Synchronization supports the Current State, Future State and Prior State synchronization functionality. Date effective changes are generally state changes related to three specific periods of time, namely Future State, Current State, and Prior State. Three types of value and/or date related changes/corrections can be accomplished using the synchronization process. These are: Future State Value Changes where the new attribute value is being supplied with a Start Date/Time that is after the Extracted Date Time. The Current State attribute value (i.e. the value currently in effect) is also supplied with its existing Start Date/Time and an End Date/Time that precedes or aligns with the Start Date/Time of the Future Date attribute value. The future dated attributes are not considered to be in effect until the future dated attribute value Start Date/Time has been reached. Current State Value Changes where the new attribute value is being supplied with a Start Date/Time that is equal to or after the Start Date/Time of the existing attribute value (i.e. the value currently in effect) in the MMD but starts before the Extracted Date Time provided in the synchronization file set. Once processed, the new attribute value would become the Current State attribute value with no End Date/Time and the previous
82
attribute value is ended with an End Date/Time equal to the Start Date/Time of the supplied new attribute value. Prior State Value and/or Date Corrections where a series of attribute values are being supplied with start date/times that are before the Current State attribute value (i.e. the value currently in effect) already in the MMD and start before the Extracted Date Time provided in the synchronization file set. The processing of the new attribute values and dates is intended to: o Correct Prior State Values where previously submitted attribute values are being corrected but the dates over which these values were effective is remaining unchanged, or Correct Prior State Dates where previously submitted attribute values are remaining unchanged (both value and order over time) but the dates over which they were effective is being corrected, or Correct Prior State Value and Date where both the previously submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules 8. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync V00. 9. The Future Dated Value Change must provide the attribute value that is currently in effect as well as the attribute value that will start at a future date/time. 10. Subsequent synchronization file set submissions must include the Future Dated Value Change until it becomes the Current State for that Attribute Value. a. All subsequent P-Sync V01 submissions must include the pair of records until the Future Dated attribute value becomes the Current State Attribute value (currently in effect). b. If the Future Dated attribute value is not provided in a subsequent I-Sync V00 submission then the future dated attribute value will be dropped from the MMD. c. Subsequent I-Sync V00 submissions only need to provide the pair of Future Dated Value Change records if there is a need to change the contents or effective dates of the Future Dated Value Change records. Current State Value Change Business Rules 11. Current State Value Changes can be submitted using P-Sync V01 and I-Sync V00. 12. To end the Current State attribute value (i.e. the value currently in effect) and start a new Attribute value (to become the value currently in effect): a. If the new attribute value Start Date Time is greater than the Start Date Time of the existing attribute value (i.e. the value currently in effect) then the existing attribute value must be provided with the same Start Date Time as that existing attribute value stored in the MMD and its new End Date Time that is equal to or less than the Start Date/Time of the new attribute value.
Version 3.3 July 7, 2011 83
b. If the new attribute value Start Date Time is equal to the Start Date Time of the existing attribute value (i.e. the value currently in effect) then the existing attribute value must NOT be provided. The synchronization will end the existing attribute value by setting its End Date/Time equal to the Start Date/Time of the existing attribute value. c. If the new attribute value Start Date Time is less than the Start Date Time of the existing attribute value (i.e. the value currently in effect) and there are no Prior State records before the existing attribute value, then the existing attribute value must NOT be provided. The synchronization will end the existing attribute value by setting its End Date Time equal to the Start Date Time of the existing attribute value. 13. To end the Current State Attribute value (i.e. the value currently in effect) and NOT start a new Attribute value a. The I-Sync records must provide the attribute value that is currently in effect in the MMD (providing the same Start Date/Time as that existing attribute value stored in the MMD) and its new End Date/Time. Prior State Value and/or Date Corrections Business Rules 14. Prior State Value and/or Date Corrections can ONLY be submitted using I-Sync V00. 15. The series of Prior State attribute value records must provide a complete set of attribute values with effective date/times to correct the existing attribute values for that period of time up to and including the Current State attribute value and Future State attribute value if required. a. Existing attribute value records that are being replaced by the Prior State attribute value records must NOT be provided. Any existing attribute value record that is no longer required once the Prior State attribute value records are applied will have the End Date Time set equal to the Start Date Time by the synchronization process. 16. The earliest record in the Prior State correction series submission must provide an attribute value with a Start Date/Time that aligns with an existing Prior State attribute value record and its Start Date/Time within the MMD. The existing prior state attribute value record within the MMD must be in effect for a period of time where the existing Prior State attribute value record has a Start Date/Time that is less than its End Date Time (i.e. the existing record value within the MMD must be a value that exists for a non-zero length of time). This rule applies to the following special cases: a. Where the series of Prior State attribute value records needs to start before the Start Date/Time of the first attribute value record within the MMD then the first record in the series of Prior State attribute value records can specify a Start Date/Time that predates the earliest Start Date/Time for the attribute value records in the MMD and the series of Prior State attribute value records will correct all of the attribute value records in the MMD for that SDP. b. Where the series of Prior State attribute value records needs to start after the Start Date/Time of the first attribute value record within the MMD then the first record in the series of Prior State attribute value records must be the earliest attribute value record and its Start Date/Time from the MMD
84
with its End Date/Time set to be equal to its Start Date/Time. This will result in the first attribute value record within the MMD being reduced to being effective for no time since Start Date/Time is an inclusive date/time and End Date/Time is an exclusive date/time and if these two date/times are the same then there is no effect period for the record. It will remain in the MMD for audit purposes only. The remaining records in the series of Prior State attribute value records will correct all of the attribute value records in the MMD up to and including the Current State attribute value record and Future State attribute value if required for that SDP.
2.3.4
Pre-conditions
The 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 multichannel 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.
85
2.3.7
Frequency and Timing

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

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

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

Tables 2.3.1 through 2.3.14 list business scenarios that can happen during the course of regular business for a LDC, and the Files and detail data Fields that must be submitted as part of an Incremental Synchronization file set for updates using the Incremental Synchronization process. The Data Type/Length, Format, and Description for the fields listed in the tables below can be found in Section 2.2.16, Periodic Audit Synchronization Version 01.
Table 2.3.1 Business Scenario 1 - Meter Change
File
Asset (The meter asset being ended/removed from the SDP must be provided so that the related Meter to Channel relationships and Scaling Constant can also be ended) (This is a required element.)
Field
Record Indicator Meter ID Type Interval Length Channel Configuration Set
Notes
Meter This is the meter ID of the meter being removed from the SDP This indicates whether this is a physical or virtual meter. This is the Interval Length of the old Meter This identifies the set of information channels to be created for the old meter.
Part 1: Remove the Old Meter from SDP
86
File
Field
Scaling Constant
Notes
This is the Scaling Constant for the old meter. Relationship The SDP ID that the meter is being removed from SDP The Meter ID that is being removed METER The inclusive start date/time of the relationship The exclusive end date/time of the relationship Communication Module This is the AMCD ID that is related to the meter being removed. This is the AMCC Type that is associated with the AMCD ID. Relationship This is the Meter ID that is being removed. METER This is the AMCD ID that is related to the meter that is being removed. COMMUNICATION MODULE This is the inclusive start date/time of the relationship. This field can be left null if the Meter to Communication Module Relationship is being left In-Effect. OR This field can provide the exclusive end date/time if the Meter to Communication Module Relationship is being ended when the old meter is removed.
Relationship (This is a required element.)
Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.) Relationship (only applicable to Communication Modules related to Physical Meters) Required to correctly end the related Data Collection Service. (This is a required element.)
Record Indicator AMCD ID AMCC Type Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time
Part 2: Provide the New Meter and all other Mandatory elements of the existing SDP
Asset (OPTIONAL) Record Indicator Universal SDP ID SDP ID Type Service Status Load Status Asset (This is a required element.) Record Indicator Meter ID Type Interval Length SDP This is the Universal SDP ID that was assigned to the SDP ID This is the SDP ID that resides in the LDCs system of record P or V, depending on whether the SDP is Physical or Virtual Y or N, depending if the service is connected to the SDP or not Y or N, depending if there is load connected to the meter or not Meter This is the meter ID of the meter being installed This indicates whether this is a physical or virtual meter. This is the Interval Length of the new
87
File
Field
Channel Configuration Set Scaling Constant
Notes
Meter This identifies the set of information channels to be created for the new meter. This is the Scaling Constant for the new meter. Communication Module This is the AMCD ID that is being installed This is the AMCC Type that is associated with the AMCD ID. Parameter This is the Meter ID that the Dials will be associated to Dials These are the number of dials on the new meter. This is the inclusive start date/time of the new Dials parameter. This field must be null. Relationship This is the Meter ID that is being installed. METER This is the AMCD ID that is being installed. COMMUNICATION MODULE This is the inclusive start date/time of the relationship. This field is left null. Parameter This is the Universal SDP ID that the VEE Service is associated to VEE Service This is the existing VEE Service. This is the inclusive start date/time of the existing VEE Service parameter. This field must be null.
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.) Parameter (This only needs to be provided if the new meter does not already exist)
Record Indicator AMCD ID AMCC Type Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time
Relationship (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Parameter (OPTIONAL)
Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time
Part 3: Create relationships between SDP, Meter and Organizations

Relationship (This is a required element.) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) Record Indicator Object 1 Relationship The SDP ID that the meter is being added to SDP This is the Meter ID that is being installed. METER This is the inclusive start date/time of the relationship. This field is left null. Relationship The SDP ID that the meter is being added to
88
File
Field
Relationship Identifier 1 Object 2
Notes
SDP This is the Billing Agent for the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect. BILLING AGENT This is the inclusive start date/time of the relationship. This field is left null. Relationship The SDP ID that the meter is being added to SDP This is the AMI Operator for the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect. AMI OPERATOR This is the inclusive start date/time of the relationship This field is left null. Parameter This is the Universal SDP ID that the Billing Cycle will be associated to Billing Cycle ID This is the Billing Cycle ID for the Universal SDP ID. This is the inclusive start date/time of the Billing Cycle ID parameter. This field must be null.
Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2
Relationship Identifier 2 Start Date Time End Date Time Parameter (OPTIONAL) Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time
Part 4: (OPTIONAL) Provide any or no other element of the existing SDP definition see Table 2.3.14
(Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.2
Business Scenario 2 - Meter Removal
File
Asset (The meter asset being ended/removed from the SDP must be provided so that the related Meter to Channel relationships and Scaling Constant can also be ended) (This is a required element.)
Field
Record Indicator Meter ID Type Interval Length Channel Configuration Set Scaling Constant
Notes
Meter This is the meter ID of the meter being removed from the SDP This indicates whether this is a physical or virtual meter. This is the Interval Length of the old Meter This identifies the set of information channels to be created for the old meter. This is the Scaling Constant for the old meter. Relationship The SDP ID that the meter is being removed from SDP
Part 1: Remove the Old Meter (provide ONLY the identified elements)
Record Indicator Object 1 Relationship Identifier 1
89
Object 2 Relationship Identifier 2 Start Date Time End Date Time Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.) Relationship (only applicable to Communication Modules related to Physical Meters) Required to correctly end the related Data Collection Service. (This is a required element.) Record Indicator AMCD ID AMCC Type Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time
The Meter ID that is being removed METER The inclusive start date/time of the relationship The exclusive end date/time of the relationship Communication Module This is the AMCD ID that is related to the meter being removed This is the AMCC Type that is associated with the AMCD ID Relationship This is the Meter ID that is being removed METER This is the AMCD ID that is related to the meter that is being removed COMMUNICATION MODULE This is the inclusive start date/time of the relationship This field can be left null if the Meter to Communication Module Relationship is being left In-Effect OR This field can provide the exclusive end date/time if the Meter to Communication Module Relationship is being ended when the old meter is removed
Table 2.3.3
Business Scenario 3 - Add new meter
File
Part 1: Create the New Meter
Asset (OPTIONAL)
Field
Record Indicator Universal SDP ID SDP ID Type Service Status Load Status
Notes
SDP This is the Universal SDP ID that was assigned to the SDP ID This is the SDP ID that resides in the LDCs system of record P or V, depending on whether the SDP is Physical or Virtual Y or N, depending if the service is connected to the SDP or not Y or N, depending if there is load connected to the meter or not Meter This is the meter ID of the meter being installed This indicates whether this is a physical or virtual meter. This is the Interval Length of the new Meter This identifies the set of information
Asset (This is a required element.)
Record Indicator Meter ID Type Interval Length Channel Configuration Set
90
File
Field
Scaling Constant
Notes
channels to be created for the new meter. This is the Scaling Constant for the new meter. Communication Module This is the AMCD ID that is being installed This is the AMCC Type that is associated with the AMCD ID Parameter This is the Meter ID that the Dials will be associated to Dials These are the number of dials on the new meter This is the inclusive start date/time of the new Dials parameter This field must be null Relationship This is the Meter ID that is being installed METER This is the AMCD ID that is being installed COMMUNICATION MODULE This is the inclusive start date/time of the relationship This field is left null Parameter This is the Universal SDP ID that the VEE Service is associated to VEE Service This is the existing VEE Service This is the inclusive start date/time of the VEE Service parameter This field must be null
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.) Parameter (This is a required element.)
Record Indicator AMCD ID AMCC Type Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time
Relationship (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Part 2: Create relationships between SDP, Meter and Organizations

Relationship (This is a required element.) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship The SDP ID that the meter is being added to SDP This is the Meter ID that is being installed METER This is the inclusive start date/time of the relationship This field is left null Relationship The SDP ID that the meter is being added to SDP This is the Billing Agent for the SDP.
91
File
Field
Notes
NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect.
BILLING AGENT This is the inclusive start date/time of the relationship This field is left null Relationship The SDP ID that the meter is being added to SDP This is the AMI Operator for the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect. AMI OPERATOR This is the inclusive start date/time of the relationship This field is left null Parameter This is the Universal SDP ID that the Billing Cycle will be associated to Billing Cycle ID This is the Billing Cycle ID for the Universal SDP ID This is the inclusive start date/time of the Billing Cycle ID parameter This field must be null
Relationship Identifier 2 Start Date Time End Date Time Parameter (Mandatory if Scheduled PUSH is used for Billing Quantities) Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time
Table 2.3.4
Business Scenario 4 - Service Cut at Pole
File
Part 1
Field
Record Indicator Universal SDP
Notes
SDP This is the Universal SDP ID associated with the SDP where the meter was cut at the pole The is the SDP ID associated with the SDP where the meter was cut at the pole P N This will be either Y or N, which ever status is currently true for the SDP.
SDP ID Type Service Status Load Status
92
Table 2.3.5
Business Scenario 5 - Booting a Meter
File
Part 1
Field
Record Indicator Universal SDP SDP ID Type Service Status Load Status
Notes
SDP This is the Universal SDP ID associated with the SDP where the meter was booted The is the SDP ID associated with the SDP where the meter was booted P This will be either Y or N, which ever status is currently true for the SDP. N
Table 2.3.6
Business Scenario 6 - Framing Structure Change
File
Service Agreement (This is a required element.)
Field
Record Indicator Commodity Framing Structure ID Universal SDP ID Universal SDP ID to Framing Structure Relationship Start Date Universal SDP ID to Framing Structure Relationship End Date
Notes
Service Agreement E This is the existing Framing Structure ID This is the Universal SDP ID associated with the existing Framing Structure This is the inclusive start date/time of the existing Framing Structure This is the exclusive end date/time of the existing Framing Structure
Part 1: End the existing Framing Structure
Part 2: Start the new Framing Structure

Service Agreement (This is a required element.) Record Indicator Commodity Framing Structure ID Universal SDP ID Service Agreement E This is the new Framing Structure ID This is the Universal SDP ID to be associated with the new Framing Structure This is the inclusive start date/time of the new Framing Structure. The start date/time should be equal to the end date/time of the existing Framing Structure This field must be null Relationship The Universal SDP ID that the meter is being added to SDP This is the Account ID that is associated with the Universal SDP ID ACCOUNT This is the inclusive start date/time of the relationship
Universal SDP ID to Framing Structure Relationship Start Date
Universal SDP ID to Framing Structure Relationship End Date Relationship NOTE: The new Framing Structure will not show in the GUI Account Tab if an SDP to Account Relationship is not in-effect. (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time
93
File
Field
End Date Time
Notes
This field is left null
Part 3: If the Framing Structure Change also results in a change of the Energy Service Provider then end the existing relationship between the SDP and the existing Energy Service Provider (Retailer). Start the new relationship between the SDP and the new Energy Service Provider. This is only necessary if the Energy Service Provider must be changed on the SDP
Relationship (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship This is the Universal SDP ID that the Energy Service Provider is associated to SDP This is the existing Energy Service Provider for the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship Relationship This is the Universal SDP ID that the Energy Service Provider is associated to SDP This is the new Energy Service Provider for the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER This is the inclusive start date of the relationship This field must be null
Relationship Identifier 2 Start Date Time End Date Time
Table 2.3.7
Business Scenario 7 - Billing Cycle ID Change
File
Parameter (This is a required element.)
Field
Record Indicator UDC ID Param Name
Notes
Parameter This is the Universal SDP ID that the Billing Cycle is associated to Billing Cycle ID
Part 1: End the existing Billing Cycle
94
File
Field
Param Value Start Date Time End Date Time
Notes
This is the existing Billing Cycle ID This is the inclusive start date/time of the existing Billing Cycle ID parameter This is the exclusive end date/time of the existing Billing Cycle ID parameter
Part 2: Start the new Billing Cycle

Parameter (This is a required element.) Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time Parameter This is the Universal SDP ID that the Billing Cycle will be associated to Billing Cycle ID This is the new Billing Cycle ID This is the inclusive start date/time of the new Billing Cycle ID parameter This field must be null
Table 2.3.8
Business Scenario 8 - VEE Service Change
File
Field
Notes
Parameter This is the Universal SDP ID that the VEE Service is associated to VEE Service This is the existing VEE Service This is the inclusive start date/time of the existing VEE Service parameter This is the exclusive end date/time of the existing VEE Service parameter
Part 1: End the existing VEE Service
Part 2: Start the new VEE Service

Parameter (This is a required element.) Record Indicator UDC ID Param Name Param Value Start Date Time End Date Time Asset (OPTIONAL) Record Indicator Universal SDP ID SDP ID Type Service Status Load Status Parameter This is the Universal SDP ID that the VEE Service will be associated to VEE Service This is the new VEE Service This is the inclusive start date/time of the new VEE Service parameter This field must be null SDP This is the Universal SDP ID that was assigned to the SDP ID This is the SDP ID that resides in the LDCs system of record P or V, depending on whether the SDP is Physical or Virtual Y or N, depending if the service is connected to the SDP or not Y or N, depending if there is load
95
File
Asset (OPTIONAL)
Field
Notes
connected to the meter or not Meter This is the meter ID of the existing Meter This indicates whether this is a physical or virtual meter. This is the Interval Length of the existing Meter This identifies the set of information channels related to the existing Meter. This is the Scaling Constant for the existing meter. Relationship The Universal SDP ID that the meter is being added to SDP This is the Meter ID that is installed METER This is the inclusive start date/time of the relationship This field is left null Relationship The Universal SDP ID that the meter is being added to SDP This is the Account ID that is associated with the Universal SDP ID ACCOUNT This is the inclusive start date/time of the relationship This field is left null
Relationship (OPTIONAL)
Relationship NOTE: The new VEE Service will not show in the GUI Account Tab if an SDP to Account Relationship is not in-effect. (OPTIONAL)
Table 2.3.9
Business Scenario 9 - CT/PT Multiplier Change
File
Field
Notes
Parameter This is the Universal SDP ID that the CT/PT multiplier is associated to CT/PT Multiplier This is the existing CT/PT multiplier This is the inclusive start date/time of the SDP to CT/PT Multiplier relationship This is the exclusive end date/time of the SDP to CT/PT Multiplier relationship
Part 1: End the existing CT/PT Multiplier
Part 2: Start the new CT/PT Multiplier

Parameter (This is a required element.) Record Indicator UDC ID Parameter This is the Universal SDP ID that the CT/PT multiplier will be associated to
96
File
Field
Param Name Param Value Start Date Time End Date Time
Notes
CT/PT Multiplier This is the new CT/PT multiplier This is the inclusive start date/time of the CTPT relationship This field must be null
Table 2.3.10
Business Scenario 10 - Account Change
File
Field
Notes
Relationship This is the Universal SDP ID that the existing account is associated to SDP This is the Account ID that is currently associated to the SDP ACCOUNT This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship
Part 1: End relationship between the SDP and the existing Account
Part 2: Start relationship between the SDP and the new Account
Relationship (This is a required element.) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time Relationship This is the Universal SDP ID that the new account is associated to SDP This is the new Account ID that is to be associated to the SDP ACCOUNT This is the inclusive start date/time of the relationship This field must be null
Part 3: If the old Account was under a Retailer Contract then end the existing relationship between the SDP and Energy Service Provider (Retailer). Start the new relationship between the SDP and Energy Service Provider. This is only necessary if the Energy Service Provider must be changed on the SDP
Relationship (OPTIONAL) Record Indicator Object 1 Relationship This is the Universal SDP ID that the existing Energy Service Provider is associated to SDP This is the existing Energy Service Provider for the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer.
97
File
Field
Relationship Identifier 2 Start Date Time
Notes
ENERGY SERVICE PROVIDER This is the inclusive start date/time of the SDP to Energy Service Provider relationship This is the exclusive end date/time of the SDP to Energy Service Provider relationship Relationship This is the Universal SDP ID that the Energy Service Provider is associated to SDP This is the new Energy Service Provider for the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER This is the inclusive start date/time of the SDP to Energy Service Provider relationship This field must be null Service Agreement E This is the Framing Structure ID. This is the Universal SDP ID associated with the Framing Structure This is the inclusive start date/time of the relationship This field must be null
End Date Time
Record Indicator Object 1 Relationship Identifier 1 Object 2
End Date Time Service Agreement (OPTIONAL) Record Indicator Commodity Framing Structure ID Universal SDP ID Universal SDP ID to Framing Structure Relationship Start Date Universal SDP ID to Framing Structure Relationship End Date
Table 2.3.11
Business Scenario 11 - Billing Agent Change
File
Asset (OPTIONAL)
Field
Notes
SDP This is the Universal SDP ID associated with the SDP where the Billing Agent change is taking place This is the SDP ID associated with the SDP where the Billing Agent change is taking place P or V, depending on whether the SDP is Physical or Virtual This is whatever Service Status is associated with the SDP
Part 1: End relationship between the SDP and the existing Billing Agent
SDP ID
Type Service Status
98
File
Field
Load Status
Notes
This is whatever Load Status is associated with the SDP Meter This is the meter ID of the existing meter P or V, depending on whether the Meter is Physical or Virtual This is the Interval Length of the existing meter This identifies the set of information channels associated with the existing meter. This is the Scaling Constant for the existing meter Communication Module This is the AMCD ID This is the AMCC Type that is associated with the AMCD ID Relationship This is the Universal SDP ID that the existing Billing Agent is associated to SDP This is the Billing Agents Organization ID that is currently associated to the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect. BILLING AGENT This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship
Asset (OPTIONAL)
Asset (only applicable to Communication Modules related to Physical Meters) (OPTIONAL) Relationship (This is a required element.)
Record Indicator AMCD ID AMCC Type Record Indicator Object 1 Relationship Identifier 1 Object 2
Part 2: Start relationship between the SDP and the new Billing Agent
Relationship (This is a required element.) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship This is the Universal SDP ID that the new Billing Agent is being associated to SDP This is the new Billing Agents Organization ID that is to be associated to the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect. BILLING AGENT This is the inclusive start date/time of the relationship This field must be null Relationship This is the Universal SDP ID that the AMI Operator is associated to SDP This is the existing AMI Operators Organization ID that is associated to the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
99
File
Field
Notes
AMI OPERATOR This is the inclusive start date/time of the existing AMI Operator relationship This field must be null Relationship The Universal SDP ID that the meter is associated to SDP This is the existing Meter ID that is associated to the SDP METER This is the inclusive start date/time of the relationship This field is left null Relationship This is the Universal SDP ID that the new Billing Agent is being associated to SDP This is the Account ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to ACCOUNT This is the inclusive start date/time of the relationship This field is left null Relationship This is the Meter ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to METER This is the AMCD ID that is currently associated with the Meter ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to COMMUNICATION MODULE This is the inclusive start date/time of the relationship This field is left null
Relationship NOTE: The new Billing Agent will not show in the GUI Account Tab if an SDP to Account Relationship is not in-effect. (OPTIONAL)
Record Indicator Object 1 Relationship Identifier 1 Object 2
Relationship (only applicable to Communication Modules related to Physical Meters) (OPTIONAL)
Record Indicator Object 1
100
Table 2.3.12
Business Scenario 12 - AMI Operator Change
File
Asset (OPTIONAL)
Field
Notes
SDP This is the Universal SDP ID associated with the SDP where the AMI Operator change is taking place This is the SDP ID associated with the SDP where the AMI Operator change is taking place P or V, depending on whether the SDP is Physical or Virtual This is whatever Service Status is associated with the SDP This is whatever Load Status is associated with the SDP Meter This is the Meter ID associated with the SDP where the AMI Operator change is taking place P or V, depending on whether the Meter is Physical or Virtual This is the Interval Length of the existing meter This identifies the set of information channels associated with the existing meter. This is the Scaling Constant for the existing meter COMMUNICATION MODULE This is the AMCD ID This is the AMCC Type that is associated with the AMCD ID Relationship This is the Universal SDP ID that the existing AMI Operator is associated to SDP This is the AMI Operators Organization ID that is currently associated to the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect. AMI OPERATOR This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship
Part 1: End relationship between the SDP and the existing AMI Operator
SDP ID
Type Service Status Load Status Asset (OPTIONAL) Record Indicator Meter ID
Type Interval Length Channel Configuration Set
Scaling Constant Asset (only applicable to Communication Modules related to Physical Meters) (OPTIONAL) Relationship (This is a required element.) Record Indicator AMCD ID AMCC Type Record Indicator Object 1 Relationship Identifier 1 Object 2
Part 2: Start relationship between the SDP and the new AMI Operator
Relationship (This is a required element.) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship This is the Universal SDP ID that the new AMI Operator is being associated to SDP This is the new AMI Operators Organization ID that is to be associated to
101
File
Field
Notes
the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
AMI OPERATOR This is the inclusive start date/time of the relationship This field must be null Relationship This is the Universal SDP ID that the Billing Agent is associated to SDP This is the existing Billing Agents Organization ID that is associated to the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect. BILLING AGENT This is the inclusive start date/time of the existing Billing Agent relationship This field must be null Relationship The Universal SDP ID that the meter is associated to SDP This is the existing Meter ID that is installed METER This is the inclusive start date/time of the relationship This field is left null Relationship This is the Universal SDP ID that the new AMI Operator is being associated to SDP This is the Account ID that is associated with the Universal SDP ID the new AMI Operator is being associated to ACCOUNT This is the inclusive start date/time of the relationship This field is left null Relationship This is the existing Meter ID that is installed METER This is the existing AMCD ID that is installed COMMUNICATION MODULE This is the inclusive start date/time of the relationship This field is left null
Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time Relationship NOTE: The new AMI Operator will not show in the GUI Account Tab if an SDP to Account Relationship is not in-effect. (OPTIONAL) Record Indicator Object 1 Relationship Identifier 1 Object 2
Relationship (only applicable to Communication Modules related to Physical Meters) (OPTIONAL)
102
File
Field
Notes
Table 2.3.13
Business Scenario 13 Energy Service Provider (Retailer) Change
File
Field
Record Indicator Object 1
Notes
Relationship This is the Universal SDP ID that the existing Energy Service Provider is associated to SDP This is the Energy Service Providers Organization ID that is currently associated to the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship Service Agreement E This is the existing Framing Structure ID This is the Universal SDP ID associated with the Framing Structure This is the inclusive start date/time of the relationship This is the exclusive end date/time of the relationship
Part 1: End relationship between the SDP and the existing Energy Service Provider
Relationship Identifier 2 Start Date Time End Date Time Service Agreement (only end the existing Framing Structure if Framing Structure is changing when the Energy Service Provider relationship is changing) (OPTIONAL) Record Indicator Commodity Framing Structure ID Universal SDP ID Universal SDP ID to Framing Structure Relationship Start Date Universal SDP ID to Framing Structure Relationship End Date
Part 2: Start relationship between the SDP and the new Energy Service Provider
Relationship (This is a required element.) Record Indicator Object 1 Relationship This is the Universal SDP ID that the new Energy Service Provider is being associated to SDP This is the new Energy Service Providers Organization ID that is to be associated to the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER
Relationship Identifier 2
103
File
Field
Start Date Time
Notes
This is the inclusive start date/time of the new SDP to Energy Service Provider relationship This field must be null Service Agreement E This is the Framing Structure ID associated with the SDP that the new Energy Service Provider is being associated with. If the Framing Structure was not ended in the previous step, then this will be the existing Framing Structure ID and its Start Date will be its existing start date/time. If the Framing Structure was ended in the previous step, then this is the new Framing Structure ID and the Start Date will be the new start date/time. This is the Universal SDP ID that the Framing Structure will be associated with This is the inclusive start date/time of the relationship This field must be null
End Date Time Service Agreement (OPTIONAL) Record Indicator Commodity Framing Structure ID
Universal SDP ID Universal SDP ID to Framing Structure Relationship Start Date Universal SDP ID to Framing Structure Relationship End Date
Table 2.3.14 Business Scenario 14 Provide all elements that define an SDP in order to either: Create a New SDP; OR Provide the definition of an existing SDP.
File
Field
Record Indicator Universal SDP ID SDP ID Type Service Status Load Status
Notes
SDP This is the Universal SDP ID that was assigned to the SDP ID This is the SDP ID that resides in the LDCs system of record P or V, depending on whether the SDP is Physical or Virtual Y or N, depending if the service is connected to the SDP or not Y or N, depending if there is load connected to the meter or not Meter This is the meter ID of the new or existing meter associated with the Universal SDP ID being provided under this scenario P or V, depending on whether the Meter is Physical or Virtual This is the Interval Length of the new or existing meter This identifies the set of information channels associated with the new or existing meter. Optional defaults to 01 kWh related channels only.
Part 1: Provide Assets: SDP, Meter and Communication Module
Record Indicator Meter ID
Type Interval Length Channel Configuration Set
104
File
Field
Scaling Constant
Notes
This is the Scaling Constant for the new or existing meter. Optional defaults to 1.00 COMMUNICATION MODULE This is the AMCD ID of the new or existing Communication Module associated with the Meter ID being provided under this scenario This is the AMCC Type that is associated with the AMCD ID
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Record Indicator AMCD ID
AMCC Type
Part 2: Provide Premise: for new or existing Premise

Premise (This is a required element.) Record Indicator Universal SDP ID Premise Address Premise This is the Universal SDP ID associated with the premise This is the address, or other value as determined by the LDC, that the SDP resides at This is the city, or other value as determined by the LDC, that the SDP resides in This is the province, or other value as determined by the LDC, that the SDP resides in This is the postal code, or other value as determined by the LDC, that the SDP resides in EST or CST, depending on the time zone the SDP resides in
City
Province
Postal Code
Time Zone
Part 3: Provide mandatory SDP and Meter Parameters for new or existing SDPs
Parameter (Mandatory if Scheduled PUSH is used for Billing Quantities) Record Indicator UDC ID Param Name Param Value Start Date Time Parameter This is the Universal SDP ID that the parameter will be associated to Billing Cycle ID This is the Billing Cycle ID This is the inclusive start date/time for the new or existing Billing Cycle ID parameter This must be null Parameter This is the Universal SDP ID that the parameter will be associated to VEE Service This is the VEE Service This is the inclusive start date/time for the new or existing VEE Service parameter This must be null Parameter This is the Meter ID that the parameter will be associated to Dials This is the number of dials
End Date Time Parameter (This is a required element.) Record Indicator UDC ID Param Name Param Value Start Date Time
End Date Time Parameter (Mandatory for Physical Meters only) Record Indicator UDC ID Param Name Param Value
105
File
Field
Start Date Time
Notes
This is the inclusive start date/time for the number of Dials associated with this new or existing Meter This must be null
End Date Time
Part 4: Provide Framing Structure for new or existing SDPs

Service Agreement (This is a required element.) Record Indicator Commodity Framing Structure ID Universal SDP ID Universal SDP ID to Framing Structure Relationship Start Date Universal SDP ID to Framing Structure Relationship End Date Service Agreement E This is the Framing Structure that will be associated with the SDP This is the Universal SDP ID that the Framing Structure will be associated with This is the inclusive start date/time for the new or existing Framing Structure This must be null
Part 5: Provide relationships between SDP, Meter, Communication Module and Organizations for new or existing SDPs
Relationship (This is a required element.) Record Indicator Object 1 Relationship This is the Universal SDP ID that will be associated with the new or existing meter SDP This is the new or existing Meter ID that will be associated with the SDP METER This is the inclusive start date/time for the new or existing relationship This must be null Relationship This is the Universal SDP ID that will be associated with the new or existing account SDP This is the new or existing Account ID, or other value that the LDC determines will be associated with the SDP ACCOUNT This is the inclusive start date/time for the new or existing relationship This must be null Relationship This is the Meter ID that will be associated with the Communications Module METER This is the AMCD ID that will be associated with the new or existing Meter COMMUNICATION MODULE This is the inclusive start date/time for the new or existing relationship
Relationship Identifier 1 Object 2 Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) NOTE: The Framing Structure; VEE Service; Billing Agent, and AMI Operator will not show in the GUI Account Tab if an SDP to Account Relationship is not in-effect. Record Indicator Object 1
Relationship Identifier 2 Start Date Time End Date Time Relationship (only applicable to Communication Modules related to Physical Meters) (This is a required element.) Record Indicator Object 1
106
File
Field
End Date Time Record Indicator Object 1
Notes
This must be null Relationship This is the Universal SDP ID that will be associated with the new or existing Billing Agent SDP This is the Billing Agent Organization ID that will be associated with the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect. BILLING AGENT This is the inclusive start date/time for the new or existing relationship This must be null Relationship This is the Universal SDP ID that will be associated with the new or existing AMI Operator SDP This is the AMI Operator Organization ID that will be associated with the SDP NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect. AMI OPERATOR This is the inclusive start date/time for the new or existing relationship This must be null Relationship This is the Universal SDP ID that will be associated with the new or existing Energy Service Provider SDP This is the Energy Service Provider Organization ID that will be associated with the SDP NOTE: The SDP to ENERGY SERVICE PROVIDER relationship determines the organization to which read-only web services access is granted for each SDP. LDCs may use this relationship to provide data access to a Retailer organization for which a customer is signed up with the Retailer. ENERGY SERVICE PROVIDER This is the inclusive stat date/time for the new or existing relationship This must be null
Relationship Identifier 2 Start Date Time End Date Time Relationship (This is a required element.) Record Indicator Object 1
Relationship Identifier 2 Start Date Time End Date Time Relationship (OPTIONAL) Relationship Identifier 1 Object 2 Record Indicator Object 1
Part 6: Create new or provide existing Component SDP related elements of Virtual SDPs
Channel to Channel Relationship (Only applicable to Virtual SDPs.) Record Indicator Parent Universal SDP ID Channel to Channel This is the Parent Universal SDP ID associated with the contributing Member Universal SDP ID below. This is the unit of measurement for the Parent of the Channel to Channel
Parent Unit of Measurement
107
File
Field
Notes
Relationship. The Parent is always a Virtual Interval Channel.
This is the interval length for the Parent of the Channel to Channel Relationship. The Parent is always a Virtual Interval Channel. The contributing Member of the Channel to Channel Relationship can be either a Physical Interval Channel which can exist on a physical SDP or a Virtual Interval Channel existing on a Physical SDP or Virtual SDP depending on the specified Meter Asset Channel Configuration Set. This is the unit of measurement for the contributing Member of the Channel to Channel Relationship. This is the interval length for the contributing Member of the Channel to Channel Relationship. The contributing Member can be a Physical Interval Channel or a Virtual Interval Channel. This is a symbolic name for the contributing Member of the Channel to Channel Relationship. The Alias is used in the Formula Expression provided in the related Channel to Formula record. This is the inclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship starts. This is the exclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship ends. Channel to Formula This is the Parent Universal SDP ID associated with the Parent Interval information channel. This is the unit of measurement for the Parent of the Channel to Formula Relationship. The Parent is always a Virtual Interval Channel. This is the interval length for the Parent of the Channel to Formula Relationship. The Parent is always a Virtual Interval Channel. This field identifies the type of calculation to be performed with the result stored in the identified Parent Interval Information Channel. This is the inclusive date/time for which the Parent Interval Channel to Formula relationship starts. This is the exclusive date/time for which the Parent Interval Channel to Formula relationship ends. This is the Formula Expression that will be evaluated when the Formula Type is specified as Expression.
Member Universal SDP ID
Member Unit of Measurement
Member Interval Length
Member Alias
Channel to Channel Relationship Start Date
Channel to Channel Relationship End Date
Channel to Formula Relationship (Only applicable to Virtual SDPs.)
Record Indicator Parent Universal SDP ID
Parent Unit of Measurement
Formula Type
Channel to Formula Relationship Start Date Channel to Channel Relationship End Date Formula Expression
108
File
Field
Record Indicator UDC ID Param Name Param Value Start Date Time
Notes
Parameter This is the Universal SDP ID that the parameter will be associated to Loss Factor Classification This will be used to drive aggregation. This is the inclusive start date/time for the Loss Factor Classification associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Service Volts Volts of the service to the SDP. This is the inclusive start date/time for the Service Volts associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Service Amps Amps of the service to the SDP. This is the inclusive start date/time for the Service Amps associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Service Phases Phase of the service to the SDP. This is the inclusive start date/time for the Service Phase associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Service Form Service wires i.e. 3 phase 4 wire, 3 phase 3 wire. This is the inclusive start date/time for the Service Form associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to
Part 7: Create new or provide existing optional elements of an SDP
End Date Time Parameter (OPTIONAL) Record Indicator UDC ID Param Name Param Value Start Date Time
End Date Time Parameter (OPTIONAL) Record Indicator UDC ID
109
File
Field
Param Name Param Value Start Date Time
Notes
Dem-firm #1 Placeholder for future demographic data. This is the inclusive start date/time for the Demographic-Firmographic #1 value associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Dem-firm #2 Placeholder for future demographic data. This is the inclusive start date/time for the Demographic-Firmographic #2 value associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Dem-firm #3 Placeholder for future demographic data. This is the inclusive start date/time for the Demographic-Firmographic #3 value associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to Dem-firm #4 Placeholder for future demographic data. This is the inclusive start date/time for the Demographic-Firmographic #4 value associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to IVR PIN A number assigned by the LDC to permit the current Customers access to their meter read and Billing Quantity data via the IVR This is the inclusive start date/time for the IVR PIN associated with this new or existing SDP This must be null Parameter This is the Universal SDP ID that the parameter will be associated to CT/PT Multiplier The multiplier that should be applied to the metering data received from the
End Date Time Parameter (OPTIONAL) Record Indicator UDC ID Param Name Param Value
Start Date Time
110
File
Field
Start Date Time
Notes
AMCC. This is the inclusive start date/time for the CT/PT Multiplier associated with this new or existing SDP This must be null Parameter This is the Meter ID that the parameter will be associated to Meter Volts Volts of the Meter. This is the inclusive start date/time for the Meter Volts associated with this new or existing Meter This must be null Parameter This is the Meter ID that the parameter will be associated to Meter Amps Amps of the Meter. This is the inclusive start date/time for the Meter Amps associated with this new or existing Meter This must be null Parameter This is the Meter ID that the parameter will be associated to Meter Phases Phase of the Meter. This is the inclusive start date/time for the Meter Phase associated with this new or existing Meter This must be null Parameter This is the Meter ID that the parameter will be associated to Meter Form This is the meter form factor for the SDP as defined by the ANSI C12.10 standard (i.e. 2S, 16S, etc). This is the inclusive start date/time for the Meter Form associated with this new or existing Meter This must be null Relationship This is the Universal SDP ID that will be associated with the new or existing CCA Service Provider SDP This is the CCA Service Provider Organization ID that will be associated with the SDP
Start Date Time
End Date Time Relationship (OPTIONAL) Record Indicator Object 1
111
File
Field
Notes
CCA SERVICE PROVIDER This is the inclusive start date/time for the new or existing relationship This must be null
112
2.4
Billing Service Standard Interface - Request

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

This is a batch process involving the transfer and processing of the EnergyIP Billing Service Standard Interface RequestMessage files in an .xml file format using the EnergyIP BillingXmlFileImportAdaptor.
2.4.3
Business Rules
1. The following MMD master data and request date/time data conditions must exist: a. The SDP must have a Framing Structure that specifies the framing of interval data into TOU/CPP, Periodic or Hourly kWh energy quantities. The applicable Framing Structures are as specified in the Technical Interface Specifications, Section 2.2.8, Table 2.2.13. b. The RequestMessage must be submitted by the organization (either the LDC or its Billing Agent) associated with the Billing Service for the SDP. The SDP to BILLING AGENT Relationship must be the in-effect relationship for the
113
submitting organization for each SDP as submitted in the Relationship Data file of the Synchronization file set. c. The request must have a valid end date/time for the requested billing period for each SDP. d. If the request has a start date/time for the requested billing period, the start date/time for the requested billing period must be prior to the requested end date/time. e. The billing Request <startTime> (if specified) and <endTime> must be on interval boundaries (e.g. at midnight or the top of the hour for 60 minute interval data). EnergyIP Release 7.2 will support partial day framing for whole intervals only and will not prorate partial intervals for date/time specified between interval boundaries. 2. The duration of the billing period for the Billing Quantity data will be determined in one of two ways: a. The LDC (or its Billing Agent) includes the Request <startTime> and the Request <endTime> in the RequestMessage / Request. The start date and time in each request is inclusive, and the end date and time in each request is exclusive. b. The LDC (or its Billing Agent) includes only the Request <endTime> in the RequestMessage / Request. In this case the <startTime> for the request will equal the date and time of the <endTime> of the billing period for the previous billing period response. 3. With the deployment of EnergyIP Release 7.2 the notion of Billing Window is redefined as a Register Read Billing Window and an additional request Execution Window is introduced (replacing the earlier notion of Billing Window). Billing quantity request processing utilizes these two windows or timeframes as follows: Register Read Billing Window This is the range of time when a register reading must occur to be considered an acceptable end register reading to be used in the billing quantity response. Execution Window This is the range of time during which a billing quantity request remains active.
4. For each request the Register Read Billing Window is determined by the Request <endTime> and the billing service properties. The Request <endTime> sets the date and time of the anchor point around which the Register Read Billing Window is set by the following billing service properties. AllowableReadAge (for on-cycle requests) or OffCycleAllowableReadAge (for off-cycle requests) defines the timeframe before the Request <endTime> within which a register reading is valid for billing quantity processing. Read Window Max (for on-cycle requests) or OffCycle Read Window Max (for off-cycle requests) defines the timeframe after the Request <endTime> within which a register reading is valid for billing quantity processing.
114
5. For each request the Execution Window is determined by the Request <endTime> and the following combinations of the billing service properties and the RequestMessage processStartDate and processEndDate. i. The Request <endTime> sets the Execution Window start date and time. The Execution Window end date and time is set by the Request <endTime> plus the LatestReportDays (for on-cycle requests) or the OffCycleLatestReportDays (for off-cycle requests). This Execution Window can be modified for each request by including the Request <processStartDate> and Request <processEndDate> as follows: ii. The Request <processStartDate> is a date and time specified by the LDC (or its Billing Agent) at which to start processing of the request. If the request includes a <processStartDate> without a <processEndDate>, the end date and time of the Execution Window is the Request <processStartDate> plus the LatestReportDays (for on-cycle requests) or the OffCycleLatestReportDays (for off-cycle requests). iii. If the Request <processStartDate> and <processEndDate> is specified in the request by the LDC (or its Billing Agent) then the start date and time of the Execution Window is the Request <processStartDate> and the end date and time of the Execution Window is the Request <processEndDate>. When both Request <processStartDate> and <processEndDate> are specified in the request the billing service properties are not used. 6. For each request billing exception handling, both ODEST (if enabled for interval data estimation) and ManualReads (for register read calculation), is determined by the Request <endTime> and the following combinations of the billing service properties and the Request <processStartDate> and <processEndDate>. i. The start date and time for the billing exception process is set by the Request <endTime> plus the TriggerAfterDays (for on-cycle requests) or the OffCycleTriggerAfterDays (for off-cycle requests). The billing exception handling process start can be modified for each request by including the Request <processStartDate> and <processEndDate> as follows: ii. The Request <processStartDate> is a date and time specified by the LDC (or its Billing Agent) at which to start processing of the request. If the request includes a <processStartDate> without a <processEndDate>, the start date and time of the billing exception handling process is the Request <processStartDate> plus the TriggerAfterDaysDays (for on-cycle requests) or the OffCycleTriggerAfterDays (for off-cycle requests). iii. When the Request <processStartDate> and <processEndDate> is specified by the LDC (or its Billing Agent) the date time for the Request <processEndDate> must be greater than the date and time of the Request <processStartDate> plus the TriggerAfterDays (for on-cycle requests) or the Request <processStartDate> plus the OffCycleTriggerAfterDays (for off-cycle requests). The billing exception handling process will not initiate if the Request <processEndDate> is less than the Request <processStartDate> plus the TriggerAfterDays (for on-cycle requests) or the Request <processStartDate> plus the OffCycleTriggerAfterDays (for off-cycle requests). 7. Rules Affecting Requests for Retroactive Billing Periods and Re-Billing: To assure the availability of billing exception handling, requests for billing periods
115
submitted at a time later than the end date/time of the Execution Window as determined by the Request <endTime> plus the LatestReportDays (for on-cycle requests) or by the Request <endTime> plus the OffCycleLatestReportDays (for off-cycle requests), the start of the Execution Window and the start of billing exception handling must be determined by the use of the Request <processStartDate>. i. To provide a non-zero Execution Window the Request <processStartDate> must be specified by the LDC (or its Billing Agent) at a date/time later than the RequestMessage / Header <dateTime> or the date/time that the request file will be processed by the MDM/R, whichever is later. This may also be accomplished by the specification of the <processStart Date> and the <processEnd Date> in accordance with Business Rule 5.iii. ii. To provide billing exception handling the Request <processStartDate> must be specified by the LDC (or its Billing Agent) at a date/time later than the RequestMessage / Header <dateTime> or the date/time that the request file will be processed by the MDM/R, whichever is later. This may also be accomplished by the specification of the <processStart Date> and the <processEnd Date> in accordance with Business Rule 6.iii. 8. Rules Affecting Register Reading Changes in Prior Billing Periods: For a ReadsForBilling request, if an End register reading from the prior billing period is found in the billing_detail table, this previously sent end End register reading will be used as the Start register reading for the subsequent billing period request. i. A ReadsForBilling request must be initiated for the affected billing period upon indication of a End register read change on Report BR03: Re-Billing Report to assure that the changed End register reading is used as the Start register reading for the ReadsForBilling request for the subsequent billing period. 9. The following are exception cases: a. EnergyIP detects exceptions when the Universal SDP ID value is not submitted in the billing quantity request. b. EnergyIP detects exceptions when the LDC ID or Universal SDP ID values are not known by the system. c. EnergyIP detects exceptions when the Universal SDP ID is associated with an LDC ID and SDP ID for which that Universal SDP ID was not originally assigned. d. EnergyIP detects exceptions when mandatory attributes of the RequestMessage are not provided. e. EnergyIP detects exceptions when the billing quantity request does not have a Request <endTime>. f. EnergyIP detects exceptions when the billing quantity Request <startTime> or <endTime> malformed or is an invalid date.
g. EnergyIP detects exceptions when the Request <startTime> is greater than the request endTime. h. EnergyIP detects exceptions when there is not an associated Billing Service for the SDP during the requested date range.
Version 3.3 July 7, 2011 116
i.
EnergyIP detects exceptions when the requesting organization (i.e. the LDC or its Billing Agent) is not the currently in-effect organization defined by the SDP to BILLING AGENT Relationship associated with the Billing Service for the SDP. The Billing Request Detailed Exception Report has error message(s) for each rejected record explaining the reason. (Refer to Report IR08 in Section 2.4.10 of the MDM/R Reports Technical Specifications).
10. The following Billing Quantity Request exception report is created:
The interface creates exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC or Billing Agent.
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.
2.4.6
Assumptions
Attributes for validation of the SDP to Billing Agent Relationship and external file identifiers, and provision of the Universal SDP ID in the Billing Quantity response will be provided in an early service pack for EnergyIP Release 7.2.
2.4.7

Frequency: This interface is triggered by the submission of a Billing Service Standard Interface RequestMessage file from the LDC or its Billing Agent. Timing: None
117
2.4.8
2.4.8.1
File Format
File Name Record for the Billing Service RequestMessage File
Table 2.4.1 Field Name
Prefix
FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
An example of this record for Version 00 would be: <FTSFN>ORG11111.ORG22222.5500.00.20070214221345.DAT</FTSFN> NOTE: Please reference Section 1.8.2 for use of file format version number.
2.4.8.2 Request Message Input File
The EnergyIP billing service standard request/reply .xml schema is based on the XML Technology standards of the World Wide Web Consortium (W3C). The request .xml schema supports a namespace binding using a default attribute of form DefaultAttName = xmlns thus providing for no attribute prefix to be associated with each attribute name as generally described in the W3C standard: Namespaces in XML. The use of the namespace attribute prefix tns: is optional and request message files utilizing an attribute prefix will be processed without validation of the prefix namespace. The EnergyIP billing service standard interface elements are defined in the eMeter EipReadsForBillingInterface2.xsd providing definition for several record types including: RequestMessage ChangeMessage BillingHoldMessage ReplyMessage BillHistoryLoaderMessage AckMessage
The MDM/R deployment supports only the RequestMessage and ReplyMessage and will only process those elements and attributes as specified in the following tables 2.4.2, 2.4.3, 2.4.4 and 2.4.5.
Table 2.4.2 INPUT FILE MESSAGES ELEMENT
The EnergyIP BillingXmlFileImportAdapter uses an input file <Messages> element to accommodate one or many requests in a single Billing Quantity request file. The XML
118
version and character encoding declaration and <Messages> element should immediately follow the File Name Record.
<Attribute> Data Type/ Length Format Required
Y
Description
XML declaration. Defines the XML version and the character encoding used in the document. Defines the opening of a request file consisting of one or multiple billing requests.
<?xml version=1.0 encoding=UTF-8?>
For namespace binding DefaultAttName = xmlns use: <Messages xmlns=http://www.emeter.com/energyip/readsforbillinginterface2>
The RequestMessage portion of the EnergyIP billing service standard interface includes the two elements listed below. Refer to the diagram that follows for an XML schema view of these elements. Header Contains general, descriptive information about the message payload. Request Contains the details regarding the request.
Table 2.4.3 <Attribute>
REQUEST MESSAGE HEADER RequestMessage/Header Data Type/ Length Format Required Description
<RequestMessage> The <RequestMessage> records are organized into repeating blocks for each requested Billing Period for each Universal SDP ID in the Billing Service Standard Interface Request file. <RequestMessage> Y Defines the request message element for each billing request for a single Universal SDP ID.
<Header> <verb> <noun> String String Specific Usage: create Specific Usage One of: ReadsForBilling or ReadsForBillingInform ational Y Y Must be set to the literal create. Main subject of message. Must be set to the literal ReadsForBilling, if the billing response is to be used for billing purposes. or ReadsForBillingInformational 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
119
<Attribute>
Data Type/ Length
Format
Required
Description
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 ReadsForBillingInformational literal does not set these flags for Register Reads or Interval data when for information billing quantity data is successfully exported.
<revision>
String
Specific Usage: 2
Revision level of message type. The version of the request message xml. Must be set to 2. The date/time when the request was initiated in EST
<dateTime>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] Example: 2008-04-31T12:00:0005:00 Specific Usage: Must always be Billing_Import_Adapte r_IESO
<source>
Varchar (100)
This value will be populated in the LAST_UPD_BY field of billing_request table. <source> = Billing_Import_Adapter_IESO will enable the SDP to Billing Agent Relationship validation. Unique identifier used to corelate this request with its response and for other tracking purposes. This ID is provided by the requestor and stored as the EXTNL_BILLING_REQUEST_I D in the billing_request table.
<messageID>
Varchar (30)
General: AAAAAAAAAAA
</Header>
120
REQUEST MESSAGE RequestMessage/Request Data Type/ Length

Date/Time
Format
<Request>
Required
Description
<startTime>
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00
Start date and time for requested billing period in EST. If not provided, previous bill period end time will be the start time for the request if billing quantities have been successfully exported for a prior billing period. (Read Status = READ_FOUND, Export Status = EXPORT_SENT. SENT_FOR_BILLING = S in 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. End date and time for the requested billing period. This is the exclusive end date for a given request. It represents the first date/time that will NOT be included in 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-01T00:00:00.00005:00 would request data that occurs up to 00:00:00 EST on May 1, 2007 (which is the end of April 30, 2007) (FUTURE) If the requested end time is part way though the reported interval of the meter the data set returned will end with the last interval quantity prorated.
<endTime>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
121
<Attribute>
<versionTime>
Data Type/ Length

Date/Time
Format
Required
N
Description
Allows the requestor to request Billing Quantity data over a specified period but only using Meter and Usage data up to the versionTime. This is a date time other than the current date time. If the intent of the request is to validate or rebuild previously delivered Billing Quantity data underlying previously delivered Billing Quantity data, then this date time must be the same as the ReplyMessage / MeterReadings / MeterReading / Reading / Quality <versionTime> attribute of the delivered Billing Quantities Response. NOTE 1: For billing quantity responses consisting of multiple measurements (for example three TOU quantities and a start and end register reading) each measurement can have differing version date times. Using the maximum version date time from all the response measurements will produce the original billing quantity response. NOTE 2 : If no versionTime specified, the most current version of data will be delivered. To allow the LDC or Billing Agent to specify a unique identifier related to the request file. This identifier is stored as the EXTNL_BATCH_ID in the billing_request table. Defines the type of asset ID provided in request. For the MDM/R this field will indicate the object type of Universal SDP ID for the <objectId>. SDP_X_UNIVERSAL_ID will always be used The organization identifier assigned to the LDC during the MDM/R Registration/Enrolment process. Value that uniquely identifies the <objectId>. Value must be the ORG_ID assigned to the LDC that owns the SDP. Universal SDP ID (Physical or Virtual)
<externalBatchId>
Varchar (30)
General : AAAAAAAA
<objectIdType>
Varchar (30)
General : AAAAAAAA Specific Usage: SDP_X_UNIVERSAL _ID
<objectIdNameSpace>
Char (8)
AAAAAAAA Example: ORG12345
<objectId>
Fixed Number (8)
AAAAAAAA For example: 87654321
122
<Attribute>
<offcycle>
Data Type/ Length

Boolean
Format
Specific usage Only for off-cycle requests: true
Required
N
Description
If set to true, indicates the request is an off-cycle request. For off-cycle requests the <offcycle> attribute value must be true. For on-cycle requests the <offcycle> attribute may be set to false or the <offcycle> attribute may be omitted i.e. not be present. The organization identifier assigned to the LDC during the MDM/R Registration/Enrolment process. Utility name to use to generate the exceptions or statistics. Value must be the ORG_ID assigned to the LDC that owns the SDP. The identifier assigned to the Organization during the MDM/R Registration/Enrollment process, 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 for the SDP. If the LDC is providing its own Billing Services then the LDCs Organization Identifier must be placed in this field. The <billingAgentId> value is validated against the in-effect SDP to Billing Agent Relationship. If this validation fails the ReplyMessage will be returned with the Header/<replyCode> = 8 and Reply/<billingAgentId> = the Request/<billingAgentId> with no billing quantity values. The date/time in EST when the execution window for the request should start. If provided, the billing request will be processed when this date is reached. Note: The <processStartDate> must be specified in accordance with Section 2.4.3, Business Rule #7 for retroactive billing requests if billing exception handling is required. The date/time in EST when the execution window for the request should end. If provided, the billing request will be stopped when this date is reached.
<utilityName>
Char (8)
General: AAAAAAAAA Example: ORG12345
<billingAgentId>
Char (30)
General : AAAAAAAA Example : ORG83462
<processStartDate>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] Example: 2008-04-31T12:00:0005:00 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|-
<processEndDate>
Date/Time
123
<Attribute>
Data Type/ Length
Format
]TZH:TZM] Example: 2008-04-31T12:00:0005:00
Required
Description
</Request> </RequestMessage>

</Messages>
INPUT FILE MESSAGES ELEMENT Data Type/ Length Format Required

Y
Description
Defines the closing of a request file consisting of one or multiple billing requests.
2.4.8.2.1 Sample Request Message File-based Input
Sample XML Request and Response files are available on the Smart Metering Entity website at www.ontario-sme.ca/sample-reports-and-files / Billing Quantity Request and Response. The following is a text example of a file-based Billing Service Standard XML Interface Request file for 2 SDPs.
<FTSFN>ORG12345.ORG12345.5500.00.20100819233017.DAT</FTSFN> <?xml version=1.0 encoding=UTF-8?> <Messages xmlns="http://www.emeter.com/energyip/readsforbillinginterface2"> <RequestMessage> <Header> <verb>create</verb> <noun>ReadsForBilling</noun> <revision>2</revision> <dateTime>2010-08-20T09:30:15-05:00</dateTime> <source>Billing_Import_Adapter_IESO</source> <messageID>6888281</messageID> </Header> <Request> <startTime>2010-05-14T00:00:00-05:00</startTime> <endTime>2010-07-01T00:00:00-05:00</endTime> <externalBatchId>123456</objectIdType> <objectIdType>SDP_X_UNIVERSAL_ID</externalBatchId> <objectIdNameSpace>ORG12345</objectIdNameSpace> <objectId>12345678</objectId> <offcycle>true</offcycle> <utilityName>ORG12345</utilityName> <billingAgentId>ORG12345</billingAgentId> <processStartDate>2010-08-20T11:00:00-05:00</processStartDate> <processEndDate>2010-08-20T11:30:00-05:00</processEndDate> </Request> </RequestMessage> <RequestMessage> <Header> <verb>create</verb>
Version 3.3 July 7, 2011 124
<noun>ReadsForBilling</noun> <revision>2</revision> <dateTime>2010-08-20T09:30:15-05:00</dateTime> <source>ABC8642</source> <messageID>6888282</messageID> </Header> <Request> <startTime>2010-05-14T00:00:00-05:00</startTime> <endTime>2010-07-01T00:00:00-05:00</endTime> <externalBatchId>123457</objectIdType> <objectIdType>SDP_X_UNIVERSAL_ID</externalBatchId> <objectIdNameSpace>ORG12345</objectIdNameSpace> <objectId>87654321</objectId> <offcycle>true</offcycle> <utilityName>ORG12345</utilityName> <billingAgentId>ORG12345</billingAgentId> <processStartDate>2010-08-20T11:00:00-05:00</processStartDate> <processEndDate>2010-08-20T11:30:00-05:00</processEndDate> </Request> </RequestMessage> <Messages>
125
2.5
Billing Service Standard Interface - Reply

Note: This new Billing Service Standard Interface Reply will replace the existing Billing Quantity Response and will be developed and deployed to support the MDM/R Universal Solution for verification and reconciliation of billing quantities based on Measurement Canada approved meter registrations.
2.5.1
Description
The EnergyIP Billing Service Standard Interface billing quantity response is called a ReplyMessage. The purpose of this interface is to prepare the file with Billing Quantity data and send the file to the LDC or authorized Billing Agent based on either a scheduled Billing Cycle Schedule or as a result of processing a Billing Service Standard RequestMessage file. 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 offcycle 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
2.5.2.1
Integration
File Direction
MDM/R to the LDC or Billing Agent

This is a batch process involving the transfer and processing of the EnergyIP Billing Service Standard Interface ReplyMessage files in an .xml file format using the EnergyIP BillingXmlFileExportAdaptor.
2.5.3
Business Rules
1. Billing Quantity data are computed based on the <startTime> and <endTime> specified in the EnergyIP Billing Service Standard Interface Request or the Read Date identified in the Billing Cycle Schedule (to a time of mid-night of the day configured for the BillingCycleDate parameter for the BillingCycleModule).
126
a. The Billing Service Standard XML Interface will support a Request <startTime> or <endTime> as specified on any interval boundary (e.g. at midnight or the top of any hour for 60 minute interval data). EnergyIP Release 7.2 will support partial day framing for whole intervals only and will not prorate partial intervals for date/times specified between interval boundaries. 2. Multiple Billing Quantity replies (automatic bill segmenting initiated by either the request-response or scheduled push billing service) may be provided for a single Billing Quantity request if the following conditions occur: a. A season change (i.e. a global RPP price change event) occurred during the period being requested. For any SDP for which the Framing Structure is TOU/CPP or Periodic the billing service looks for a global price change event that falls within the billing period and delivers Billing Quantities for each sub-period defined by one or more global price change events. The global RPP price change events are defined in the Energy Purchase Service Calendar associated with the Framing Structure assigned to each SDP. b. A framing structure / Energy Purchase Service change (i.e. Rate Change event) for an SDP during the period being requested. c. An SDP to Account Relationship change (i.e. Account Change event) during the period being requested. The billing service looks for an Account to SDP relationship change that falls within the billing period and delivers Billing Quantities for each sub-period defined by one or more Account to SDP relationship change events. d. Global price changes, account changes, and framing structure changes will occur at midnight. i. SDP to Framing Structure Relationship start date/time and end date/time must be specified at midnight using the synchronization processes to support the Register Read Calculation process. ii. SDP to Account Relationship start date/time and end date/time must be at midnight if specified using the synchronization processes to support the Register Read Calculation process. e. Automatic bill segmenting will only be supported by EnergyIP Release 7.2 as deployed for the MDM/R for Global price changes, account changes, and framing structure changes. f. Manual bill segmenting by the use of multiple requests for account changes, and framing structure changes must be specified by the Request <startTime> and <endTime> on a midnight boundary and may be done using on-cycle or off-cycle requests.
3. Meter Change and CT/PT Multiplier Change Events supported by EnergyIP Release 7.2 as deployed for the MDM/R SDP to Meter relationship or the SDP CT/PT Multiplier parameter changes during the period requested. a. Meter Change and CT/PT Multiplier Change must be manually segmented using a billing request for the removed meter and a second request for the installed meter when these change events occur during a billing period.
127
i. A minimum one-interval gap in time must exist between the <endTime> of the removed meter request and <startTime> of the request for the installed meter to allow for separate register reads at the removal of the old meter and the install of the new meter. ii. Register readings will be calculated at the request <endTime> for the removed meter and at the request <startTime> for the installed meter if actual meter readings coinciding with the request times for old and new meter have not been received. b. The end date/time of the SDP to Meter Relationship for the removed meter as specified using the synchronization processes should reflect the actual time of the meter removal to allow processing by the MDM/R of any final transmission of interval data or register read data. i. The last register reading for the removed meter should be provided to the MDM/R to be available for VEE Post Processing. The date/time of the last register reading must be less than the end date/time of the SDP to Meter Relationship for the removed meter to assure that it will not be rejected. c. The start date/time of the SDP to Meter Relationship for the newly installed meter as specified using the synchronization processes should reflect the actual time of the meter installation to allow processing by the MDM/R of any first transmission of interval data or register read data. i. The first register reading of the new meter should be provided to the MDM/R to be available for VEE Post Processing. The date/time of the first register reading should be greater than the start date/time for the SDP to Meter Relationship for the new meter to assure that it will not be rejected. d. A CT/PT Multiplier change must be submitted with a corresponding actual or logical Meter Change using the Synchronization process when a change to the SDP CT/PT Multiplier parameter occurs. Applying a logical meter change (defined as ending and starting the SDP to Meter Relationship for the same meter with the same end date/time and start date/time) when a CT/PT Multiplier only change event occurs will provide the correct CT/PT Multiplier applicable for the Billing Validation Sum Check for each segment and is required to support the Register Read Calculator process. 4. The following are exception cases: a. The MDM/R is unable to produce a Billing Quantity Response since there was no meter associated with the SDP in the required period. b. The MDM/R is unable to produce a Billing Quantity Response due to missing intervals in the required period. c. One or more intervals have the VEE outcome of NVE d. Start register reading and/or end register reading required for the Billing Quantity response is not available.
128
2.5.4
Pre-conditions
The following must exist for the input file to be processed through the interface: A Billing Service Standard Interface RequestMessage file has been submitted and has been processed by the Billing Quantity Request Interface for PULL requests. For PUSH requests, the LDC or Billing Agent has provided the MDM/R with a Billing Cycle Schedule. For PUSH requests, the Billing Cycle attribute for an SDP has been populated with a Billing Cycle that is contained in the Billing Cycle Schedule.
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
Attributes for validation of the SDP to Billing Agent Relationship and external file identifiers, and provision of the Universal SDP ID in the Billing Quantity response will be provided in an early service pack for EnergyIP Release 7.2.
2.5.7

Frequency: For the Request-Response Billing Service (Pull) a Billing Service Standard Interface ReplyMessage is sent in response to a specific Billing Service Standard Interface RequestMessage. For the Scheduled Billing Service (Push) a Billing Service Standard Interface ReplyMessage file is sent for each billing cycle scheduled for delivery on that day to the LDC or its Billing Agent. Register Read Billing Window: With the deployment of EnergyIP Release 7.2 the notion of Billing Window is redefined as a Register Read Billing Window. The Register Read Billing Window determines the range of time when a register reading must occur to be considered an acceptable register reading to be used as the end register reading in the billing quantity response. For on-cycle billing requests the Register Read Billing Window is controlled by the request endTime and the following billing service properties set for each VEE Service/Data Delivery Service: AllowableReadAge for example set to 1 Day, 23 Hours, 59 Minutes AllowableReadAgeType for example set to Calendar days Read Window - Max for example set to 0 Days
129
Read Window Type for example set to Calendar days
For off-cycle billing requests the Register Read Billing Window is controlled by the request endTime and the following billing service properties set for each VEE Service/Data Delivery Service: OffCycleAllowableReadAge for example set to 0 Days AllowableReadAgeType for example set to Calendar days OffCycle Read Window - Max for example set to 0 Days OffCycle Read Window Type for example set to Calendar days
Execution Window: With the deployment of EnergyIP Release 7.1 the notion of Billing Window is replaced by a new billing request Execution Window. The Execution Window determines the range of time during which a billing request remains active. For on-cycle billing requests the billing request Execution Window is controlled by the request endTime and the following billing service properties set for each VEE Service/Data Delivery Service: LatestReportDays for example set to 3 Days LatestReportDaysType for example set to Business days TriggerAfterDays for example set to 2 Days TriggerAfterDaysType for example set to Calendar days
For off-cycle billing requests the billing request Execution Window is controlled by the request endTime and the following billing service properties set for each VEE Service/Data Delivery Service: OffCycleLatestReportDays for example set to 10 Minutes LatestReportDaysType for example set to Business days OffCycleTriggerAfterDays for example set to 1 Minute TriggerAfterDaysType for example set to Calendar days
All related VEE Service/Data Delivery Service billing service properties will be specified in the MDM/R VEE Standard for the Ontario Smart Metering System. During the Execution Window billing requests (Push or Pull, on-cycle or off-cycle) remain active if complete framed usage data or interval data for any day or if required start or end register readings are not available, or for which the Validation Status is NVE. A noData reply is returned for all unfulfilled requests no later than 08:00 EST on the calendar day after an Execution Window closes. The Execution Window can be partially or fully determined by use of the request processStartDate and processEndDate. Use of these request attributes can be used to override the configured billing service properties and to provide ODEST at any date or time after the Execution Window would normally close as determined by the billing service properties configuration for each VEE Service/Data Delivery Service. Timing: The Billing Service Reads Processor (BSRP) will launch and process the off-cycle requests when initially received. On-cycle requests and Scheduled PUSH requests (as well as off-cycle requests that remain active after initial processing) will be processed
130
on the regularly scheduled run of the BSRP process. This process is configured to run at certain times during the day. This process will run every three hours each day between the hours of 08:00 EST and 23:00 EST, and once at 00:30 EST to initiate earlier processing of billing exception handling. Experience gained during testing and initial production operations of the MDM/R has affirmed the efficacy of this schedule in meeting operational requirements. Initially, scheduled PUSH (Request Type S) for the current day will be loaded at 07:30 EST. This schedule may be modified to meet operational requirements. The BillingXmlFileExportAdaptor writes multiple xml ReplyMessages into a single output file. Two properties control the output to the xml file export: xmlFileCronTrigger.cronExpression The CRON expression to close the export file on a scheduled timeout if the file is idle. Initially this property is set to 0 0/1 * * * ? indicating a timeout after 1 minute. xmlFileExportAdaptor.maximumNumberOfRecordsPerFile The maximum number of ReplyMessages allowed in one xml file export. Initially this property is set to 999999. Based on experienced gained during initial operations of the MDM/R, these parameters may be modified to meet operational requirements. Service Levels: The Billing Service Standard Reply File is provided within the following timeframes, based on the Billing Service Global Parameters of AllowableReadAge of 0 calendar days and LatestReportDays of 3 business days: For the Scheduled Billing Service - Billing Quantity data will be provided by 21:05 through the third business day after Day N for all SDPs that have successfully completed the VEE process by 15:00 on any subsequent day through the third business day after Day N. For the Request-Response Billing Service - Billing Quantity data will be provided within six hours of the timestamp of the receipt of the Billing Quantity Request for all SDPs that have successfully completed the VEE process by that time. Where the Billing Quantity Request includes Request Daily Read Period End Dates that are in the future, the Billing Quantity data will be provided within six hours of the Request Daily Read Period End Date based on the Billing Quantity process runs on the Request Daily Read Period End Date. For SDPs that complete the VEE process after the Request Daily Read Period End Date, the Billing Quantity Response will be provided on any subsequent day through the third business day after Day N (the exclusive end date for the Billing Quantity Request). In both cases, Scheduled Billing Service and Request-Response Billing Service, if the process is unable to provide a Billing Quantity response by the end of the billing window (being the exclusive end date plus the LatestReport Days) then on the first run of the Billing Quantity processing after the close of the billing window a no data available Billing Quantity response record will be delivered for each SDP for which Billing Quantity values can not be produced.
131
2.5.8
2.5.8.1
File Format
File Name Record for the Billing Quantity ReplyMessage File
Table 2.5.1 Field Name
Prefix
FILE NAME RECORD FOR THE BILLING QUANTITY REPLY MESSAGE FILE Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.5.8.2 Reply Message Output File
The EnergyIP billing service standard request/reply .xml schema is based on the XML Technology standards of the World Wide Web Consortium (W3C). The reply .xml schema supports a namespace binding using a default attribute of form DefaultAttName = xmlns thus providing for no attribute prefix to be associated with each atttribute name as generally described in the W3C standard: Namespaces in XML. The EnergyIP billing service standard interface elements are defined in the eMeter EipReadsForBillingInterface2.xsd providing definition for several record types including: RequestMessage ChangeMessage BillingHoldMessage ReplyMessage BillHistoryLoaderMessage AckMessage
The MDM/R deployment supports only the RequestMessage and ReplyMessage and will only process those elements and attributes as specified in the following tables 2.5.2, 2.5.3, 2.5.4, 2.5.5 and 2.5.6.
Table 2.5.2 OUTPUT FILE MESSAGES ELEMENT
The EnergyIP BillingXmlFileExportAdapter uses an input file <Messages> element to accommodate one or many replys in a single Billing Quantity reply file. The XML version and character encoding declaration and <Messages> element will immediately follow the File Name Record.
Version 3.3 July 7, 2011 132
<Attribute>
Data Type/ Length
Format
Required
Y
Description
XML declaration. Defines the XML version and the character encoding used in the document. Note: EnergyIP Release 7.2 will not return the version and encoding declaration during initial testing. Service packs deployed prior to promotion to Production will return this declaration. Defines the opening of a reply file consisting of one or multiple billing requests.
<?xml version=1.0 encoding=UTF-8?>
<Messages xmlns=http://www.emeter.com/energyip/readsforbillinginterface2>
The ReplyMessage portion of the EnergyIP standard billing service interface includes the three elements listed below. Refer to the diagram that follows for an XML schema view of these elements. Header Contains descriptive information about the message. Reply Contains the details regarding the reply. MeterReadings
REPLY MESSAGE HEADER ReplyMessage/Header Data Type/ Length Format Required Description
<ReplyMessage> The <ReplyMessage> records are organized into repeating blocks for each requested Billing Period for each Universal SDP ID in the Billing Service Standard Interface Reply file. <ReplyMessage xmlns=http://www.emeter.com/energyip/readsforbillinginterface2> Y Defines the start of a reply message element for each billing reply for a single Universal SDP ID. This attribute including the namespace declaration in the opening tag is repeated for each reply in a multiple response file.
<Header> <verb> <noun> String String Specific Usage: reply Specific Usage One of: ReadsForBilling or ReadsForBilling Informational Y Y Always will be the literal reply. Main subject of message. Set to the literal ReadsForBilling or ReadsForBilling Informational if request was for information.
133
<Attribute>
Data Type/ Length
Format
Required
Description
Note 1: The ReplyMessage literal ReadsForBilling Informational includes a space. Note 2: Billing Validation Sum Check is not performed for ReadsForBilling Informational requests.
<revision>
String
Specific Usage: 2
Revision level of message type. The version of the reply message xml. Currently revision of the xml specification is set to 2. The date/time when this response was generated in EST. Note: EnergyIP Release 7.2 does not support this <dateTime> attribute. The ReplyMessage / Header / dateTime is Reserved for future use.
<dateTime>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] Example: 2008-04-31T12:00:0005:00 Example: ABC8642
<source>
Varchar (100)
This value is populated from the LAST_UPD_BY field of billing_request table. The <source> in each reply will be populated with the ORG_ID assigned to the LDC that owns the SDP.
</Header>
REPLY MESSAGE ReplyMessage/Reply Data Type/ Length

Varchar (30)
Format
<Reply>
Required
Description
<correlationId>
General: AAAAAAAAAAA
Populated with the <messageId> in RequestMessage/Header if one was provided. This is the unique request identifier assigned by the LDC or its Billing Agent (the EXTNL_BILLING_REQUEST_I D from the billing_request table). For Scheduled PUSH billing service this attribute will not be present in the replyMessage. Populated with 0 for success and non zero for an error response. Codes and values include: 0 Successful read 1 Lookup failure, for example invalid SDP ID in the request
<replyCode>
String
General: NN Specific usage: One of 0, 1, 2, 8, 9 10, 11, 12, 15, 16, 17, 18
134
<Attribute>
Data Type/ Length
Format
Required
Description
2 Reads failure (billing window expired) 8 Requesting organization does not match active Billing Agent for the SDP 9 Invalid billing determinant for a hold request 10 Missing or invalid DDS parameter (configuration error) 11 Validation failure, will be present if the data delivery service validation fails. For the MDM/R billing validation sum check failure, i.e. <Reading>/<validationCode> = 6 or 7. 12 Meter not found for segment or bill period 13 Cycle ID not found for the SDP to process the ByCycle request (Disabled for the MDM/R) 14 Missing Route Cycle ID (Disabled for the MDM/R) 15 Request was cancelled 16 No measurement attached to Measurement Profile or Measurement Profile name is null in the DDS 17 Invalid primary billing determinants 18 Symbol not found for calculative read determinant
<requestId> <id> Number (50) Y The internal EnergyIP billing request identifier (the BILLING_REQUEST_ID field from the billing_request table). This identifier will be present in the replyMessage for both Request-Response and Scheduled PUSH billing services.
</requestId> <offcycle> Boolean Specific usage For off-cycle requests: true For on-cycle requests: false For ReadsForBilling Informational requests (both on-cycle and offcycle): true Y Indicates the response is for an off-cycle billing request. For off-cycle requests value will be true. For on-cycle requests or Scheduled PUSH requests value will be false. The EnergyIP GUI Request Message screen displays the following values in the Off Cycle field: For off-cycle ReadsForBilling requests: value = B For on-cycle ReadsForBilling
135
<Attribute>
Data Type/ Length
Format
Required
Description
requests: value = P For off-cycle and on-cycle ReadsForBilling Informational requests: value = I
<externalBatchId>
Varchar (30)
General : AAAAAAAA
To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request. This is the identifier stored as the EXTNL_BATCH_ID in the billing_request table. This is the <billingAgentId> value submitted in the RequestMessage/Request/ <billingAgentId>. Billing Quantities are only provided to the Organization for which the SDP to Billing Agent Relationship is in-effect. For requests for which the requesting organization does not match the in-effect SDP to Billing Agent Relationship the <replyCode> = 8 will be returned in the reply.
<billingAgentId>
Char (30)
</Reply>
REPLY MESSAGE ReplyMessage/MeterReadings Data Type/ Length

Date/Time
Format
<MeterReadings>
Required
Description
<startTime>
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00
Start date and time for billing period provided in the billing reply in EST. If no prior completed billing exists this startTime may differ from the requested billing period startTime as determined by the date/time of an actual register reading closest to the requested startTime and within the Start Read Tolerance parameter of the billing data delivery service assigned to the SDP. End date and time for the billing period provided in the billing reply in EST. This is the exclusive end date for a given request. It represents the first date/time that will NOT be included in 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
<endTime>
Date/Time
136
<Attribute>
Data Type/ Length
Format
Required
Description
is the beginning 00:00:00 of the exclusive end date). For example, an endTime of 2007-05-01T00: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.
<MeterReading> <ServicePoint> <id> Fixed Number (8) General: NNNNNNNN Example: 00037483 Specific usage: SDP_X_UNIVERSAL_ ID </ServicePoint> <Meter> <id> Varchar (50) No format prescribed Y The identifier of the currently installed meter and must be unique within an LDC. This is the Meter ID submitted in the Asset Data File of the Synchronization file set and populated by the Synch STG in the stgmeter.badge_id (i.e. Meter Badge ID as displayed in the EnergyIP GUI). Object ID Type. For Meter ID Value = METER_X_UNIVERSAL_ID Y This is the Universal SDP ID. (Physical or Virtual)
<idType>
String
Object ID Type. For Universal SDP ID Value = SDP_X_UNIVERSAL_ID
<idType>
String
Specific usage: METER_X_UNIVERS AL_ID </Meter> <Premise>
<id>
String
The MDM/R Synchronization Staging Table Loader populates the Premise ID with the SDP ID on the creation of the Premise master data records.
137
<Attribute>
<idType>
Data Type/ Length

String
Format
Specific usage: X_CLIENT_PRMSE_I D </Premise> <CustomerAccount>
Required
Y
Description
Object ID Type. For Premise ID Value = X_CLIENT_PRMSE_ID
<id>
String
This is the currently in-effect Account ID value as submitted in the Object 2 field Relationship Identifier 2 = ACCOUNT in the Relationship Data File of the Synchronization file set. For periods for which no Account is in-effect the <CustomerAccount> record will not be present. Object ID Type. For CustomerAccount ID Value = X_UDC_ACCNT_ID
<idType>
String
Specific usage: X_UDC_ACCNT_ID </CustomerAccount>
<Reading> The <Reading> reply records are organized into the following repeating blocks for TOU or Periodic billing quantities and related Start and End Register Readings <startTime> Date/Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00 General: NNNNNNNNNNN.NN For example: 924.061352 General: AAAAAAA Specific usage: For TOU/CPP, Periodic and Demand: Framer For Meter Reads N The startTime attribute will not be present for TOU, Periodic, or Demand billing quantities. The startTime attribute will not be present for related Start or End Register Readings.
<endTime>
Date/Time
The endTime attribute will not be present for TOU, Periodic, or Demand billing quantities. The endTime attribute will be present for the related Start or End Register Readings.
<value>
Number (21,6)
The quantity value related to the <readingTypeId>
<measurementSource>
String
This is EnergyIP application that is the internal source of the billing quantity value. For TOU/CPP and Periodic billing quantities the value is: Framer For Demand billing quantities
138
<Attribute>
Data Type/ Length
Format
Interfaces: One of MAS, SENSUS, SmartSynch, Tantalus, Trilliant For estimated Register Reads: eMeter
Required
Description
the value is: Framer For Register Reads received via the Meter Reads Interfaces, values are: Elster = MAS Sensus = SENSUS SmartSynch = SmartSynch Tantalus = Tantalus Trilliant = Trilliant Note: The values for the Meter Read Interfaces are established by the AMCC Type specified for the Communication Module as part of the Asset Data File Detail Record using the Synchronization processes. For estimated Register Reads value is: eMeter
<readingTypeId>
Varchar (50)
General: AAAAAAA Specific usage for TOU/CPP: KWH On Peak Usage BC KWH Mid Peak Usage BC KWH Off Peak Usage BC KWH Usage BC Specific usage for Periodic: KWH Usage BC Specific usage for Hourly: KWH Usage BC Specific usage for demand: Peak KW BC Peak KVA BC Peak KW77 BC Peak KVA77 BC Coincident KW Demand BC Coincident KVA Demand BC Coincident Rolling KW Demand BC Coincident Rolling KVA Demand BC Specific usage for Register Readings: Start Read KWH RR Cum BC Start Register End Read KWH RR Cum BC
This code identifies the measurement that defines the data used for the billing quantities being calculated. (From the MEAS_EXTENSION_CODE of the billing_detail table.) For TOU/CPP (EST) and TOU/CPP (CST), values are: KWH On Peak Usage BC KWH Mid Peak Usage BC KWH Off Peak Usage BC KWH Usage BC For Periodic, value is: KWH Usage BC For Demand Billing Quantities, values are: Peak KW BC Peak KW77 BC Peak KVA BC Peak KVA77 BC Coincident KW Demand BC Coincident KVA Demand BC Coincident Rolling KW Demand BC Coincident Rolling KVA Demand BC For Start Register Readings, value is: KWH RR Cum BC Start Register For End Register Readings, value is: KWH RR Cum BC Note: Estimated interval data total kWh will be returned as the <Quality> <estimatedUsage> value for each usage reading. To be delivered with EnergyIP Release 7.2 SP7. For CPP Billing Quantities, value is: KWH CPP1 Usage BC
139
<Attribute>
<validationCode>
Data Type/ Length

String
Format
AAAAAAAA Specific usage: One of: 6, 7
Required
N
Description
Data delivery service validation failure reason. Codes and values include: 1 HiLo warn occurred 2 HiLo fail occurred 3 HiLo No threshold basis found 4 Consecutive estimation check failed 5 Span length failed 6 Sum check failed 7 Sum check skipped Note 1: Codes 1, 2, 3, 4, and 5 not used by the MDM/R. Note 2: The Billing Validation Sum Check is not performed for ReadsForBillingInformational requests i.e. RequestMessage, ReplyMessage / Header / <noun> = ReadsForBilling Informational. Thus codes 6 and 7 will not be present. The <validationCode> attribute will not be present if there is not a data delivery service validation failure. When there is a data delivery service validation failure and billing determininants are delivered: the <validationCode> attribute will be present for for <readingTypeId> = KWH Usage BC the <validationCode> attribute will not be present for register readings associated with usage determinants Demand peak time. Applicable to demand measurement only.
<demandPeakTime>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] <Quality>
<versionTime>
Date/Time
This is the latest insert date time of the set of data used for billing quantity calculations. This date time is prior to the billing quantity response data being written into the billing quantity response file that is transferred to organization assigned to the Data Delivery Service associated with the SDP. NOTE: For a billing quantity
140
<Attribute>
Data Type/ Length
Format
Required
Description
reply consisting of multiple measurements (for example three TOU quantities and a start and end register reading) each measurement can have differing version date times. The maximum version date time from all the response measurements should be used as the RequestMessage / Request <versionTime> to produce the original billing quantity response.
<noData>
Boolean
Specific usage For a no data condition: true
If any billing determinant (i.e. <readingTypeId>) is not available for billing for the billing period, then <noData> = true for all billing determinants and the <value> will not be present for every <readingType> in the reply. The <noData> attribute will not be present when all the required measurement data is available for billing (i.e. required interval, usage and register data for the billing period is valid or estimated). For usage-based measurements (TOU, Periodic) if the ratio of the total number of estimated intervals in the billing period to the total number of intervals for the billing period exceeds the value of the Interval Est Th parameter for the VEE Service/DDS Service assigned to the SDP, the <validationStatus> will be set to EST. Otherwise the <validationStatus> = VAL. For register readings <validationStatus> = VAL for all register readings processed through the Meter Reads interfaces. <validationStatus> = EST for register readings calculated by the Register Read Calculator. The total kWh quantity of estimated interval data associated with each usage reading value related to the <readingTypeId>. This kWh value will be specific to each TOU or Periodic measurement. If there is no estimated interval data associated with a specific usage value the <estimatedUsage> = 0 Note: The <estimatedUsage> for the <readingTypeId> = KWH
<validationStatus>
String
Specific usage: One of: VAL EST
<estimatedUsage>
Number (21,6)
General: NNNNNNNNNNN.NN For example: 14.000000 0
141
<Attribute>
Data Type/ Length
Format
Required
Description
Usage BC is a total of the kWh for each estimated interval, whereas the sum of Hourly <IReading> values with a <validationStatus> = EST may overstate the estimated kWh if the meter interval length is less than 60 minutes.
numEstIntervals
String
General: AAAA Example: 12 General: AAAA Example: 2160 </Quality> </Reading>
(Reserved for future use.)
numIntervals
String
(Reserved for future use.)
<IntervalBlock> <IntervalBlock> reply records provide the response for Hourly Billing Quantities <readingTypeId> Varchar (50) General: AAAAAAA Specific usage for Hourly: KWH Interval 60 Minutes N This code identifies the measurement that defines the data used for the billing quantities being calculated. (From the MEAS_EXTENSION_CODE of the billing_detail table.) For Hourly, value is: KWH Interval 60 Minutes
<IReading> The <IRreading> reply records are organized into the following repeating blocks for Hourly Billing Quantities. Note 1: Start Register Readings and End Register Readings associated with each Hourly reply will be found in the <Reading> block of the reply message. Note 2: KWH Usage BC and associated <Quality> <estimatedUsage> associated with each Hourly reply will be found in the <Reading> block of the reply message. <startTime> Date/Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00 N The startTime attribute will not be present for Hourly billing quantities.
<endTime>
Date/Time
The endTime attribute will be present for each Hoully billing quantity. For Hourly billing quantity values aggregated from interval data of interval length less than 60 minutes, the endTime will be the maximum local_interval_time from the lp_interval records making up the reading (i.e. the end date/time of the interval ending at the top of the hour).
142
<Attribute>
<intervalLength>
Data Type/ Length

Integer
Format
Specific usage: For Hourly billing quantities always 3600 General: NNNNNNNNNNN.NN For example: 924.061352 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] General: AAAAAAA Specific usage: For Hourly quantities from 60 minute data, One of MAS, SENSUS, SmartSynch, Tantalus, Trilliant or VEEPP, INTVLMON, PPIV For aggregated Hourly quantities: BSRP For estimated interval data: eMeter
Required
N
Description
Interval length, in seconds, if applicable to measurement. Value will always be 3600 for SDPs for which the Framing Structure is Hourly. The quantity value related to the <readingTypeId>
<value>
Number (21,6)
<demandPeakTime>
Date/Time
Demand peak time. Applicable to demand measurement only.
<measurementSource>
String
This is EnergyIP application that is the internal source of the billing quantity value. For Hourly billing quantity data comprised of 60 minute interval data, values are: Elster = MAS Sensus = SENSUS SmartSynch = SmartSynch Tantalus = Tantalus Trilliant = Trilliant Note 1: The values for interval data are established by the AMCC Type specified for the Communication Module as part of the Asset Data File Detail Record using the Synchronization processes. Note 2: Processes acting on meter read data after initial processing by the meter read interfaces may result in the following values: VEEPP generated by the VEE Post Processor INTVLMON generated by the Interval Monitor PPIV generated by the Post Process Interval Validator For Hourly billing quantity data aggregated from interval data of interval length less than 60 minutes the value is: BSRP For estimated interval data value is: eMeter
<Quality>
143
<Attribute>
<versionTime>
Data Type/ Length

Date/Time
Format
Required
N
Description
This is the latest insert date time of the set of data used for billing quantity calculations. This date time is prior to the billing quantity response data being written into the billing quantity response file that is transferred to organization assigned to the Data Delivery Service associated with the SDP. Validation status of the interval read. For Hourly billing quantity data aggregated from interval data of interval length less than 60 minutes the <validationStatus> value is the worst-case status set by a hierarchy of interval validation status values ranked from best-case = 1 to worstcase = 3 for which: 1 = VAL (Validated) 2 = NV (Not Validated) 3 = EST (Estimated) Change method used for estimation. The <changeMethod> attribute will be present when <validation Status> = EST. For Hourly billing quantity data based on interval data of interval length equal to 60 minutes the <changeMethod> value will be the current change method for the associated interval. For Hourly billing quantity data aggregated from interval data of interval length less than 60 minutes the <changeMethod> value is set by the lowest rank of the child intervals as determined by the configuration of the CHANGE_METHOD_RANK table as follows: 1 = ESA 2 = ESB 3 = ESC 4 = ESD 5 = ESE 6 = ESF 7 = ESG 8 = ESZ 9 = EDT 10 = EDC -1 = UNK Note: EnergyIP will output the UNK value in the reply message if one of the child intervals has a change method code which does not appear in the CHANGE_METHOD_RANK table.
<validationStatus>
String
Specific usage: One of: VAL NV EST
<changeMethod>
String
Specific usage: One of: ESA ESB ESC ESD ESE ESF ESG ESZ EDT EDC
144
<Attribute>
<noData>
Data Type/ Length

Boolean
Format
Specific usage For a no data condition: true
Required
N
Description
If any billing determinant (i.e. <readingTypeId>) is not available for billing for the billing period, then <noData> = true for all billing determinants and the <value> will not be present for every <readingType> in the reply. The <noData> attribute will not be present when all the required measurement data is available for billing (i.e. required interval, and register data for the billing period is valid or estimated). Indicates if the interval data is locked from any further updates. <locked> = true if interval data is locked. <locked> = false if interval data is not locked.
<locked>
Boolean
Specific usage For the MDM/R always: false
</Quality> </IReading> <validationCode> String AAAAAAAA Specific usage: One of: 6, 7 N Data delivery service validation failure reason. Codes and values include: 1 HiLo warn occurred 2 HiLo fail occurred 3 HiLo No threshold basis found 4 Consecutive estimation check failed 5 Span length failed 6 Sum check failed 7 Sum check skipped Note 1: Codes 1, 2, 3, 4, and 5 not used by the MDM/R. Note 2: The Billing Validation Sum Check is not performed for ReadsForBillingInformational requests i.e. RequestMessage, ReplyMessage / Header / <noun> = ReadsForBilling Informational. Thus codes 6 and 7 will not be present. The <validationCode> attribute will not be present if there is not a data delivery service validation failure.
</IntervalBlock> <segmentReason> String Specific usage, one of: Price Change Meter Installed Meter Removed Move Out Move In New Transformer Ratio Rate Change N The <segmentReason> will be present for each billing event (i.e. multiple values can be reported) if the corresponding data delivery event is configured to Split Period and the Request <startTime> or <endTime> coincides with the dateTime of the event or events. Valid values are:
145
<Attribute>
Data Type/ Length
Format
Required
Description
Price Change indicating a Global Price Change event Rate Change indicating a Framing Structure or Energy Purchase Service Change event Meter Installed indicating a Meter Change event Meter Removed indicating a Meter Change event Move Out indicating an Account Change event involving an SDP to Account Relationship end Move In indicating an Account Change event indicating an SDP to Account Relationship start New Transformer Ratio indicating a CT/PT Multiplier Change event The <segmentReason> element will be present in the first segment for values: Meter Removed Move Out The <segmentReason> element will be present in the second segment for values: Meter Installed Move In Price Change Rate Change Retailer Change New Transformer Ratio
<startTime>
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: 2010-05-14T00:00:0005:00 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Start date and time for the segmented billing period provided in the billing reply in EST. For a billing reply that is not segmented this startTime will be equal to the MeterReadings/startTime for the reply billing period.
<endTime>
Date/Time
End date and time for the segmented billing period provided in the billing reply in EST. 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
146
<Attribute>
Data Type/ Length
Format
Required
Description
Window - Max For off-cycle requests: OffCycleAllowableReadAge and OffCycle Read Window Max for off-cycle requests. For a billing reply that is not segmented, the endTime also falls under the same determination for a segmented billing period. The endTime will not equal the MeterReadings/endTime if the register reading is not aligned to the time for the reply billing period, but will instead be the date/time of the actual register reading.
<transformerRatio> <retailerId>
String String
For example: 1.0 For example: ORG98364
N N
CT/PT Multiplier The value in the <retailerId> attribute is populated based on the active SDP to Energy Service Provider relationship. This is the Organization ID for Relationship Data records submitted as Relationship 2 = ENERGY SERVICE PROVIDER
</MeterReading> </MeterReadings> </ReplyMessage> </ReplyMessage> Y Defines the end of a reply message element for each billing reply for a single Universal SDP ID.

</Messages>
OUTPUT FILE MESSAGES ELEMENT Data Type/ Length Format Required

Y
Description
Defines the closing of a reply file consisting of one or multiple billing reply.
2.5.8.2.1 Sample Reply Message File-based Output
Sample XML Request and Response files are available on the Smart Metering Entity website at www.ontario-sme.ca/sample-reports-and-files / Billing Quantity Request and Response. The following is a text example of a file-based Billing Service Standard XML Interface Reply file for a single SDP.
<FTSFN>ORG12345.ORG12345.6500.00.20100820093117.DAT</FTSFN> <?xml version=1.0 encoding=UTF-8?> <Messages xmlns="http://www.emeter.com/energyip/readsforbillinginterface2"> <ReplyMessage xmlns="http://www.emeter.com/energyip/readsforbillinginterface2"> <Header> <verb>reply</verb> <noun>ReadsForBilling</noun>
147
<revision>2</revision> <source>ABC8642</source> </Header> <Reply> <correlationId>6888281</correlationId> <replyCode>11</replyCode> <requestId> <id>3090238</id> </requestId> <offcycle>true</offcycle> <externalBatchId>123456</externalBatchId> <billingAgentId>ORG12345</billingAgentId> </Reply> <MeterReadings> <startTime>2010-05-14T00:00:00-05:00</startTime> <endTime>2010-07-01T00:00:00-05:00</endTime> <MeterReading> <ServicePoint> <id>12345678</id> <idType>SDP_X_UNIVERSAL_ID</idType> </ServicePoint> <Meter> <id>Meter654321</id> <idType>METER_X_UNIVERSAL_ID</idType> </Meter> <Premise> <id>Sdp12345678</id> <idType>X_CLIENT_PRMSE_ID</idType> </Premise> <CustomerAccount> <id>ACCOUNT87654321</id> <idType>X_UDC_ACCNT_ID</idType> </CustomerAccount> <Reading> <value>718.693570</value> <measurementSource>Framer</measurementSource> <readingTypeId>KWH Off Peak Usage BC</readingTypeId> <validationCode>6</validationCode> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> <estimatedUsage>14.654321</estimatedUsage> </Quality> </Reading> <Reading> <value>196.545791</value> <measurementSource>Framer</measurementSource> <readingTypeId>KWH On Peak Usage BC</readingTypeId> <validationCode>6</validationCode> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> <estimatedUsage>0</estimatedUsage> </Quality> </Reading>
148
<Reading> <value>294.497500</value> <measurementSource>Framer</measurementSource> <readingTypeId>KWH Mid Peak Usage BC</readingTypeId> <validationCode>6</validationCode> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> <estimatedUsage>7.321000</estimatedUsage> </Quality> </Reading> <Reading> <value>1209.736861</value> <measurementSource>Framer</measurementSource> <readingTypeId>KWH Usage BC</readingTypeId> <validationCode>6</validationCode> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> <estimatedUsage>21.975321</estimatedUsage> </Quality> </Reading> <Reading> <endTime>2010-05-14T00:00:00-05:00</endTime> <value>294.497500</value> <measurementSource>Trilliant</measurementSource> <readingTypeId>KWH RR Cum BC Start Register</readingTypeId> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> </Quality> </Reading> <Reading> <endTime>2010-07-01T00:00:00-05:00</endTime> <value>1796.000000</value> <measurementSource>Trilliant</measurementSource> <readingTypeId>KWH RR Cum BC</readingTypeId> <Quality> <versionTime>2010-07-01T04:11:26.000-05:00</versionTime> <validationStatus>EST</validationStatus> </Quality> </Reading> <startTime>2010-05-14T00:00:00-05:00</startTime> <endTime>2010-07-01T00:00:00-05:00</endTime> <transformerRatio>1.0</transformerRatio > </MeterReading> </MeterReadings> </ReplyMessage> </Messages>
149
2.6
2.6.1
Billing Quantity Request

Description
The purpose of this interface is for the LDC or their Billing Agent to submit requests to the MDM/R for Billing Quantity data. The request is made either by the LDC or by the Billing Agent on behalf of the LDC. The Billing Quantity Request interface file contains a number of Universal SDP IDs together with date(s) that define the date range for which the billing quantities are needed. These requests are satisfied using the Billing Quantity Response Interface that is described in Section 15.7 of the MDM/R Detailed Design Document, Billing Quantity Response Interface. The MDM/R supports two methods for preparing Billing Quantity data to send to LDCs or their billing agents. The LDC or their billing agent may choose to use one or the other method based on their operational requirements: 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 their billing agents with the MDM/R. The Billing Quantity Request Interface is not required to be used by this method. Request-Response Billing Data Service (request-response) method delivers Billing Quantity data in response to a request from the LDC or their billing agents using this Billing Quantity Request Interface. This method is used for requesting Billing Quantity data for both on-cycle and off-cycle billing.
2.6.2
2.6.2.1
Integration
File Direction
LDC or their Billing Agent to the MDM/R

This is a batch process involving the transfer and processing of pipe (|) delimited text files.
2.6.3 Business Rules

1. The following checks are performed: a. The Billing Quantity Request must be submitted by the organization (either the LDC or its Billing Agent) associated with the Billing Service for the SDP. The SDP to BILLING AGENT Relationship must be the ineffect relationship for the submitting organization for each SDP as submitted in the Relationship Data file of the Synchronization file set.. b. The Billing Quantity Request File must have a valid Request Daily Read Period End Date for each Universal SDP ID Billing Quantity Detail record c. If the Billing Quantity Request File has a Request Daily Read Period Start Date for a Universal SDP ID, the Request Daily Read Period Start Date, if populated, must be prior to the Request Daily Read Period End Date.
150
2. The MDM/R will determine the duration of the billing window for the Billing Quantity data in one of two ways: a. The LDC or their Billing Agent will include a Request Daily Read Period Start Date and a Request Daily Read Period End Date in the Billing Request Detail Record. The start dates in Billing Quantity Request Detail Records are inclusive, and end dates are exclusive. b. The LDC or their Billing Agent will include only the Request Daily Read Period End Date in the Billing Request Detail Record. In this case the first Daily Read Period date that will be included in the response to this Billing Quantity Request is the previous Billing Quantity Response Daily Read Period End Date. 3. The validated Billing Quantity Request File is passed to the Billing Quantity engine 4. The processed Billing Quantity Request File is placed in the Processed Directory by MDM/R. 5. The following are exception cases: a. The MDM/R Billing Quantity Request Adapter detects exceptions in regards to invalid pipe (|) delimited file formats and data type errors. b. The MDM/R detects exceptions when the LDC ID or Universal SDP ID values are not known by the system. c. The MDM/R detects exceptions when, in the file, the Universal SDP ID is associated with an LDC ID and SDP ID for which that Universal SDP ID was not originally assigned. d. The MDM/R detects exceptions when the LDC or their Billing Agent is not associated with the Billing Service for the SDP during the requested date range. e. The MDM/R detects exceptions when, in the file, the Universal SDP ID does not have a Request Daily Read Period End Date. f. The MDM/R detects exceptions when, in the file, the Universal SDP ID has a Request Daily Read Period Start Date that is greater than the Request Daily Read Period End Date.
g. The MDM/R detects exceptions when Billing Quantities are requested for a Universal SDP ID that is not active during the requested date range. Required attributes for active SDPs are described in detail in Section 3.4 of the MDM/R Detailed Design Document, SDP Attributes of this document. h. The MDM/R detects exceptions when, in the file, a Request Version Date Time field is populated for a Universal SDP but the Request Type is not O 6. The following Billing Quantity Request exception report is created: The Billing Request Detailed Exception Report has error message(s) for each rejected record explaining the reason. (Refer to Report IR08 in Section 2.4.10 of the MDM/R Reports Technical Specifications).
151
The interface creates exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC or Billing Agent.
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
2.6.7

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

2.6.8.1 File Name Record for the Billing Quantity Request File
152
Table 2.6.1
FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.6.8.2 Billing Quantity Request File Header Record
Table 2.6.2 BILLING QUANTITY REQUEST HEADER RECORD
Field
Record Type Identifier
Data Type/Length
Char(2)
Format
General: AA Specific Usage: RH General: NN Specific Usage: 00 General : AAAAAAAA Example : ORG83462
Required
Y
Description
To indicate that this record is Request Header record in the LDC or Billing Agents Billing Quantity Request file. Value must be: RH The version of the request file to allow for migration from one format to the next as formats change. Recommended that no more than 2 or 3 are supported. The identifier assigned to the LDC during the MDM/R Registration/Enrollment process. The LDC creates SDPs and thus owns those Service Delivery Points and controls the Data Delivery Service associated with each of their SDPs. The identifier assigned to the Organization during the MDM/R Registration/Enrollment process, 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 LDCs Organization Identifier would be placed in both fields. To allow the LDC or Billing Agent to specify a unique identifier related to the request file. This identifier will be associated with each Billing Quantity Request Detail Record as it is stored for processing within the
Request File Format Version
Fixed Number(2)
LDC Organization Identifier
Char(8)
Data Delivery Service Organization Identifier
Char(8)
Request File Identifier
Varchar (30)
AAAAAAAAAAA
153
Field
Data Type/Length
Format
Required
Description
MDM/R.
2.6.8.3
Billing Quantity Request Detail Record

Table 2.6.3 BILLING QUANTITY REQUEST DETAIL RECORDS
Field
Data Type/Length
Char(2)
Format
General: AA Specific Usage: RD AAAAAA
Required
Y
Description
To indicate that this record is Request Detail record in the LDC or Billing Agents Billing Quantity Data Delivery Request file. Value must be: RD To allow the LDC or Billing Agent to 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) The first Daily Read Period date to be included in the Billing Quantity Response file for this request detail record. 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.
Request Detail Identifier
Varchar(30)
Request Daily Read Period Start Date (Optional on PULL Request)
Date
yyyyMMdd
154
Field
Request Daily Read Period End Date
Data Type/Length
Date
Format
yyyyMMdd
Required
Y
Description
This is the exclusive end date for a given billing request. It represents the first date that will NOT be included in billing quantities for the SDP associated with the request. The end date is an exclusive end date. It is treated as the beginning of the Request Daily Read Period End Date (midnight (00:00:00) which is the beginning of the day) NOTE: Special Off-Cycle Billing Quantity Requests: 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 end date of the original response (i.e. the Response Daily Read Period End Date). If this date differs, then the Billing Quantity response will end with this requested date. If the request end date is later than the Request Version Date Time then the request can not be satisfied for the purpose of rebuilding a previous Billing Quantity response.
Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: 00037482 General : A Specific : P,O, or S
The LDC/Billing Agent must provide the specific Universal SDP IDs that are to be reported on by the Billing Data Interface. This field is used to inform the MDM/R if this is an On-Cycle Request and Off-Cycle Request. Values: P Requested PULL On Cycle O Requested PULL Off Cycle S Scheduled PUSH On Cycle (this code is not applicable in this request format) Allows the requestor to request the calculation of Billing Quantities over a specified period but only using Meter and Usage data up to the Request Version Date Time. This is a date time other than the current date time. This time must be reported in EST 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 Response Version Date Time of the original response. The Request Type must be set to O Requested PULL Off Cycle, when this field is specified in the request otherwise the request will be rejected.
Request Type
Char(1)
Request Version Date Time
Date/Time
yyyyMMddHHmmss
155
2.7
Billing Quantity Response

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

The purpose of this interface is to prepare the file with Billing Quantity data and send the file to the LDC or authorized Billing Agent based on either a scheduled Billing Cycle Schedule or as a result of processing a Billing Quantity Request File. The MDM/R supports two methods for preparing Billing Quantity data to send to LDCs or their Billing Agents. The LDC or their Billing Agents may choose one method or the other based on its operational requirements. 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 Quantity data has been synchronized by the LDC or their billing agents with the MDM/R. Request-Response Billing Data Service (request-response) method which delivers Billing Quantity data in response to a request from the LDC or their Billing Agents using this Billing Quantity Request Interface. This method can be used for requesting Billing Quantity data for both on-cycle and off-cycle billing.
Section 7 of the MDM/R Detailed Design Document, Framing of Billing Quantities discusses the framing of Billing Quantity data. Section 8 of the MDM/R Detailed Design Document, Billing Quantity Processing, discusses the delivery of Billing Quantity data.
2.7.2
2.7.2.1
Integration
Direction
MDM/R to the LDC or their Billing Agent

This is a batch process involving the transfer of pipe (|) delimited text files.
2.7.3
Business Rules
1. In MDM/R, Billing Quantity data are computed based on the Read Date identified in the Billing Cycle Schedule or the Request Daily Read Period End Date specified in the Billing Quantity Request Detail record. 2. The Billing Quantity Response File is generated in the appropriate format. 3. Multiple Billing Quantity Responses may be provided for a single Billing Quantity Request (or push) if the following conditions occur:
156
a. A season change (i.e. a global RPP price change event) occurred during the period being requested. For any SDP for which the Framing Structure is TOU/CPP or Periodic the billing service looks for a global price change event that falls within the billing period and delivers Billing Quantities for each sub-period defined by one or more global price change events. The global RPP price change events are defined in the Energy Purchase Service Calendar associated with the Framing Structure assigned to each SDP b. The framing structure for an SDP changed during the period being requested. c. An Account to SDP relationship changed during the period being requested. The billing service looks for an Account to SDP relationship change that falls within the billing period and delivers Billing Quantities for each sub-period defined by one or more Account to SDP relationship change events. 4. The following are exception cases: a. The MDM/R is unable to produce a Billing Quantity Response since there was no meter associated with the SDP in the required period. b. The MDM/R is unable to produce a Billing Quantity Response due to missing intervals in the required period. c. The MDM/R is unable to produce a Billing Quantity Response since the SDP is not active during the billing period. d. One or more intervals have the VEE outcome of NVE
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
157
2.7.7

Frequency: For the Request-Response Billing Service (Pull) a Billing Quantity Response file is sent in response to a specific Billing Quantity Request. For the Scheduled Billing Service (Push) a Billing Quantity Response file is sent for each billing cycle scheduled for delivery on that day to the LDC or its Billing Agent. Billing Window: Both Push and Pull billing services are controlled by global billing service properties that establish a billing window of three business days. AllowableReadAge / AllowableRead AgeType is set to 0 / Calendar days this global configuration provides that a requested billing period will not be foreshortened, that is, all days requested in a billing period must be included in each Billing Quantity response. LatestReportDays / LatestReportDaysType is set to 3 / Business days this global configuration provides a period of three business days after the last day of a billing period to allow time for the LDC or its authorized agent to provide necessary interval data that may be missing or requires verification or edit. All related global billing service properties are specified in the MDM/R VEE Standard for the Ontario Smart Metering System.
During the billing window Billing Quantity requests (Push or Pull, On-Cycle or OffCycle) remain active if complete framed usage data or interval data for any day are not available or for which the Validation Status is NVE. A no data available response is returned for all unfulfilled requests at 08:00 EST on the calendar day after a billing window closes. Billing Quantity requests submitted after the billing window is closed (i.e. submitted more than three business days after the Request Daily Read Period End Date) will be processed once with a Billing Quantity response returned immediately (with or without a Billing Quantity value dependent on the Transaction Status of the response). Timing: The Billing Quantity Response process will launch and process the Off-Cycle requests (Request Type O) when initially received. On Cycle PULL requests (Request Type P) and On Cycle Scheduled PUSH (Request Type S) will be processed on the regularly scheduled run of the Billing Quantity Response process. This process is configured to run at certain times during the day. This process will run every three hours each day between the hours of 08:00 EST and 23:00 EST, and once at 00:30 EST to initiate ealier processing of billing exception handling. Based on experience gained during ongoing operations of the MDM/R, this schedule may be modified to meet operational requirements. Initially, scheduled PUSH (Request Type S) for the current day will be loaded at 07:30 EST. This schedule may be modified to meet operational requirements The Billing Quantity Response Files are closed and moved to the appropriate FTS/AS2 delivery directories on the following conditions; i. the billing quantity processing has not written to the file for more than BillingExportAdapter.FileIdle seconds, or; ii. the number of records written to the currently open file exceeds BillingExportAdapter.MaxRecords.
158
Initially, the Billing Service Global Parameters of FileIdle and MaxRecords are set to 60 seconds and 10,000 records. Based on experienced gained during initial operations of the MDM/R, these parameters may be modified to meet operational requirements. Service Levels: The Billing Quantity Response File is provided within the following timeframes, based on the Billing Service Global Parameters of AllowableReadAge of 0 calendar days and LatestReportDays of 3 business days: For the Scheduled Billing Service - Billing Quantity data will be provided by 21:05 through the third business day after Day N for all SDPs that have successfully completed the VEE process by 15:00 on any subsequent day through the third business day after Day N. For the Request-Response Billing Service - Billing Quantity data will be provided within six hours of the timestamp of the receipt of the Billing Quantity Request for all SDPs that have successfully completed the VEE process by that time. Where the Billing Quantity Request includes Request Daily Read Period End Dates that are in the future, the Billing Quantity data will be provided within six hours of the Request Daily Read Period End Date based on the Billing Quantity process runs on the Request Daily Read Period End Date. For SDPs that complete the VEE process after the Request Daily Read Period End Date, the Billing Quantity Response will be provided on any subsequent day through the third business day after Day N (the exclusive end date for the Billing Quantity Request). In both cases, Scheduled Billing Service and Request-Response Billing Service, if the process is unable to provide a Billing Quantity response by the end of the billing window (being the exclusive end date plus the LatestReport Days) then on the first run of the Billing Quantity processing after the close of the billing window a no data available Billing Quantity response record will be delivered for each SDP for which Billing Quantity values can not be produced.
2.7.8
2.7.8.1
File Format
TOU/CPP & Periodic Billing Quantity Response File
2.7.8.1.1 File Name Record for the TOU/CPP & Periodic Billing Quantity Response File
Table 2.7.1 FILE NAME RECORD FOR THE TOU/CPP & PERIODIC BILLING QUANTITY RESPONSE FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Specific Usage: <FTSFN> Refer to Section 1.8
Required
Y
Description
This field always contains the record type <FTSFN> This field contains the name of the file on the originating system, as defined in Section 1.8
File Name
Varchar (250)
159
Field Name
Suffix
Data Type/Length
Char (8)
Format
Specific Usage: </FTSFN>
Required
Y
Description
This field always contains the record type </FTSFN>
An example of this record Version 00 would be: <FTSFN>ORG11111.ORG22222.6000.00.20070214221345.DAT</FTSFN> NOTE: Please reference Section 1.8.2 for use of file format version number.
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
Field
Data Type / Length

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

Table 2.7.3 TOU/CPP BILLING QUANTITY RESPONSE DETAIL RECORD
Field
Data Type / Length

Char(2)
Format
General: AA Specific Usage: TR
Required
Y
Description
To indicate that this record is TOU Response Detail record in the LDC or Billing Agents Billing Quantity Response file. Value must be: TR
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if
To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Header Record
160
Field
Data Type / Length
Format
Required
supplied For PUSH Billing Quantities, N
Description
associated with the Request Detail records. This identifier is returned to link the response to the request. To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Detail Record. This identifier is returned to link the response to the request. The first Daily Read Period date included in the TOU/CPP Billing Quantity Response Record for the requested or scheduled SDPs. This date could be different than the Requested Daily Read Period Start Date if there has been a Move Out/Move In at the SDP subsequent to the requested start date during the requested period or if a Season Change related to the TOU Framing has occurred during the requested period. This is the exclusive end date for a given billing quantity response. It 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) Scheduled PUSH responses will provide the Billing Cycle Identifier associated with the SDP in the MMD. Requested PULL responses will contain a null value in this field. Scheduled PUSH responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDCs Organization ID+the Billing Cycle ID. Requested PULL responses will contain a null value in this field. The Universal SDP ID that is associated with the Billing Quantity. The Framing Structure associated with the Service Delivery Point. In this field the value will be: TOU/CPP(EST) for SDPs in Eastern Standard Time. TOU/CPP (CST) for SDPs in Central Standard Time. This field indicates if this was a response to an On-Cycle Request and Off-Cycle Request. Values: P Requested PULL On Cycle O Requested PULL Off Cycle
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
Response Daily Read Period Start Date
Date
yyyyMMdd
Response Daily Read Period End Date
Date
yyyyMMdd
Billing Cycle Identifier (for PUSH only)
Varchar(3)
AAA
Route Identifier (for PUSH only)
Varchar(11)
AAAAAAAAAA A
Universal SDP ID Framing Structure
Fixed Number (8) Varchar (12)
NNNNNNNNNN General: AAAAAAAAA Specific: TOU/CPP(EST) Or TOU/CPP(CST)
Y Y
Request Type
Char(1)
General: A Specific: P, O, or S
161
Field
Data Type / Length

Date/Time
Format
Required
Description
S Scheduled PUSH On Cycle
yyyyMMddHHm mss
To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request.
Response Detail Identifier
Varchar (30)
AAAAAAAAAA
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response. This is the latest insert date time of the set of data used for billing quantity calculations This date time is prior to the Billing Quantity Response data being written into the Billing Quantity Response file that is transferred to the Data Delivery Service Organization. Provides the status of the request transaction. Values include: 00 = Response Completed Successfully 01 = unable to process the request general configuration error. 02 = no data available, billing window expired. 06 = Billing Validation Sum Check failed 07 = Billing Validation Sum Check skipped 08 = Billing Quantity value is not provided in the response 09 = Invalid Billing Determinant 10 = Missing DDS Parameter 11 = Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check (disabled for the MDM/R) 12 = Meter Gap Events Handling 13 = No Dates In Data Delivery Cycles Table (disabled for the MDM/R) 14 = Missing Route Cycle ID (disabled for the MDM/R) 15 = Request Cancelled 16 = Invalid Measurement Profile 17 = Missing Primary Measurement for a Demand Billing Quantity 18 = Reference not found for a calculated billing determinant See Table 2.7.4 for descriptions of the Transaction Status codes and the billing service process conditions or root causes of the exceptions indicated by these codes.
Response Version Date Time
Date/Time
yyyyMMddHHm mss
Transaction Status
Fixed Number(2)
General: NN For EnergyIP Release 6.3 and 7.0, One of 00, 01, 02, 06, 07, 08, 09, 10, 12, 15, 16, 17, 18
Unit of Measure UOM
Varchar (15)
General: AAAAAAA
Provides the Unit of Measure applicable to the Billing Quantities
162
Field
Data Type / Length
Format
Specific Usage for TOU/CPP: KWH
Required
Description
being provided in this response record. Valid values for energy: KWH
Estimated Energy Consumption
Number 2 (12,2)
NNNNNNNNNN NN.NN
Provides that portion of the total energy consumption reported over the period defined from the Response Daily Read Period Start Date to the Response Daily Read Period End Date that has been estimated. 0.00 value if there is no estimated energy consumption NULL if No Response No Billing Quantity value is provided for Transaction Status Codes: 01, 02, 08, 09, 10, 13, 14, 15, 16, 17, or 18. Billing Quantity value is provided for Transaction Status Codes 06 and 07 when the Billing Validation Sum Check BillingSumCheckFailAction parameter is set to Value
Number of Billing Quantity Pairs
Numeric(3)
NNN
The number of Billing Quantity Identifier and Billing Quantity pairs with this response record. For TOU/CPP this should be a minimum of 3 based on the present structure of TOU buckets. Each CPP Event Billing Quantity to be reported will increase the number of pairs by 1. Multiple CPP events with the same price will be summarized into a single CPP event pair for the billing period. For example, a TOU/CPP Response with 2 CPP Events to be reported would result in this field containing the value 5. The design maximum is 10 pairs. To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak To hold the Billing Quantity related to the associated Billing Quantity
Billing Quantity 1 Identifier
Varchar(9)
General: AAAAAAA Example: On Peak
Billing Quantity 1
Number (12,2) Varchar(9)
NNNNNNNNNN NN.NN General: AAAAAAA Example: Mid Peak
Billing Quantity 2
Number (12,2)
NNNNNNNNNN NN.NN
With the deployment of EnergyIP Release 7.2 export of this value and all Billing Quantity values will be Data Type/Length = Number (21,6).
Version 3.3 July 7, 2011 163
Field
Data Type / Length

Varchar(9)
Format
Required
Description
Identifier
General: AAAAAAA Example: Off Peak
To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event
Billing Quantity 3
NNNNNNNNNN NN.NN General: AAAAAAA Example: CPP-08.90
Billing Quantity 4
NNNNNNNNNN NN.NN General: AAAAAAA Example : CPP-08.92
Billing Quantity 5
Billing Quantity 6
NNNNNNNNNN NN.NN General: AAAAAAA Example : CPP-08.96
164
Field
Data Type / Length
Format
Required
Description
by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing.
Billing Quantity 7
To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event by its pricing. E.g. CPP-xx.xx where xx.xx would identify the CPP Event Pricing. To hold the Billing Quantity related to the associated Billing Quantity Identifier
Billing Quantity 8
Billing Quantity 9
Billing Quantity 10
Number (12,2)
NNNNNNNNNN NN.NN
Table 2.7.4 provides descriptions of the Transaction Status codes reported in each Billing Quantity response and also in Report BR04 Billing Delivery Detail Report. The billing service process condition and/or the root causes of exceptions are also described. This table also indicates the EnergyIP Releases which support each code.
Table 2.7.4 Billing Quantity Response Transaction Status and Exceptions
Code 00 Transaction Status / Report BR04 Error Message Response completed successfully Billing Service Condition / Cause of Exception Billing Service successfully processed the Billing Quantity Request EnergyIP Release All
165
Code
Transaction Status / Report BR04 Error Message
Billing Service Condition / Cause of Exception This may occur when: SDP Not active during billing period No meter associated with SDP during billing period Invalid SDP ID 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 period One or more intervals in the billing period has a VEE outcome of NVE ThresholdValue was exceeded for the VEE 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 new meter. 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 Billing Agent Billing Quantity Request placed on HOLD Configuration Error - a Data Delivery Service parameter is missing (Disabled for the MDM/R) Meter not found for a segment or billing period (Disabled for the MDM/R) (Disabled for the MDM/R) Billing Quantity Request cancelled via the GUI Configuration error No measurement attached to the Measurement Profile, or Measurement Profile Name is null in the Data Delivery Service Primary measurement referenced by a
EnergyIP Release
01
Unable to process the request general configuration error
All
02
No data available, billing window expired.
All
06
Billing Validation Sum Check failed ThresholdValue exceeded
6.3, 7.0
07
Billing Validation Sum Check skipped
6.3, 7.0
08 09 10 11 12 13 14 15
Billing Quantity value is not provided in the response Invalid Billing Determinant Missing DDS Parameter Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check Meter Gap Events Handling No Dates In Data Delivery Cycles Table Missing Route Cycle ID Request Cancelled
6.3, 7.0 6.3, 7.0 6.3, 7.0 n/a 6.3, 7.0 n/a n/a 6.3, 7.0
16
Invalid Measurement Profile
6.3, 7.0
17
Missing Primary Measurement for a Demand Billing
6.3, 7.0
166
Code
Transaction Status / Report BR04 Error Message Quantity
Billing Service Condition / Cause of Exception Coincident Peak Demand measurement is missing, or When using tie breaking to determine the peak demand, the coincident peak demand is missing
EnergyIP Release
18
Reference not found for a calculated billing determinant
Reference for symbol in a calculative billing determinant cannot be found. For example, in the expression (CAL1|*25), the value CAL1| should reference a DDS product parameter or a measurement symbol value but the referenced value is not available.
6.3, 7.0
Table 2.7.5 PERIODIC BILLING QUANTITY RESPONSE DETAIL RECORD
Field
Data Type / Length

Char(2)
Format
General: AA Specific Usage: PR
Required
Y
Description
To indicate that this record is Periodic Billing Quantity Response Detail record in the LDC or Billing Agents Billing Quantity Data Delivery Response file. Value must be: PR To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Header Record associated with the Request Detail records. This identifier is returned to link the response to the request. To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Detail Record. This identifier is returned to link the response to the request. The first Daily Read Period date included in the PERIODIC Billing 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. This is the exclusive end date for a given billing quantity response. It 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) Scheduled PUSH responses will provide the Billing Cycle Identifier associated with the SDP in the MMD. This field will contain a null value for Requested PULL responses. Scheduled PUSH responses will
Varchar (30)
AAAAAAAAAA
Varchar (30)
AAAAAAAAAA
Date
yyyyMMdd
Date
yyyyMMdd
Varchar(3)
AAA
Route Identifier
Varchar(11)
AAAAAAAAAAA
167
Field
(for PUSH only)
Data Type / Length
Format
Required
Description
provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDCs Organization ID+the Billing Cycle ID This field will contain a null value for Requested PULL responses.
Fixed Number (8) Varchar(12)
NNNNNNNNNN General: AAAAAAA Specific Usage: PERIODIC
Y Y
The Universal SDP ID that is associated with the Billing Quantity. The Framing Structure associated with the Service Delivery Point. In this record the value should indicate PERIODIC This field indicates if this was a response to an On-Cycle Request and Off-Cycle Request. Values: P Requested PULL On Cycle O Requested PULL Off Cycle S Scheduled PUSH On Cycle To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request.
Request Type
Char(1)
Date/Time
yyyyMMddHHm mss
Varchar (30)
AAAAAAAAAA
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response. This is the latest insert date time of the set of data used for billing quantity calculations This date time is prior to the Billing Quantity Response data being written into the Billing Quantity Response file that is transferred to the Data Delivery Service Organization. Provides the status of the request transaction. Values include: 00 = Response Completed Successfully 01 = unable to process the request general configuration error. 02 = no data available, billing window expired. 06 = billing validation sum check failed 07 = billing validation sum check skipped 08 = Billing Quantity value is not provided in the response 09 = Invalid Billing Determinant 10 = Missing DDS Parameter 11 = Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check
Date/Time
yyyyMMddHHm mss
Transaction Status
Fixed Number(2)
General: NN For EnergyIP Release 6.3, and 7.0 One of 00, 01, 02, 06, 07, 08, 09, 10, 12, 15, 16, 17, 18
168
Field
Data Type / Length
Format
Required
Description
(disabled for the MDM/R) 12 = Meter Gap Events Handling 13 = No Dates In Data Delivery Cycles Table (disabled for the MDM/R) 14 = Missing Route Cycle ID (disabled for the MDM/R) 15 = Request Cancelled 16 = Invalid Measurement Profile 17 = Missing Primary Measurement for a Demand Billing Quantity 18 = Reference not fopund for a calculated billing determinant See Table 2.7.4 for descriptions of the Transaction Status codes and the Billing Service process conditions or root causes of the exceptions indicated by these codes.
Unit of Measure UOM
Varchar (15)
General: AAAAAAA Specific Usage for Periodic: KWH NNNNNNNNNN NN.NN
Provides the Unit of Measure applicable to the Billing Quantities being provided in this response record. Valid values for energy: KWH Provides that portion of the total energy consumption reported over the period defined from the Response Daily Read Period Start Date to the Response Daily Read Period End Date that has been estimated. 0.00 value if there is no estimated energy consumption NULL if No Response No Billing Quantity value is provided for Transaction Status Codes 01, 02, 08, 09, 10, 13, 14, 15, 16, 17, or 18. Billing Quantity value is provided for Transaction Status Codes 06 and 07 when the Billing Validation Sum Check BillingSumCheckFailAction parameter is set to Value
Numeric (12,2)
Periodic Billing Quantity
Numeric (12,2)
NNNNNNNNNN NN.NN
To hold the single Billing Quantity for the period.
2.7.8.2
Hourly Billing Quantity Response File
2.7.8.2.1 File Name Record for Hourly Billing Quantity Response
Table 2.7.6 FILE NAME RECORD FOR THE HOURLY BILLING QUANTITY RESPONSE FILE
Field Name
Data Type/Length
Format
Required
Description
169
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.7.8.2.2 Hourly Billing Quantity Response File Header Record
Table 2.7.7 HOURLY BILLING QUANTITY RESPONSE FILE HEADER RECORD
Field
Data Type / Length

Char(2)
Format
General: AA Specific Usage: HR
Required
Y
Description
Char(2)
AA
Char(8)
Char(8)
Date/Time
yyyyMMddHHm mss
2.7.8.2.3 Hourly Billing Quantity Response Detail Record

Table 2.7.8 HOURLY BILLING QUANTITY RESPONSE DETAIL RECORD
Field
Record Type
Data Type / Length

Char(2)
Format
General:
Required
Y
Description
To indicate that this record is Hourly
170
Field
Identifier
Data Type / Length
Format
AA Specific Usage: SR
Required
Description
Billing Quantity Response Detail record in the LDC or Billing Agents Billing Quantity Data Delivery Response file. Value must be: SR
Varchar (30)
AAAAAAAAAA
To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Header Record associated with the Request Detail records. This identifier is returned to link the response to the request. To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Detail Record. This identifier is returned to link the response to the request. The Response Daily Read Period date for this specific HOURLY Billing Quantity Response Record for the requested SDP. Scheduled PUSH responses will provide the Billing Cycle Identifier associated with the SDP in the MMD. This field will contain a null value for Requested PULL responses. Scheduled PUSH responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDCs Organization ID+the Billing Cycle ID This field will contain a null value for Requested PULL responses. The Universal SDP ID that is associated with the Billing Quantity. The Framing Structure associated with the Service Delivery Point. In this record the value should indicate HOURLY This field indicates if this was a response to an On-Cycle Request and Off-Cycle Request. Values: P Requested PULL On Cycle O Requested PULL Off Cycle S Scheduled PUSH On Cycle To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request.
Varchar (30)
AAAAAAAAAA
Response Daily Read Period Date Billing Cycle Identifier (for PUSH only)
Date
yyyyMMdd
Varchar(3)
AAA
Varchar(11)
AAAAAAAAAAA
NNNNNNNN General: AAAAAA Specific: HOURLY
Y Y
Request Type
Char(1)
General : A Specific : P, O, or S
Date/Time
yyyyMMddHHm mss
Varchar (30)
AAAAAAAAAA
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response.
171
Field
Data Type / Length

Date/Time
Format
yyyyMMddHHm mss
Required
Y
Description
This is the latest insert date time of the set of data used for billing quantity calculations This date time is prior to the Billing Quantity Response data being written into the Billing Quantity Response file that is transferred to the Data Delivery Service Organization. Provides the status of the request transaction. Values include: 00 = Response Completed Successfully 01 = unable to process the request general configuration error. 02 = no data available, billing window expired. 06 = billing sum validation check failed 07 = billing validation sum check skipped 08 = Billing Quantity value is not provided in the response 09 = Invalid Billing Determinant 10 = Missing DDS Parameter 11 = Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check (disabled for the MDM/R) 12 = Meter Gap Events Handling 13 = No Dates In Data Delivery Cycles Table (disabled for the MDM/R) 14 = Missing Route Cycle ID (disabled for the MDM/R) 15 = Request Cancelled 16 = Invalid Measurement Profile 17 = Missing Primary Measurement for a Demand Billing Quantity 18 = Reference not found for a calculated billing determinant See Table 2.7.4 for descriptions of the Transaction Status codes and the Billing Service process conditions or root causes of the exceptions indicated by these codes. Provides the Unit of Measure applicable to the Billing Quantities being provided in this response record. Valid values for energy: KWH Provides that portion of the total energy consumption reported for the Response Daily Read Period Date that has been estimated. 0.00 value if there is no estimated energy consumption
Transaction Status
Fixed Number(2)
General: NN For EnergyIP Release 6.3, and 7.0 One of 00, 01, 02, 06, 07, 08, 09, 10, 12, 15, 16, 17, 18
Unit of Measure UOM
Varchar (15)
General: AAAAAAAA Specific Usage for Hourly: KWH NNNNNNNNNN NN.NN
Numeric (12,2)
172
Field
Data Type / Length
Format
Required
Description
NULL if No Response No Billing Quantity value is provided for Transaction Status Codes 01, 02, 08, 09, 10, 13, 14, 15, 16, 17, or 18. Billing Quantity value is provided for Transaction Status Codes 06 and 07 when the Billing Validation Sum Check parameter BillingSumCheckFailAction is set to Value
Billing Quantity Hour Ending 01 Billing Quantity Hour Ending 02 Billing Quantity Hour Ending 03 Billing Quantity Hour Ending 04 Billing Quantity Hour Ending 05 Billing Quantity Hour Ending 06 Billing Quantity Hour Ending 07 Billing Quantity Hour Ending 08 Billing Quantity Hour Ending 09 Billing Quantity Hour Ending 10 Billing Quantity Hour Ending 11 Billing Quantity Hour Ending 12 Billing Quantity Hour Ending 13 Billing Quantity Hour Ending 14 Billing Quantity Hour Ending 15 Billing Quantity Hour Ending 16
Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2)
NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN
The Billing Quantity for the Hour Ending 01:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 02:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 03:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 04:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 05:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 06:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 07:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 08:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 09:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 10:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 11:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 12:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 13:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 14:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 15:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 16:00:00 EST on the
173
Field
Data Type / Length

Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2) Numeric (12,2)
Format
Required
Description
Response Daily Read Period Date.
Billing Quantity Hour Ending 17 Billing Quantity Hour Ending 18 Billing Quantity Hour Ending 19 Billing Quantity Hour Ending 20 Billing Quantity Hour Ending 21 Billing Quantity Hour Ending 22 Billing Quantity Hour Ending 23 Billing Quantity Hour Ending 00
NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN NNNNNNNNNN NN.NN
The Billing Quantity for the Hour Ending 17:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 18:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 19:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 20:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 21:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 22:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 23:00:00 EST on the Response Daily Read Period Date. The Billing Quantity for the Hour Ending 00:00:00 EST on the Response Daily Read Period Date + 1 (also known as Hour Ending 24 on the Response Daily Read Period Date).
2.7.9
Description Demand Billing Quantities

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

This is a batch process involving the transfer of pipe (|) delimited text files.
174

A) General Meter Read Data 1. The physical meters for the SDP or the meters contributing to the SDP must be delivering Meter Read data to the MDM/R to be processed as required to populate the configured interval data channels. 2. The Meter Read data from physical meters and calculated interval data for virtual channels must be complete for all intervals for all days of the billing period and the latest versions of this data must be used. i. kW calculations and the determination of Peak kW Demand related Billing Quantity data must not be performed if any of the kWh intervals within billing period has a Validation Status of NVE. ii. kVA calculations and the determination of Peak kVA Demand related Billing Quantity data must not be performed if any of the kVAh or kVARh intervals within billing period has a Validation Status of NVE. iii. Neither kWh energy nor kW or kVA demand Billing Quantity responses will be delivered if any of the related kWh, kVAh or kVARh interval data within a billing period has a Validation Status of NVE. 3. Intervals used in all demand calculations must be calculated from interval data within the billing period (defined as intervals with end date/times greater than the Request Daily Read Period Start Date and less than or equal to the Request Daily Read Period End Date). 4. All derived quantity and peak demand determinations, except calculation of kW77 Peak Demand, will be performed for the billing period in EST for all SDPs throughout Ontario. 5. The SDP must have a Framing Structure that specifies the framing of interval data into derived kW and kVA quantities in addition to TOU/CPP, Periodic or Hourly kWh energy quantities. The applicable Framing Structures (as specified in the Technical Interface Specifications, Section 2.2.8, Table 2.2.13) that provide such framing are listed below. For the Eastern Time Zone: TOU/CPP 15 minute Block (EST) TOU/CPP 60 minute Block (EST) TOU/CPP 15 minute Rolling (EST) TOU/CPP 60 minute Rolling (EST) Periodic 15 minute Block (EST) Periodic 60 minute Block (EST) Periodic 15 minute Rolling (EST) Periodic 60 minute Rolling (EST) Hourly 15 minute Block (EST) Hourly 60 minute Block (EST) Hourly 15 minute Rolling (EST)
175
Hourly 60 minute Rolling (EST) For the Central Time Zone: TOU/CPP 15 minute Block (CST) TOU/CPP 60 minute Block (CST) TOU/CPP 15 minute Rolling (CST) TOU/CPP 60 minute Rolling (CST) Hourly 15 minute Block (CST) Hourly 60 minute Rolling (CST) Hourly 15 minute Rolling (CST) Hourly 60 minute Block (CST) Periodic 15 minute Block (CST) Periodic 60 minute Block (CST) Periodic 15 minute Rolling (CST) Periodic 60 minute Rolling (CST) 6. Meter Read data or calculated data for the kWh or kVAh interval channels must have been framed (according to the rules associated with the Framing Structure for the SDP for the billing period) into the appropriate derived kW or kVA quantities before the determination of the kW or kVA Demand related Billing Quantities. 7. Derived kW and kVA quantities will not be stored. Underlying versions of kWh, kVAh and kVARh interval data will support Billing Quantity version traceability. B) kW Demand Determinations The following MMD master data condition must exist for the calculation of kW demand quantities: The SDP must have a physical or virtual meter configured with a Channel Configuration Set that supports the derivation of kW demand quantities. These would be Channel Configuration Sets as specified in the Technical Interface Specifications, Section 2.2.10, Table 2.2.28 specifically, one of: 01 Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh), or 02 Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVARh, derived kVAh), or 03 Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVAh), or 04 - Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVARh, Physical kVAh), or 05 Virtual SDP, Virtual Meter, Virtual Channels (establishing Interval Channels for Virtual kWh), or
176
06 Virtual SDP, Virtual Meter, Virtual Channels (establishing Interval Channels for Virtual kWh, Virtual kVARh, derived Virtual kVAh). C) kVA Demand Determinations The following MMD master data condition must exist for the calculation of kVA related demand quantities: The SDP must have a physical or virtual meter configured with a Channel Configuration Set that supports the derivation of kVA demand quantities. These would be Channel Configuration Sets as specified in the Technical Interface Specifications, Section 2.2.10, Table 2.2.28 specifically, one of: 02 Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVARh, derived kVAh), or 03 Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVAh), or 04 - Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh, Physical kVARh, Physical kVAh), or 06 Virtual SDP, Virtual Meter, Virtual Channels (establishing Interval Channels for Virtual kWh, Virtual kVARh, derived Virtual kVAh). D) Block kW and kVA Derived Quantities 1. Block 60 minute kW derived quantities will be calculated for each clock hour at the end of the hour (e.g. 01:00, 02:00, 03:00) based on the energy (kWh) consumed during each hour for all hours of the day. 2. Block 60 minute kVA derived quantities will be calculated on the each clock hour at the end of the hour (e.g. 01:00, 02:00, 03:00) based on the voltampere hours (kVAh) or var hours (kVARh) consumed during each hour for all hours of the day. 3. Block 15 minute kW derived quantities will be calculated on the quarter hour at the end of each quarter hour (e.g. 01:15, 01:30, 01:45, 02:00) based on the energy (kWh) consumed during each quarter hour for all hours of the day. 4. Block 15 minute kVA derived quantities will be calculated on the quarter hour at the end of each quarter hour (e.g. 01:15, 01:30, 01:45, 02:00) based on the volt-ampere hours (kVAh) or var hours (kVARh) consumed during each quarter hour for all hours of the day. 5. Block 60 minute derived quantities can be based on 5, 10, 15, 30 or 60 minute interval data ending wholly within each clock hour. 6. Block 15 minute derived quantities can be based on 5 or 15 minute interval data ending wholly within each quarter hour. 7. Billing Period Block kW and kVA derived quantities will only be calculated from interval data within the Billing Period (defined as intervals with end date/times greater than the Request Daily Read Period Start Date and less than or equal to the Request Daily Read Period End Date). 8. kW77 Block kW and kVA derived quantities for use in the kW77 Peak kW and kVA demand determination must be based on interval data within the
177
period between 7:00 a.m. & 7:00 p.m. prevailing time. The kW77 period is defined as follows: i. For the Eastern time zone is the period between 0700 hours to 1900 hours Eastern Standard Time during winter (i.e. during Standard Time) and 0600 hours to 1800 hours Eastern Standard Time during summer (i.e. during Daylight Savings Time) on weekdays that are not statutory holidays. ii. For the Central time zone is the period between 0800 hours to 2000 hours Eastern Standard Time during winter (i.e. during Standard Time) and 0700 hours to 1900 hours Eastern Standard Time during summer (i.e. during Daylight Savings Time) on weekdays that are not statutory holidays. E) Rolling kW and kVA Derived Quantities 1. Rolling 60 minute kW derived quantities are based on calculations from subintervals over a rolling period of 60 minutes. These derived quantities are calculated at the end of each sub-interval based on the energy (kWh) consumed during the rolling 60 minute period. 2. Rolling 60 minute kVA derived quantities are based on calculations from subintervals over a rolling period of 60 minutes. These derived quantities are calculated at the end of each sub-interval based on the volt-ampere hours (kVAh) or var hours (kVARh) consumed during the rolling 60 minute period. 3. Rolling 15 minute kW derived quantities are based on calculations from subintervals over a rolling period of 15 minutes. These derived quantities are calculated at the end of each sub-interval based on the energy (kWh) consumed during the rolling 15 minute period. 4. Rolling 15 minute kVA derived quantities are based on calculations from subintervals over a rolling period of 15 minutes. These derived quantities are calculated at the end of each sub-interval based on the volt-ampere hours (kVAh) or var hours (kVARh) consumed during the rolling 15 minute period. 5. Supported sub-interval lengths for rolling 60 minute periods are 5,10,15 and 30 minute. 6. Supported sub-interval lengths for rolling 15 minute periods is 5 minutes. 7. Billing Period Rolling kW and kVA derived quantities will only be calculated from interval data within the Billing Period (defined as intervals with end date/times greater than the Request Daily Read Period Start Date and less than or equal to the Request Daily Read Period End Date). 8. kW77 Rolling kW and kVA derived quantities for use in the kW77 Peak kW and kVA demand determination must be based on interval data within the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory holidays. The kW77 period is defined as follows: i. For the Eastern time zone is the period between 0700 hours to 1900 hours Eastern Standard Time during winter (i.e. during Standard Time) and 0600 hours to 1800 hours Eastern Standard Time during summer (i.e. during Daylight Savings Time).
178
ii. For the Central time zone is the period between 0800 hours to 2000 hours Eastern Standard Time during winter (i.e. during Standard Time) and 0700 hours to 1900 hours Eastern Standard Time during summer (i.e. during Daylight Savings Time). F) Peak Demand Determination and Coincident Quantity The following rules will be used to determine the Peak kW and Peak kVA Demand and associated Coincident kVA and kW Billing Quantities. 1. Peak kW Demand is the maximum kW demand quantity in any period within the billing period using the derived kW data. The derived data can be: i. One of 15 minute or 60 minute and one of Block or Rolling as specified by the Framing Structure in effect during the billing period. 2. The Coincident kVA Quantity associated with the Peak kW Demand will be the highest coincident kVA quantity subject to the following tie breaking rules: i. In the event that there are multiple occurrences of a maximum kW demand quantity in the billing period, the maximum kW demand quantity with the highest coincident kVA quantity will be selected. ii. If there are multiple occurrences of a maximum kW demand quantity with the same highest coincident kVA quantity in the billing period, the most recent maximum kW demand quantity and highest coincident kVA quantity will be selected. 3. Peak kVA Demand is the maximum kVA demand quantity in any period within the billing period using the derived kVA data. The derived data can be: i. One of 15 minute or 60 minute and one of Block or Rolling as specified by the Framing Structure in effect during the billing period. 4. The Coincident kW Quantity associated with the Peak kVA Demand will be the highest coincident kW quantity subject to the following tie breaking rules: i. In the event that there are multiple occurrences of a maximum kVA demand quantity in the billing period, the maximum kVA demand quantity with the highest coincident kW quantity will be selected. ii. If there are multiple occurrences of a maximum kVA demand quantity with the same highest coincident kW quantity in the billing period, the most recent maximum kVA demand quantity and highest coincident kW quantity will be selected. G) kW77 Peak Demand Determination and Coincident Quantity The following rules will be used to determine the kW77 Peak kW and kW77 Peak kVA Demand and associated Coincident kVA and kW Billing Quantities. 1. Peak kW77 Demand is the maximum kW demand quantity in any kW77 period (the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory holidays) within the billing period using the kW77 related derived kW data. The derived data can be: i. One of 15 minute or 60 minute and one of Block or Rolling as specified by the Framing Structure in effect during the billing period.
179
2. The Coincident kVA Quantity associated with the Peak kW77 Demand will be the highest coincident kVA quantity subject to the following tie breaking rules: i. In the event that there are multiple occurrences of a maximum kW demand quantity in all kW77 periods in the billing period, the maximum kW demand quantity with the highest coincident kVA quantity will be selected. ii. If there are multiple occurrences of a maximum kW demand quantity with the same highest coincident kVA quantity in all kW77 periods in the billing period, the most recent maximum kW demand quantity and highest coincident kVA quantity will be selected. 3. Peak kVA77 Demand is the maximum kVA demand quantity in any kW77 period (the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory holidays) within the billing period using the kW77 related derived kVA data. The derived data can be: i. One of 15 minute or 60 minute and one of Block or Rolling as specified by the Framing Structure in effect during the billing period. 4. The Coincident kW Quantity associated with the Peak kVA77 Demand will be the highest coincident kW quantity subject to the following tie breaking rules: i. In the event that there are multiple occurrences of a maximum kVA demand quantity in all kW77 periods in the billing period, the maximum kVA demand quantity with the highest coincident kW quantity will be selected. ii. If there are multiple occurrences of a maximum kVA demand quantity with the same highest coincident kW quantity in all kW77 periods in the billing period, the most recent maximum kVA demand quantity and highest coincident kW quantity will be selected.
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. 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.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.
180
2.7.14 Assumptions
None.
2.7.15 Frequency and Timing

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

2.7.16.1 Demand Billing Quantity Response File Supplement to TOU/CPP, Periodic and Hourly Energy Response
A demand Billing Quantity response record will supplement the corresponding energy related Billing Quantity response record for SDPs assigned a Framing Structure ID code 05 through 28 in the synchronization process.
2.7.16.1.1 File Name Record for Demand Billing Quantity Response
Table 2.7.9 FILE NAME RECORD FOR THE DEMAND BILLING QUANTITY RESPONSE FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
181
2.7.16.1.2 Demand Billing Quantity Response File Header Record

Table 2.7.10 DEMAND BILLING QUANTITY RESPONSE FILE HEADER RECORD
Field
Data Type / Length

Char(2)
Format
General: AA Specific Usage: HR
Required
Y
Description
Char(2)
AA
Char(8)
Char(8)
Date/Time
yyyyMMddHHm mss
2.7.16.1.3 Demand Billing Quantity Response Detail Record

Table 2.7.11 DEMAND BILLING QUANTITY RESPONSE DETAIL RECORD
Field
Data Type / Length

Char(2)
Format
General: AA Specific Usage: DR AAAAAAAAAA
Required
Y
Description
To indicate that this record is Demand related Detail record in the LDC or Billing Agents Billing Quantity Response file. Value must be: DR To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Header Record associated with the Request Detail records. This identifier is returned to link the response to the request. To feedback the unique identifier that the LDC or Billing Agent had supplied in the Request Detail Record. This identifier is returned to link the response to the request. The first Daily Read Period date included in the demand related Billing Quantity Response Record for the
Varchar (30)
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N Y
Varchar (30)
AAAAAAAAAA
Date
yyyyMMdd
182
Field
Data Type / Length
Format
Required
Description
requested or scheduled SDPs. This date could be different than the Requested Daily Read Period Start Date if there has been a Move Out/Move In at the SDP subsequent to the requested start date during the requested period or if a Season Change related to the TOU Framing has occurred during the requested period.
Date
yyyyMMdd
This is the exclusive end date for a given billing quantity response. It 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) Scheduled PUSH responses will provide the Billing Cycle Identifier associated with the SDP in the MMD. Requested PULL responses will contain a null value in this field. Scheduled PUSH responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDCs Organization ID+the Billing Cycle ID. Requested PULL responses will contain a null value in this field. The Universal SDP ID that is associated with the Billing Quantity. The Framing Structure associated with the Service Delivery Point. In this field the value will be one of the demand related framing structures related to Framing Structure ID values 05 through 28 (reference Section 2.2.8, Table 2.2.13).
Varchar(3)
AAA
Varchar(11)
AAAAAAAAAAA
NNNNNNNNNN General: AAAAAAAAA Specific Usage: One of TOU/CPP 15 minute Block (EST), or TOU/CPP 60 minute Block (EST), or TOU/CPP 15 minute Rolling (EST), or TOU/CPP 60 minute Rolling (EST), or Hourly 15 minute Block (EST), or Hourly 60 minute Block (EST), or Hourly 15 minute Rolling (EST), or Hourly 60 minute Rolling (EST), or Periodic 15 minute Block (EST), or Periodic 60 minute Block (EST), or Periodic 15 minute Rolling (EST), or
Y Y
183
Field
Data Type / Length
Format
Periodic 60 minute Rolling (EST), or TOU/CPP 15 minute Block (CST), or TOU/CPP 60 minute Block (CST), or TOU/CPP 15 minute Rolling (CST), or TOU/CPP 60 minute Rolling (CST), or Hourly 15 minute Block (CST), or Hourly 60 minute Block (CST), or Hourly 15 minute Rolling (CST), or Hourly 60 minute Rolling (CST), or Periodic 15 minute Block (CST), or Periodic 60 minute Block (CST), or Periodic 15 minute Rolling (CST), or Periodic 60 minute Rolling (CST)
Required
Description
Request Type
Char(1)
General: A Specific Usage: P, O, or S
This field indicates if this was a response to an On-Cycle Request and Off-Cycle Request. Values: P Requested PULL On Cycle O Requested PULL Off Cycle S Scheduled PUSH On Cycle To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request. To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response. This is the latest insert date time of the set of data used for billing quantity calculations This date time is prior to the Billing Quantity response data being written into the Billing Quantity response file that is transferred to the Data Delivery Service Organization. Provides the status of the request transaction. Values include: 00 = Response Completed Successfully 01 = unable to process the request general configuration error. 02 = no data available, billing window expired. 06 = billing validation sum check
Date/Time
yyyyMMddHHmmss
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N Y
Varchar (30)
AAAAAAAAAA
Date/Time
yyyyMMddHHmmss
Transaction Status
Fixed Number(2)
General: NN Specific Usage: For EnergyIP Release 6.3, and 7.0 One of 00, 01, 02, 06, 07, 08, 09, 10, 12, 15, 16, 17,
184
Field
Data Type / Length
Format
18
Required
Description
failed 07 = billing validation sum check skipped 08 = Billing Quantity value is not provided in the response 09 = Invalid Billing Determinant 10 = Missing DDS Parameter 11 = Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check (disabled for the MDM/R) 12 = Meter Gap Events Handling 13 = No Dates In Data Delivery Cycles Table (disabled for the MDM/R) 14 = Missing Route Cycle ID (disabled for the MDM/R) 15 = Request Cancelled 16 = Invalid Measurement Profile 17 = Missing Primary Measurement for a Demand Billing Quantity 18 = Reference not fopund for a calculated billing determinant See Table 2.7.4 for descriptions of the Transaction Status codes and the Billing Service process conditions or root causes of the exceptions indicated by these codes.
Peak 1 Quantity Identifier
Varchar (10)
General: AAAAAAA Specific Usage: One of Peak kW, or Peak kVA, or Peak kW77, or Peak kVA77
To identify the associated peak Demand Billing Quantity. Values: Peak kW the Peak kW Demand Quantity in the Billing Period Peak kVA the Peak kVA Demand Quantity in the Billing Period Peak kW77 the Peak kW Demand Quantity in the Billing Period in accordance with the kW77 daily periods Peak kVA77 the Peak kVA Demand Quantity in the Billing Period in accordance with the kW77 daily periods This peak demand value will be 15 minute or 60 minute; Block or Rolling; and EST or CST based on the Framing Structure associated with the Service Delivery Point. NOTE 1: kVA quantities for Peak kVA and Peak kVA77 will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. The quantity that was coincident with the peak demand quantity in the Billing Period. For Peak kW and Peak kW77 this quantity is the coincident kVA for the same date time.
Peak 1 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Peak 1 Coincident Quantity
Number (12,2)
NNNNNNNNNNNN. NN
185
Field
Data Type / Length
Format
Required
Description
For Peak kVA and Peak kVA77 this quantity is the coincident kW for the same date time. NOTE 2: Coincident kVA quantities will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. NOTE 3: Coincident kW quantities can only be determined if the Peak kVA Demand Quantity has been determined.
Peak 1 End Date Time
Date/Time
yyyyMMddHHmmss
The date time of the peak kW/coincident kVA pair, or the peak kVA/coincident kW pair. This is the end date time in EST of the 15 minute or 60 minute Block or Rolling period in which the Peak kW Demand Quantity occurred during the Billing Period. To identify the associated peak Demand Billing Quantity. Values: Peak kW the Peak kW Demand Quantity in the Billing Period Peak kVA the Peak kVA Demand Quantity in the Billing Period Peak kW77 the Peak kW Demand Quantity in the Billing Period in accordance with the kW77 daily periods Peak kVA77 the Peak kVA Demand Quantity in the Billing Period in accordance with the kW77 daily periods This peak demand value will be 15 minute or 60 minute; Block or Rolling; and EST or CST based on the Framing Structure associated with the Service Delivery Point. NOTE 1: kVA quantities for Peak kVA and Peak kVA77 will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. The quantity that was coincident with the peak demand quantity in the Billing Period. For Peak kW and Peak kW77 this quantity is the coincident kVA for the same date time. For Peak kVA and Peak kVA77 this quantity is the coincident kW for the same date time. NOTE 2: Coincident kVA quantities will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See
Varchar (10)
General: AAAAAAA Specific Usage: One of Peak kW, or Peak kVA or Peak kW77, or Peak kVA77
Peak 2 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Number (12,2)
NNNNNNNNNNNN. NN
186
Field
Data Type / Length
Format
Required
Description
Business Rules. NOTE 3: Coincident kW quantities can only be determined if the Peak kVA Demand Quantity has been determined.
Date/Time
yyyyMMddHHmmss
The date time of the peak kW/coincident kVA pair, or the peak kVA/coincident kW pair. This is the end date time in EST of the 15 minute or 60 minute Block or Rolling period in which the Peak kW Demand Quantity occurred during the Billing Period. To identify the associated peak Demand Billing Quantity. Values: Peak kW the Peak kW Demand Quantity in the Billing Period Peak kVA the Peak kVA Demand Quantity in the Billing Period Peak kW77 the Peak kW Demand Quantity in the Billing Period in accordance with the kW77 daily periods Peak kVA77 the Peak kVA Demand Quantity in the Billing Period in accordance with the kW77 daily periods This peak demand value will be 15 minute or 60 minute; Block or Rolling; and EST or CST based on the Framing Structure associated with the Service Delivery Point. NOTE 1: kVA quantities for Peak kVA and Peak kVA77 will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. The quantity that was coincident with the peak demand quantity in the Billing Period. For Peak kW and Peak kW77 this quantity is the coincident kVA for the same date time. For Peak kVA and Peak kVA77 this quantity is the coincident kW for the same date time. NOTE 2: Coincident kVA quantities will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. NOTE 3: Coincident kW quantities can only be determined if the Peak kVA Demand Quantity has been determined. The date time of the peak kW/coincident kVA pair, or the peak kVA/coincident kW pair.
Varchar (10)
Peak 3 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Number (12,2)
NNNNNNNNNNNN. NN
Date/Time
yyyyMMddHHmmss
187
Field
Data Type / Length
Format
Required
Description
This is the end date time in EST of the 15 minute or 60 minute Block or Rolling period in which the Peak kW Demand Quantity occurred during the Billing Period.
Varchar (10)
To identify the associated peak Demand Billing Quantity. Values: Peak kW the Peak kW Demand Quantity in the Billing Period Peak kVA the Peak kVA Demand Quantity in the Billing Period Peak kW77 the Peak kW Demand Quantity in the Billing Period in accordance with the kW77 daily periods Peak kVA77 the Peak kVA Demand Quantity in the Billing Period in accordance with the kW77 daily periods This peak demand value will be 15 minute or 60 minute; Block or Rolling; and EST or CST based on the Framing Structure associated with the Service Delivery Point. NOTE 1: kVA quantities for Peak kVA and Peak kVA77 will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. The quantity that was coincident with the peak demand quantity in the Billing Period. For Peak kW and Peak kW77 this quantity is the coincident kVA for the same date time. For Peak kVA and Peak kVA77 this quantity is the coincident kW for the same date time. NOTE 2: Coincident kVA quantities will only be produced if the MMD master data and meter data conditions for the calculation of kVA demand quantities exists See Business Rules. NOTE 3: Coincident kW quantities can only be determined if the Peak kVA Demand Quantity has been determined. The date time of the peak kW/coincident kVA pair, or the peak kVA/coincident kW pair. This is the end date time in EST of the 15 minute or 60 minute Block or Rolling period in which the Peak kW Demand Quantity occurred during the Billing Period.
Peak 4 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Number (12,2)
NNNNNNNNNNNN. NN
Date/Time
yyyyMMddHHmmss
188
2.7.17 File Format Billing Quantity Response Version 01

Version 01 for all Billing Quantity response file types will involve only incrementing the FTS file name File Version (element 4: FILE_VER) to a value of 01, and the addition of an End-Of-File record as the last record for each Billing Quantity response file. All other file format specifications Response File Header records and Response File Detail records specified for Version 00 will remain unchanged in Version 01. The following provides the File Name Record specification and End-Of-File record specification for Version 01 for all MDM/R Billing Quantity response types.
2.7.17.1 File Name Record Version 01
The first record in the response interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
Table 2.7.12 FILE NAME RECORD FOR VERSION 01 BILLING QUANTITY RESPONSE FILES
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.7.17.1.1 File Name Record: TOU/CPP & Periodic Billing Quantity Response File
2.7.17.1.2 File Name Record: Hourly Billing Quantity Response File
2.7.17.1.3 File Name Record: Hourly Billing Quantity Response File
2.7.17.2 End-of-File Record Version 01
The last record in each Billing Quantity response file will be an End-Of-File (EOF) record as described in table 2.7.13. Other than the Record Type being set to ER, the
189
remaining fields in this record will contain the same values as found in the header record of the file. The EOF Record will be present in each Version 01 Billing Quantity response file for the following FTS File Types: File ID 6000 Billing Quantity Response TOU/CPP & Periodic File ID 6100 Billing Quantity Response Hourly File ID 6200 Billing Quantity Response Demand
END-OF-FILE RECORD FOR VERSION 01 BILLING QUANTITY RESPONSE
Table 2.7.13 FILES
Data Element
Data Type/Length
Char(2)
Format
General: AA Specific usage: ER General: AA Specific usage: 01 General: AAAAAAAA Example: ORG23153
Required
Y
Comments
This field indicates that this record is the last or end-of-file record of the response file. Value must be ER This field indicates that this record is the last or end-of-file record of the response file. Value must be ER This field contains the Organization ID of the LDC that owns the SDPs in the response file. This is the unique identifier assigned to the LDC during the registration/enrollment process. The LDC creates each SDP and thus owns those SDPs. The Organization ID assigned to the Organization that is providing Billing Services for the LDC (this may be the LDC itself). Billing Quantities are only provided to the Organization that is associated with each SDP as providing Billing Services in the MMD. Provides the date time when the Response File was created by the MDM/R EnergyIP. This is not the date time of the delivery.
Char(2)
LDC Organization Number
Char(8)
Char(8)
Date/Time
yyyyMMddHHmmss
Sample End-Of-File Record Version 01 Billing Quantity Response Types: 6000, 6100, 6200 ER|01|ORG70000|ORG70000|20100910150721
190
2.8
2.8.1
Billing Cycle Schedule Interface

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

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)

1. The MDM/R posts valid dates for each Billing Cycle ID in the file in MDM/R. Valid dates are any dates that exist in a calendar year (i.e.: June 31st is an invalid date, July 1st is a valid date) 2. Valid dates (for a given LDC Identifier and Billing Cycle ID) overwrite any previous dates in MDM/R as long as the date is beyond the FutureDays parameter. 3. Updates to a Billing Cycle records that are within the number of calendar days specified by the FutureDays parameter are not processed and an exception is created. 4. The processed Billing Cycle File sent by the LDC is placed in the Process Directory in the MDM/R. 5. The following are exception cases: a. The MDM/R Billing Cycle Schedule Adapter detects exceptions in regards to invalid file format and data type exceptions. b. The MDM/R detects exceptions when the Billing Cycle date is in the past or when the Billing Cycle record is within the number of calendar days specified by the FutureDays parameter. 6. The Billing Cycle Schedule Interface Exceptions are reported via the systems standard output and written to the Cycle Synchronization log file.
192
A confirmation will be sent to the LDC in Report IR03, Billing Cycle Schedule Exceptions Report, indicating a successful or failed load. NOTE: In the event of a load failure, the pre-existing Billing Cycle Schedule may have been corrupted and remedial action will need to be taken by the LDC and/or its designated agents in association with the SME/OSP. As this corruption will effectively remove all future Billing Cycle dates, the OSP will retain and reinstate the most recent copy of the LDCs Billing Cycle Schedule.
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 LDCs 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
2.8.7

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

2.8.8.1 File Name Record for the Billing Cycle Schedule File
193
Table 2.8.1
FILE NAME RECORD FOR THE BILLING CYCLE SCHEDULE FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.8.8.2 Billing Cycle Schedule File
Table 2.8.2 BILLING CYCLE SCHEDULE FILE
Field
Read Date
Data Type/Length
Date
Format
DDMMYYYY
Required
Y
Description
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 SDPs associated with this billing cycle ID. Note: The date format does not conform to the Section 1.7 date format specification.
Day of week
Varchar (3 )
General: AAA Examples: MON TUE.
This is the 3 character abbreviation for the day of the week for the given cycle date all in caps.
Billing Cycle ID
Varchar (3)
General: AAA Examples: 1 C45.
Each SDP may have a Billing Cycle ID defined as part of the Periodic Audit or Incremental Synchronization process (see sections 2.2 and 2.3 of this document). The Billing Cycle ID is the LDCs identifier for a group of SDPs that have the same billing period.
194
2.9
2.9.1
Aggregated Settlement Data

Description
The MDM/R supports the aggregation of interval consumption data on an hourly basis for each LDC based on the Loss Factor Classifications for each SDP for a Daily Read Period date. These aggregations are provided to support LDCs requirements for settlement in the following areas: Net System Load Shape Calculations; and RPP Variance Account Management.
This aggregated data will be provided to the LDC as a scheduled production of a file on a daily basis.
2.9.2
2.9.2.1
Integration
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.3
Business Rules
1. Virtual SDPs will be ignored. 2. Only physical SDPs with a valid Loss Factor Classification of 01 through 12 will be considered in this process. SDPs without a Loss Factor Classification will be ignored. 3. Only physical SDPs with a Framing Structure of Hourly or TOU/CPP(xxx) will be considered in this process. SDPs with Framing Structure of Periodic will be ignored. 4. At 00:00:00 on Daily Read Period date N + 1, Capture the SDP and associated Loss Factor Classification for each LDC for all SDPs that have a Loss Factor Classification associated on a given Daily Read Period date N. 5. On day N + 3 for all SDPs by Loss Factor Classification for day N, gather all of the latest interval consumption data (validated) for each interval for all meters associated with the SDPs. This interval consumption and related meter data is required to ensure that the Data Aggregation File and the Data Aggregation Contributors File are produced from the same data for auditing purposes. (Based on experience gained in the initial operations of the MDM/R, the number of days between the daily read period and aggregation may be extended if more days are necessary to complete the VEE process to ensure a high quality result of the Data Aggregations)
195
6. Using the gathered interval consumption data (from previous step) compute the hour-by-hour aggregations for each Loss Factor Classification for each LDC. Hour-by hour aggregations will include: Total Aggregated Consumption including intervals with Validation Status VAL; NV; EST, and NVE Validated Aggregated Consumption including intervals with Validation Status VAL (all Change Methods) and NV Estimated Aggregated Consumption including intervals with EST (all Change Methods) NVE Aggregated Consumption including intervals with Validation Status NVE
7. A daily Data Aggregations File is generated for each LDC for Daily Read Period date N will include for each of the 24 hours of the Daily Read Period: Aggregation Version Date Time which is the latest insert time of the interval data set used each hourly aggregation Loss Factor Classification The hour-by-hour aggregations specified in Item 6 above The actual SDP count for each hour-by-hour aggregation The actual interval count for each hour-by-hour aggregation specified in Item 6 above The count of interval expected to contribute to each hour-by-hour aggregation
8. A Data Aggregations Contributors File will be created with the following detail: Universal SDP ID (all active Universal SDP IDs with the associated Loss Factor Classification must be listed in the report even if they dont have a meter associated with them.) Loss Factor Classification (Aggregation Classification) For all Interval Consumption data related to the SDP for day N includes the following details for each unique SDP_Ref, Channel_Ref, Meter_Ref: a. Meter ID (associated with the Meter_Ref) b. Channel Ref c. Interval Length d. Number of intervals (number of intervals found with any validation status) e. Number of Validated Intervals (number of intervals with validation status (NV or VAL) f. Number of Estimated Intervals (number of intervals with validation status (EST)
196
g. Number of Needs Verification Editing Intervals (number of intervals with validation status (NVE)
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.
2.9.7

Frequency: The Data Aggregation process is run daily. Timing: The Data Aggregation file and the related Data Aggregation Contributors File are produced for each Daily Read Period date N on day N + 3 calendar days and sent to the LDC.
2.9.8
2.9.8.1
File Format
Data Aggregation File
2.9.8.1.1 File Name Record for the Data Aggregation File
Table 2.9.1 FILE NAME RECORD FOR THE DATA AGGREGATION FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
This field always contains the record type <FTSFN> This field contains the name of the file on the originating system This field always contains the record type </FTSFN>
File Name Suffix
Varchar (250) Char (8)
Y Y
197
2.9.8.1.2 Data Aggregation File Header Record
Table 2.9.2 Data Aggregation Header Record
Field
Record Type Identifier File Format Version LDC Organization ID
Data Type / Length

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

Char(1)
Format
A
Description
To indicate that this record is Detail record in the Data Aggregation file. Value shall be: D This is the latest insert time of the set of intervals underlying each hourly aggregation value The Loss Factor Classification is an LDC supplied attribute for physical SDPs supplied via the synchronization process. Valid values: 01 through 12 The end date time for each of the 24 hours ending 01:00:00 EST through 00:00:00 EST of the Daily Read Period. Note: Hour Ending 24 of the Daily Read Period N is denoted as 00:00:00 on date N+1
Date/Time
yyyyMMddHHmm ss NN
Number (2)
Aggregated Consumption Hour Ending Date/Time Total Aggregated Consumption Hour Ending HH
Date/Time
yyyyMMddHHmm ss
Numeric (12,2)
NNNNNNNNNN. NN
The sum of interval consumption values for physical SDPs with a Framing Structure of Hourly or TOU/CPP (EST) or TOU/CPP (CST) for Loss Factor Classification NN for all intervals ending hour HH including validation status VAL; NV: EST, and NVE
198
Field
Data Type / Length
Format
Description
Intervals with validation status VAL will include Change Methods: NULL and VER. Intervals with validation status EST will include Change Methods: NULL; ESA: ESB; ESC; ESD; ESE; ESF; and EDT
Valid Aggregated Consumption Hour Ending HH
Numeric (12,2)
NNNNNNNNNN. NN
The sum of interval consumption values for physical SDPs with a Framing Structure of Hourly or TOU/CPP (EST) or TOU/CPP (CST) for Loss Factor Classification NN for all intervals ending hour HH including validation status VAL and NV. Intervals with validation status VAL will include Change Methods: NULL and VER.
Estimated Aggregated Consumption Hour Ending HH
Numeric (12,2)
NNNNNNNNNN. NN
The sum of interval consumption values for physical SDPs with a Framing Structure of Hourly or TOU/CPP (EST) or TOU/CPP (CST) for Loss Factor Classification NN for all intervals ending hour HH including validation status EST. Intervals with validation status EST will include Change Methods: NULL; ESA: ESB; ESC; ESD; ESE; ESF; and EDT
NVE Aggregated Consumption Hour Ending HH
Numeric (12,2)
NNNNNNNNNN. NN
The sum of interval consumption values for physical SDPs with a Framing Structure of Hourly or TOU/CPP (EST) or TOU/CPP (CST) for Loss Factor Classification NN for all intervals ending hour HH including validation status NVE Actual count of physical SDPs contributing to the Total Aggregated Consumption Hour Ending HH. Actual count of intervals within hour ending HH 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
SDP Count for Hour Ending HH Total Interval Count for Hour Ending HH
Number (8) Number (10)
NNNNNNNN NNNNNNNNNN
Valid Interval Count for Hour Ending HH Estimated Interval Count for Hour Ending HH
Number (10)
NNNNNNNNNN
Actual count of intervals within hour ending HH with validation status VAL and NV Intervals with validation status VAL will include Change Methods: NULL or VER.
Number (10)
NNNNNNNNNN
Actual count of intervals within hour ending HH with validation status EST. Intervals with validation status EST will include Change Methods: NULL; ESA: ESB; ESC; ESD; ESE; ESF; or EDT
NVE Interval Count for Hour Ending HH Expected Interval Count for Hour Ending HH
Number (10)
NNNNNNNNNN
Actual count of intervals within hour ending HH with validation status NVE. Count of intervals expected to contribute within hour ending HH. For example an hourly channel is expected to contribute 1 interval; a 15 minute channel is expected to contribute 4 intervals.
Number (10)
NNNNNNNNNN
199
2.9.8.2
Data Aggregation Contributors File
2.9.8.2.1 File Name Record for the Data Aggregation Contributors File
Table 2.9.4 FILE NAME RECORD FOR THE DATA AGGREGATION CONTRIBUTORS FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
This field always contains the record type <FTSFN> This field contains the name of the file on the originating system This field always contains the record type </FTSFN>
File Name Suffix
Varchar (250) Char (8)
Y Y
2.9.8.2.2 Data Aggregation Contributors File Header Record This assumes that all data for a given LDC for a given Daily Read Period date (N) is all selected (copied to a temporary table for this processing) at the same time. If the selection of data is performed on a per LDC per Loss Factor Classification one at a time then this may require multiple headers or multiple files.
Table 2.9.5 Data Aggregation Contributors Report Header Record
Field
Record Type Identifier File Format Version LDC Organization Identifier Daily Read Period Date
Data Type / Length

Char (1)
Format
A
Description
To indicate that this record is Header record in the Data Aggregations Contributors Report file. Value shall be: H The version of the file to allow for migration from one format to the next as formats change. Recommended that no more than 2 or 3 are supported at any one time. The identifier assigned to the LDC during the MDM/R Registration/Enrollment process. The LDC creates SDPs and thus owns those Service Delivery Points. The date of the Daily Read Period that is being processed through the Settlement Aggregation process. This is the 24-hour period including all intervals of the hour ending 01:00:00 of the Daily Read Period date N th and extending through all intervals of the 24 hour ending 00:00:00 on date N+1
Char (2)
NN
Char (8) Example: ORG82357 Date
NNNNN
yyyyMMdd
Data Aggregation End Date Time
Date Time
yyyyMMddH Hmmss
The date time when the Data Aggregation process and Data Aggregation Contributors Report process ended. (In EST)
200
2.9.8.2.3 Data Aggregation Contributors File Detail Records There will be one detailed record per SDP, Loss Factor Classification, Meter combination that contributed to the aggregations in an LDCs Data Aggregations file for the specified Daily Read Period date.
Table 2.9.6 Data Aggregation Contributors File Detail Records
Field
Record Type Identifier Universal SDP ID
Data Type / Length

Char(1)
Format
A
Description
To indicate that this record is Detail record in the Data Aggregation Contributors Report file. Value shall be: D The Ontario-wide unique identifier assigned by the Universal SDP ID Assignment Request/Response process. The Loss Factor Classification is an LDC supplied attribute for physical SDPs supplied via the synchronization process. Valid values: 01 through 12 This identifier is maintained in the LDC systems and uniquely identifies the SDP.
Number (8)
NNNNNNNN
Loss Factor Classification
Number (2)
NN
SDP ID
Varchar (50)
For Universal SDP IDs with an associated Loss Factor Classification and No associated meter the following fields will be empty. Meter ID Varchar (50) No format prescribed NNNNNNNNNNN NNNN NNNN yyyyMMddHHmm ss NNNN This is an identifier of the installed meter that was supplied by the LDC and must be unique within an LDC. This is an internal system identifier within EnergyIP for the channel associated with an SDP. Channel interval length in seconds This is the latest insert time of the set of intervals for this meter channel on this Daily Read Period date 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 Count Number (4) NNNN Actual count of intervals found for this meter 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 Count Number (4) NNNN Actual count of intervals found for this meter 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 Count Number (4) NNNN Actual count of intervals found for this meter channel on this Daily Read Period date with Validation Status of Needs Verification/Editing (NVE)
Channel_Ref Interval Length Version Date Time Interval Count
Varchar (15) Number (4) Date/Time
Number (4)
201
2.10
Meter Reads Retrieval Web Services Request/Reply

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

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

1. The LDC, AMI Operator, Billing Agent, Retailer, or other Customer Contracted Agent, is authorized to receive web services.
The addition of register readings is planned for deployment as part of EnergyIP Release 7.2
202
a. Organizations utilizing Web-Services must be registered and setup as an active organization in the MDM/R. b. Self-signed certificates must be created and exchanged with the MDM/R prior to use of Web-Services. c. LDC access to Web-Services and all SDPs created by the LDC is granted when each SDP is created using the synchronization process. d. Using the synchronization processes the LDC grants read-only WebServices access for each SDP to it AMI Operator by establishing an SDP to AMI Operator Relationship for each SDP. e. Using the synchronization processes the LDC grants read-only WebServices access for each SDP to it Billing Agent by establishing an SDP to Billing Relationship for each SDP. f. Using the synchronization processes the LDC may grant read-only Web-Services access for each SDP to Retailers by establishing an SDP to Energy Service Provider Relationship for each SDP.
g. Using the synchronization processes the LDC may grant read-only Web-Services access for each SDP to Customer Contracted Agents (CCA) by establishing an SDP to CCA Service Provider Relationship for each SDP. 2. The response message will contain zero data records in the following events: a. the Universal SDP ID is not recognized by the MDM/R; b. no data records are available between the request start time and end time; c. the measurementProfile is invalid. This may be due to the following causes: The measurementProfile value requested is not MP01, MP02, MP03, or MP04, as currently defined; The measurementProfile requested does not map to the Framing Structure of the SDP.
3. Interval consumption data can be delivered for any SDP regardless of framing structure. 4. Daily consumption data can be delivered for any SDP regardless of framing structure. 5. Daily consumption values will only be delivered for requests of complete 24 hour periods that start at midnight and end at midnight of any subsequent day. 6. For SDPs that are framed as TOU/CPP, daily TOU Billing Quantity data and Interval Consumption data will be returned, if requested and available. 7. For SDPs that are framed as Periodic or Hourly, Daily TOU Billing Quantity data is not available. 8. For Virtual SDPs, interval data delivered will be summed data, including the most restrictive data quality indicator, from the physical SDPs associated to that Virtual SDP (e.g.: where an hourly interval of one child SDP has a
203
validation Status of VAL and the same hourly interval from a second child has a validation Status of EST, the most restrictive quality indicator is EST).
The LDC is enrolled and has an Organization ID assigned. The AMI Operator, Billing Agent, Retailer, or other Customer contracted agents has an Organization ID The LDC has authorized access to the SDP to the AMI Operator, Billing Agent, Retailer, or other Customer Contracted Agent.
The following outcome will result from the file being processed through the interface: The requested interval consumption data or Billing Quantity data for the identified Universal SDP ID for the specified date range has been generated and delivered to the requesting LDC or Authorized Interested Party. The response message contains zero data records if: The Universal SDP ID is not recognized by the MDM/R No data records are available between the request start time and end time. The measurementProfile is invalid.
2.10.6 Assumptions
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MM-DDTHH:MI:SS.sss[[+|-]TZH:TZM] Date/Time fields must always be expressed in Eastern Standard Time (EST)

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

2.10.8.1 Interval and Billing Quantity Request Message
The EnergyIP meter reads retrieval .xml schema is based on the XML Technology standards of the World Wide Web Consortium (W3C). The following schema uses the namespace prefix PrefixedAttName = xmlns: specifying the namespace name NCName = met associated with each atttribute name as generally described in the W3C standard: Namespaces in XML.4 The RequestMessage portion of the EnergyIP meter reads retrieval request/reply interface includes the elements listed below. Refer to the diagram that follows for the XML schema view of these elements.
4
Use of the namespace prefix and namespace name met for the meter reads retrieval request and reply will be deployed with EnergyIP Release 7.0.
Version 3.3 July 7, 2011 204
Header Contains descriptive information about the message Request Contains the details regarding the request.
Table 2.10.1
REQUEST MESSAGE ATTRIBUTES
<Attribute>
Data Type/ Length
Format
Required
Description
<?xml version=1.0 encoding=UTF-8?> XML declaration Specific Usage: <?xml version=1.0 encoding=UTF-8?> </soapenv:Envelope> <soapenv:Body> <met:RequestMessage> <met:RequestMessage> Specific Usage: xmlns:met =http:/www.emeter.co m/energyip/meterreadi nterface <met:Header> <met:verb> <met:noun> <met:revision> Specific Usage: get Specific Usage MeterRead Specific Usage: 1 Date/ Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] AAAAAAAAA Y Y Y The only value displayed under this Tag is get The only value displayed under this Tag is MeterRead This Tag indicates the version of the message The only value is 1 The date/time of the request in EST Y Location of the xml name space Y
Defines the XML version and the character encoding used in the document
<met:dateTime>
<met:messageID>
Varchar (30)
The unique ID for the message. This will be populated as <correlationId> in the response if supplied in the request.
</met:Header> <met:Request> <met:startTime> Date/ Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example: Y Start date/time for data requested. NOTE : When requesting daily Consumption or TOU data, the startTime must be 00:00:00 of the date being requested. If a time other than 00:00:00 is specified, no data will be returned. For Interval data, this time may be any time during the
205
<Attribute>
Data Type/ Length
Format
UTC 5 (EST) would be: 1994-1105T08:15:30.00005:00 UTC would be: 1994-11-05T13:15:30Z
Required
Description
day For example, a startTime of 2007-04-01T05:00:00.000-05:00 would request data that occurs after 00:00 EST on April 1, 2007 If the requested start time is part way though the reported interval of the meter, the data set returned will start with the next interval reported. For example, for a meter reporting 15 minute intervals, a startTime of 2007-0401T05:05:00.000-05:00 would request data that occurs after 00:05 EST on April 1, 2007. The first interval reported would be the 15 minute interval ending at 00:15 EST on April 1, 2007
<met:endTime>
Date/ Time
End date/time for data requested. This is the exclusive end date for a given request. It represents the first date that will NOT be included in quantities for the Universal SDP ID 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). NOTE : When requesting daily Consumption or TOU data, the endTime must be 00:00:00 of the date being requested. If a time other than 00:00:00 is specified, no data will be returned. For Interval data, this time may be any time during the day. 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) If the requested end time is part way though the reported interval of the meter, the data set returned will end with the last interval reported. For example, for a meter reporting 15 minute intervals, an endTime of 2007-0501T10:05:00.000-05:00 would request data that occurs after 05:05 EST on May 1, 2007. The last interval reported would be the complete 15 minute interval
206
<Attribute>
Data Type/ Length
Format
Required
Description
ending at 05:00 EST on May 1, 2007
<met:versionTime>
Date/Time
Allows the requestor to Request Billing Quantity data or Interval Consumption data over a specified period but only using Meter and Usage data up to the Version Time. This is a date time other than the current date time. If the intent of the request is to validate or rebuild previously delivered Billing Quantity data or Interval Consumption data underlying previously delivered Billing Quantity data, then this date must be the same as the Response Version Date Time of the delivered Billing Quantities Response. NOTE: If no versionTime specified, the most current version of data will be delivered. This field should be hard-coded to indicate that SDP_X_UNIVERSAL_ID will always be used Universal SDP ID (Physical or Virtual) Determines the type of data that is returned through the Web Services Response. The following values can be specified : MP01 Daily cumulative consumption MP02 Daily TOU consumption MP03 Interval consumption MP04 Daily TOU and Interval consumption NOTE : If not submitted default response will be MP01 Organization ID of the requestor. Used for authorization.
<met:objectIdType>
Varchar (30)
General : AAAAAAAA Specific Usage: SDP_X_UNIVERSAL _ID AAAAAAAA General: AAAAAAAAA Specific usage: One of MP01 MP02 MP03 MP04
<met:objectId> <met:measurementProfile>
Varchar (30) Varchar (30)
Y N
<met:organisationCode>
Varchar (30)
General: AAAAAAAAA Example: ORG12345 </met:Request> </met:RequestMessage> </soapenv:Body> </soapenv:Envelope>
2.10.8.1.1 Sample Request Message <?xml version=1.0 encoding=UTF-8?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://www.emeter.com/energyip/meterreadinterface"> <soapenv:Header/> <soapenv:Body>
207
<met.RequestMessage > <met.Header> <met.verb>get</met.verb> <met.noun>MeterRead</met.noun> <met.revision>1</met.revision> <met.dateTime>2007-04-10T09:30:15-05:00</met.dateTime> <met.messageID>TXN12345</met.messageID> </met.Header> <met.Request> <met.startTime>2007-04-01T00:00:00-05:00</met.startTime> <met.endTime>2007-04-03T00:00:00-05:00</met.endTime>   <met.objectIdType>SDP_X_UNIVERSAL_ID</met.objectIdType> <met.objectId>1234567890</met.objectId>   <met.organisationCode>ORG12345</met.organisationCode> </met.Request> </met.RequestMessage> </soapenv:Body> </soapenv:Envelope>
2.10.8.2 Interval and Billing Quantity Response Message
The EnergyIP meter reads retrieval .xml schema is based on the XML Technology standards of the World Wide Web Consortium (W3C). The following schema uses the namespace prefix PrefixedAttName = xmlns: specifying the namespace name NCName = met associated with each atttribute name as generally described in the W3C Namespaces in XML standard. The ReplyMessage portion of the EnergyIP meter reads retrieval request/reply interface includes the elements listed below. Refer to the diagram that follows for the XML schema view of these elements. Header Contains descriptive information about the message Reply Contains the details regarding the request. Payload Providing the start time, end time, and quantity values of the data set for each reading type in the reply.
The <MeterReading> reply records are organized into repeating blocks for each <readingTypeId> in the reply.
208
Table 2.10.2
REPLY MESSAGE ATTRIBUTES
<Attribute>
Data Type/ Length
Format
Description
<?xml version=1.0 encoding=http://schemas.xmlsoap.org/soap/envelope/?> XML declaration Specific Usage: <?xml version=1.0 encoding=http://schema s.xmlsoap.org/soap/env elope/?> </soapenv:Envelope> </soapenv:Header> </soapenv:Body> <met:ReplyMessage> <met:ReplyMessage> Specific Usage: xmlns:met=http:/www. emeter.com/energyip/ meterreadinterface <met:Header> <met:verb> <met:noun> <met:revision> <met:dateTime> Date/Time Specific Usage: reply Specific Usage: MeterRead Specific Usage: 1 Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] </met:Header> <met:Reply> <met:correlationId> <met:replyCode> Varchar (30) Varchar (2) AAAAAAAAA General: AA Specific Usage 0, 1, 2, 3, -1 The unique ID for the message. This will be populated as <messageID> from the request. Indicates the quality of the response. replyCode possible values are: 0 SUCCESS 1 SDP NOT FOUND 2 Request not authorized 3 INVALID REQUEST 4 METER NOT FOUND 5 PREMISE NOT FOUND 6 ACCOUNT NOT FOUND -1 Unanticipated Exception The text error message associated with the replyCode The value displayed under this Tag is reply The value displayed under this Tag is MeterRead This Tag indicates the version of the message The only value is 1 The date/time of the reply in EST Location of the xml name space
Defines the XML version and the character encoding used in the document
<met:replyText>
Varchar (50)
AAAAAAAAAAAAAAA Specific Usage: One of SUCCESS Sdp not found Request not authorized Invalid Request [ ]
209
<Attribute>
Data Type/ Length
Format
</met:Reply> <met:Payload> <met:MeterReading> <met:ServicePoint>
Description
<met:mRID
Varchar (8)
Example: 1-1E8B00 </met:ServicePoint> <met:IntervalBlock>
The internal Siebel reference for the SDP, specifically the SDP-Ref.
<met: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.10.3
<met:Ireading> <met:startTime> Date Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM] Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM] NNNNNNNNNN (Ex. 3600 for 1 hour interval) AAAAAAAAAAAA.AA <met:Quality> <met:versionTime> Date/Time Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM] AAA This is the insert date time of the latest version of data used for billing quantity calculations This date time is prior to the Billing Quantity Response data being written into the Billing Quantity Response file that is transferred to the Data Delivery Service Organization. Can take the following values: NV No Validation performed VAL Interval has been Validated EST Interval has been Estimated or Edited NVE Interval requires Validation or Editing If validationStatus is not VAL then this field will be a hex-based bit-mapped flag, delivered as an integer value indicating validation and estimation failure types. These codes can be found in table 2.10.4 The start time and date in EST for the data within this data set. This is not provided with interval data records
<met:endTime>
Date/Time
End date/time in EST of the data set.
<met:intervalLength>
Number (10)
Length in seconds of the data set. This field will only be populated if the readingTypeID field is populated with KWH Interval 60 Minutes Value reported for the period
<met:value>
Number 5 (12,5)
<met:validationStatus>
Varchar(3)
<met:validationFailure Reasons>
Number(10)
NNNN
With the deployment of EnergyIP Release 7.2 export of this value will be Data Type/Length = Number (21,6).
Version 3.3 July 7, 2011 210
<Attribute>
<met:changeMethod>
Data Type/ Length

Varchar(30)
Format
AAAAAAA
Description
Validation or estimation change method. If validationStatus is VAL, valid changeMethod is: VER: Interval has been manually reviewed and verified If validationStatus is EST, valid changeMethod are: ESA: Interval value estimated using linear interpolation, estimation method em01 ESB: Interval value estimated using historic estimation method em02 without register read scaling. ESC: Interval value estimated using historical estimation method em02 with register read scaling method sm01. ESD: Interval value estimated using Class Load Profile estimation method em10 without register read scaling. ESE: Interval value estimated using Class Load Profile estimation scaled using Average Daily Usage from register reads, estimation method em03. ESF: Interval value estimated using Class Load Profile estimation method em03 or em10 with register read scaling method sm01. ESG: Interval value was estimated using the Inactive Meter estimation method em19. EDT: Interval value has been manually edited. EDC: Interval value estimated external to the MDM/R, DC_DATA_ESTIMATION flag set based on data quality flag transmitted from the AMCC. ESZ: Interval value was estimated using the Zero Reads estimation method em14. Indicates if energy flow was reversed during the time frame of data set. If this condition exists, then the value returned will be true. If this conditions does not exist, then no value is returned This is applicable only where ReadingTypeID = KWH Usage Indicates if there is no data for this data set. If this condition exists, then the value returned will be true. If this conditions does not exist, then no value is returned This is applicable for all values returned in ReadingTypeID Indicates if there was a Power Off Flag during the time frame of this data set. If this condition exists, then the value returned will be true. If this conditions does not exist, then no value is returned This is applicable only where ReadingTypeID = KWH Interval Indicates that the source data for this period was incomplete. If this condition exists, then the value returned will be true. If this conditions does not exist, then no value is returned This is only applicable if readingTypeID = KWH Usage
<met:reverseRotation>
Char (4)
General: AAAA Specific Usage: true
<met:noData>
Char(4)
<met:powerOff>
Char(4)
<met:partialData>
Char(4)
</met:Quality>
211
<Attribute>
Data Type/ Length
Format
</met:Ireading> </met:IntervalBlock> </met:MeterReading> </met:Payload> </met:ReplyMessage> </soapenv:Body> </soapenv:Envelope>
Description
2.10.8.2.1 Sample Response Message
Sample MP01, MP02, MP03, and MP04 will be supplied on the SMSIP website. Table 2.10.3 defines the Measurement Profiles that can be submitted with each meter reads retrieval web services request and the <readingTypeId> codes that will be returned in the Reply message for each measurement included in the requested <measurementProfile> (in the Reply <readingTypeId> and <value> elements)
Table 2.10.3 Measurement Profiles
measurementProfile
MP01
readingTypeIds returned
KWH Usage KWH Est Usage COUNT KWH Est Intervals KWH RR Cum KWH Usage KWH Est Usage COUNT KWH Est Intervals KWH Off Peak Usage KWH Mid Peak Usage KWH On Peak Usage KWH CPP1 Usage KWH RR Cum KWH Interval 60 Minutes KWH RR Cum KWH Usage KWH Est Usage COUNT KWH Est Intervals KWH Off Peak Usage KWH Mid Peak Usage KWH On Peak Usage KWH CPP1 Usage KWH Interval 60 Minutes KWH RR Cum
readingTypeId Description
Total daily KWH consumption Total daily estimated KWH consumption Total number of estimated intervals in the day Register reading data for the period Total daily KWH consumption Total daily estimated KWH consumption Total number of estimated intervals in the day Total daily TOU Off Peak consumption Total daily TOU Mid Peak consumption Total daily TOU On Peak consumption Total daily CPP price event consumption (future) Register reading data for the period Interval data for the period Register reading data for the period Total daily KWH consumption Total daily estimated KWH consumption Total number of estimated intervals in the day Total daily TOU Off Peak consumption Total daily TOU Mid Peak consumption Total daily TOU On Peak consumption Total daily CPP price event consumption (future) Interval data for the period Register reading data for the period
MP02
MP03 MP04
Table 2.10.4 defines the integer and hex-based codes representing validation and estimation failure types that will be present in the <validationFailureReasons> attribute when the <validationStatus> is not VAL. The code returned can include the addition of the listed integer values.
212
Table 2.10.4
validationFailureReasons Codes
Integer Value
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576
Hex Value
0x0001 0x0002 0x0004 0x0008 0x0010 0x0020 0x0040 0x0080 0x0100 0x0200 0x0400 0x0800 0x1000 0x2000 0x4000 0x8000 0x10000 0x20000 0x40000 0x80000 0x100000
Description
Interval failed Spike Check validation. Interval was part of a failed Message Sum Check validation. EnergyIP NO_DATA flag set for Interval or failed Missing Intervals Check validation. EnergyIP PULSE_OVERFLOW flag set for Interval or failed Pulse Overflow Check validation. EnergyIP TIME_CHANGE flag set for Interval or failed Time Check validation. EnergyIP TEST_MODE flag set for Interval or failed Test Mode Check validation. Interval failed Maximum Demand Check validation. EnergyIP METER_RESET flag set for Interval or failed Meter Diagnostic Check validation. EnergyIP REVERSE_ROTATION flag set for Interval failed Reverse Energy Check validation. Interval could not be estimated due to NO LIKE DAYS (no valid same day of week or like reference days). Interval could not be estimated because gap exceeded Maximum Estimation Days that can be estimated. Interval could not be estimated because no endpoints were available for a linear interpolation. Interval could not be estimated because of an internal processing (typically configuration) error. Interval was part of a failed Consecutive Zeros Check validation Interval was estimated but failed to scale with available register readings, resulting in a Validation Status of NVE and Change Method ESB. Interval failed cross-channel Watt-VAR Check validation. Interval failed cross-channel Excessive Watt-VAR Check validation. Interval is currently pending Watt-VAR validation. Interval skipped Watt-VAR validation. Class Load Profile data not found. EnergyIP DC_DATA_ESTIMATION flag set. Interval data estimated by external data collection system. EnergyIP AMI_ERROR flag set for Interval or failed due to data collection or reporting error in external AMI system. (Note that this flag is only used for Elster MAS 6.x and MAS 5.7.) EnergyIP POWER_OFF flag set for interval. EnergyIP CRC_ERROR flag set for interval. EnergyIP PHASE_FAILURE flag set for interval. EnergyIP PARTIAL_INTERVAL flag set for interval. Estimation error could not estimate using any specified method Interval is part of a detected Number of Zeros validation failure. Interval failed HI-LO validation.
FailureFlag
SPK SUM MIS OVF TIM TST DEM RST REV NLK GAP PTS ERR ZER SCL
WVF WVE WVP WVS CLP EDC AMI
2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456
0x200000 0x400000 0x800000 0x1000000 0x2000000 0x4000000 0x8000000 0x10000000
OUT CRC PHA PRT EER NMZ HLO
If there are multiple validation or estimation failures, 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.
213
2.11
Meter Read Interface (Sensus)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Sensus AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.11.1 Description
2.11.2 Integration
2.11.2.1 Direction
AMCC to the MDM/R

This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDPs 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
214
when using a CMEP interface and, if this maximum is used, requires a register read record corresponding to the end of each interval data record of a maximum length of 48 interval data triplets. It is recommended that interval data be transmitted in Meter Transfer Blocks no longer than 24 hours long, and if possible, a Meter Transfer Block should end at midnight or with one hour (plus or minus) of midnight to assure that the Billing Validation Sum Check can be effectively performed.
2.11.2.3 Transmission of First and Last Register Readings
Register readings including the first register reading of a meter collected when the meter is installed, and the last register reading of a meter collected when the meter is exchanged, may be transmitted to the MDM/R either as part of a Meter Transfer Block (i.e. a set of interval data with the register reading at the end of the set of interval data), or as a Meter Read record consisting only of the register reading (i.e. a single value for which the Units are KWHREG). Register readings are stored in the register read table of the Meter Data Database and are available via the MDM/R GUI. kWh, kVAh, and kVARh register readings are processed and stored only for physical register data channels created by the Channel Configuration Set for a physical meter established using the synchronization processes. For meters for which a non-unity Scaling Constant is provided in the synchronization process the register read data is multiplied by the Scaling Constant before being loaded into the Meter Data Database. Register readings received as part of a Meter Transfer Block are available for Message Sum Check validation, and Register Read Scaling of Historic and Class Load Profile estimation. Register reading received as part of a Meter Transfer Block are also available to the Billing Validation Sum Check if the Date/Time of the register reading is within the MaxRegisterRange hours of midnight. Register readings received as a single KWHREG value are only available to the Billing Validation Sum Check if the Date/Time of the register reading is within the MaxRegisterRange hours of midnight.

1. Universal SDP ID and AMCD ID must be a valid pair for the LDCs Organization ID for the Daily Read Period date being reported 2. Where the LDCs Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 5. The following are exception cases: a. The MDM/R CMEP Adapter detects exceptions in regards to invalid file format and data type exceptions.
215
b. The MDM/R detects exceptions when the LDCs Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 6. Meter Reads exception reports are created: The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications). The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R Reports Technical Specifications).
The interface creates exception reports and places them in the designated storage location for the File Transfer Services transfer to the LDC or its AMI Operator.
Rules Affecting Meter Read Processing for SDPs Requiring Demand Determination
7. The SDP must be assigned a Channel Configuration Set through the synchronization processes that establishes the data channels by unit of measurement and type necessary to support the receipt of and processing of interval consumption data and register read data for multiple units of measurement as transmitted by the meter. 8. For meters not used for net metering and used for the determination of demand, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 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.
216
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. The Universal SDP ID has a relationship with the corresponding AMCD ID in the MMD for the Daily Read Period being reported. All of the attributes associated with the Data Collection Service must be populated.
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.

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

2.11.8.1 File Name Record for the Sensus CMEP File
217
Table 2.11.1
FILE NAME RECORD FOR THE SENSUS CMEP FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.11.8.2 Sensus CMEP Record
The data mapping definitions and the file format layout following the File Name Record are based on the California Metering Exchange Protocol (CMEP) Version 1.20, with some modifications made specific to the Ontario Smart Metering System implementation. Other than the specific modifications described in this specification data file transmissions should conform to the specifications of CMEP Version 1.20. The CMEP files will contain only the following record types: MEPMD01 - Metering Data Type 1 - Interval Data The CMEP files will not contain the following record types: MEPAD01 - Administrative Data Type 1 DASR MEPAD02 - Administrative Data Type 2 - Credit Data MEPMD02 - Metering Data Type 2 - TOU Data MEPBD01 - Billing Data Type 1 - Billed Dollars MEPBD02 - Billing Data Type 2 - Interval Pricing Plan MEPBD03 - Billing Data Type 3 - TOU Pricing Plan MEPLF01 - Distribution Loss Factors Electric MEPEC01 - Equipment Configuration Type 1 MEPRR01 - Record Reject Type 1
Table 2.11.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SENSUS
CMEP Field Name

Record Type
Data Type/Length
Varchar (7)
Format
General : AAAAAAA Specific Usage: MEPMD01
Required
Y
Description
This field will always contain MEPMD01
Record Version
Date
General: yyyyMMdd Specific Usage: 19970819
This field will contain the CMEP version date. The current version being supported is 19970819
218
CMEP Field Name

Sender ID
Data Type/Length
Varchar (10)
Format
General: AAAAAAAAAA Specific Usage: Sensus
Required
N
Description
This field will always contain Sensus. NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Sensus: FILE ID = 7000
Sender Customer ID
Char (8)
General: AAAAAAAA Example: ORG83729
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process. This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Receiver ID
Char (8)
General: AAAAAAAA Specific Usage The MDM/R will only recognize ORG29738
Receiver Customer ID
Fixed Number (8)
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with. This field Is populated with the date and time that this record was created. This time must be reported in EST This is the ID that is used as a key for 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 Indicates the reason for this data transmission. Defined values are: OK Normal transmission Resend Retransmission of previously sent data Summary Summary of SP totalled data. History Archival account data Profile Account usage profile data Template Account usage template data Reject Data is rejected and being returned to sender Describes what commodity type is being delivered E Electricity G Gas W Water S - Steam
Time Stamp
Date/Time
yyyyMMddHHmm
Meter ID
Varchar (50)
Purpose
Varchar (8)
General: AAAAAAAA Specific Usage: The MDM/R will only recognize OK, RESEND
Commodity
Char(1)
General: A Specific Usage: The MDM/R will only recognize E
219
CMEP Field Name

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

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

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

Numeric floating point
Data Type/Length
Number (12,5)
6
Format
General: NNNNNNNNNNN N.NNNNN Specific: 123456789012.34
Required
Y
Description
This field is populated with either the register read (if the Units field is populated with KWHREG) or the interval consumption (if the Units field is populated with KWH)
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
Table 2.11.3 describes the action taken by the EnergyIP application in processing the simple protocol text quality flags for interval consumption data provided for each data triplet within the Sensus CMEP file, and the setting of EnergyIP flags as applicable. The same protocol text quality flags are recognized and processed for KWH, KVARH, and KVAH interval data.
Table 2.11.3
Bit Bit Value 00 00 Bit 0 00 01
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus
Sensus Data Quality Flag Description EnergyIP Action Sensus Indicates an error free interval No EnergyIP flag is set, data will be treated as normal data Sensus Communication failure (meter could not be read) No EnergyIP flag is set, data will be treated as normal data Sensus Power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done Sensus Power restoral EnergyIP PwrOn flag is set in GUI, Missing Interval Check NO_DATA flag is cleared, validation/estimation resumes on subsequent interval data Sensus Voltage sag No EnergyIP flag is set, data will be treated as normal data Sensus Voltage swell No EnergyIP flag is set, data will be treated as normal data Sensus Missing data EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check Sensus Daylight savings in effect No EnergyIP flag is set, data will be treated as normal data Sensus Meter was out of service No EnergyIP flag is set, data will be treated as normal data Required CMEP Flag R 00 00 R 00 01 EnergyIP Flag null null
Bit 1
00 02
R 00 02
POWER_OFF
Bit 2
00 04
R 00 04
POWER_ON
Bit 3 Bit 4
00 08 00 10
R 00 08 R 00 10
null null
Bit 5
00 20
N 00 20
NO_DATA
Bit 6 Bit 7
00 40 00 80
R 00 40 R 00 80
null null
With the deployment of EnergyIP Release 7.2 processing of this value will support Data Type/Length = Number (21,6). Values exceeding 6 decimal places will be rounded and stored to 6 decimal places.
Version 3.3 July 7, 2011 223
2.11.8.3
Addition of Hexadecimal Quality Flags
The EnergyIP CMEP adaptor for Sensus will support the combination or addition of multiple hexadecimal data quality flags up to the 256 hexadecimal code values involving Bit 0 through Bit 7.
224
2.12
Meter Read Interface (Sensus2)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Sensus2 AMCC Meter Read interface providing support for the Sensus FlexNet extended CMEP file format. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.12.1 Description
2.12.2 Integration
2.12.2.1 Direction
AMCC to the MDM/R

This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDPs 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
Version 3.3 July 7, 2011 225
when using a CMEP interface and, if this maximum is used, requires a register read record corresponding to the end of each interval data record of a maximum length of 48 interval data triplets. It is recommended that interval data be transmitted in Meter Transfer Blocks no longer than 24 hours long, and if possible, a Meter Transfer Block should end at midnight or with one hour (plus or minus) of midnight to assure that the Billing Validation Sum Check can be effectively performed.

1. Universal SDP ID and AMCD ID must be a valid pair for the LDCs Organization ID for the Daily Read Period date being reported 2. Where the LDCs Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 5. The following are exception cases: a. The MDM/R CMEP Adapter detects exceptions in regards to invalid file format and data type exceptions.
226
b. The MDM/R detects exceptions when the LDCs Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 6. Meter Reads exception reports are created: The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications). The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R Reports Technical Specifications).
227
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. The Universal SDP ID has a relationship with the corresponding AMCD ID in the MMD for the Daily Read Period being reported. All of the attributes associated with the Data Collection Service must be populated.
2.12.6 Assumptions

2.12.8 File Format

2.12.8.1 File Name Record for the Sensus2 CMEP File
228
Table 2.12.1
FILE NAME RECORD FOR THE SENSUS2 CMEP FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
2.12.8.2 Sensus2 CMEP Record
The data mapping definitions and the file format layout following the File Name Record are based on the California Metering Exchange Protocol (CMEP) Version 1.20 as extended by Sensus, with some modifications made specific to the Ontario Smart Metering System implementation. Other than the specific modifications described in this specification data file transmissions should conform to the specifications of CMEP Version 1.20. The CMEP files will contain only the following record types: MEPMD01 - Metering Data Type 1 - Interval Data The CMEP files will not contain the following record types: MEPAD01 - Administrative Data Type 1 DASR MEPAD02 - Administrative Data Type 2 - Credit Data MEPMD02 - Metering Data Type 2 - TOU Data MEPBD01 - Billing Data Type 1 - Billed Dollars MEPBD02 - Billing Data Type 2 - Interval Pricing Plan MEPBD03 - Billing Data Type 3 - TOU Pricing Plan MEPLF01 - Distribution Loss Factors Electric MEPEC01 - Equipment Configuration Type 1 MEPRR01 - Record Reject Type 1
Table 2.12.2 FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SENSUS2
CMEP Field Name

Record Type
Data Type/Length
Varchar (7)
Format
General : AAAAAAA Specific Usage: MEPMD01 The MDM/R will load only MEPMD01 data.
Required
Y
Description
The Sensus Extended CMEP File Format provides mapping to metering data types MEPMD01 Interval Data, and MEPMD02 TOU Data. The MDM/R is configured to support only interval data and reference register reading data. This field will always contain MEPMD01
229
CMEP Field Name

Record Version
Data Type/Length
Date
Format
General: yyyyMMdd Example: 19970819 or null
Required
N
Description
This field will contain the CMEP version date. The current version being supported is 20080130 The Sensus2 adaptor will not validate this field. The Record Version field may be null. This field will always contain Sensus. NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Sensus2: FILE ID = 7001
Sender ID
Varchar (10)
General: AAAAAAAAAA Specific Usage: Sensus
Sender Customer ID
Char (8)
Receiver ID
Char (8)
General: AAAAAAAA Specific Usage The MDM/R will only recognize ORG29738
Fixed Number (8)
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with. This field Is populated with the date and time that this record was created. This time must be reported in EST This is the ID that is used as a key for 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 Indicates the reason for this data transmission. Defined values are: OK Normal transmission Resend Retransmission of previously sent data Summary Summary of SP totalled data. History Archival account data Profile Account usage profile data Template Account usage template data Reject Data is rejected and being returned to sender
Time Stamp
Date/Time
yyyyMMddHHmm
Meter ID
Varchar (50)
Purpose
Varchar (8)
General: AAAAAAAA Specific Usage: The MDM/R will only recognize OK, RESEND
230
CMEP Field Name

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

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

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

Data Type/Length
Number (12,5)
7
Format
General: NNNNNNNNNNN N.NNNNN Specific: 123456789012.34
Required
Y
Description
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
Bit Bit Value 00 00
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus2
Sensus Data Quality Flag Description EnergyIP Action Sensus Indicates an error free interval No EnergyIP flag is set, data will be treated as normal data Sensus Communication failure (meter could not be read) No EnergyIP flag is set, data will be treated as normal data Sensus Power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done Sensus Power restoral EnergyIP PwrOn flag is set in GUI, Missing Interval Check NO_DATA flag is cleared, validation/estimation resumes on subsequent interval data Sensus Voltage sag No EnergyIP flag is set, data will be treated as normal data Sensus Voltage swell No EnergyIP flag is set, data will be treated as normal data Sensus Missing data EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check Sensus Daylight savings in effect No EnergyIP flag is set, data will be treated as normal data Sensus Meter was out of service No EnergyIP flag is set, data will be treated as normal data Required CMEP Flag R0 EnergyIP Flag
null
Bit 0
00 01
R1
null
Bit 1
00 02
R2
POWER_OFF
Bit 2
00 04
R4
POWER_ON
Bit 3
00 08
R8 Not used for interval data N32
null
Bit 4
00 10
null
Bit 5
00 20
NO_DATA
Bit 6
00 40
R64
null
Bit 7
00 80
Not used
null
Version 3.3 July 7, 2011 234
Bit
Bit Value 01 00
Sensus Data Quality Flag Description EnergyIP Action Sensus Time Adjustment (direction unspecified) EnergyIP flag TimeChg is set in GUI, data is subject to the Time Change Validation check Sensus Overflow EnergyIP Overflow flag is set in GUI, data is subject to Pulse Overflow Validation check Sensus Long interval EnergyIP LongInt flag is set in GUI, data will be treated as normal data Sensus Short interval EnergyIP ShortInt flag is set in GUI, data will be treated as normal data Sensus Test mode EnergyIP TestMode flag is set in GUI, data is subject to Test Mode Validation check Sensus Register rollover detected No EnergyIP flag is set, data will be treated as normal data Sensus Register reset detected No EnergyIP flag is set, data will be treated as normal data Sensus Clock out of sync EnergyIP flag TimeChg is set in GUI, data is subject to the Time Change Validation check
Required CMEP Flag R256
EnergyIP Flag
Bit 8
TIME_CHANGE
Bit 9
02 00
R512
PULSE_OVERFLOW
Bit 10
04 00
R1024
LONG_INTERVAL
Bit 11
08 00
R2048
SHORT_INTERVAL
Bit 12
10 00
R4096 Not used for interval data Not used for interval data R32768
TEST_MODE
Bit 13
20 00
null
Bit 14
40 00
null
Bit 15
80 00
TIME_CHANGE
2.12.8.3 Addition of Hexadecimal Quality Flags
The Sensus2 EnergyIP CMEP adaptor will support the combination or addition of multiple hexadecimal data quality flags up to the 65536 hexadecimal code values involving Bit 0 through Bit 15.
235
2.13
Meter Read Interface (Elster)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Elster AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.13.1 Description
2.13.2 Integration
2.13.2.1 Direction
AMCC to the MDM/R

This is a batch process involving the transfer and processing of XML files. Meter read data may be received from the AMCC for all meters that are associated to SDPs 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 meters 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.
Register readings including the first register reading of a meter collected when the meter is installed, and the last register reading of a meter collected when the meter is
Version 3.3 July 7, 2011 236
exchanged, may be transmitted to the MDM/R either as part of a Meter Transfer Block (i.e. a set of interval data with the register reading at or near the end of the set of interval data), or as a Meter Read record consisting only of the register reading (i.e. a single value for ConsumptionData or EOI Snapshot register value). Register readings are stored in the register read table of the Meter Data Database and are available via the MDM/R GUI. kWh, kVAh, and kVARh register readings are processed and stored only for physical register data channels created by the Channel Configuration Set for a physical meter established using the synchronization processes. For meters for which a non-unity Scaling Constant is provided in the synchronization process the register read data is multiplied by the Scaling Constant before being loaded into the Meter Data Database. Register readings received as part of a Meter Transfer Block are available for Message Sum Check validation, and Register Read Scaling of Historic and Class Load Profile estimation. Register reading received as part of a Meter Transfer Block are also available to the Billing Validation Sum Check if the Date/Time of the register reading is within the MaxRegisterRange hours of midnight. Register readings received as a single ConsumptionData value are only available to the Billing Validation Sum Check if the Date/Time of the register reading is within the MaxRegisterRange hours of midnight.

1. Universal SDP ID and AMCD ID must be a valid pair for the LDCs Organization ID for the Daily Read Period date being reported. 2. Where the LDCs Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters may be programmed to provide the energy delivered, or programmed to provide the sum of the absolute values of the energy delivered and the energy received. This will apply to both interval consumption data and register read data. 4. The values reported in the AMRDEF file for both register reads and interval data are the result of converting the units stored in the meter to engineering units by applying the meter multiplier. The values are reported as the actual number of kWh that have passed through the meter. a. Use of a Scaling Constant will support certain types of meters that transmit register read data bare of the meter multiplier while transmitting interval consumption data multiplied by the meter multiplier. For meters for which a Scaling Constant is provided in the synchronization process, the register read data is multiplied by the Scaling Constant before being loaded into the Meter Data Database. b. For meters for which a Scaling Constant is not provided, the synchronization Staging Table Loader will default a value of 1.00 for this meter parameter, and register read data will be stored asreceived in the Meter Data Database. 5. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory.
Version 3.3 July 7, 2011 237
6. The following are exception cases: a. The MDM/R Elster MAS Adapter detects exceptions in regards to invalid file format and data type exceptions. b. The MDM/R detects exceptions when the LDC Identifier values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 7. Meter Reads exception reports are created: The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC06 and DC16 in Section 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications). The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R Reports Technical Specifications), The interface creates exception reports and places them in the designated storage location for the File Transfer Services transfer to the LDC.
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.
The following must exist for the input file to be processed through the interface:
238
The LDC is enrolled and has an LDC ID assigned. The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File. The Universal SDP ID has a relationship with the corresponding AMCD ID in the MMD for the Daily Read Period being reported. All of the attributes associated with the Data Collection Service must be populated.
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

2.13.8 File Format

2.13.8.1 File Name Record for the Elster File
The first element in this interface file is used to store the name of the file as specified in Section 1.8. This element is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first element of the interface file contains the following data:
Table 2.13.1 FILE NAME RECORD FOR THE ELSTER FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Specific Usage: <FTSFN> Refer to Section 1.8
Required
Y
Description
This field always contains the record type <FTSFN> This field contains the name of the file on the originating system, as defined in Section 1.8
File Name
Varchar (250)
239
Field Name
Suffix
Data Type/Length
Char (8)
Format
Specific Usage: </FTSFN>
Required
Y
Description
This field always contains the record type </FTSFN>
2.13.8.2 Elster EnergyAxis Management System (EA_MS) AMRDEF Export File
The data mapping definitions and the file format layout are as defined for the AMRDEF Export Format in the EnergyAxis Management System (formerly branded as the Elster EnergyAxis Metering Automation Server) AMRDEF Reference Release 7.0. The AMR Data Exchange Format (AMRDEF) export files may contain all the element and attributes as defined in the Elster EnergyAxis Management System AMRDEF Reference Release 7.0 document. The MDM/R will only load and process the elements and attributes as outlined in the following tables 2.13.2 and 2.13.3 and 2.13.4. The Element/Attribute naming convention in the following tables 2.13.2, 2.13.3 and 2.13.4 are as follows. General form: {element name}[{element separator}{element name}]{element separator}{attribute name} Examples: AMRDEF.MeterReadings.CollectionTime AMRDEF.MeterReadings.Meter.SerialNumber The AMRDEF Reference Release 7.0 AMRDEF Export Format is used to supply the MDM/R with consumption read data (i.e. register read data) as follows in table 2.13.2.
TABLE 2.13.2 CONSUMPTION DATA ELEMENTS AND ATTRIBUTES (REGISTER READ DATA)
AMRDEF Reference (Release 6.0) Element/Attribute Name Data Type/Length Format <MeterReadings> AMRDEF. MeterReadings. CollectionTime Date As per AMRDEF Export Format: yyyy-mmdd hh24:mi:ss Y Date and time that the data was collected. This is to be delivered in EST Required Description
240
AMRDEF Reference (Release 6.0) Element/Attribute Name
Data Type/Length
Format <Meter>
Required
Description
AMRDEF. MeterReadings. Meter. MeterName
Varchar (50)
This is the LDCs unique identifier for the AMCD (the AMCD ID in the synchronization file). This is the ID 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 This is the type of meter installed at this SDP. The following are the values that will be recognized by the MDM/R A3 A3 ALPHA Meter A3_ILN A3 ALPHA Node A3_Collector A3 ALPHA Meter with option board REX REX Meter This field is populated with the assigned Universal SDP ID.
AMRDEF. MeterReadings. Meter. MeterType
Varchar (15)
General: AAAAAAAAAAAAAA Specific Usage: One of A3, A3_ILN, A3_Collector or REX General: NNNNNNNN Example: 00037482 <ConsumptionData> <ConsumptionSpec>
AMRDEF. MeterReadings. Meter. SdpIdent
Fixed Number (8)
AMRDEF. MeterReadings. ConsumptionData. ConsumptionSpec. UOM
Varchar (10)
General: AAAAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R will load values: KWH or kWh, KVARH or kVARh KVAH or kVAh
The MDM/R will process register read values (the AMRDEF. MeterReadings.ConsumptionData.Re ading.Value attribute) where this unit of measurement is consistent with the register data channels supported by the Channel Configuration Set assigned to the SDP. For energy valid values are: delivered KWH or kWh. For VAR-hours valid values are: inductive (Power Factor lagging) delivered KVARH or kVARh For VA-hours valid values are: delivered KVAH or kVAh
241
AMRDEF Reference (Release 6.0) Element/Attribute Name AMRDEF. MeterReadings. ConsumptionData. ConsumptionSpec. Direction
Data Type/Length Varchar (9)
Format General: AAAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R only recognizes and loads Sum or Delivered values.
Required N
Description This field indicates power flow direction. Delivered indicates that the quantity has been delivered to meter location. Received indicates that the quantity has been received from the meter location. Sum indicates that the value is the sum of the absolute values of the energy delivered and the energy received. The quantity is the value in the AMRDEF.MeterReadings. ConsumptionData.Reading.Value attribute. If Received, no data will be processed or reported upon The MDM/R recognizes values (the AMRDEF.MeterReadings. ConsumptionData.Reading.Value attribute) where the TOU bucket is: Total indicating that the value is the sum of all TOU buckets as from the kWh register of the meter.
AMRDEF. MeterReadings. ConsumptionData. ConsumptionSpec. TouBucket
Varchar (5)
General: AAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R only recognizes and loads Total values. General: AAAAAAAAAAAAAAAA AAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R recognizes and loads Current and EndOfIntervalSnapshot values.
AMRDEF. MeterReadings. ConsumptionData. ConsumptionSpec. MeasurementPeriod
Varchar (24)
The MDM/R recognizes values (the AMRDEF.MeterReadings. ConsumptionData.Reading.Value attribute) where the Measurement Period is: Current indicating that the usage data is from the current period rather than historical data from the previous billing period or previous season. EndOfIntervalSnapshot indicating the end of interval snapshot register value taken just before the end of the last interval of a block of interval data per collector reading of interval data 8 (normally configured for 6 hours).
<Reading>
Processing of EndOfIntervalSnapshot register values will be available with the deployment of EnergyIP Release 7.0 into the MDM/R Production and testing environments.
Version 3.3 July 7, 2011 242
AMRDEF Reference (Release 6.0) Element/Attribute Name AMRDEF. MeterReadings. ConsumptionData. Reading. Timestamp AMRDEF. MeterReadings. ConsumptionData. Reading. Value
Data Type/Length Date/Time
Format As per AMRDEF Export Format: yyyy-mm-dd hh24:mi:ss
Required Y
Description Date and time this reading was taken from the meter. This time must be in EST
Number 9 (12,5) NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
General: NNNNNNNNNNNN.NN NNN Specific: Examples: 7659 765434.56
The reading value. As per the AMRDEF.MeterReadings. ConsumptionData. ConsumptionSpec.UOM attribute.
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 (Release 6.0) Element/Attribute Name Data Type/Length Format <MeterReadings> AMRDEF. MeterReadings. CollectionTime Date/Time As per AMRDEF Export Format: yyyy-mm-dd hh24:mi:ss <Meter> AMRDEF. MeterReadings. Meter. MeterName Varchar (50) No format prescribed Y This is the LDCs unique identifier for the AMCD (the AMCD ID in the synchronization file). This is the ID 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 Y Date and time that the data was collected. This is to be delivered in EST Required Description
Version 3.3 July 7, 2011 243
AMRDEF Reference (Release 6.0) Element/Attribute Name AMRDEF. MeterReadings. Meter. MeterType
Data Type/Length Varchar (15)
Format General: AAAAAAAAAAAAAAA Specific Usage: One of A3, A3_ILN, A3_Collector or REX General: NNNNNNNN Example: 00037482 <IntervalData> <IntervalSpec>
Required Y
Description This is the type of meter installed at this SDP. The following are the values that will be recognized by the MDM/R A3 A3 ALPHA Meter A3_ILN A3 ALPHA Node A3_Collector A3 ALPHA Meter with option board REX REX Meter This field is populated with the assigned Universal SDP ID.
AMRDEF. MeterReadings. MetersRead. Meter. SdpIdent
Fixed Number (8)
AMRDEF. MeterReadings. IntervalData. IntervalSpec. UOM
Varchar (10)
General: AAAAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R will load values: KWH or kWh, KVARH or kVARh KVAH or kVAh
The MDM/R will process interval data values (the AMRDEF. MeterReadings.IntervalData. Reading.RawReading attribute) where this unit of measurement is consistent with the interval data channels supported by the Channel Configuration Set assigned to the SDP. For energy valid values are: delivered KWH or kWh. For VAR-hours valid values are: inductive (Power Factor lagging) delivered KVARH or kVARh For VA-hours valid values are: delivered KVAH or kVAh. This field indicates power flow direction. Delivered indicates that the quantity has been delivered to meter location. Received indicates that the quantity has been received from the meter location. Sum indicates that the value is the sum of the absolute values of the energy delivered and the energy received. The quantity is the value in the AMRDEF.MeterReadings. IntervalData.Reading.RawReading attribute. If Received, no data will be processed or reported upon Interval in minutes at which interval data is collected.
AMRDEF. MeterReadings IntervalData. IntervalSpec. Direction
Varchar (9)
General: AAAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R only recognizes and loads Sum or Delivered values
AMRDEF. MeterReadings. IntervalData. IntervalSpec. Interval
Number (3)
General: NNN Example: 60 15 <Reading>
AMRDEF. MeterReadings. IntervalData. Reading. TimeStamp
Date/Time
As per AMRDEF Export Format: yyyy-mm dd hh24:mi:ss
Date and time this reading was taken from the meter. The interval end time. This must be in EST
244
AMRDEF Reference (Release 6.0) Element/Attribute Name AMRDEF. MeterReadings. IntervalData. Reading. RawReading
Data Type/Length Number 10 (12,5) NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
Format General: NNNNNNNNNNNN.NN NNN Examples: 7659 765434.56
Required N
Description The reading value per the AMRDEF.MeterReadings. IntervalData.IntervalSpec.UOM attribute for load profile interval as identified by the AMRDEF. MeterReadings.IntervalData. Reading.TimeStamp.
<QualityFlags> AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. TimeChanged Number (1,0) General: N Specific Usage: 1 N The meters time was changed during the period represented by the data. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a TimeChanged flag, the EnergyIP TimeChg flag is set in the GUI, the database TIME_CHANGE Flag is set, data is subject to the Time Change Validation Check. The meters clock was set backward during the interval. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a ClockSetBackward flag, the EnergyIP TimeChg flag is set in the GUI, the database TIME_CHANGE Flag is set, data is subject to the Time Change Validation Check. The interval was longer than expected. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a LongInterval flag, the EnergyIP LongInt flag is set in the GUI, the database LONG_INTERVAL Flag is set, data is treated as normal data.
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. ClockSetBackward
Number (1,0)
General: N Specific Usage: 1
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. LongInterval
Number (1,0)
10
Version 3.3 July 7, 2011 245
AMRDEF Reference (Release 6.0) Element/Attribute Name AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. ClockSetForward
Data Type/Length Number (1,0)
Format General: N Specific Usage: 1
Required N
Description The meters clock was set forward during the interval. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a ClockSetForward flag, the EnergyIP TimeChg flag is set in the GUI, the database TIME_CHANGE Flag is set, data is subject to the Time Change Validation Check. The interval was shorter than expected. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a PartialInterval flag, the EnergyIP Partial flag is set in the GUI, the database PARTIAL_INTERVAL Flag is set, data is treated as normal data. The InvalidTime tag indicates that the TimeStamp associated with the interval data reading is invalid. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a InvalidTime flag, the EnergyIP AMI Error flag is set in the GUI, the database AMI_ERROR Flag is set, data is subject to the AMI 11 Error Validation Check.. NOTE 1: EnergyIP will not load any interval data from a Meter Transfer Block with interval data readings where the <TimeStamp> of the last interval of the Meter Transfer block is later than the system time at which EnergyIP processes the Meter Read data. NOTE 2: Multiple duplicate interval data readings received for the same interval (i.e. same TimeStamp) in the same data transmission and not differentiated by the InvalidTime tag will NOT be loaded. The interval was skipped by the meter. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of the SkippedInterval flag, the EnergyIP NoData flag is set in the GUI, the database NO_DATA
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. PartialInterval
Number (1,0)
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. InvalidTime
Number (1,0)
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. SkippedInterval
Number (1,0)
11
With the deployment of EnergyIP Release 7.0 the MAS Meter Reads Adaptor is re-configured for the MDM/R to process interval data for which the InvalidTime data quality flag is set.
Version 3.3 July 7, 2011 246
Data Type/Length
Format
Required
Description flag is set, data is subject to the 12 Missing Intervals Validation check.
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. CompleteOutage
Number (1,0)
The meter experienced an outage (all phases). If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a CompleteOutage flag, the EnergyIP PwrFail flag is set in the GUI, Missing Interval Validation check NO_DATA flag is cleared, the database POWER_OFF Flag is set, no estimation is done. The register overflowed. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of the PulseOverflow flag, the EnergyIP Overflow flag is set in the GUI, the database PULSE_OVERFLOW flag is set, data is subject to the Pulse Overflow Validation Check. The meter was in test mode during the interval. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a TestMode flag, the EnergyIP TestMode flag is set in the GUI, the database TEST_MODE Flag is set, data is subject to the Test Mode Validation Check At lease one phase lost power during the interval. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a PartialOutage flag, the EnergyIP PwrFail flag is set in the GUI, Missing Interval Validation check NO_DATA flag is cleared, the database POWER_OFF Flag is set, no estimation done. An outage may have occurred, but there was not enough evidence to say for sure. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a SuspectedOutage flag, the EnergyIP PwrFail flag is set in the GUI, Missing Interval Validation check NO_DATA flag is cleared, the database POWER_OFF
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. PulseOverflow
Number (1,0)
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. TestMode
Number (1,0)
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. PartialOutage
Number (1,0)
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. SuspectedOutage
Number (1,0)
12
As of September 2007 the SkippedInterval flag is not produced by any Elster meter deployed in Ontario. Elsters provision of this quality flag is to accompdate possible future deployment of meter types that may provide this flag.
Version 3.3 July 7, 2011 247
Data Type/Length
Format
Required
Description Flag is set, no estimation done.
AMRDEF. MeterReadings. IntervalData. Reading. QualityFlags. Restoration
Number (1,0)
Power was restored to the meter. If this condition occurs, then this value will be 1. If this condition does not exist, this element will not be present in the file. Upon receipt of a Restoration flag the EnergyIP PwrOn flag is set in the GUI, Missing Interval Check NO_DATA flag is cleared in the database, database POWER_ON flag is set, estimation resumes on subsequent interval data.
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 (Release 5.7) Element/Attribute Name Data Type/Length Format <MeterReadings> <ReadingQualityIndicator> AMRDEF. MeterReadings. ReadingQualityIndicator. Name Varchar (12) General: AAAAAAAAAAA Specific Usage : Tamper Alert OR Meter Health Varchar (5) General: AAAAA Specific Usage : True OR False <MeterReadings> <Statuses> AMRDEF. MeterReadings. Statuses. Status Varchar (N) NN N The Statuses tag will be present only where there is an abnormal value reported by the meter. There will be one Status tag for each meter status reported in the reading. N N This indicates that the data read from the meter may be suspect. The only valid entries are Tamper Alert and Meter Health Required Description
AMRDEF. MeterReadings. ReadingQualityIndicator. Value
If True, the meter reported a condition that affects the meters health.
248
EnergyIP captures the ReadingQualityIndicator.Name and for every Status that has a Status.Category = ReadingQualityIndicator.Name and ReadingQualityIndicator.Value = True, the EnergyIP METER_RESET flag is set for each Status.Name designated in Tables 2.13.5, 2.13.6, and 2.13.7. These tables outline the Status elements designated by Elster to identify Meter Read data that should not be used for billing. Table 2.13.5 lists the Status elements specific to A3 ALPHA meters. Table 2.13.6 lists the Status elements specific to A3 ALPHA Node meters. Table 2.13.7 lists the Status elements specific to REX meters.
Table 2.13.5 A3 ALPHA Meter Status indicating Data that Should Not be used for Billing (MeterType = A3 and A3_Collector)
ID
2 4 6 7 15 21 22 23 24 25 26 91
Category
Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health
Name
Configuration error RAM failure Registered memory error Clock error Crystal oscillator error EEPROM access error Internal Communication /IC2 error Tariff EE write error Tariff EE read error DSP download error Table CRC Error Internal meter warning (latched)
EnergyIP Action
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
Table 2.13.6 A3 ALPHA Node Status indicating Data that Should Not be used for Billing (MeterType = A3_ILN)
ID
16 19 20 21 22 23 24
Category
Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health
Name
ILC Configuration Error Meter Error Configuration Error RAM Failure ROM Error Registered Memory Error Clock Error
EnergyIP Action
EnergyIP MtrDiagError/METER_RESET is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data
249
ID
28 29 30 31 32 33 34 38 40 41
Category
Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health
Name
EEPROM Access Error Internal Communication /I2C Error Tariff EE Write Error Tariff EE Read Error Crystal Oscillator Error Table CRC Error DSP Download Error Internal Meter Warning ILC Shared Memory Error ILC Power Fail Save Fail
EnergyIP Action
is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
Table 2.13.7 REX Meter Status indicating Data that Should Not be used for Billing (MeterType = REX)
ID
29 30 31 32 33 34 72
Category
Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health Meter Health
Name
ROM Checksum Error Registered Memory Error Configuration Error Table CRC Error EEPROM Access Error Meter Chip Error Radio Config Error
EnergyIP Action
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check. EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
250
2.14
Meter Read Interface (Trilliant)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Trilliant AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.14.1 Description
2.14.2 Integration
2.14.2.1 Direction
AMCC to the MDM/R

This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDPs 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.
251
It is recommended that interval data be transmitted in Meter Transfer Blocks no longer than 24 hours long, and if possible, a Meter Transfer Block should end at midnight or with one hour (plus or minus) of midnight to assure that the Billing Validation Sum Check can be effectively performed.

1. Universal SDP ID and AMCD ID must be a valid pair for the LDCs Organization ID for the Daily Read Period date being reported 2. Where the LDCs Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 5. The following are exception cases: a. The MDM/R CMEP Adapter detects exceptions in regards to invalid file format and data type exceptions. b. The MDM/R detects exceptions when the LDCs Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system.
Version 3.3 July 7, 2011 252
d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 6. Meter Reads exception reports are created: The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC06 and DC16 in Section 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications). The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R Reports Technical Specifications).
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 kilovoltampere hours. This will apply to both interval consumption data and register read data.
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.
253
The Universal SDP ID has a relationship with the corresponding AMCD ID in the MMD for the Daily Read Period being reported All of the attributes associated with the Data Collection Service must be populated.
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

2.14.8 File Format

2.14.8.1 File Name Record for the Trilliant CMEP File
Table 2.14.1 FILE NAME RECORD FOR THE TRILLIANT CMEP FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
254
2.14.8.2 Trilliant CMEP File
The data mapping definitions and the file format layout following the File Name Record are based on the California Metering Exchange Protocol (CMEP) Version 1.20, with some modifications made specific to the Ontario Smart Metering System implementation. Other than the specific modifications described in this specification data file transmissions should conform to the specifications of CMEP Version 1.20. The CMEP files will contain only the following record types:
Table 2.14.2
"MEPMD01" - Metering Data Type 1 - Interval Data MEPAD01" - Administrative Data Type 1 DASR "MEPAD02" - Administrative Data Type 2 - Credit Data "MEPMD02" - Metering Data Type 2 - TOU Data "MEPBD01" - Billing Data Type 1 - Billed Dollars "MEPBD02" - Billing Data Type 2 - Interval Pricing Plan "MEPBD03" - Billing Data Type 3 - TOU Pricing Plan "MEPLF01" - Distribution Loss Factors Electric "MEPEC01" - Equipment Configuration Type 1 "MEPRR01" - Record Reject Type 1
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TRILLIANT
The CMEP files will not contain the following record types:
CMEP Field Name

Record Type
Data Type/Length
Varchar (7)
Format
Required
Y
Description
Record Version
Date
Sender ID
Varchar (10)
General: AAAAAAAAAA Specific Usage: Trilliant
This field will always contain Trilliant. NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Trilliant: FILE ID = 7200
Sender Customer ID
Char (8)
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process.
255
CMEP Field Name

Receiver ID
Data Type/Length
Char (8)
Format
General: AAAAAAAA Specific Usage: The MDM/R will only recognize ORG29738
Required
Y
Description
This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Fixed Number (8)
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with. This field Is populated with the date and time that this record was created. This time must be reported in EST This is the ID that is used as a key for the integration between the MDM/R and Trilliant 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 Indicates the reason for this data transmission. Defined values are : OK Normal transmission Resend Retransmission of previously sent data Summary Summary of SP totalled data. History Archival account data Profile Account usage profile data Template Account usage template data Reject Data is rejected and being returned to sender Describes what commodity type is being delivered E Electricity G Gas W Water S - Steam
Time Stamp
Date/Time
yyyyMMddHHm m No format prescribed
Meter ID
Varchar (50)
Purpose
Varchar (8)
General: AAAAAAAA Specific Usage: The MDM/R will only recognize OK, RESEND"
Commodity
Char(1)
256
CMEP Field Name

Units
Data Type/Length
Char (6)
Format
Required
Y
Description
The MDM/R will process interval data and register read data where the unit of measurement is consistent with the interval data and register data channels supported by the Channel Configuration Set assigned to the SDP. This field will contain one of the following per record. For energy valid values are: KWH for records containing interval data in kWh delivered. KWHREG for records containing a delivered kWh register read taken at the end of the Meter Transfer Block. For VA-hours valid values are: KVAH for records containing interval data in kVAh delivered. KVAHREG for records containing a delivered kVAh register read taken at the end of the Meter Transfer Block. For VAR-hours valid values are: KVARH for records containing interval data in kVARh inductive (Power Factor lagging) delivered. KVARHREG for records containing a register read for kVARh inductive (Power Factor lagging) delivered taken at the end of the Meter Transfer Block. The Calculation Constant will always contain 1. Units will always be delivered in kWh, kVAh, or kVARh hence no calculation to engineering units will be required. Describes the time interval between readings. Metering data is transmitted as Date/Time and value pairs. In many cases the time intervals for the data values is so regular that Date/Time information past the first reading is essentially redundant. This field minimizes the redundancy problem. If a Date/Time field, after the first reading in a line, is empty, it is calculated by adding this interval to the Date/Time of the previous interval. The field is ignored if no empty Date/Time fields are encountered in the record.
Number (1,0)
Interval
Time Interval
MMDDhhmm Example: 00000100 indicates a time interval of one hour 00000015 indicates a time interval of 15 minutes
257
CMEP Field Name

Count
Data Type/Length
Number (2,0)
Format
Required
Y
Description
Indicates the number of Date/Time, flag, and value sets to follow. NOTE: The number of sets is limited to a maximum of 48 sets per record in conformance with the maximum number of sets allowed as specified for the MEPMD01 Record Type in the California Metering Exchange Protocol. If the Units field is populated with KWHREG, KVAHREG or KVARHREG then count will be 1, indicating that a register read for the end of the Meter Transfer Block is being transmitted If the Units field is populated with KWH, KVAH, or KVARH then the count will be the number of intervals that are included in the Meter Transfer Block
Data Triplet the following three fields repeat for each interval/register read provided in the file Date/Time Date/Time yyyyMMddHHm m Y Per CMEP, the Date/Time field must be supplied for the first record provided. When the Interval field is supplied, Date/Time fields after the first may be left empty to be calculated when the record is read. For Ontario, a Date/Time must be provided for every interval/register value delivered. It must be the time at the end of the interval. The Date/Time must be in EST.
258
CMEP Field Name

Protocol Text
Data Type/Length
Char (7)
Format
General: AAAAAAA (7 characters including a space at the second and fifth character position) Examples: For a simple code A raw interval read for which a power outage occurred during the interval is R 00 40. For a compound code A raw interval read for which a power outage occurred concurrent with a RAM error would be R 02 40
Required
Y
Description
This field is populated with the data quality information. The first character is either R, a raw reading as supplied from the AMCC without validation, estimation or editing, or N indicating no value has been supplied for this interval. The second and third digits are a 10-bit hexadecimal number from 00 to 03 FF. The 10bits indicate the following quality conditions: The Trilliant SerViewCom AMI can transmit the following simple Data Quality code values: R 00 00 (no Bit is set) R 00 01 (Bit 0) R 00 02 (Bit 1) N 00 04 (Bit 2) Missing data will always be accompanied by a Numeric floating point value of 0. R 00 08 (Bit 3) R 00 10 (Bit 4) R 00 20 (Bit 5) R 00 40 (Bit 6) R 00 80 (Bit 7) R 01 00 (Bit 8) R 02 00 (Bit 9) Table 2.14.3 provides the Trilliant descriptions of these simple Data Quality Flags and the action taken by the MDM/R for each flag for interval consumption data. The Data Quality Flags may also be applied to register read data. Only Power outage R 00 40 (Bit 6) will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag and viewed in the GUI as Power Off. Other valid flags will be ignored. NOTE: The Trilliant SerViewCom AMI can also transmit these simple codes in combination as compound codes. See Section 2.14.8.3 regarding treatment of additive quality bit codes.
Number (12,5)
13
General: NNNNNNNNNN NN.NNNNN Specific: 123456789012.3 4
13
Version 3.3 July 7, 2011 259
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 triplet within the Trilliant 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.14.3
Bit Bit Value 00 00
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Trilliant
Trilliant Data Quality Flag Description EnergyIP Action Trilliant No data quality problems No EnergyIP flag is set, data will be treated as normal data Trilliant Manually entered or modified EnergyIP DCEstimated flag is set in GUI, Validation status set to EST, Change Method set to EDC Trilliant Automatically estimated EnergyIP DCEstimated flag is set in GUI, Validation status set to EST, Change Method set to EDC Trilliant Missing data for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check Trilliant Overflow: Consumption is more than the MeshReader can record EnergyIP Overflow flag is set in GUI, data is subject to the Pulse Overflow Validation check Trilliant Partial interval is on: When set this status indicates the effective interval duration was shortened EnergyIP ShortInt flag is set in GUI, data will be treated as normal data Trilliant Too full: Indicates too much pulse content, happens when the clock is adjusted EnergyIP LongInt flag is set in GUI, data is treated as normal data Trilliant Power outage: Indicates start of power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done Trilliant Power restore: Indicates power was restored EnergyIP PwrOn flag is set in GUI, Missing Intervals validation check NO_DATA flag is cleared, validation/estimation resumes on subsequent interval data Trilliant Clock error: Clock time was messed up EnergyIP TimeChg flag is set in GUI, data is subject to the Time Change Validation check Trilliant Diagnostic error: RAM or memory error EnergyIP MtrDiagError flag is set in GUI, data is subject to the Meter Diagnostic Validation check Required CMEP Flag R 00 00 EnergyIP Flag null
Bit 0
00 01
R 00 01
DC_DATA_ESTIMATION
Bit 1
00 02
R 00 02
DC_DATA_ESTIMATION
Bit 2
00 04
N 00 04
NO_DATA
Bit 3
00 08
R 00 08
PULSE_OVERFLOW
Bit 4
00 10
R 00 10
SHORT_INTERVAL
Bit 5
00 20
R 00 20
LONG_INTERVAL
Bit 6
00 40
R 00 40
POWER_OFF
Bit 7
00 80
R 00 80
POWER_ON
Bit 8
01 00
R 01 00
TIME_CHANGE
Bit 9
02 00
R 02 00
METER_RESET
2.14.8.3 Addition of Hexadecimal Quality Flags
The EnergyIP CMEP adaptor for Trilliant will support the combination or addition of multiple hexadecimal data quality flags up to the 1024 hexadecimal code values involving Bit 0 through Bit 9.
260
2.15
Meter Read Transformation for Transmission via Trilliant CMEP Interface

The use of a CMEP file format to transmit Meter Read data sourced from AMI systems other than the source AMI system is possible. LDCs may elect to transform Meter Read data as retrieved by the source Advanced Metering Control Computer (AMCC) to a CMEP format when correction of Meter Read data in the past is required, or to utilize the interval data Data Collection Estimation data quality flag available only via the Trilliant Meter Read Interface. LDCs electing to transform Meter Read data to a CMEP format must transmit such transformed data in the Trilliant CMEP format. The Trilliant CMEP format provides the greatest parity regarding transmission of interval data, register read data, and related data quality flags available from other AMI systems deployed as part of the Ontario Smart Metering System. The purpose of this specification is to define the requirements for data transformations applied to Meter Read data collected by non-Trilliant AMI Advanced Metering Control Computers (AMCC) and transformed by an LDCs meter read translator prior to transmission to the MDM/R via the Trilliant Meter Read Interface. This specification anticipates that such data transformations may be used to process data on an exception basis for Meter Read data correction, or may be used for daily production transmission of Meter Read data to the MDM/R for each Daily Read Period for an LDCs entire smart meter population.
2.15.1 Description
2.15.2 Integration
2.15.2.1 Direction
AMCC to Meter Read Translator to the MDM/R Trilliant Meter Read Interface
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 LDCs meter read translator for all meters that are associated to SDPs 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.
Version 3.3 July 7, 2011 261
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. Subject to the limitation for the maximum number of data triplets per record described above, interval data will be transmitted in Meter Transfer Blocks for an entire day or days, with the Meter Transfer Block beginning and ending at midnight whenever possible to do so. Transmission of partial day interval data should be avoided. At least one register reading should be transmitted to the MDM/R for each Daily Read Period. However, interval data for an entire day may be transmitted without an associated register reading if an associated register reading has not been collected by the source AMCC.
2.15.2.3 Transmission of Register Readings
Register readings transmitted to the MDM/R will be cumulative values established from meter readings approved and verified by Measurement Canada as registered and transmitted by the meter and assigned engineering units and date/time values by the source Advanced Metering Control Computer (AMCC) that retrieves the register readings. Quantity values and date/time stamps assigned by the AMCC to register readings will not be altered in any way when transmitted to the MDM/R. Estimated register readings in terms of altered quantity value or altered date/time stamp will be not transmitted to the MDM/R using the Trilliant Meter Read Interface. Such externally estimated register readings may be transmitted to the MDM/R indicating such register readings as estimated using the (future) Universal Meter Read Interface.
Register readings including the first register reading of a meter collected when the meter is installed, and the last register reading of a meter collected when the meter is exchanged, may be transmitted to the MDM/R either as part of a Meter Transfer Block (i.e. a set of interval data with the register reading at the end of the set of interval data), or as a Meter Read record consisting only of the register reading (i.e. a single value for which the Units are KWHREG). Register readings are stored in the register read table of the Meter Data Database and are available via the MDM/R GUI. kWh, kVAh, and kVARh register readings are processed and stored only for physical register data channels created by the Channel Configuration Set for a physical meter established using the synchronization processes. For meters for which a non-unity Scaling Constant is provided in the synchronization process the register read data is multiplied by the Scaling Constant before being loaded into the Meter Data Database. The latest register reading received as part of a Meter Transfer Block is available for Message Sum Check validation, and Register Read Scaling of Historic and Class Load Profile estimation. Register readings received as part of a Meter Transfer Block are also available to the Billing Validation Sum Check if the Date/Time of the register reading is within the MaxRegisterRange hours of the billing period start date/time or billing period end date/time. Register readings received as a single KWHREG value are only available to the Billing Validation Sum Check if the Date/Time of the register reading is within the
262
MaxRegisterRange hours of the billing period start date/time or billing period end date/time.

In addition to the Business Rules specified in Section 2.14.3 the following rules apply to data transformations utilizing the Trilliant Meter Read interface.
A) Rules Affecting Synchronization
The AMCC Type is used by the MDM/R Register Read Monitor as the key for several Data Collection reports that provide reporting against each AMI technology. This includes Reports DC01, DC02 and DC05. The AMCC Type also is used as the basis of the <measurementSource> attribute in the Billing Service Standard Interface Reply. 1. When establishing each Communication Module asset as part of the Asset Data File Detail Record the AMCC Type will be specified as the actual AMI technology used for each meter. a. For all Elster meters, AMCC Type must equal 01 b. For all Sensus meters, AMCC Type must equal 02 c. For all Tantalus meters, AMCC Type must equal 04
B) Rules Affecting File Transfer Services (FTS)
1. If the LDC elects to transmit Meter Read data sourced from a non-Trilliant AMI system, the LDC or its AMI Operator must be registered to transmit FTS files of File Type 7200 Meter Read Interface (Trilliant) 2. Meter Read data sourced from non-Trilliant meters and transmitted using a Trilliant CMEP format must be sent as a FILE ID 7200.
C) Rules Affecting Meter Read Data sourced from the Elster AMCC
Register read data from REX meters and transmitted in the MAS AMRDEF Export XML as <ConsumptionData> is collected predominantly at mid-interval and does not coincide with the end date/time of any interval data block. LDCs deploying REX2 (R2S) Meters or REX1 (R1S) Meters with firmware 4.1 or higher and operating EnergyAxis Metering Automation Server (MAS) Release 6.2 or EnergyAxis Management System (EA_MS) Release 7.0 can expect the AMRDEF Export XML interval data records to be accompanied by an <EndOfIntervalSnapshot> record. This End Of Interval Snapshot is a register read coinciding with the end date/time of each collected interval data block. 1. Register readings included in each Meter Transfer Block should be sourced from the End Of Interval Snapshot if available and should be at the end of the Meter Transfer Block or as late as possible within the date/time range of the interval data set. 2. Register readings included in each Meter Transfer Block sourced from Consumption Data should be as late possible within the date/time range of the interval data set.
Please see Section 2.14.4 Pre-Conditions for the Meter Read Interface (Trilliant).
263
Please see Section 2.14.5 Post-Conditions for the Meter Read Interface (Trilliant).
2.15.6 Assumptions
Please see Section 2.14.6 Assumptions for the Meter Read Interface (Trilliant).

Frequency: Meter Read data is supplied, at a minimum, once per day. The preference is for Meter Read data to be supplied in midnight to midnight Meter Transfer Blocks whenever possible to do so. The LDCs will establish their frequency based on their operational requirements. Timing: Meter Read data received by the MDM/R by 05:00 EST for the prior Daily Read Period shall be available by 07:10 EST on the day following the Daily Read Period.
2.15.8 File Format

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

2.15.9.1 Translation of Elster <QualityFlags> and <Statuses> to Trilliant CMEP
The Elster MAS AMRDEF provides data quality information using two differing tag types namely the <QualityFlags> tags and <Statuses> tags. These data quality indicators should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.1.
Table 2.15.1
Elster Tag (not available) (not available) (not available) <QualityFlags.SkippedInterval> <QualityFlags.PulseOverflow> <QualityFlags.PartialInterval> <QualityFlags.LongInterval> <QualityFlags.CompleteOutage> <QualityFlags.PartialOutage> <QualityFlags.SuspectedOutage> <QualityFlags.Restoration> <QualityFlags.TimeChanged> <QualityFlags.ClockSetBackward> <QualityFlags.ClockSetForward> <ReadingQualityIndicator> <Statuses><Status.Name> For A3 ALPHA Meter see Table 2.13.5
Note 2. Note 1.
Mapping of Elster Quality Flags to Trilliant Protocol Text Codes

Trilliant Data Quality Flag Description No data quality problems Manually entered or modified Automatically estimated Missing data for the interval Overflow consumption Partial data in the interval Too much pulse content Start of power outage Required CMEP Flag R 00 00 R 00 01 R 00 02 N 00 04 R 00 08 R 00 10 R 00 20 R 00 40 EnergyIP Flag null DC_DATA_ESTIMATION DC_DATA_ESTIMATION NO_DATA PULSE_OVERFLOW PARTIAL_INTERVAL LONG_INTERVAL POWER_OFF
Power is restored Clock error
R 00 80 R 01 00
POWER_ON TIME_CHANGE
Diagnostic error, Ram or memory error
R 02 00
METER_RESET
264
Elster Tag For A3 ALPHA NODE see Table 2.13.6 For REX Meters see Table 2.13.7 <QualityFlags.InvalidTime> <QualityFlags.TestMode>
Note 3.
Trilliant Data Quality Flag Description
Required CMEP Flag
EnergyIP Flag
(not available) (not available)
N 00 04 -
NO_DATA TEST_MODE
Note 4.
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage R 00 40 will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
Note 1: Interval data submitted for which there are no data quality problems must be submitted in the CMEP format with the Protocol Text code of R 00 00. Note 2: The <SkippedInterval> tag is not produced by any Elster Energy Axis AMI system deployed in Ontario and the AMRDEF Export XML does not include records for missing interval data. Elsters 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 7.0 as deployed for the MDM/R will process interval data readings marked with the <InvalidTime> tag subjecting the interval to the AMI Error Check. The AMI Error Action is set to Estimate for all VEE Services at the request of the Elster LDC community. Setting the CMEP no data flag will result in estimation. 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>
265
and <Status.Name> tags are set as defined in these tables and transformed to the Trilliant CMEP format should include the R 02 00 Protocol text code. Multiple Elster Data Quality Problems The Elster AMRDEF Export XML indicates multiple data quality problems by setting each <QualityFlag> to a value of 1 if the condition occurs and also by setting the <ReadingQualityIndicator> and <Status.Name> tags in the same data transmission. The equivalent Trilliant function is accomplished by the use of compound hexadecimal codes. The Trilliant Meter Read Interface supports the combination of multiple data quality flags up to the possible 1024 code values resulting from the hexadecimal addition of the CMEP codes. If your proposed translation of Elster meter read data is intended to provide the Data Collection Estimation codes (i.e. Manually entered or modified, or Automatically estimated) we recommend that these simple codes be used for any combination data quality condition corrected by manual editing or automatic estimation.
2.15.9.2 Translation of Sensus CMEP to Trilliant CMEP
Transformation of the Sensus CMEP Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.2.
Table 2.15.2 Mapping of Sensus Protocol Text Codes to Trilliant Protocol Text Codes
Sensus CMEP Flag R 00 00 N 00 20 R 00 02 R 00 04 R 00 01 R 00 08 R 00 10 R 00 40 R 00 80 Trilliant Data Quality Flag Description No data quality problems Manually entered or modified Automatically estimated Missing data for the interval Overflow consumption Partial data in the interval Too much pulse content Start of power outage Power is restored Clock error Diagnostic error, Ram or memory error (not available) (not available) (not available) (not available) (not available) Required CMEP Flag R 00 00 R 00 01 R 00 02 N 00 04 R 00 08 R 00 10 R 00 20 R 00 40 R 00 80 R 01 00 R 02 00 EnergyIP Flag null DC_DATA_ESTIMATION DC_DATA_ESTIMATION NO_DATA PULSE_OVERFLOW PARTIAL_INTERVAL LONG_INTERVAL POWER_OFF POWER_ON TIME_CHANGE METER_RESET null null null null null
Sensus Data Quality Flag Description Error free interval (not available) (not available) Missing data (not available) (not available) (not available) Power outage Power restoral (not available) (not available) Communication failure Voltage sag Voltage swell Daylight savings in effect Meter was out of service
266
2.15.9.3 Translation of Sensus2 CMEP to Trilliant CMEP
Transformation of the Sensus FlexNet extended file CMEP format Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.3.
Table 2.15.3 Mapping of Sensus2 Protocol Text Codes to Trilliant Protocol Text Codes
Sensus2 CMEP Flag R0 N32 R512 R1024 R2048 R2 R4 R256 R1 R8 Not used R64 Not used R4096 Not used R32768 Trilliant Data Quality Flag Description No data quality problems Manually entered or modified Automatically estimated Missing data for the interval Overflow consumption Partial data in the interval Too much pulse content (not available) Start of power outage Power is restored Clock error Diagnostic error, Ram or memory error (not available) (not available) (not available) (not available) (not available) (not available) (not available) Clock error Required CMEP Flag R 00 00 R 00 01 R 00 02 N 00 04 R 00 08 R 00 10 R 00 20 R 00 40 R 00 80 R 01 00 R 02 00 R 01 00 EnergyIP Flag null DC_DATA_ESTIMATION DC_DATA_ESTIMATION NO_DATA PULSE_OVERFLOW PARTIAL_INTERVAL LONG_INTERVAL SHORT_INTERVAL POWER_OFF POWER_ON TIME_CHANGE METER_RESET null null null null null TEST_MODE null TIME_CHANGE
Sensus2 Data Quality Flag Description Error free interval (not available) (not available) Missing data Overflow (not available) Long interval Short interval Power outage Power restoral Time Adjustment (not available) Communication failure Voltage sag Voltage swell Daylight savings in effect Meter was out of service Test mode Register rollover detected Clock out of sync
2.15.9.4 Translation of Tantalus CMEP to Trilliant CMEP
Transformation of the Tantalus CMEP Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.4.
Table 2.15.4 Mapping of Tantalus Protocol Text Codes to Trilliant Protocol Text Codes
Sensus2 CMEP Flag R 00 00 N 00 20 R 00 02 Trilliant Data Quality Flag Description No data quality problems Manually entered or modified Automatically estimated Missing data for the interval Overflow consumption Partial data in the interval Too much pulse content Start of power outage Required CMEP Flag R 00 00 R 00 01 R 00 02 N 00 04 R 00 08 R 00 10 R 00 20 R 00 40 EnergyIP Flag null DC_DATA_ESTIMATION DC_DATA_ESTIMATION NO_DATA PULSE_OVERFLOW PARTIAL_INTERVAL LONG_INTERVAL POWER_OFF
Tantalus Data Quality Flag Description Normal raw data (not available) (not available) Consumption reading missing for this interval (not available) (not available) (not available) Power was out for all or part
267
Tantalus Data Quality Flag Description of the interval Power was restored during this interval (not available) The meter has failed Communication failure within the meter Voltage sag was in effect for all or part of the interval Voltage swell was in effect for all or part of the interval Daylight savings was in effect Meter was out of service for all or part of the interval Meter was unavailable due to maintenance by the utility
Sensus2 CMEP Flag R 00 04 R 01 00 R 00 01 R 00 08 R 00 10 R 00 40 R 00 80 R 02 00
Trilliant Data Quality Flag Description Power is restored Clock error Diagnostic error, Ram or memory error (not available) (not available) (not available) (not available) (not available) (not available)
Required CMEP Flag R 00 80 R 01 00 R 02 00 -
EnergyIP Flag
POWER_ON TIME_CHANGE METER_RESET null null null null Null null
268
2.16
Meter Read Interface (Tantalus)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Tantalus AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.16.1 Description
2.16.2 Integration
2.16.2.1 Direction
AMCC to the MDM/R

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

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

2.16.8 File Format

2.16.8.1 File Name Record for the Tantalus CMEP file
Table 2.16.1 FILE NAME RECORD FOR THE TANTALUS CMEP FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
272
2.16.8.2 Tantalus CMEP File
Table 2.16.2
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TANTALUS
CMEP Field Name

Record Type
Data Type/Length
Varchar (7)
Format
Required
Y
Description
Record Version
Date
Sender ID
Varchar (10)
General: AAAAAAAAAA Specific Usage: Tantalus
This field will always contain Tantalus. NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Tantalus: FILE ID = 7300
Sender Customer ID
Char (8)
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process.
273
CMEP Field Name

Receiver ID
Data Type/Length
Char (8)
Format
Required
Y
Description
This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Fixed Number (8)
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with. This field Is populated with the date and time that this record was created. This time must be reported in EST This is the ID that is used as a key for the integration between the MDM/R and Tantalus 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 Indicates the reason for this data transmission. Defined values are : OK Normal transmission Resend Retransmission of previously sent data Summary Summary of SP totalled data. History Archival account data Profile Account usage profile data Template Account usage template data Reject Data is rejected and being returned to sender Describes what commodity type is being delivered E Electricity G Gas W Water S Steam
Time Stamp
Date/Time
Meter ID
Varchar (50)
Purpose
Varchar (8)
Commodity
Char(1)
274
CMEP Field Name

Units
Data Type/Length
Char (6)
Format
Required
Y
Description
Number (1,0)
Interval
Time Interval
MMDDHHMM Example: 00000100 indicates a time interval of one hour 00000015 indicates a time interval of 15 minutes
275
CMEP Field Name

Count
Data Type/Length
Number (2,0)
Format
Required
Y
Description
Data Triplet the following three fields repeat for each interval/register read provided in the file Date/Time Date/Time yyyyMMddHHm m Y Per CMEP, the Date/Time field must be supplied for the first record provided. When the Interval field is supplied, Date/Time fields after the first may be left empty to be calculated when the record is read. For Ontario, a Date/Time must be provided for every interval/register value delivered. It must be the time at the end of the interval. The Date/Time must be in EST. If the Units field is populated with KWHREG, then count will be 1, indicating that a register read for the end of the Meter Transfer Block is being transmitted. If the Units field is populated with KWH, then the count will be the number of intervals that are included in the Meter Transfer Block.
276
CMEP Field Name

Protocol Text
Data Type/Length
Char (7)
Format
General: AAAAAAA Examples: For a simple code A raw interval read for which a power outage occurred during the interval is R 00 02. For a compound code A raw interval read for which a power outage occurred during daylight savings time would be R 00 42 (7 characters including a space at the second and fifth character position)
Required
Y
Description
This field is populated with the data quality information. The first digit is either R, a raw reading as supplied from the AMCC without validation, estimation or editing, or N indicating no value has been supplied for this interval. The second and third digits are an 10-bit hexadecimal number from 00 to 03 FF. The 10bits indicate the following quality conditions: The Tantalus TUNet AMI can transmit the following simple Data Quality code values: R 00 00 (no Bit is set) R 00 01 (Bit 0) R 00 02 (Bit 1) R 00 04 (Bit 2) R 00 08 (Bit 3) R 00 10 (Bit 4) N 00 20 (Bit 5) Missing data will always be accompanied by a Numeric floating point value of 0.00. R 00 40 (Bit 6) R 00 80 (Bit 7) R 01 00 (Bit 8) R 02 00 (Bit 9) Bits 10-15 are currently not defined but may be so in the future Table 2.16.3 provides the Tantalus descriptions of these simple Data Quality Flags and the action taken by the MDM/R for each flag for interval consumption data. The Data Quality Flags may also be applied to register read data. Only Power outage R 00 02 (Bit 1) will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag and viewed in the GUI as Power Off. Other valid flags will be ignored. NOTE: The Tantalus TUNet AMI can also transmit these simple codes in combination as compound codes. See Section 2.16.8.3 regarding treatment of additive quality bit codes.
277
CMEP Field Name

Data Type/Length
Number (12,5)
14
Format
Required
Y
Description
Table 2.16.3 describes the action taken by EnergyIP application in processing the simple protocol text quality flags for interval consumption data provided for each data triplet within the Tantalus 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.16.3
Bit Bit Value 00 00 Bit 0 00 01
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Tantalus
Tantalus Data Quality Flag Description EnergyIP Action Tantalus Normal raw data No EnergyIP flag is set, data will be treated as normal data Tantalus Communication failure within the meter No EnergyIP flag is set, data will be treated as normal data Tantalus Power was out for all or part of the interval EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done Tantalus Power was restored during this interval EnergyIP PwrOn flag is set in GUI, Missing Interval Check NO_DATA flag is cleared, validation/estimation resumes on subsequent interval data Tantalus A voltage sag was in effect for all or part of the interval No EnergyIP flag is set, data will be treated as normal data Tantalus A voltage swell was in effect for all or part of the interval No EnergyIP flag is set, data will be treated as normal data Tantalus Consumption reading was missing for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check Tantalus Daylight Savings Time was in effect No EnergyIP flag is set, data will be treated as normal data Tantalus The meter was out of service for all or part of the interval No EnergyIP flag is set, data will be treated as normal data Tantalus The meter has failed EnergyIP MtrDiagError flag is set in GUI, data is subject to Required CMEP Flag R 00 00 R 00 01 EnergyIP Flag null null
Bit 1
00 02
R 00 02
POWER_OFF
Bit 2
00 04
R 00 04
POWER_ON
Bit 3
00 08
R 00 08
null
Bit 4
00 10
R 00 10
null
Bit 5
00 20
N 00 20
NO_DATA
Bit 6
00 40
R 00 40
null
Bit 7 Bit 8
00 80 01 00
R 00 80 R 01 00
null METER_RESET
14
Version 3.3 July 7, 2011 278
Bit
Bit Value
Tantalus Data Quality Flag Description EnergyIP Action the Meter Diagnostic Validation check Tantalus The meter unavailable due to maintenance by the utility No EnergyIP flag is set, data will be treated as normal data
Required CMEP Flag
EnergyIP Flag
Bit 9
02 00
R 02 00
null
2.16.8.3 Addition of Hexadecimal Quality Flags EnergyIP Release 6.3 and 7.0
The EnergyIP CMEP adaptor for Tantalus will support the combination or addition of multiple hexadecimal data quality flags up to the 1024 hexadecimal code values involving Bit 0 through Bit 9.
279
2.17
Meter Read Interface (SmartSynch)

The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the SmartSynch Transaction Management System (TMS) AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). The handling of interface files through the initial file checks is described in Section 11 of the MDM/R Detailed Design Document, MDM/R File Transfer Services. Section 5 of the MDM/R Detailed Design Document, Meter Data Collection and Processing, discusses Meter Data Collection.
2.17.1 Description
2.17.2 Integration
2.17.2.1 Direction
AMCC to the MDM/R

280

1. Universal SDP ID and AMCD ID must be a valid pair for the LDCs Organization ID for the Daily Read Period date being reported 2. Where the LDCs Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 5. The following are exception cases: a. The MDM/R CMEP Adapter detects exceptions in regards to invalid file format and data type exceptions. b. The MDM/R detects exceptions when the LDCs Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system.
Version 3.3 July 7, 2011 281
282
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

2.17.8 File Format

2.17.8.1 File Name Record for the SmartSynch CMEP File
Table 2.17.1 FILE NAME RECORD FOR THE SMARTSYNCH CMEP FILE
Field Name
Prefix
Data Type/Length
Char (7)
Format
Required
Y
Description
File Name
Varchar (250)
Suffix
Char (8)
283
2.17.8.2 SmartSynch CMEP File
Table 2.17.2
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SMARTSYNCH
CMEP Field Name

Record Type
Data Type/Length
Varchar (7)
Format
Required
Y
Description
The SmartSynch CMEP File Format provides mapping to metering data types MEPMD01 Interval Data, and MEPMD02 TOU Data. The MDM/R is configured to support only interval data and reference register reading data. This field will always contain MEPMD01 This field will contain the CMEP version date. The current version being supported is 19970819 The SmartSynch adaptor will not validate this field. The Record Version field may be null.
Record Version
Date
General: yyyyMMdd Example: 19970819 or null
284
CMEP Field Name

Sender ID
Data Type/Length
Varchar (10)
Format
General: AAAAAAAAAA Specific Usage: SmartSynch
Required
N
Description
This field will always contain SmartSynch. NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For SmartSynch: FILE ID = 7400
Sender Customer ID
Char (8)
Receiver ID
Char (8)
Fixed Number (8)
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with. This field Is populated with the date and time that this record was created. This time must be reported in EST This is the ID that is used as a key for the integration between the MDM/R and the SmartSynch TMS 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 Indicates the reason for this data transmission. Defined values are : OK Normal transmission Resend Retransmission of previously sent data Summary Summary of SP totalled data. History Archival account data Profile Account usage profile data Template Account usage template data Reject Data is rejected and being returned to sender Describes what commodity type is being delivered E Electricity G Gas W Water S - Steam
Time Stamp
Date/Time
Meter ID
Varchar (50)
Purpose
Varchar (8)
Commodity
Char(1)
285
CMEP Field Name

Units
Data Type/Length
Char (6)
Format
Required
Y
Description
Number (1,0)
Interval
Time Interval
MMDDhhmm Example: 00000100 indicates a time interval of one hour 00000015 indicates a time interval of 15 minutes
286
CMEP Field Name

Count
Data Type/Length
Number (2,0)
Format
Required
Y
Description
Data Triplet the following three fields repeat for each interval/register read provided in the file Date/Time Date/Time yyyyMMddHHm m Y Per CMEP, the Date/Time field must be supplied for the first record provided. When the Interval field is supplied, Date/Time fields after the first may be left empty to be calculated when the record is read. For Ontario, a Date/Time must be provided for every interval/register value delivered. It must be the time at the end of the interval. The Date/Time must be in EST.
287
CMEP Field Name

Protocol Text
Data Type/Length
Char (7)
Format
General: AAAAAAA (7 characters including a space at the second and fifth character position) Examples: For a simple code A raw interval read for which a power outage occurred during the interval is R 00 40. For a compound code A raw interval read for which a power outage occurred concurrent with a RAM error would be R 02 40
Required
Y
Description
This field is populated with the data quality information. The first character is either R, a raw reading as supplied from the AMCC without validation, estimation or editing, or N indicating no value has been supplied for this interval. The second and third digits are a 10-bit hexadecimal number from 00 to 03 FF. The 10bits indicate the following quality conditions: The SmartSynch TMS can transmit the following simple Data Quality code values: R 00 00 (no Bit is set) R 00 01 (Bit 0) R 00 02 (Bit 1) N 00 04 (Bit 2) Missing data will always be accompanied by a Numeric floating point value of 0. R 00 08 (Bit 3) R 00 10 (Bit 4) R 00 20 (Bit 5) R 00 40 (Bit 6) R 00 80 (Bit 7) R 01 00 (Bit 8) R 02 00 (Bit 9) Table 2.17.3 provides the SmartSynch descriptions of these simple Data Quality Flags and the action taken by the MDM/R for each flag for interval consumption data. The Data Quality Flags may also be applied to register read data. Only Power outage R 00 40 (Bit 6) will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag and viewed in the GUI as Power Off. Other valid flags will be ignored. NOTE: The SmartSynch TMS AMCC can also transmit these simple codes in combination as compound codes. See Section 2.17.8.3 regarding treatment of additive quality bit codes.
Number (12,5)
15
15
Version 3.3 July 7, 2011 288
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 triplet within the SmartSynch TMS CMEP file, and the setting of EnergyIP flags as applicable. The same protocol text quality flags are recognized and processed for KWH, KVARH, and KVAH interval data.
Table 2.17.3 Mapping of Protocol Text Field Quality Flags to EnergyIP Action for SmartSynch TMS
Bit Bit Value 00 00 SmartSynch Data Quality Flag Description EnergyIP Action SmartSynch No data quality problems No EnergyIP flag is set, data will be treated as normal data SmartSynch Manually entered or modified EnergyIP DCEstimated flag is set in GUI, Validation status set to EST, Change Method set to EDC SmartSynch Automatically estimated EnergyIP DCEstimated flag is set in GUI, Validation status set to EST, Change Method set to EDC SmartSynch Missing data for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check SmartSynch Overflow: Consumption is more than the meter can record EnergyIP Overflow flag is set in GUI, data is subject to the Pulse Overflow Validation check SmartSynch Partial: Indicates partial data in the interval. TMS Partial (short interval) flag is set EnergyIP ShortInt flag is set in GUI, data will be treated as normal data SmartSynch Too full: Indicates too much pulse content, happens when the clock is adjusted backwards EnergyIP LongInt flag is set in GUI, data is treated as normal data SmartSynch Power outage: Indicates start of power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done SmartSynch Power restore: Indicates power was restored EnergyIP PwrOn flag is set in GUI, Missing Intervals validation check NO_DATA flag is cleared, validation/estimation resumes on subsequent interval data SmartSynch Clock error: The meter clock was corrected due as a result of being outside allowable drift tolerances EnergyIP TimeChg flag is set in GUI, data is subject to the Time Change Validation check SmartSynch Diagnostic error: RAM or memory error EnergyIP MtrDiagError flag is set in GUI, data is subject to the Meter Diagnostic Validation check Required CMEP Flag R 00 00 EnergyIP Flag null
Bit 0
00 01
R 00 01
DC_DATA_ESTIMATION
Bit 1
00 02
Not used
DC_DATA_ESTIMATION
Bit 2
00 04
N 00 04
NO_DATA
Bit 3
00 08
R 00 08
PULSE_OVERFLOW
Bit 4
00 10
R 00 10
SHORT_INTERVAL
Bit 5
00 20
R 00 20
LONG_INTERVAL
Bit 6
00 40
R 00 40
POWER_OFF
Bit 7
00 80
R 00 80
POWER_ON
Bit 8
01 00
R 01 00
TIME_CHANGE
Bit 9
02 00
R 02 00
METER_RESET
2.17.8.3 Addition of Hexadecimal Quality Flags EnergyIP Release 6.3 and 7.0
The EnergyIP CMEP adaptor for SmartSynch will support the combination or addition of multiple hexadecimal data quality flags up to the 1024 hexadecimal code values involving Bit 0 through Bit 9.
289
2.18
Universal Meter Read Interface (Future)

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

MDMR Technical Interface Spec v3.3 20110707 CLEAN

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MDMR Technical Interface Spec v3.3 20110707 CLEAN

Hochgeladen von

Copyright:

Verfügbare Formate

IESO_SPEC_9027

Meter Data Management and Repository

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Status of these Specifications

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Description of Change Updated sample to delete KWH Est Usage reading.

End of Table of Changes

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Assumptions and Limitations

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Billing Quantity Block Demand

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

TERM CIS CST Consumer or Customer CPP

Daily Read Period

EST File Transfer Service or FTS Firmographic /Demographic

Framing Framing Structure

Interested Party IVR

kVAh kVARh kWh kW77 Peak Demand

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

TERM LDC Meter Read

Meter Read Block

Meter Transfer Block

MDM/R Administrator MMD

OSP Rolling Demand PIPe

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

TERM SDP REF

SSL SOAP TOU

Organization of this Document

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Version 3.3 July 7, 2011

Meter Data Management and Repository

MDM/R Technical Interface Specifications IESO_SPEC_9027

Figure 1.6.1 Interrelationships between MDM/R Documents

MDM/R Logical Applications and Data Architecture

MDM/R Functional Specification

MDM/R Business Process Description