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 / / . This element currently enables the SDP to Billing Agent Relationship without providing a positive control mechanism.
Table of Contents Table of Contents .......................................................................................................................... ii Related Documents ...................................................................................................................... iii Table of Changes ......................................................................................................................... iv 1
Introduction ............................................................................................................................. 1 1.1 Purpose .............................................................................................................................. 1 1.2 Document Scope ................................................................................................................ 1 1.3 Assumptions and Limitations ............................................................................................. 1 1.4 Definition of Terms ............................................................................................................. 2 1.5 Organization of this Document ........................................................................................... 5 1.6 Document Relationships .................................................................................................... 6 1.7 Conventions for Data Field Formats ................................................................................ 10 1.8 MDM/R FTS Use of File Names....................................................................................... 11 1.9 Timelines .......................................................................................................................... 21 1.10 Position Statement – Meter Read Data Transformations .............................................. 22
2
Technical Interface Specifications ...................................................................................... 25 2.1 Universal SDP ID Assignment Request / Response Interface ........................................ 25 2.2 Periodic Audit Synchronization Interface ......................................................................... 37 2.3 Incremental Synchronization Interface............................................................................. 77 2.4 Billing Service Standard Interface - Request ................................................................. 113 2.5 Billing Service Standard Interface - Reply ..................................................................... 126 2.6 Billing Quantity Request ................................................................................................. 150 2.7 Billing Quantity Response .............................................................................................. 156 2.8 Billing Cycle Schedule Interface..................................................................................... 191 2.9 Aggregated Settlement Data .......................................................................................... 195 2.10 Meter Reads Retrieval Web Services Request/Reply ................................................. 202 2.11 Meter Read Interface (Sensus) .................................................................................... 214 2.12 Meter Read Interface (Sensus2) .................................................................................. 225 2.13 Meter Read Interface (Elster) ....................................................................................... 236 2.14 Meter Read Interface (Trilliant) .................................................................................... 251 2.15 Meter Read Transformation for Transmission via Trilliant CMEP Interface ................ 261 2.16 Meter Read Interface (Tantalus) .................................................................................. 269 2.17 Meter Read Interface (SmartSynch) ............................................................................ 280 2.18 Universal Meter Read Interface (Future) ..................................................................... 290
IESO_DES_9001: MDM/R V1.0 Detailed Design – Version 2.0
30 April 2008
SME_SPEC_0001: MDM/R V1.0 Reports Technical Specifications – Version 3.0
29 April 2010
IESO_STD_0078: MDM/R VEE Standard for the Ontario Smart Metering System – Issue 4.1
March 1, 2011
SME_MAN_0005: MDM/R Meter Data Management and Repository (MDM/R) TOU Schedule and Calendar Manual – Issue 2.0
December 19, 2008
MDM/R File Transfer Services and Web Services Configuration Workbook – Version 1.0
October 15, 2008
MDM/R Service and Performance Levels
Issue 2.0, December 14, 2006
MDM/R Business Process Descriptions
Issue 2.0, December 14, 2006
Ontario Regulation 440/07: Functional Specifications for an Advanced Metering Infrastructure, Version 2
July 5, 2007
Ontario Regulation 233/08: Designation of Smart Metering Entity
Made: June 17, 2008
Measurement Canada General Bulletin: GEN-25-E, Policy on the Approval, Initial Verification, and Reverification for Electricity and Gas Meters: Legal Units of Measurement and Functions used for Billing
Date: 2000-06-26
Measurement Canada General Bulletin: GEN-31-E (rev.1), Policy on Multirate Register Metering
Issue Date: 2010-02-10 Effective Date: 2010-04-01
California Metering Exchange Protocol Version 1.20 – Update for EDI DASR compatibility
March 7, 2000
Elster EnergyAxis® Management System AMR Data Exchange Format Reference Release 7.0
2010 January 5
Sensus Meter Systems Extended CMEP File Format, Version 0.87
Table of Changes The following is a summary of changes to this document from version 3.2 dated 2 June 2011. Reference (Section and Page)
Description of Change
Section 2.4, Section 2.4.3, page 116
Billing Service Standard Interface – Request Business Rules § Added new Business Rule 8. – Rules Affecting Register Reading Changes in Prior Billing Periods.
Section 2.5, Section 2.5.3, pages 128
Billing Service Standard Interface – Reply Business Rules § Business Rule 3.d, Minor edit of logical meter change defined, for clarity
Billing Service Standard Interface – Reply Output File § Table 2.5.5 – ReplyMessage/MeterReadings • Updated / / § Deleted ‘KWH Est Usage’ specific usage from Format and Description. • Updated / / § 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 attribute. To be delivered as part of EnergyIP R7.2 SP7. • Updated / / Description to indicate presence of this attribute for ‘KWH Usage BC’. • Updated / / Description delete reference to Hourly measurement.. • Updated / / § Added new attribute which will provide the total kWh quantity of estimated interval data associated with each usage reading. § Added new attributes and indicating these attributes a reserved for future use. • Updated description of the element adding Note 2 indicating provision of ‘KWH Usage BC’ and associated with each Hourly reply in the block of the reply message. § Sample Request Message File-based Output • Updated sample to add attribute. • Updated sample to add Start and End register readings.
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’.
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
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.
Definition of Terms Terms used within this document have been defined in Table 1.4.1 below. Table 1.4.1 – Definitions
TERM
Description
AMCC
AMCC means the Advanced Metering Control Computer that is used to retrieve or receive and temporarily store Meter Reads before or as they are being transmitted to the MDM/R. The information stored in the AMCC is available to log maintenance and transmission faults and issue reports on the overall health of the AMI to the LDC.
AMI
AMI means the Advanced Metering Infrastructure, it includes the meter, Advanced Metering Communication Device (AMCD), Local Area Network (LAN), Advanced Metering Regional Collector (AMRC), Advanced Metering Control Computer (AMCC), Wide Area Network (WAN), and related hardware, software, and connectivity required for a fully functioning data collection system. An AMI does not include the MDM/R.
API
API means an Application Program Interface, which is the interface (calling conventions) application program used for accessing services provided by another module.
AS2
AS2 means Applicability Statement 2 and is a specification of the Electronic Data Interchange over the Internet (EDIINT) working group of the Internet Engineering Task Force (IETF).
Billing Quantity
Refers to consumption data that has been through VEE and Framing and is ready for use in billing.
Block Demand
Calculated kVA and/or kW demand based on a time period with fixed boundaries, such as one hour (e.g. 16:00 to 17:00)
The Customer Information System, in which Customer account information is held.
CST
Central Standard Time
Consumer or Customer
Refers to residential or small general service consumers where the metering of demand is not required.
CPP
Refers to specific rate structures called Critical Peak Pricing. Under these structures, the price of electricity is variable. Such an occurrence will typically occur when wholesale prices for electricity are very high due to constrained supply. One or more of the TOU rating periods will be used to track a Consumer’s electricity consumption during CPP events.
Daily Read Period
Means the 24-hour period for collecting Meter Reads, subject to the two periods during which changes to and from Daylight Savings Time take place. The Daily Read Period commences at 12:00 midnight each day.
EnergyIP
Rebranding of the PIPe product name. The Meter Data Management system developed by eMeter Inc that forms the foundation for the MDM/R solution. (Please see the definition of PIPe below.)
EST
Eastern Standard Time
File Transfer Service or FTS
The service which manages the transfer of files between the MDM/R and LDCs and/or the LDC’s authorized agents.
Firmographic /Demographic
Basic profiling information about business organizations and individuals, respectively. Firmographic data is more relevant for business-to-business transactions involving automated electronic data exchange between businesses or trading partners; they do not typically involve Customers.
Framing
The process by which interval data is assembled into Billing Quantities.
Framing Structure
Framing Structure means a parameter that denotes the method by which Meter Reads are assembled into Billing Quantities by the MDM/R.
GUI
Graphical User Interface. The most commonly used type of computer interface, exemplified by Microsoft Windows and MacOS. Typical elements of a GUI are a mouse interface and a system of visual directories that look like file folders.
Interested Party
Those entities that are authorized to access specific data from the MDM/R.
IVR
Interactive Voice Response - A computerized system that allows a person, typically a telephone caller, to select an option from a voice menu and otherwise interface with a computer system.
kVAh
Kilovolt-ampere hour
kVARh
Kilovolt-ampere-reactive hour
kWh
Kilowatt hour
kW77 Peak Demand
Calculated kVA and/or kW demand in the period between 7:00 a.m. & 7:00 p.m. prevailing time on weekdays that are not statutory holidays within a billing period.
Means a Local Distribution Company, which is an LDC, as defined in the Ontario Energy Board Act, 1998
Meter Read
Is a number generated by a meter that reflects cumulative electricity consumption at a specific point in time. (The Meter Read and related data will be reported to the MDM/R at a specific Service Delivery Point.)
Meter Read Block
Meter Read Block is used by the MDM/R for validation and estimation purposes. All validation and estimation functions are based on acting upon a set of contiguous intervals bounded by a start register read and a stop register read. In some instances a Meter Read Block may span two or more Meter Transfer Blocks. For a Meter Transfer Block consisting of interval consumption data with a register reading at the end of a set of interval consumption data, the start register read for the Meter Read Block will be the immediately preceding (contiguous) stop register read
Meter Transfer Block
Meter Transfer Block is a set of data transferred from an AMCC (or other system) to the MDM/R relating to Meter Reads for a specific Universal SDP ID. A Meter Transfer Block is a set of interval consumption data with a register reading at the end of the set of interval data, or a set of interval register reads for a number of contiguous intervals.
MDM/R
Means the meter data management and meter data repository functions within which Meter Reads are processed to produce Billing Quantity data and the storage of data for future use.
MDM/R Administrator
An administrator of the MDM/R system. This may be a person from the OSP or the Smart Meter Entity (SME) depending on the task involved.
MMD
Means the MDM/R Master Directory, which is a portion of the MDM/R that contains the data relationship among the Meter Read data received from the AMCC and the Service Delivery Point.
Organization ID
A unique Identifier for an organization that will be assigned within the MDM/R during the registration process. Examples of organizations include LDC, billing agents, AMI operators and Retailers.
OSP
Operational Service Provider.
Rolling Demand
Calculated kVA and/or kW demand based on calculations from sub-interval data over a rolling period such as 60 minutes.
PIPe
Power Information Platform by eMeter - The Meter Data Management system developed by eMeter Inc that will form the foundation for the MDM/R solution. (See also EnergyIP)
RPP
Regulated Price Plan (RPP) for Consumers that sets out the prices per kWh that local electricity utilities charge for electricity use.
SDP
Service Delivery Point means the point at which delivery is metered or calculated. The SDP is the point at which billing occurs based on input from one or more smart meters.
SDP ID
Service Delivery Point Identifier - The LDC supplied and controlled identifier that relates to the SDP. It can be an existing identifier (or combination of identifiers) that is unique within the LDC’s systems and relates to the SDP within the MDM/R.
Service Delivery Point Reference - The unique EnergyIP internal identifier for each Service Delivery Point. It is assigned by the EnergyIP system as a Service Delivery Point is created for the first time.
SSL
Secure Sockets Layer - A cryptographic protocol which provides secure communications on the Internet.
SOAP
Simple Object Access Protocol – A protocol for exchanging XML based messages over computer networks normally using Http.
TOU
Time of Use - The sale of electricity based on rates established for certain times of day, days of week, and/or season of year. For billing purposes, Hourly Meter Reads are grouped into a number of rating periods, in accordance with the rate structure, to enable the recording of consumption at certain times of the day, week, or year.
Universal SDP ID
Universal Service Delivery Point Identifier – The MDM/R unique identifier by which authorized Parties interact with the Service Delivery Point. This identifier will be provided to the LDC in the “Universal SDP ID Assignment Response” file. The Universal SDP ID is unique across the province.
VEE
Means Validation, Estimating and Editing of Meter Reads to identify and account for missed and inaccurate Meter Reads to derive billing data. The algorithm to complete VEE identifies gaps in Meter Reads and rebuilds consumption based on historical trending and averaging.
WPG
WebSphere Partner Gateway - provides the platform for the MDM/R to manage the business to business (B2B) transactions for file transfer and translations
Integration Terminology TERM
Description
Request/Response
An asynchronous pair of related data flows
Request/Reply
A synchronous pair of related data flows
Send
An asynchronous one-way flow of data
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.11: Meter Read Interface (Sensus) Section 2.12: Meter Read Interface (Sensus2)
•
Section 2.13: Meter Read Interface (Elster)
•
Section 2.14: Meter Read Interface (Trilliant)
•
Section 2.15: Meter Read Transformation for Transmission via Trilliant CMEP Interface
• •
Section 2.16: Meter Read Interface (Tantalus) Section 2.17: Meter Read Interface (SmartSynch)
•
Section 2.18: Universal Meter Read Interface
Each interface section has a common layout, as follows: • Description • Integration • Business Rules • Pre-conditions • Post-conditions • Assumptions • Frequency and Timing • File Formats
1.6
Document Relationships
1.6.1
Related Documents Overview This document is part of a library that specifies the design, functions and technical interfaces belonging to the Meter Data Management/Repository (MDM/R). This library is comprised of the following documents: 1) Meter Data Management and Repository MDM/R V1.0 Detailed Design (the “Detailed Design”): This document sets out the design of the MDM/R in accordance with the MDM/R Functional Specification that forms part of the “MDM/R Specification” document series (described below). 2) Meter Data Management and Repository MDM/R V1.0 Technical Interface Specifications (the “Technical Interface Specification”): This document describes the format and content of all file-based technical interfaces between the MDM/R and various authorized, interested parties. The Technical Specifications for reports are included in item 4 below. 3) MDM/R File Transfer Services and Web Services Configuration Workbook: This document is an aide to assist Organizations with their AS2 configurations for file transfers to and from the MDM/R. 4) Meter Data Management and Repository MDM/R V1.0 Reports Technical Specifications: This document describes the format and content of MDM/R generated standard and exception reports.
The documents in this library were preceded by the publication of the “MDM/R Specification” document series, produced by the IESO’s Smart Metering System Implementation Program (SMSIP). The MDM/R Specification, is a series of documents developed for the procurement and functional specification of the MDM/R, and includes the following documents: 1) MDM/R Functional Specification – IESO_SPEC_0241: This document sets out the functional description of the Meter Data Management and Repository functions. 2) MDM/R Business Process Description – IESO_SPEC_0240: This document contains a high-level view of the major business process areas identified in the, “MDM/R Functional Specification” 3) MDM/R Logical Application and Data Architecture (LADA) – IESO_ARCH_0008: This document sets out an overview of a logical architecture for the applications, data and inter-dependencies related to the Smart Metering System (in general) and the Meter Data Management Repository (specifically). 4) MDM/R Service and Performance Levels – IESO_SPEC_0239: This document sets out the volumetric projections, and corresponding expectations for service and performance for the MDM/R. The MDM/R Specification document series is available from the SMSIP website (http://www.smi-ieso.ca). The interrelationships between these various documents are depicted in Figure 1.6.1.
Figure 1.6.1 – Interrelationships between MDM/R Documents MDM/R Specification Document Series (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
MDM/R Business Process Description
IESO_SPEC_0241 IESO_SPEC_0240 Functions to be accommodated
Functional Description to be accommodated by the MDM/R design
MDM/R V1.0– Detailed Design
MDM/R Service and Performance Levels Business Processes to be supported by the MDM/R solution
SME_DES_9001 MDM/R File Transfer Services and Web Services Configuration Workbook SME_MAN_9001 Design and Functional Description
Technical Interface Description
MDM/R Document Library for Design, Functions, and Technical Interfaces
1.6.2
Subject Cross-reference: MDM/R Design and Functionality to Technical Interfaces As described earlier, the Detailed Design provides a functional overview to the design, including each of the information flows that are supported by an MDM/R Technical Interface. All technical interfaces are described from a functional standpoint in section 15 of the Detailed Design. Most of these MDM/R Technical Interfaces are supported by the form and content of file-based transfers which are described in the Technical Interface Specifications. Table 1.6.1 below cross-references the major subjects described in the Detailed Design with the Technical Interface Specifications.
Interface Functional Specification – Web Services Interface
2.10
Web Services Interface
Aggregation for Settlement
2.9
Aggregated Settlement Data
Subject Matter
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)
Description
A fixed length alphanumer ic field with a defined length of “X”
Format
Special Instructions
AAAAA
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
Version 3.3 – July 7, 2011
Varchar(X)
A variable length alphanumeric field with a maximum length of “X”
AAAAA
Fixed Number (X)
Number (X) or Number (X,Y)
A fixed length numeric field with a defined length of “X”
NNNNN
Includes the full ASCII character set, with the exception of the Pipe (|) character All Meter Read Interface files: The optional Segment Number file name element is limited to alpha and number characters. Special characters of the ASCII
Fields of this type must be padded to the left with zeros.
Date/Time
Time Interval
A floating numeric field with a maximum of “X” digits to the left of the decimal and a maximum of “Y” digits to the right of the decimal (if existing).
A Date/Time or Date field.
A length of time as indicated in months, days, hours and minutes.
NNNNN.NN
yyyyMMddHH mmss or yyyyMMdd
MMDDhhmm
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
MM – Month DD – Day hh – Hour, in 24 hour format mm – Minutes
CMEP Meter Data files provide Date/Time as: yyyyMMddHH mm
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]
Format example
1.8
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
MDM/R FTS Use of File Names The MDM/R FTS refers to each registered organization as a Community Participant. The value assigned to the Community Participant is used in two places. •
The first is in the configuration of the Community Participant AS2 client. The AS2 client will add the AS2 ID to the AS2 protocol headers attached to each file that it sends to the MDM/R.
•
The second is in the list of Community Participants and their associated Organization ID’s. This list is part of the MDM/R FTS configuration files and is maintained by the MDM/R Administrator.
Each file that is sent by a Community Participant to the MDM/R or by the MDM/R to a Community Participant has a file name that meets the specifications in this section. MDM/R FTS depends on the file name specification to direct incoming files into the appropriate directory for processing by the target application such as EnergyIP or MDM/R Staging Table Loader without looking into the content of the file. Likewise, the Community Participant is able to rely on the names of files received from the MDM/R.
1.8.1
Structure of MDM/R file names The file names used by MDM/R are structured into two groups of elements. The first group of elements is common to all file names and each element must always be present and in the order in which they are specified in the next section. The second group of elements is dependent upon the file type being named. If an element is specified for a file type then it must be present and it must be in the order in which it is specified. File name elements are separated by a period (.). File name elements may contain letters (A-Z, a-z) and numbers (0-9). Other than letters, numbers and the separator character, no other characters are permitted in the file name elements.
The file name ends with the extension .DAT. The file name specification does not speak to the manner in which data in the file is organized. Files containing delimited data and files containing XML encoded data will both have a .DAT extension. The general syntax for the file name is: ....{.request specific element n}.DAT The specific elements of the file name are described in the following sections.
1.8.2
File name elements common to all files The first five elements described below are common to all file names. Element 1: ORG_ID_1 (Organization ID) This mandatory element is the 8 character Organization ID, beginning with ORG, that identifies the Community Participant on whose behalf the file has been submitted for or received on behalf of. The Organization ID must be a valid Organization ID that is already known to the MDM/R FTS. In the situation where a Community Participant is submitting its own files the Organization ID and the Agent Organization ID will be identical. The relationship of Organization ID to Agent Organization ID must be known to the MDM/R FTS at the time the relationship is asserted through an incoming file name. This information is captured when the relationship is established. It is maintained by the MDM/R Administrator in MDM/R FTS configuration files. Agent Organization ID is used in situations where one organization is acting on behalf of another organization. An example of such a relationship is a third party AMI operator submitting meter read data on behalf of the LDC with which it has a contract. Element 2: ORG_ID_2 (Agent Organization ID) This mandatory element is the 8 character Organization ID, beginning with ORG, that identifies the Community Participant that is acting as the agent for the Community Participant on whose behalf the file has been submitted for or received on behalf of. The Agent Organization ID must be a valid Organization ID that is already known to the MDM/R FTS. In the situation where a Community Participant is submitting its own files the Organization ID and the Agent Organization ID will be identical. The relationship of Organization ID to Agent Organization ID must be known to the MDM/R FTS at the time the relationship is asserted through an incoming file name. This information is captured when the relationship is established. It is maintained by the MDM/R Administrator in MDM/R FTS configuration files. Agent Organization ID is used in situations where one organization is acting on behalf of another organization. An example of such a relationship is a third party AMI operator submitting meter read data on behalf of the LDC with which it has a contract. Element 3: FILE_ID (FILE ID) This mandatory element is a four digit value that identifies the type of file.
FILE ID comes from the list of valid files that can be sent to the MDM/R. This list is maintained by the MDM/R Administrator and is part of the MDM/R FTS configuration files. This list only changes when a new type of file is introduced or retired. The MDM/R Technical Interface Specifications document contains the list of valid files and the specification of each. The MDM/R Reports Technical Specifications document contains the list of valid reports and the specification of each. Table 1.8.1: Valid file types
FILE ID
File Type
Comments
1000
Universal SDP ID Assignment Request
Request for the assignment of one or more Universal Service Delivery Points
2000
Universal SDP ID Assignment Response
Response containing the requested assignment of Universal Service Delivery Points.
3000
Periodic Audit Synchronization
Process a complete synchronization of the MDM/R Master Directory with the LDC Data Source(s)
4000
Incremental Synchronization
Update the MDM/R Master Directory as SDP attributes and relationships changes are supplied by the LDC to the MDM/R, based on changes in LDC Data Source(s)
5000
Billing Quantity Request
Requests to the MDM/R for Billing Quantity data
5500
Billing Service Standard Interface – Request
EnergyIP standard XML requests to the MDM/R for Billing Quantity data
6000
Billing Quantity Response – TOU/CPP & Periodic
Response from the MDM/R for TOU/Periodic Billing Quantity data
6100
Billing Quantity Response – Hourly
Response from the MDM/R for Hourly Billing Quantity data
6200
Billing Quantity Response – Demand
Response from the MDM/R for Peak Demand Quantities and Coincident Quantities data
6500
Billing Service Standard Interface – Reply
EnergyIP standard XML reply from the MDM/R for Billing Quantity data – TOU, Periodic, Hourly
7000
Meter Read Interface (Sensus)
Deliver Meter Read data for smart meters to the MDM/R
7001
Meter Read Interface (Sensus2)
Deliver Meter Read data for smart meters to the MDM/R
7100
Meter Read Interface (Elster)
Deliver Meter Read data for smart meters to the MDM/R
7200
Meter Read Interface (Trilliant)
Deliver Meter Read data for smart meters to the MDM/R
7300
Meter Read Interface (Tantalus)
Deliver Meter Read data for smart meters to the MDM/R
7400
Meter Read Interface (SmartSynch)
Deliver Meter Read data for smart meters to the MDM/R
7500
Universal Meter Read Interface (FUTURE)
Deliver externally estimated register read data to the MDM/R
8000
Billing Cycle Schedule
Inform the MDM/R of the billing cycle schedule dates that map to each billing cycle
9000
Data Aggregation File
The daily Aggregated Settlement data provided to LDCs
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.
File ID 3000 – Periodic Audit Synchronization – Version 01 Version 01 of the Periodic Audit Synchronization interface is a single file set made up of a set of 7 related files. The additional file name elements in the file name link these files such that the MDM/R is able to determine which files belong to any given submission and when the complete set (all 7 files) has been received. Element 6 – TX_ID (Transaction Identifier) This mandatory element is a fixed 6 character value that relates all 7 files in this file type. The same value must be present in this element position for each file that makes up the synchronization file set. The value that is placed in this element is defined by the sender. The value is used to group a given file set together and as a reference for the sender. Element 7 – FILE_NO (File Number) This mandatory element is a 2 digit value that identifies which of the 7 files that make up a Periodic Audit Synchronization file set the particular file is. 00. Manifest File 01. Asset Data File 02. Premise Data File 03. Service Agreement Data File 04. Parameter Data File 05. Relationship Data File 06. (Not Used) 07. Component SDP Channel to Channel & Channel to Formula Data File Element 8 – SEGMENT_NO (Segment Number) This mandatory element is a fixed 2 digit value that represents the file segment number. The purpose of this is to allow an LDC to break up a large synchronization file into smaller synchronization files. For example, if you are submitting three Asset files, the segment numbers will be 01, 02, and 03. If a file is sent as a single segment the value for the Segment Number element must be 01. File ID 4000 – Incremental Synchronization – Version 00 Version 00 of the Incremental Synchronization is conceptually a single file but it is made up of a set of 7 related files in the same way as Version 01 of the Periodic Audit Synchronization. Element 6 – TX_ID (Transaction Identifier) This mandatory element is a fixed 6 character value that relates all 7 files in this file type. The same value must be present in this element position for each file that makes up the synchronization file set. The value that is placed in this element is defined by the sender. The value is used to group a given file set together and as a reference for the sender.
Element 7 – FILE_NO (File Number) This mandatory element is a 2 digit value that identifies which of the 7 files that make up an Incremental Synchronization file set the particular file is. 00. Manifest File 01. Asset Data File 02. Premise Data File 03. Service Agreement Data File 04. Parameter Data File 05. Relationship Data File 06. (Not Used) 07. Component SDP Channel to Channel & Channel to Formula Data File 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
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
transmission for the same DATE_TIME into multiple Meter Read data files. The segment numbers for multiple files for the same DATE_TIME may take any alphanumeric value without relationship to each other. NOTE: Characters used in this optional file name element are limited to the alpha (upper and lower case letters) and number characters (integers 0 through 9) of the ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all others). File ID 7400 – Meter Read Interface (SmartSynch) Element 6 – SEGMENT_NO (Segment Number) This optional element is a Varchar(10) value that represents a file segment number. The purpose of this element is to allow an LDC to break down a large Meter Read data transmission for the same DATE_TIME into multiple Meter Read data files. The segment numbers for multiple files for the same DATE_TIME may take any alphanumeric value without relationship to each other. NOTE: Characters used in this optional file name element are limited to the alpha (upper and lower case letters) and number characters (integers 0 through 9) of the ASCII character set. Special characters must not be used (e.g. / \ : * ? “ | < > and all others). File ID 7500 – Universal Meter Read Interface (FUTURE) (Future) File ID 8000 – Billing Cycle Schedule This file does not have any additional file name elements. File ID 9000 – Data Aggregation This file does not have any additional file name elements. File ID 9100 – Data Aggregation Contributors This file does not have any additional file name elements.
1.8.4
File Name Record Different AS2 clients have different ways of treating filenames. While some will retain the original file name when transferring the file from one AS2 system to another, others will change the name. To ensure that the file names are retained regardless of what AS2 client an Organization chooses to install, the file name is the first record of every inbound file from an Organization to the MDM/R and every outbound file from the MDM/R to an Organization.
1.8.5
MDM/R File Name Examples The following examples illustrate the naming of files exchanged with the MDM/R. Assume that the following organizations or Community Participants have been enrolled with the MDM/R and assigned Organization ID’s (ORG_ID): §
ORG11111 is Acme Hydro (a fictitious utility)
§
ORG22222 is Ace AMI Operations Limited (a fictitious AMI operations company)
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: ....{.request specific element n}.DAT Table 1.8.2
Examples of File Names
Transaction description
File Name
A version 01 Universal SDP ID Assignment Request file is sent by Acme Hydro to the MDM/R.
ORG11111.ORG11111.1000.01.20070214221345.DAT
The MDM/R processes the work in the example above and sends back a version 01 Universal SDP ID Assignment Response file to Acme Hydro.
ORG11111.ORG11111.2000.01.20070214221345.DAT
Ace AMI Operations Limited sends a version 01 file of meter data from the Acme Hydro Elster AMI system to the MDM/R.
ORG11111.ORG22222.7100.01.20070214221345.DAT
Ace AMI Operations Limited sends a version 00 file of meter data from the Acme Hydro Sensus AMI system to the MDM/R consisting of four segments on May 4, 2008.
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’.
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’.
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
Version 3.3 – July 7, 2011
MDM/R Timeline for Last Daily Read Period “N” included in a Billing Period
Position Statement – Meter Read Data Transformations Regarding: Data transformations involving Meter Read data prior to transmission to the MDM/R. Authority: This MDM/R Position Statement has been issued by the Independent Electricity System Operator (IESO) acting in the capacity of the Smart Metering Entity (SME) as set out in Electricity Act (S.O. 1998, c. 15, Sch. A) and through its regulatory right to establish detailed requirements for all inbound meter read interfaces to the MDM/R (Ontario Regulation 233/08 “Designation of Smart Metering Entity”). The Issue: It has come to the attention of the IESO that some MDM/R service recipients (i.e. organizations registered with the IESO as users of the MDM/R and their agents) may be applying various data transformations to meter read data prior to its transmission from the Advanced Metering Control Computer (AMCC) to the Meter Data Management Repository (MDM/R). These data transformations are in some cases taking place outside of components of the smart metering systems that are governed by either: §
The provincial government regulation pertaining to the functional specification of the Advanced Metering Infrastructure, specifically Ontario Regulation 440/07 “Functional Specifications for an Advanced Metering Infrastructure”, or
§
The Technical Interface Specification documents issued by the IESO.
A contextual diagram of the issue addressed by this position statement is provided in Figure 1.10.1. The MDM/R is the recipient of such transformed meter read data and the IESO has the right to specify the nature of the meter read interface to the MDM/R under the authority of Ontario Regulation 233/08 “Designation of Smart Metering Entity”. Therefore, this Position statement is intended to clarify the IESO’s view of such data transformations. Position Statement: From the IESO’s viewpoint, meter read data transformations taking place between an MDM/R service recipient’s AMCC (or an AMCC belonging to a service recipient’s duly registered agent for the purpose of sending meter read data to the MDM/R) and the MDM/R meter read interface: 1. are allowable, 2. shall be in compliance with all applicable law (including any applicable regulations governing the role of the SME) and not contradict the role of the MDM/R with respect to the Validation Estimation and Editing (VEE) Standard for the Ontario Smart Metering System, and 3. the resulting meter read data arriving at the MDM/R interface will, in all circumstances be processed in the manner set out in these MDM/R V1.0 Technical Interface Specifications.
Governance of the AMI to MDM/R interface: Ontario Regulation 440/07: “Criteria and Requirements for meters and metering equipment systems and technology”
Inbound Meter Read Data Flow:
Advanced Metering Regional Collectors (AMRCs)
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
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
Electricity Gas and Inspection Act (R.S.C. 1985, c. E-4)
Smart Meters – including Advanced Metering Communication Device (AMCD)
MDM/R Position Statement:
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
Collector (AMRC). All components of the AMI (including the smart meters themselves) are subject to the functional specification set out in Ontario Regulation 440/07. This regulation also requires AMI components to comply with regulatory requirements established by Industry Canada, the Canadian Standards Association, the Ontario Energy Board and the Electrical Safety Authority. State 2: AMRCs feed Meter Read data to the Advanced Metering Control Computer (AMCC) for assembly into meter read files that must be transmitted to the MDM/R. AMCC’s are also deemed to be a portion of the AMI infrastructure governed by Ontario Regulation 440/07. State 3: Meter Read data arriving at the MDM/R interface will be processed in accordance with these MDM/R V1.0 Technical Interface Specifications (IESO_SPEC_9027) and any applicable provisions or regulations made under the Electricity, Gas and Inspection Act (R.S.C. 1985, c. E-4). The technical interface specification document sets out the interface requirements that must be met by all Meter Read data. Presently this document and the associated MDM/R interface makes accommodation for different types of smart metering technology (see Meter Read Interface specifications in this document for further details). State 2 (b) – Optional State Transition: Changes to the format or content of Meter Read data between “State 2” and “State 3” are the subject of this MDM/R Position statement. These changes may take place outside the scope of the AMI and its associated, governing instruments. However, Meter Read data is still subject to a number of applicable laws including various information privacy laws. It is the responsibility of the MDM/R service recipient to be informed of all applicable law governing such data and to adhere to it. As noted above, the IESO does not seek to restrict an MDM/R service recipient from carrying out such data transformations, so long as it is clearly understood that Meter Read data arriving at the MDM/R interface will be processed in accordance with these MDM/R V1.0 Technical Interface Specifications (IESO_SPEC_9027) and the MDM/R Validation Estimation and Editing Standard for the Ontario Smart Metering System (IESO_STD_0078).
Universal SDP ID Assignment Request / Response Interface Note: Version 00 of the Response interface will be retired and replaced by Version 01 with the deployment of EnergyIP Release 7.0 into the MDM/R Production environment. For the Version 01 specification see Sections 2.1.9 through 2.1.16.
2.1.1
Description – Version 00 The purpose of this interface is to process requests from the LDC for Universal Service Delivery Point Identifiers (Universal SDP IDs) and to return the assigned Universal SDP IDs to the LDC. This interface meets a business requirement that a province-wide unique identifier be made available to the LDC in order to pair it with an LDC-specific Service Delivery Point ID (SDP ID) and to be able to uniquely identify itself to the MDM/R in future transactions. The LDC uses this interface to request one or more Universal SDP IDs at a time. The LDC sends a Universal SDP ID Assignment Request File with an LDC ID that uniquely identifies the LDC, along with LDC-generated SDP IDs to which the corresponding Universal SDP IDs is assigned to through this interface. SDP IDs are generated by the LDC, and are unique within the LDCs systems. The Universal SDP ID Assignment Response File is sent back to the LDC with a Universal SDP ID assigned against every SDP ID in the Universal SDP ID Assignment Request File. This interface uses the Universal SDP ID Generator features within the MDM/R system to manage the assignment of Universal SDP IDs. Universal SDP IDs and SDP IDs are described in detail in Section 3 of the MDM/R Detailed Design Document, Service Delivery Point.
2.1.2
Integration – Version 00
2.1.2.1
File Direction
Universal SDP ID Assignment Request: LDC to the MDM/R Universal SDP ID Assignment Response: MDM/R to the LDC 2.1.2.2
Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files. The Universal SDP ID Assignment Request File contains all of the information described in tables 2.1.1 to 2.1.3. The Universal SDP ID Assignment Response File contains all of the information described in tables 2.1.4 to 2.1.6.
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.
Post-conditions – Version 00 The following outcome results from the file being processed through the interface:
2.1.6
§
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).
Assumptions – Version 00 §
2.1.7
The LDC will ensure that Universal SDP IDs are being requested only for SDPs that are or will be associated with Smart Meters.
Frequency and Timing – Version 00 Frequency: A Universal SDP ID Assignment Request File may be sent at any time by the LDC. Timing: The Universal SDP ID Assignment Request File is processed by the EnergyIP application upon receipt by the ‘USDP Assignment’ shell script – a scheduled job configured to run every 15 minutes daily.
2.1.8
File Format – Version 00
2.1.8.1
Universal SDP ID Assignment Request File
2.1.8.1.1 File Name Record for the Universal SDP ID Assignment Request File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.1.1
File Name Record for the Universal SDP ID Assignment Request File
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.1000.00.20070214221345.DAT
NOTE: Please reference Section 1.8.2 for use of file format version number.
2.1.8.1.2 Universal SDP ID Assignment Request File Header Record
The second record will be a header record as described in table 2.1.2. Table 2.1.2: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char(1)
General: A Specific: H
Y
This field indicates that this record is a header record. It must be ‘H’
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG30153’
Y
The unique organization identifier assigned to the LDC during the registration/enrollment process.
Request ID
Number (8)
General: NNNNNNNN Example: ‘543’
N
Populated with an LDC generated identifier for the request. Used to correlate the Universal SDP ID Assignment response with the request.
Request Date and Time
Date/Time
yyyyMMddHHmmss
Y
The date and time the data in this file was produced.
2.1.8.1.3 Universal SDP ID Assignment Request File Detail Record
The data records start after the header and will contain one line for each request of an individual Universal SDP ID as defined in table 2.1.3. Table 2.1.3
UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char (1)
General: A Specific: D
Y
This field indicates that this record is a detail record. It must be ‘D’
SDP ID
Varchar (50)
No format prescribed
Y
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 ID’s) for which a Universal SDP ID needs to be assigned.
2.1.8.2.1 File Name Record for the Universal SDP ID Assignment Response File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.1.4
File Name Record for the Universal SDP ID Assignment Response File
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.2000.00.20070214221345.DAT
NOTE: Please reference Section 1.8.2 for use of file format version number. 2.1.8.2.2 Universal SDP ID Assignment Response File Header Record
The second record will be a header record as described in table 2.1.5. Table 2.1.5
UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char(1)
General: A Specific: H
Y
This field indicates that this record is a header record. It must be ‘H’
LDC ID
Char(8)
General: AAAAAAAA Example: ‘ORG23153’
Y
The unique organization identifier assigned to the LDC during the registration/enrollment process.
Response ID
Number (8)
General: NNNNNNNN Example: ‘543’
N
Populated with the Request ID from the Universal SDP ID Assignment Request file.
Response Time
Date/Time
yyyyMMddHHmmss
Y
The date time the data in this file was produced.
The data records start after the header and will contain one line for each assigned Universal SDP ID as defined in table 2.1.6. The file will not contain records for SDP ID’s for which a Universal SDP ID cannot be assigned. The exception report described in Section 2.1.5 includes these SDP ID’s and the reason for the exception.
2.1.8.2.3 Universal SDP ID Assignment Response File Detail Record Table 2.1.6
UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char (1)
General: A Specific: D
Y
This field indicates that this record is a detail record. It must be ‘D’
SDP ID
Varchar (50)
No format prescribed
Y
A unique LDC Identifier for a SDP that will be associated with a smart meter as provided in the request file.
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Y
This field is populated with the assigned Universal SDP ID.
Y
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
(NOTE: For Version 00 Specification see Sections 2.1.1 through 2.1.8)
2.1.9
Description – Version 01 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 2.1.10.2 Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files. The Universal SDP ID Assignment Request File contains all of the information described in tables 2.1.7 to 2.1.9. The Universal SDP ID Assignment Response File contains all of the information described in tables 2.1.10 to 2.1.13. Once the Universal SDP ID Assignment Request File is delivered to the MDM/R (see Section 11, File Transfer Services of the MDM/R Detailed Design) the Universal SDP ID Assignment process will process the request file and generate the response file.
2.1.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:
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
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.1.7
File Name Record for the Universal SDP ID Assignment Request File
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 01 would be: ORG11111.ORG22222.1000.01.20070214221345.DAT
NOTE: Please reference Section 1.8.2 for use of file format version number. 2.1.16.1.2 Universal SDP ID Assignment Request File Header Record
The second record will be a header record as described in table 2.1.8.
Table 2.1.8: UNIVERSAL SDP ID ASSIGNMENT REQUEST HEADER RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char(1)
General: A Specific: H
Y
This field indicates that this record is a header record. It must be ‘H’
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG30153’
Y
The unique organization identifier assigned to the LDC during the registration/enrollment process.
Request ID
Number (8)
General: NNNNNNNN Example: ‘543’
N
Populated with an LDC generated identifier for the request. Used to correlate the Universal SDP ID Assignment response with the request.
Request Date and Time
Date/Time
yyyyMMddHHmmss
Y
The date and time the data in this file was produced.
2.1.16.1.3 Universal SDP ID Assignment Request File Detail Record
The data records start after the header and will contain one line for each request of an individual Universal SDP ID as defined in table 2.1.9. Table 2.1.9
2.1.16.2
UNIVERSAL SDP ID ASSIGNMENT REQUEST DETAIL RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char (1)
General: A Specific: D
Y
This field indicates that this record is a detail record. It must be ‘D’
SDP ID
Varchar (50)
No format prescribed
Y
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 ID’s) for which a Universal SDP ID needs to be assigned.
Universal SDP ID Assignment Response File – Version 01
2.1.16.2.1 File Name Record for the Universal SDP ID Assignment Response File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
File Name Record for the Universal SDP ID Assignment Response File
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 01 would be: ORG11111.ORG22222.2000.01.20070214221345.DAT
NOTE: Please reference Section 1.8.2 for use of file format version number. 2.1.16.2.2 Universal SDP ID Assignment Response File Header Record
The second record will be a header record as described in table 2.1.11. Table 2.1.11
UNIVERSAL SDP ID ASSIGNMENT RESPONSE HEADER RECORD
Data Element
Data Type/Length
Format
Required
Comments
Record Type
Char(1)
General: A Specific usage: H
Y
This field indicates that this record is a header record. Value must be ‘H’
LDC ID
Char(8)
General: AAAAAAAA Example: ‘ORG23153’
Y
The unique organization identifier assigned to the LDC during the registration/enrollment process.
Response ID
Number (8)
General: NNNNNNNN Example: ‘543’
N
Populated with the Request ID from the Universal SDP ID Assignment Request file.
Response Time
Date/Time
yyyyMMddHHmmss
Y
The date time the data in this file was produced.
The data records start after the header and will contain one line for each assigned Universal SDP ID as defined in table 2.1.12. The file will not contain records for SDP ID’s for which a Universal SDP ID cannot be assigned. The exception report described in Section 2.1.13 includes these SDP ID’s and the reason for the exception.
2.1.16.2.3 Universal SDP ID Assignment Response File Detail Record Table 2.1.12
UNIVERSAL SDP ID ASSIGNMENT RESPONSE DETAIL RECORD
Data Element
Record Type
Version 3.3 – July 7, 2011
Data Type/Length
Format
Required
Comments
Char (1)
General: A Specific: D
Y
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.
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Y
This field is populated with the assigned Universal SDP ID.
Y
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
Universal SDP ID
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
Data Type/Length
Format
Required
Comments
Record Type
Char(1)
General: A Specific usage: E
Y
This field indicates that this record is the last or end-of-file record of the response file. Value must be ‘E’
LDC ID
Char(8)
General: AAAAAAAA Example: ‘ORG23153’
Y
The unique organization identifier assigned to the LDC during the registration/enrollment process.
Response ID
Number (8)
General: NNNNNNNN Example: ‘543’
N
Populated with the Request ID from the Universal SDP ID Assignment Request file.
Description – Version 01 SDP attributes can be updated through the Periodic Audit Synchronization Interface, or the Incremental synchronization Interface. The purpose of the Periodic Audit Synchronization interface is to process a complete synchronization of the MDM/R Master Directory (MMD) with the LDC data source(s). This interface is used by LDC’s to: §
“Create” Service Delivery Point (SDP) objects in the MDM/R. This is a 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
Integration – Version 01
2.2.2.1
File Direction
LDC to the MDM/R 2.2.2.2
Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files. The Periodic Audit Synchronization consists of a set of seven files, as follows: §
Version 3.3 – July 7, 2011
File No. 00 – A Manifest File, listing each file that is included in the specific Periodic Audit Synchronization data set submission.
File No. 01 – One or more Asset Data Files that describes the primary attributes associated with an SDP, a Meter, and a Communication Module
§
File No. 02 – One or more Premise Data Files that describes the premise related attributes (e.g. physical address) associated with an SDP
§
File No. 03 – One or more Service Agreement Data Files that describe the Framing Structure and Commodity Type associated with an SDP
§
File No. 04 – One or more Parameter Data Files that describes additional attributes of an SDP or a Meter.
§
File No. 05 – One or more Relationship Data Files that describes the relationship between two assets or an asset and an organization.
§
File No. 06 – Not Used (NOTE: The Meter Read Data file has been eliminated from the Version 01 Periodic Audit Synchronization file set. File Number 06 should not be submitted, and if submitted will not be processed by the MDM/R. First and last register readings can be submitted using the Meter Read Interface.)
§
File No. 07 – One or more Component SDP Data Files that describes ‘Channel to Channel’ and ‘Channel to Formula’ relationships between virtual and physical SDPs for all existing and new Virtual Service Delivery Points.
For Periodic Audit Synchronization Version 01, File Numbers 00, 01, 02, 03, 04 and 05 are mandatory and must be submitted as part of the sync file set. Periodic Audit Synchronization Detail Records are required for each SDP that has either already been created in the MDM/R or is to be created (reference TIS Section 2.2.1). The data contained in the Periodic Audit Synchronization file set must represent a consistent data set for each SDP. In order to allow for the efficient transmission of Synchronization data file sets, synchronization data files can be split or segmented into multiple smaller files. All records in a segmented file must be complete. File segmentation can only be between complete records. Partial records will result in exceptions. For example, an LDC submitting 1000 records for an Asset Data File could submit a single file with 1000 records, or 10 files with 100 records. These file segments must be appropriately named (as described in Section 1.8.3 of this document) and the name of each file submitted in the single Manifest File for the synchronization submission. The Staging Table Loader (STL) will process each segmented file as submitted in the Manifest File for Periodic Audit Synchronization Version 01. The segment numbers of any one file of the file set must include the value 01 but may have gaps and do not need to be sequential. The STL does load the data for each of the mandatory files of the sync file set (i.e. files 01, 02, 03, 04 and 05) in a particular order but does not consider order when loading the data from any one segmented file. A file sent as one segment must have the SEGMENT_NO value set to 01. The Incomplete Synchronization File Set Report informs the LDC that their synchronization file set was not accepted by the MDM/R, The following cases would result in this condition: • All files for a particular synchronization file set have not been received after an allowed length of time and has been rejected; • The synchronization file set was received out of sequence and is being held, awaiting for the missing synchronization file set(s) to be submitted; Version 3.3 – July 7, 2011
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.
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
Incremental Synchronization interface must be used to submit the end date transaction. 5. Three threshold checks are conducted to determine the number of updates.1 Thresholds for these checks are defined with the LDC during Enrollment but may be updated based upon operational and business requirements. These three checks are performed sequentially. Checks 1 and 2 are performed prior to making any updates to the MMD. If either of these checks fail, no updates to the MMD will be made. Check 3 is performed during the synchronization process. Failure of check 3 allows for MMD updates to be made up to the point in the synchronization process at which the check fails but terminates the synchronization process preventing further MMD updates. The three checks are: Critical Tables Check – Check 1 Upon submission of the synchronization file set the synchronization staging tables will be populated based on the information contained in the synchronization files. Once the synchronization staging tables have been populated, a check will be performed to ensure that there is at least 1 record in each of a sub-set of the synchronization staging tables. The selection of synchronization staging tables used for this check is configured globally. If each synchronization staging table used for the Critical Tables Check does not contain at least one record, this check has failed. Failure of Check 1 will result in the following: •
Termination of the synchronization process and creation of a system error notification to the OSP. Notification of the failure is not captured in any of the MDM/R reports provided to the LDC. The OSP will initiate communication of the failure through the Service Management process.
•
No updates will be made to the MMD.
Validate Minimum Records Percentage – Check 2 The number of records populated in a larger set of the synchronization staging tables as the result of the current synchronization is compared to the number of records populated in the same set of synchronization staging tables from the previous synchronization. The selection of synchronization staging tables used for this check is configured globally. The defined threshold percentage used for the Validate Minimum Records Percentage Check is configured for each LDC and applies to all selected tables. The comparison is performed on each synchronization staging table and if the difference is less than a defined percentage on any table, this check has failed. The same configured percentage is used on each table. For example, if this threshold is set to 60% and in the previous synchronization there were 10 records, then synchronization will abort if the current synchronization contains less than 6 records in the same synchronization staging table. This check is to prevent erroneously inactivating a large number of SDPs by inadvertently submitting partial files. Failure of this check will result in the following:
1
These threshold checks are disabled during initial loading of the synchronization and initial testing.
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.
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:
Version 3.3 – July 7, 2011
§
The Synchronization Updates Report provides a complete listing of the records that were updated via the Periodic Audit Synchronization process. (Reference Report IR06 in Sections 2.4.6 and 2.4.7 of the MDM/R Reports Technical Specifications).
§
The Synchronization Exception Report provides a complete listing of the records that were not updated via the Periodic Audit Synchronization process because an error occurred. (Reference Report IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports Technical Specifications).
The interface creates the updates and exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC. Rules Affecting Future and Retroactive Dating
The data contained in the synchronization file set represent the condition of the master data in LDC’s source system(s) at a point in time. This point in time is identified in the header records of the synchronization file set as the Extracted Date Time. This is the date and time that the data in the synchronization file set was extracted from the source system(s). This time will likely be coincident with the time that the files were created. With the deployment of EnergyIP Release 6.1+, the synchronization file set’s Extracted Date Time will provide the point in time against which all transactions are evaluated to determine if such transactions are intended to make changes in the past or in the future. Periodic Audit Synchronization will only support the submission of Current State and Future State attribute values. Incremental Synchronization must be used for Prior State attribute value changes and/or corrections. Incremental Synchronization supports the Current State, Future State and Retroactive Date synchronization functionality. Date effective changes are generally state changes related to three specific periods of time, namely Future State, Current State, and Prior State. Three types of value and/or date related changes/corrections can be accomplished using the synchronization process. These are: §
Future State Value Changes – where the new attribute value is being supplied with a Start Date/Time that is after the Extracted Date Time. The Current State attribute value (i.e. the value currently in effect) is also supplied with its existing Start Date/Time and an End Date/Time that precedes or aligns with the Start Date/Time of the Future Date attribute value. The future dated attributes are not considered to be in effect until the future dated attribute value Start Date/Time has been reached.
§
Current State Value Changes – where the new attribute value is being supplied with a Start Date/Time that is equal to or after the Start Date/Time of the existing attribute value (i.e. the value currently in effect) in the MMD but starts before the Extracted Date Time provided in the synchronization file set. Once processed, the new attribute value would become the Current State attribute value with no End Date/Time and the previous attribute value is ended with an End Date/Time equal to the Start Date/Time of the supplied new attribute value.
§
Prior State Value and/or Date Corrections – where a series of attribute values are being supplied with start date/times that are before the Current State attribute value (i.e. the value currently in effect) already in the MMD and start before the Extracted Date Time provided in the synchronization file set. The processing of the new attribute values and dates is intended to: o
Version 3.3 – July 7, 2011
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
o
Correct Prior State Value and Date – where both the previously submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules 11. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync V00. 12. The Future Dated Value Change must provide the Current State attribute value that is currently in effect as well as the attribute value that will start at a future date/time. a. The Current State attribute value Start Date/Time must be earlier than the Extracted Date Time. b. The Current State attribute value End Date/Time must be later than the Extracted Date Time, and c. The Current State attribute value End Date/Time must be earlier or equal to the Start Date/Time of the Future Date attribute value. d. If there is not a currently in effect attribute value the Future Date attribute value may be provided alone. 13. Subsequent synchronization file set submissions must include the Future Dated Value Change until it becomes the Current State for that attribute value. a. All subsequent P-Sync V01 submissions must include the pair of records until the Future Dated attribute value becomes the Current State attribute value (currently in effect). b. If the Future Dated attribute value is not provided in a subsequent P-Sync V01 submission then the future dated attribute value will be dropped from the MMD. c. Subsequent I-Sync V00 submissions only need to provide the pair of Future Dated Value Change records if there is a need to change the contents or effective dates of the Future Dated Value Change records. Current State Value Change Business Rules 14. Current State Value Changes can be submitted using P-Sync V01 and I-Sync V00. 15. To end the Current State attribute value (i.e. the value currently in effect) and start a new Attribute value (to become the value currently in effect): a. The P-Sync records may provide the new attribute value with a Start Date/Time that equals or is after the Start Date/Time of the existing attribute value. b. The Periodic Audit Synchronization process will end date the existing attribute value with an End Date/Time equal to the Start Date/Time of the new attribute in accordance with Business Rule No. 3.
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:
2.2.5
§
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.
Post-conditions – Version 01 The following outcome results from the file being processed through the interface:
2.2.6
§
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.
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).
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 LDC’s experience in keeping their master data consistent. Timing: To Be Determined
2.2.8
File Format – Periodic Audit Synchronization Version 01 and Incremental Synchronization Version 00
2.2.8.1
Manifest File
2.2.8.1.1 File Name Record for the Manifest File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.2.1
FILE NAME RECORD FOR THE MANIFEST FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcedf.00.01.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.00.01.DAT
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
Field Record Type
MANIFEST FILE HEADER RECORD
Data Type/Length Char (1)
Version 3.3 – July 7, 2011
Format General: A Specific: H
P Sync V01 Required
I Sync V00 Required
Y
Y
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.
Process Mode
Varchar (20)
General: AAAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or ‘IncrementalSync’
Y
Y
Populated with “PeriodicAuditSync” or “IncrementalSync”
Process Object
Char (20)
General: AAAAAAAAAAAAAA A Specific Usage: ‘Manifest’
Y
Y
Always populated with “Manifest”
Extracted Date Time
Date/Time
yyyyMMddHHmmss
Y
Y
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.
Sequence Number
Number (6)
General: AAAAAA
Y
Y
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.
Format
Examples: 000001 007353 999999
Description
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
Field
Data Type/Length
Filename
Varchar (250)
Version 3.3 – July 7, 2011
MANIFEST FILE DETAIL RECORD
Format
P Sync V01 Required
I Sync V00 Required
Y
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.
2.2.8.2.1 File Name Record for the Asset Data File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.2.4
FILE NAME RECORD FOR THE ASSET DATA FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.01.02.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.01.02.DAT
2.2.8.2.2 Asset Data File Header Record
The second record will be a header record as described in table 2.2.5: Table 2.2.5
Field
ASSET DATA FILE HEADER RECORD
Data Type/Length
Format
P Sync V01 Required
Record Type
Char (1)
General; A Specific: H
Y
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG25153’
Y
Process Mode
Varchar (20)
General: AAAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or ‘IncrementalSync’
Y
Version 3.3 – July 7, 2011
I Sync V00 Required
Description This field indicates that this record is a header record. It must be ‘H’
File Name Record and Header Record are required whether or not Detail Record data are required.
The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with “PeriodicAuditSync” or “IncrementalSync”
Format General: AAAAAAAAAAAAA AA Specific Usage: ‘Asset’
Y
yyyyMMddHHmmss
Y
I Sync V00 Required
Description Always populated with “Asset”
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
Table 2.2.6
Field
Data Type/Length
ASSET DATA FILE DETAIL RECORD
Format
P Sync V01 Required
Record Indicator
Varchar (50)
General: AAAAAAAA Specific Usage: One of the following ‘SDP’ ‘Meter’ ‘Communication Module’
Y
Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
If Record Indicator is “SDP”, then Y If Record Indicator is not “SDP”, then N
SDP ID
Varchar (50)
No format prescribed
If Record Indicator is “SDP”, then Y If Record Indicator is not “SDP”, then N
Type
Varchar (50)
General: A Specific Usage: ONE of the following
If Record Indicator is “SDP” or “Meter”, then Y
Version 3.3 – July 7, 2011
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
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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
If Record Indicator is not “SDP” or “Meter”, then N
physical. ‘V’ is for virtual. This field will only be populated if the Record Indicator field is populated with “SDP” or “Meter”
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’.
If Record Indicator is “SDP”, then Y If Record Indicator is not “SDP”, then N
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”
Load 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’.
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)
No format prescribed
If Record Indicator is “Meter”, then Y If Record Indicator is not “Meter”, then N
AMCD ID
Varchar (50)
No format prescribed
If Record Indicator is “Communicati on Module”, then Y If Record Indicator is not “Communicati on Module”, then N
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
Version 3.3 – July 7, 2011
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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 LDC’s 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”
If Record Indicator is “Meter”, then Y If Record Indicator is not “Meter”, then N
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).
Channel Configur ation Set
Number (2)
General: NN Specific Usage: One of the following ‘01’ ‘02’ ‘03’ ‘04’ ‘05’ ‘06’
If Record Indicator is “Meter”, then Y If Record Indicator is not “Meter”, then N
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.
Scaling Constant
Number (20,10)
General: NNNNN.NN Examples: ‘1’, ‘100’, ‘130.33’ and ‘99999.99’
If Record Indicator is “Meter”, then Y If Record Indicator is not “Meter”, then N
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.
Asset Extra 1
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Asset Extra 2
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Asset Extra 3
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Asset Extra 4
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Asset Extra 5
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
2.2.8.3
Premise Data File
2.2.8.3.1 File Name Record for the Premise Data File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.02.01.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.02.01.DAT
2.2.8.3.2 Premise Data File Header Record
The second record will be a header record as described in table 2.2.8: Table 2.2.8
Field
PREMISE DATA FILE HEADER RECORD
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Type
Char (1)
General; A Specific: H
Y
This field indicates that this record is a header record. It must be ‘H’
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG25153’
Y
The unique Organization identifier assigned to the LDC during the registration/enrollment process.
Process Mode
Varchar (20)
General: AAAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or “IncrementalSync”
Y
Process Object
Char (20)
General: AAAAAAAAAAAAA AA Specific Usage: ‘Premise’
Y
Extracted Date Time
Date/Time
yyyyMMddHHmmss
Y
Version 3.3 – July 7, 2011
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.
Populated with “PeriodicAuditSync” or “IncrementalSync”
Always populated with “Premise”
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.
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
Field
Data Type/Length
PREMISE DATA FILE DETAIL RECORD
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Indicator
Varchar (50)
General: AAAAAAAAAA Specific Usage: “Premise”
Y
This field indicates the type of record being submitted. For this file this will always be “Premise”
Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Y
This identifier is maintained in the LDC systems and uniquely identifies the SDP
Premise Address
Varchar (100)
No format prescribed
Y
The physical address of the SDP. Alternatively, the LDC may provide the Premise ID or other value as may be determined by the LDC.
City
Varchar (20)
No format prescribed
Y
Province
Varchar (20)
No format prescribed
Y
Postal Code
Varchar (10)
No format prescribed
Y
Time Zone
Char(3)
General: AAA Specific Usage: ‘EST’
Y
Premise Extra 1
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Premise Extra 2
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Premise Extra 3
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
2.2.8.4
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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’.
Service Agreement Data File
2.2.8.4.1 File Name Record for the Service Agreement Data File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
FILE NAME RECORD FOR THE SERVICE AGREEMENT DATA FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.03.01.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.03.01.DAT
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
Field
SERVICE AGREEMENT FILE HEADER RECORD
Data Type/Length
Format
P Sync V01 Required
Record Type
Char (1)
General: A Specific: H
Y
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG83458’
Y
Process Mode
Varchar (20)
General: AAAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or “IncrementalSync”
Y
Process Object
Varchar (20)
General: AAAAAAAAAAA Specific Usage: ‘Service Agreement’
Y
Extracted Date Time
Date/Time
yyyyMMddHHmmss
Y
Version 3.3 – July 7, 2011
I Sync V00 Required
Description This field indicates that this record is a header record. It must be ‘H’
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.
The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with “PeriodicAuditSync” or “IncrementalSync”
Always populated with “Service Agreement”
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.
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
Field
SERVICE AGREEMENT DATA FILE DETAIL RECORD
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Indicator
Varchar (50)
General: AAAAAAAAAA Specific Usage: ‘Service Agreement’
Y
This field indicates the type of record being submitted. For this file this will always be “Service Agreement”
Commodity
Char(1)
General: A Specific Usage: ONE of the following characters, ‘E’, or ‘G’, or ‘W’
Y
Always “E” for when the underlying commodity is electricity. Future placeholders of “G” for gas and “W” for water.
Framing Structure ID
Char (2)
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’.
Y
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
Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Y
Universal SDP ID to Framing Structure Relationship Start Date
Date/Time
yyyyMMddHHmmss
Y
Version 3.3 – July 7, 2011
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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 End Date
Date/Time
yyyyMMddHHmmss
For P-Sync, (See note) For I-Sync, N
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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.
Service Agreement Extra 1
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Service Agreement Extra 2
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
Reserved for future use
Service Agreement Extra 3
Varchar (50)
No format prescribed
This field must be empty
This field must be empty
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.
"Energy Purchase Service, TOU/CPP 15 minute Rolling (EST)"
"MP TOU 15 minute Rolling Billing Quantities"
“26”
"TOU/CPP 15 minute Rolling (CST)" TOU/CPP kWh (CST) and 15 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST)
"Energy Purchase Service, TOU/CPP 15 minute Rolling (CST)"
"MP TOU 15 minute Rolling Billing Quantities"
“27”
"TOU/CPP 60 minute Rolling (EST)" TOU/CPP kWh (EST) and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (EST)
"Energy Purchase Service, TOU/CPP 60 minute Rolling (EST)"
"MP TOU 60 minute Rolling Billing Quantities"
"Energy Purchase Service, TOU/CPP 60 minute Rolling (CST)"
"MP TOU 60 minute Rolling Billing Quantities"
"TOU/CPP 60 minute Rolling (CST)" “28”
TOU/CPP kWh (CST) and 60 minute Rolling Demand calculations (EST) with kW77 Peak Demand (CST)
2.2.8.5 Parameter Data File 2.2.8.5.1 File Name Record for the Parameter Data File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.2.14
FILE NAME RECORD FOR THE PARAMETER DATA FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.04.01.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.04.01.DAT
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
General: AAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or “IncrementalSync”
Y
Process Object
Varchar (20)
General: AAAAAAAAAAAA Specific Usage: ‘Parameter’
Y
Extracted Date Time
Date/Time
yyyyMMddHHmmss
Y
I Sync V01 Required
Description This field indicates that this record is a header record. It must be ‘H’
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.
The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with “PeriodicAuditSync” or “IncrementalSync”
Always populated with “Parameter”
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.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
Field Record Indicator
Data Type/Length Varchar (50)
PARAMETER DATA FILE DETAIL RECORD
Format
P Sync V01 Required
General: AAAAAAAAAA Specific Usage: ‘Parameter’
Y
UDC ID
Varchar(50)
General: AAAAAAAAAA Example; 984233
Y
Param Name
Varchar(50)
General: AAAAAAAAA
Y
Version 3.3 – July 7, 2011
I Sync V00 Required
Description This field indicates the type of record being submitted. For this file this will always be “Parameter”
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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”
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.
End Date Time
Date/Time
yyyyMMddHH mmss
For P-Sync, (See note)
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.
For I-Sync, N
Table 2.2.17
This is the value that is associated with the parameter being submitted. Refer to Table 2.2.17 for descriptions of these data elements.
Data Values for Param Value field
Param Value
Data Type/Length
Loss Factor Classification
Number (2)
General: NN Valid Values: ‘01’ through ‘12’
N
N
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”
Service Volts
Varchar (20)
No format prescribed
N
N
Volts of the service to the SDP. Supplied to the MDM/R for informational purposes only.
Service Amps
Varchar (20)
No format prescribed
N
N
Amps of the service to the SDP. Supplied to the MDM/R for informational purposes only.
Phase of the service to the SDP. Supplied to the MDM/R for informational purposes only.
Service Form
Varchar (20)
No format prescribed
N
N
Service wires i.e. 3 phase 4 wire, 3 phase 3 wire. Supplied to the MDM/R for informational purposes only.
Dem-firm #1
Varchar (50)
No format prescribed
N
N
Placeholder for future demographic data.
Dem-firm #2
Varchar (50)
No format prescribed
N
N
Placeholder for future demographic data.
Dem-firm #3
Varchar (50)
No format prescribed
N
N
Placeholder for future demographic data.
Dem-firm #4
Varchar (50)
No format prescribed
N
N
Placeholder for future demographic data.
IVR PIN
Fixed Number (4)
General: NNNN Examples: ‘0000’ ‘9999’
N
N
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”
Billing Cycle ID
Varchar (3)
General: AAA Examples: ‘1’ ‘C45’
Y, if Scheduled “PUSH” is used for Billing Quantities
Y, if Scheduled “PUSH” is used for Billing Quantities
N, if “Request/ Response” is used exclusively
N, if “Request/ Response” is used exclusively
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.
N
N
CT/PT Multiplier
Number (20,10)
Version 3.3 – July 7, 2011
Format
General: NNNNN.N N Examples: ‘1’, ‘100’ ‘130.33’. and ‘99999.99’
Description
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’
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’
Y
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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’
Y
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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.
If UDC ID = Meter ID
Meter Volts
Varchar (20)
No format prescribed
N
N
Volts of the Meter. Supplied to the MDM/R for informational purposes only.
Meter Amps
Varchar (20)
No format prescribed
N
N
Amps of the Meter. Supplied to the MDM/R for informational purposes only.
Meter Phases
Varchar (20)
No format prescribed
N
N
Phase of the Meter. Supplied to the MDM/R for informational purposes only.
Meter Form
Varchar (20)
No format prescribed
N
N
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.
2.2.8.6
Relationship Data File
2.2.8.6.1 File Name Record for the Relationship Data File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements:
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.05.01.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.05.01.DAT
2.2.8.6.2 Relationship Data File Header Record
The second record of the file will be a header record as described in table 2.2.19 Table 2.2.19
Field
RELATIONSHIP DATA FILE HEADER RECORD
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Type
Char (1)
General; A Specific: H
Y
This field indicates that this record is a header record. It must be ‘H’
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG84153’
Y
The unique Organization identifier assigned to the LDC during the registration/enrollment process.
Process Mode
Varchar (20)
General: AAAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or “IncrementalSync”
Y
Process Object
Varchar (20)
General: AAAAAAAAAAAAA AAA Specific Usage: ‘Relationship”
Y
Extracted Date Time
Date/Time
yyyyMMddHHmms s
Y
Version 3.3 – July 7, 2011
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.
Populated with “PeriodicAuditSync” or “IncrementalSync”
Always populated with “Relationship”
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.
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
Values – Relationship Identifier 2
Required Relationship
Future Dates
SDP
METER
Required
Not Allowed
SDP
ACCOUNT
Optional
Allowed
METER
COMMUNICATION MODULE
Required
Not Allowed
SDP
BILLING AGENT
Required
Not Allowed
SDP
AMI OPERATOR
Required
Not Allowed
SDP
ENERGY SERVICE PROVIDER
Optional
Not Allowed
SDP
CCA SERVICE PROVIDER
Optional
Not Allowed
Table 2.2.21
Field
Data Type/Length
Record Indicator
Varchar (50)
Object 1
If Relationship Identifier 1 is “SDP” - Fixed Number (8) “METER” Varchar (50)
Relations hip Identifier 1
Varchar (50)
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” –
Version 3.3 – July 7, 2011
RELATIONSHIP DATA FILE DETAIL RECORD
Format General: AAAAAAAAAA Specific Usage: “Relationship”
General: AAAAAAAAAA Specific Usage “SDP” or “METER”
P Sync V01 Required
I Sync V00 Required
Description
Y
This field indicates the type of record being submitted. For this file this will always be “Relationship”
Y
Based on what is submitted in the “Object 1” field, this value could be § The Universal SDP ID § The Meter ID
Y
This is the type of asset being submitted in the “Relationship Identifier 1” field Acceptable values are defined in table 2.2.20
Y, if field is : “METER”, “COMMUNICA TION MODULE”, “BILLING AGENT”, “AMI OPERATOR” N, if field is: “ACCOUNT”, “ENERGY SERVICE PROVIDER”, “CCA SERVICE PROVIDER”
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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
General: AAAAAAAAAA Specific Usage One of: ‘METER’ ‘ACCOUNT’ ‘COMMUNICA TION MODULE’ ‘BILLING AGENT’ ‘AMI OPERATOR’ ‘ENERGY SERVICE PROVIDER’ ‘CCA SERVICE PROVIDER’
Y
Start Date Time
Date/Time
yyyyMMddHH mmss
Y
Version 3.3 – July 7, 2011
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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
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
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
2.2.8.7
Date/Time
yyyyMMddHH mmss
For P-Sync, (See note) For In-Sync, N
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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.
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
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.2.22 FILE NAME RECORD FOR THE COMPONENT SDP CHANNEL TO CHANNEL & CHANNEL TO FORMULA DATA FILE
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for a Version 01 Periodic Audit Synchronization file would be: ORG11111.ORG22222.3000.01.20070214221345.abcdef.07.02.DAT
or For a Version 00 Incremental Synchronization file: ORG11111.ORG22222.4000.00.20070214221345.abcdef.07. 02.DAT
2.2.8.8.2 Component SDP Channel to Channel & Channel to Formula Data File Header Record
The second record of the file will be a header record as described in table 2.2.23 Table 2.2.23 COMPONENT SDP CHANNEL to CHANNEL & CHANNEL to FORMULA DATA FILE HEADER RECORD
Data Type/Length
Field
Format
P Sync V01 Required
Record Type
Char (1)
General; A Specific: H
Y
LDC ID
Char (8)
General: AAAAAAAA Example: ‘ORG88153’
Y
Process Mode
Varchar (20)
General: AAAAAAAAAAA Specific Usage: ‘PeriodicAuditSync’ or “IncrementalSync”
Y
Process Object
Char (20)
General: AAAAAAAAAAAA Specific Usage: ‘ComponentSDP’
Y
Extracted Date Time
Date/Time
yyyyMMddHHmmss
Y
I Sync V00 Required
Description This field indicates that this record is a header record. It must be ‘H’
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.
The unique Organization identifier assigned to the LDC during the registration/enrollment process. Populated with “PeriodicAuditSync” or “IncrementalSync”
Always populated with “ComponentSDP”
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.8.3 Component SDP Channel to Channel Data File Detail Record
The “Channel to Channel” relationship data records start after the header and will contain one line for each contributing Member interval information channel associated
with a Parent interval information channel as defined in table 2.2.24. These records must be provided in conjunction with a related “Channel to Formula” record. NOTE: Until the Retroactive / Future Dated support is deployed in EnergyIP, Component SDP Data File records will not be processed into EnergyIP. Table 2.2.24
Field
COMPONENT SDP CHANNEL TO CHANNEL DATA FILE DETAIL RECORD
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Indicator
Varchar (50)
General; AAAAAAAA Specific Usage: ‘Channel to Channel’
Y
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’
Y
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.
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’
Y
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
Parent Interval Length
Number (3)
General: NNN Specific Usage: One of ‘5’, ‘10’, ‘15’, ‘30’, or ‘60’
Y
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
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”.
Member Unit of Measure ment
Varchar (15)
General: AAAAAAAAAA Specific Usage: One of ‘kWh’, ‘kVAh’, or ‘kVARh’
Y
This is the unit of measurement for the contributing Member of the Channel to Channel Relationship. Acceptable values are: kWh, kVARh and kVAh
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
Member Interval Length
Number (3)
General: NNN Specific Usage: One of ‘5’, ‘10’, ‘15’, ‘30’, or ‘60’
Y
Member Alias
Varchar (30)
General: AAAAAAAAAA
Y
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.
Channel to Channel Relations hip Start Date
Date/Time
yyyyMMddHHm mss
Y
This is the inclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship starts.
Channel to Channel Relations hip End Date
Date/Time
yyyyMMddHHm mss
N
This is the exclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship ends.
Version 3.3 – July 7, 2011
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
Format General: “A” Specific Usage: ONE of the following characters, “P” or “V”
P Sync V01 Required
I Sync V00 Required
Y
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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
Field
COMPONENT SDP CHANNEL TO FORMULA DATA FILE DETAIL RECORD
Data Type/Length
Format
P Sync V01 Required
I Sync V00 Required
Description
Record Indicator
Varchar 50
General; AAAAAAAA Specific Usage: ‘Channel to Formula’
Y
This field indicates the type of record being submitted. For this file detail record this will always be “Channel to Formula”
Parent Universal SDP ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00098472’
Y
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.
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’
Y
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
Parent Interval Length
Number (3)
General: NNN Specific Usage: One of ‘5’, ‘10’, ‘15’, ‘30’, or ‘60’
Y
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
Format General: NNNNNNNN Example: ‘Summator’ or ‘Expression’
P Sync V01 Required Y
Channel to Formula Relations hip Start Date
Date/Time
yyyyMMddHHm mss
Y
Channel to Formula Relations hip End Date
Date/Time
yyyyMMddHHm mss
For P-Sync, (See note)
Formula Expressi on
Varchar (2000)
For I-Sync, N
Version 3.3 – July 7, 2011
General: AAAAAAAAAA
I Sync V00 Required
If “Formula Type” is specified as “Expression” then Y Otherwise N
Please refer to Section 2.3.10 for Files and Detail data Fields required for each Business Scenario.
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.
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”.
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.
Universal SDP ID
NO
NA
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
LDC ID
NO
M
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
SDP ID
NO
M
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
Premise Address
NO
NA
NA
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
City
NO
NA
NA
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
Province
NO
NA
NA
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
Postal Code
NO
NA
NA
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
MO
Time Zone
NO
NA
NA
MP
MP
O
MP
MP
MP
MP
MP
MP
MP
MP
MP
MP
Service Status
NO
NA
NA
MP
MP
O
MP
MP
MP
MP
M
M
M
M
M
M
Load Status
NO
NA
NA
MP
MP
O
MP
MP
MP
MP
M
M
M
M
M
M
Type (Physical or Virtual) For SDP & Meter
NO
NA
NA
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
MF
Loss Factor Classification
YES
NA
NA
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
OP
CCA Service Provider
Energy Service Provider
Billing Service Provider
Data Collection Provider
Virtual Channel Persistence Service
Generic Framing Service
Data Delivery service
Data Collection service
Energy Purchase Service
VEE Service
SDP Inactive
SDP Active
Universal SDP Assigned
SDP Service Providers
SDP Processing Services
SDP Object Created
SDP Life Cycle
Universal SDP Requested
Start/stop Dates Associated
SDP Attributes
Effective Date Attributes
Table 2.2.26 SDP ATTRIBUTES AND SERVICES
This attribute is no longer used by EnergyIP
Retailer Classification Billing Cycle (denotes the Data Delivery Service)
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Commodity
YES
NA
NA
M
M
M
M
M
M
M
M
M
M
M
M
M
Billing Agent ID
YES
NA
NA
O
M
O
O
O
O
M
O
O
O
M
O
O
AMI Operator ID
YES
NA
NA
O
MP
O
O
MP
MP
O
O
O
M
O
O
O
ENERGY SERVICE PROVIDER ID
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
M
O
Customer Contracted Agent ID
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
M
Service Volts
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Service Amps
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Service Phases
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Service Form
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Number of Dials
YES
NA
NA
O
MP
MP
MP
MP
MP
MP
MP
MP
MP
MP
MP
MP
Version 3.3 – July 7, 2011
73
Meter Data Management and Repository
MDM/R Technical Interface Specifications
Dem-firm#1
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Dem-firm#2
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Dem-firm#3
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Dem-firm#4
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Meter ID
YES
NA
NA
O
MP
O
MP
M
MP
M
M
MV
MP
M
M
M
AMCD ID
YES
NA
NA
O
MP
O
MP
MP
MP
MP
MP
-
MP
MP
MP
MP
NA
NA
O
MP
O
MP
MP
MP
MP
MP
-
MP
MP
MP
MP
Meter AMCC Type Related to data collection service
CCA Service Provider
Energy Service Provider
Billing Service Provider
Data Collection Provider
Virtual Channel Persistence Service
Generic Framing Service
Data Delivery service
Data Collection service
Energy Purchase Service
VEE Service
SDP Inactive
SDP Active
Universal SDP Assigned
SDP Service Providers
SDP Processing Services
SDP Object Created
SDP Life Cycle
Universal SDP Requested
Start/stop Dates Associated
SDP Attributes
Effective Date Attributes
IESO_SPEC_9027
Meter Volts
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Meter Amps
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Meter Phase
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Meter Form
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Last Register Read
YES
NA
NA
O
O
O
O
O
O
O
OP
-
OP
OP
OP
OP
First Register Read
YES
NA
NA
O
O
O
O
O
O
O
OP
-
OP
OP
OP
OP
Account ID
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
CT/PT Multiplier
YES
NA
NA
O
O
O
O
O
O
O
OP
OP
OP
OP
OP
OP
IVR PIN
YES
NA
NA
O
O
O
O
O
O
O
O
O
O
O
O
O
Framing Structure (denotes the Energy Purchase Service)
YES
NA
NA
O
M
O
O
M
M
M
M
M
M
M
M
M
VEE Service (denotes the VEE service)
YES
NA
NA
O
MP
O
MP
MP
MP
M
MP
M
Channel Configuration Set (Replaces Unit of Measurement)
NO
NA
NA
O
M
O
MP
M
MP
M
M
M
O
M
Interval Length
NO
NA
NA
O
MP
O
MP
M
MP
M
M
MV
MP
M
-
-
-
-
-
O
-
O
This attribute is no longer used by EnergyIP
Demand Reset Parent Universal SDP ID (virtual SDP only)
YES
NA
NA
O
O
O
-
O
Parent Unit of Measurement (virtual SDP only)
YES
NA
NA
O
O
O
-
O
Parent Interval Length (virtual SDP only)
YES
NA
NV
O
O
O
-
Member Universal SDP
YES
NA
NA
O
O
O
-
Version 3.3 – July 7, 2011
-
MV
O
MV
O
MV
-
-
-
MV
O
MV
O
MV
-
-
O
-
MV
O
MV
O
MV
-
-
O
-
MV
O
MV
O
MV
-
-
74
Meter Data Management and Repository
MDM/R Technical Interface Specifications
CCA Service Provider
Energy Service Provider
Billing Service Provider
Data Collection Provider
Virtual Channel Persistence Service
Generic Framing Service
Data Delivery service
Data Collection service
Energy Purchase Service
VEE Service
SDP Inactive
SDP Active
Universal SDP Assigned
SDP Service Providers
SDP Processing Services
SDP Object Created
SDP Life Cycle
Universal SDP Requested
Start/stop Dates Associated
SDP Attributes
Effective Date Attributes
IESO_SPEC_9027
ID (physical or virtual SDP) Member Unit of Measurement (physical or virtual SDP)
YES
NA
NA
O
O
O
-
O
-
MV
O
MV
O
MV
-
-
Member Interval Length (physical or virtual SDP)
YES
NA
NA
O
O
O
-
O
-
MV
O
MV
O
MV
-
-
Member Alias (physical or virtual SDP)
YES
NA
NA
O
O
O
-
O
-
MV
O
MV
O
MV
-
-
Formula Type (Target virtual channel)
YES
NA
NA
O
O
O
-
O
-
MV
O
MV
O
MV
-
-
Formula Expression (Target virtual channel)
YES
NA
NA
O
O
O
-
O
-
MV
O
MV
O
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
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)
Number
Table 2.2.28 CHANNEL CONFIGURATION SETS
Classification
01
Default Configuration
Type
Derived Data (virtual Notes channel)
Interval Data
Register Data
Physical Channel kWh
Derived Usage Physical Channel kWh & kW Demand
Physical Channel kWh
Physical Derived Usage Channel kWh & kW Demand
Physical Channel kVARh
Physical Channel kVARh
Physical Meter Physical Channels
Derived data calculations controlled by specified SDP Framing Structure
(kWh only) Physical Meter Physical C & I 02 Configuration
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
Integration
2.3.2.1
Direction
LDC to the MDM/R 2.3.2.2
Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files.
An Incremental Synchronization File may contain information related to only those assets whose attributes or relationship data has changed since the last Incremental or Periodic Audit Synchronization File set. Version 00 of the Incremental Synchronization consists of the same set of seven files as Version 01 of the Periodic Audit Synchronization. The seven files are as follows: §
File No. 00 – A Manifest File, listing each file that is included in the specific Periodic Audit Synchronization data set submission.
§
File No. 01 – One or more Asset Data Files that describes the primary attributes associated with an SDP, a Meter, and a Communication Module
§
File No. 02 – One or more Premise Data Files that describes the premise related attributes (e.g. physical address) associated with an SDP
§
File No. 03 – One or more Service Agreement Data Files that describe the Framing Structure and Commodity Type associated with an SDP
§
File No. 04 – One or more Parameter Data Files that describes additional attributes of an SDP or a Meter.
§
File No. 05 – One or more Relationship Data Files that describes the relationship between two assets or an asset and an organization.
§
File No. 06 – Not Used (NOTE: The Meter Read Data file has been eliminated from the Version 00 Incremental Synchronization file set. File Number 06 should not be submitted, and if submitted will not be processed by the MDM/R. First and last register readings can be submitted using the Meter Read Interface.)
§
File No. 07 – One or more Component SDP Data Files that describes relationships between virtual and physical SDPs for updates to Virtual Service Delivery Points.
For Incremental Synchronization Version 00, File Numbers 00, 01, 02, 03, 04 and 05 are mandatory and must be submitted as part of the Incremental Synchronization file set. These five files must contain a consistent data set for the updates being submitted, which for some updates may result in an empty file. Thus, not only can a file consisting of only a File Name Record and a File Header Record be submitted without any Detail Records, such a file for any one or more of the mandatory files must be submitted. In order to allow for the efficient transmission of Synchronization data file sets, synchronization data files can be split or segmented into multiple smaller files. All records in a segmented file must be complete. File segmentation can only be between complete records. Partial records will result in exceptions. For example, an LDC submitting 1000 records for an Asset Data File could submit a single file with 1000 records, or 10 files with 100 records. These file segments must be appropriately named (as described in Section 1.8.3 of this document) and the name of each file submitted in the single Manifest File for the synchronization submission. The Staging Table Loader (STL) will process each segmented file as submitted in the Manifest File for Incremental Synchronization Version 00. The segment numbers of any one file of the file set may have gaps and do not need to be sequential. The STL does load the data for each of the mandatory files of the sync file set (i.e. files 01, 02, 03, 04 and 05) in a particular order but does not consider order when loading the data from any one segmented file.
The Incomplete Synchronization File Set Report informs the LDC that their synchronization file set was not accepted by the MDM/R, The following cases would result in this condition: • All files for a particular synchronization file set have not been received after an allowed length of time and has been rejected; • The synchronization file set was received out of sequence and is being held, awaiting for the missing synchronization file set(s) to be submitted; • The synchronization file set was received out of sequence, the missing synchronization file set(s) have not been received after an allowed length of time, and the file set has been rejected. The Synchronization Staging Table Loader Exception Report provides exceptions for problems encountered during the staging table loading process which precedes the synchronization process. Any errors encountered other than errors designated as “Warning” in the report will result in the termination of the loading of the synchronization files. 2.3.2.3
Synchronization File Set Sequencing
The “Sequence Number” provided as a mandatory element in the Manifest File Header Record defines the processing sequence for both Version 01 Periodic Audit Synchronization and Version 00 Incremental Synchronization file sets. Thus the “Sequence Number” must be incremented by the LDC for any Periodic or Incremental file set transmission in the sequence that the LDC intends each Periodic Audit Synchronization Version 01 and Incremental Synchronization Version 00 file set to be processed. The Extracted Date Time of each sequential synchronization file set must be greater than or equal to the maximum Extracted Date Time from all previously submitted and successfully processed synchronization file sets. The Extracted Date Time must be the same in each file of the same synchronization file set. Periodic and Incremental Synchronization file sets will be processed in numeric sequence. In the event that an LDC requires a Period or Incremental synchronization file set to be processed out of sequence (that is, process a synchronization file set that is not the next file set in sequence), the LDC must communicate to the MDM/R Operator the Sequence Number (i.e. the value of the “Sequence Number” field in the Manifest File Header Record) of that synchronization file set. The MDM/R Operator will manually set the transaction identifier in the MDM/R. Once this is completed, the LDC can submit the synchronization file set. NOTE: Once the MDM/R operator manually sets the new transaction identifier, the LDC cannot submit synchronization file sets with a sequence number less than the new transaction identifier. If the LDC requires a synchronization file set to be processed with a transaction identifier less than the new transaction identifier, the LDC must follow the same process described above. For example, if the most recent transaction Identifier is 003726 and the LDC requires that the next synchronization file set to be processed is 003744, the LDC must provide this transaction identifier to the MDM/R Operator. The MDM/R Operator will change the last transaction identifier provided to the MDM/R from 003726 to 003743. When this is done, the LDC would be able to submit synchronization file set transaction identifier 003744. However, the LDC would not be able to submit synchronization file sets with transaction identifier 003727 through 003743 unless they follow the same process to reset the sequence number.
The synchronization file set transaction identifier will be updated by the MDM/R upon successful completion of the synchronization process. In the event that the synchronization process (e.g. file set reported on IR10, file set reported on IR14 as not successfully loaded, or threshold checks are exceeded) does not complete successfully the synchronization file set sequence number will not be updated by the MDM/R.
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 it’s defined value was exceeded and the synchronization process will terminate. All updates previously published on the affected publish step and all updates published on prior tables will not be reversed in the MMD. The defined values used for the Max Compare Failure and the Max Publish Failure are configured for each table for each LDC. (These defined values are configured separately for P-Sync and I-Sync.) Failure of either check for any table will result in the following: •
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.
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:
Version 3.3 – July 7, 2011
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 81
Multiple Energy Service providers are associated to a given SDP
7. Update and exception reports for the Incremental Synchronization are created with the following detail. §
The Synchronization Updates Report provides a complete listing of the records, that were updated via the Incremental Synchronization process (Refer to Report IR06 in Sections 2.4.6 and 2.4.7 of the MDM/R Reports Technical Specifications).
§
The Synchronization Exception Report provides a complete listing of the records that were not updated via the Incremental Synchronization process because an error occurred (Refer to Report IR07 in Sections 2.4.8 and 2.4.9 of the MDM/R Reports Technical Specifications).
The interface creates exception reports and places them in the designated storage location for the File Transfer Services (FTS) transfer to the LDC. Rules Affecting Future and Retroactive Dating
The data contained in the synchronization file set represent the condition of the master data in LDC’s source system(s) at a point in time. This point in time is identified in the header records of the synchronization file set as the Extracted Date Time. This is the date and time that the data in the synchronization file set was extracted from the source system(s). This time will likely be coincident with the time that the synchronization file set was created. With the deployment of EnergyIP Release 6.1+ the synchronization file set’s Extracted Date Time will provide the point in time against which all transactions are evaluated to determine if such transactions are intended to make changes in the past or in the future. Periodic Audit Synchronization will only support the submission of Current State and Future State attribute values. Incremental Synchronization must be used for Prior State attribute value changes and/or corrections. Incremental Synchronization supports the Current State, Future State and Prior State synchronization functionality. Date effective changes are generally state changes related to three specific periods of time, namely Future State, Current State, and Prior State. Three types of value and/or date related changes/corrections can be accomplished using the synchronization process. These are: §
Future State Value Changes – where the new attribute value is being supplied with a Start Date/Time that is after the Extracted Date Time. The Current State attribute value (i.e. the value currently in effect) is also supplied with its existing Start Date/Time and an End Date/Time that precedes or aligns with the Start Date/Time of the Future Date attribute value. The future dated attributes are not considered to be in effect until the future dated attribute value Start Date/Time has been reached.
§
Current State Value Changes – where the new attribute value is being supplied with a Start Date/Time that is equal to or after the Start Date/Time of the existing attribute value (i.e. the value currently in effect) in the MMD but starts before the Extracted Date Time provided in the synchronization file set. Once processed, the new attribute value would become the Current State attribute value with no End Date/Time and the previous
attribute value is ended with an End Date/Time equal to the Start Date/Time of the supplied new attribute value. §
Prior State Value and/or Date Corrections – where a series of attribute values are being supplied with start date/times that are before the Current State attribute value (i.e. the value currently in effect) already in the MMD and start before the Extracted Date Time provided in the synchronization file set. The processing of the new attribute values and dates is intended to: o
Correct Prior State Values – where previously submitted attribute values are being corrected but the dates over which these values were effective is remaining unchanged, or
o
Correct Prior State Dates – where previously submitted attribute values are remaining unchanged (both value and order over time) but the dates over which they were effective is being corrected, or
o
Correct Prior State Value and Date – where both the previously submitted attribute values and their effective dates are being corrected.
Future State Value Change Business Rules 8. Future Dated Value Changes can be submitted using P-Sync V01 and I-Sync V00. 9. The Future Dated Value Change must provide the attribute value that is currently in effect as well as the attribute value that will start at a future date/time. 10. Subsequent synchronization file set submissions must include the Future Dated Value Change until it becomes the Current State for that Attribute Value. a. All subsequent P-Sync V01 submissions must include the pair of records until the Future Dated attribute value becomes the Current State Attribute value (currently in effect). b. If the Future Dated attribute value is not provided in a subsequent I-Sync V00 submission then the future dated attribute value will be dropped from the MMD. c. Subsequent I-Sync V00 submissions only need to provide the pair of Future Dated Value Change records if there is a need to change the contents or effective dates of the Future Dated Value Change records. Current State Value Change Business Rules 11. Current State Value Changes can be submitted using P-Sync V01 and I-Sync V00. 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
b. If the new attribute value Start Date Time is equal to the Start Date Time of the existing attribute value (i.e. the value currently in effect) then the existing attribute value must NOT be provided. The synchronization will end the existing attribute value by setting its End Date/Time equal to the Start Date/Time of the existing attribute value. c. If the new attribute value Start Date Time is less than the Start Date Time of the existing attribute value (i.e. the value currently in effect) and there are no Prior State records before the existing attribute value, then the existing attribute value must NOT be provided. The synchronization will end the existing attribute value by setting its End Date Time equal to the Start Date Time of the existing attribute value. 13. To end the Current State Attribute value (i.e. the value currently in effect) and NOT start a new Attribute value a. The I-Sync records must provide the attribute value that is currently in effect in the MMD (providing the same Start Date/Time as that existing attribute value stored in the MMD) and its new End Date/Time. Prior State Value and/or Date Corrections Business Rules 14. Prior State Value and/or Date Corrections can ONLY be submitted using I-Sync V00. 15. The series of Prior State attribute value records must provide a complete set of attribute values with effective date/times to correct the existing attribute values for that period of time up to and including the Current State attribute value and Future State attribute value if required. a. Existing attribute value records that are being replaced by the Prior State attribute value records must NOT be provided. Any existing attribute value record that is no longer required once the Prior State attribute value records are applied will have the End Date Time set equal to the Start Date Time by the synchronization process. 16. The earliest record in the Prior State correction series submission must provide an attribute value with a Start Date/Time that aligns with an existing Prior State attribute value record and its Start Date/Time within the MMD. The existing prior state attribute value record within the MMD must be in effect for a period of time where the existing Prior State attribute value record has a Start Date/Time that is less than it’s End Date Time (i.e. the existing record value within the MMD must be a value that exists for a non-zero length of time). This rule applies to the following special cases: a. Where the series of Prior State attribute value records needs to start before the Start Date/Time of the first attribute value record within the MMD then the first record in the series of Prior State attribute value records can specify a Start Date/Time that predates the earliest Start Date/Time for the attribute value records in the MMD and the series of Prior State attribute value records will correct all of the attribute value records in the MMD for that SDP. b. Where the series of Prior State attribute value records needs to start after the Start Date/Time of the first attribute value record within the MMD then the first record in the series of Prior State attribute value records must be the earliest attribute value record and its Start Date/Time from the MMD
with its End Date/Time set to be equal to its Start Date/Time. This will result in the first attribute value record within the MMD being reduced to being effective for no time since Start Date/Time is an inclusive date/time and End Date/Time is an exclusive date/time and if these two date/times are the same then there is no effect period for the record. It will remain in the MMD for audit purposes only. The remaining records in the series of Prior State attribute value records will correct all of the attribute value records in the MMD up to and including the Current State attribute value record and Future State attribute value if required for that SDP.
2.3.4
Pre-conditions The following must exist for the input file to be processed through the interface:
2.3.5
§
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.
Post-conditions The following outcome results from the file being processed through the interface:
2.3.6
§
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.
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.
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. §
2.3.9
The “Process Mode” field in the Manifest File Header Record will contain “IncrementalSync” rather than, “PeriodicAuditSync”.
Incremental Synchronization – Impact of Future Deployments With the deployment of EnergyIP Release 6.3 and the provision of Retroactive / Future Date support, and the elimination of the Organizational Synchronization and related EnergyIP GUI Security / Access enhancements, only the modified and expressly related information for an SDP definition must be provided in the Incremental Synchronization file set. This results in all required end date related elements being provided and only the elements that describe the new elements of the SDP being provided. This “Modified Information Only” approach results in only the information that is changing and any directly related information being provided. The LDC can choose to continue providing all elements of the SDP definition. The Business Scenario Tables 2.3.1 through 2.3.14 have been updated to indicate the required “Modified Information Only” detail data fields. For ease of reference data fields that previously were required for each specific scenario are indicated as “Optional”.
2.3.10 Business Scenarios for Incremental Synchronization Tables 2.3.1 through 2.3.14 list business scenarios that can happen during the course of regular business for a LDC, and the Files and detail data Fields that must be submitted as part of an Incremental Synchronization file set for updates using the Incremental Synchronization process. The Data Type/Length, Format, and Description for the fields listed in the tables below can be found in Section 2.2.16, Periodic Audit Synchronization Version 01. Table 2.3.1
Business Scenario 1 - Meter Change
File
Field
Notes
Part 1: Remove the Old Meter from SDP Asset (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.)
Version 3.3 – July 7, 2011
Record Indicator
“Meter”
Meter ID
This is the meter ID of the meter being removed from the SDP
Type
This indicates whether this is a physical or virtual meter.
Interval Length
This is the Interval Length of the old Meter
Channel Configuration Set
This identifies the set of information channels to be created for the old meter.
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Record Indicator
“Communication Module”
AMCD ID
This is the AMCD ID that is related to the meter being removed.
AMCC Type
This is the AMCC Type that is associated with the AMCD ID.
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
“Relationship”
Object 1
This is the Meter ID that is being removed.
Relationship Identifier 1
“METER”
Object 2
This is the AMCD ID that is related to the meter that is being removed.
Relationship Identifier 2
“COMMUNICATION MODULE”
Start Date Time
This is the inclusive start date/time of the relationship.
End Date Time
This field can be left null if the Meter to Communication Module Relationship is being left In-Effect. OR This field can provide the exclusive end date/time if the Meter to Communication Module Relationship is being ended when the old meter is removed.
Relationship (This is a required element.)
Part 2: Provide the New Meter and all other Mandatory elements of the existing SDP Asset (OPTIONAL)
Asset (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“SDP”
Universal SDP ID
This is the Universal SDP ID that was assigned to the SDP ID
SDP ID
This is the SDP ID that resides in the LDC’s system of record
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
“Y” or “N”, depending if the service is connected to the SDP or not
Load Status
“Y” or “N”, depending if there is load connected to the meter or not
Record Indicator
“Meter”
Meter ID
This is the meter ID of the meter being installed
Type
This indicates whether this is a physical or virtual meter.
This is the Billing Agent for the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect.
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time of the relationship.
End Date Time
This field is left null.
Record Indicator
“Relationship”
Object 1
The SDP ID that the meter is being added to
Relationship Identifier 1
“SDP”
Object 2
This is the AMI Operator for the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null.
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the Billing Cycle will be associated to
Param Name
“Billing Cycle ID”
Param Value
This is the Billing Cycle ID for the Universal SDP ID.
Start Date Time
This is the inclusive start date/time of the Billing Cycle ID parameter.
End Date Time
This field must be null.
Part 4: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.2
Business Scenario 2 - Meter Removal
File
Field
Notes
Part 1: Remove the Old Meter (provide ONLY the identified elements) 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.)
Relationship (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Meter”
Meter ID
This is the meter ID of the meter being removed from the SDP
Type
This indicates whether this is a physical or virtual meter.
Interval Length
This is the Interval Length of the old Meter
Channel Configuration Set
This identifies the set of information channels to be created for the old meter.
Asset (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Record Indicator
“Communication Module”
AMCD ID
This is the AMCD ID that is related to the meter being removed
AMCC Type
This is the AMCC Type that is associated with the AMCD ID
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
“Relationship”
Object 1
This is the Meter ID that is being removed
Relationship Identifier 1
“METER”
Object 2
This is the AMCD ID that is related to the meter that is being removed
Relationship Identifier 2
“COMMUNICATION MODULE”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field can be left null if the Meter to Communication Module Relationship is being left In-Effect OR This field can provide the exclusive end date/time if the Meter to Communication Module Relationship is being ended when the old meter is removed
Part 2: (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.3
Business Scenario 3 - Add new meter
File
Field
Notes
Part 1: Create the New Meter Asset (OPTIONAL)
Asset (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“SDP”
Universal SDP ID
This is the Universal SDP ID that was assigned to the SDP ID
SDP ID
This is the SDP ID that resides in the LDC’s system of record
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
“Y” or “N”, depending if the service is connected to the SDP or not
Load Status
“Y” or “N”, depending if there is load connected to the meter or not
Record Indicator
“Meter”
Meter ID
This is the meter ID of the meter being installed
Type
This indicates whether this is a physical or virtual meter.
Notes NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect.
Relationship (OPTIONAL)
Parameter (Mandatory if Scheduled “PUSH” is used for Billing Quantities)
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Relationship”
Object 1
The SDP ID that the meter is being added to
Relationship Identifier 1
“SDP”
Object 2
This is the AMI Operator for the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Parameter
UDC ID
This is the Universal SDP ID that the Billing Cycle will be associated to
Param Name
“Billing Cycle ID”
Param Value
This is the Billing Cycle ID for the Universal SDP ID
Start Date Time
This is the inclusive start date/time of the Billing Cycle ID parameter
End Date Time
This field must be null
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.4
Business Scenario 4 - Service Cut at Pole
File
Field
Notes
Part 1 Asset (This is a required element.)
Record Indicator
“SDP”
Universal SDP
This is the Universal SDP ID associated with the SDP where the meter was cut at the pole
SDP ID
The is the SDP ID associated with the SDP where the meter was cut at the pole
Type
“P”
Service Status
“N”
Load Status
This will be either “Y” or “N”, which ever status is currently true for the SDP.
Part 2: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
This is the Universal SDP ID associated with the SDP where the meter was booted
SDP ID
The is the SDP ID associated with the SDP where the meter was booted
Type
“P”
Service Status
This will be either “Y” or “N”, which ever status is currently true for the SDP.
Load Status
“N”
Part 2: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.6
Business Scenario 6 - Framing Structure Change
File
Field
Notes
Part 1: End the existing Framing Structure Service Agreement (This is a required element.)
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the existing Framing Structure ID
Universal SDP ID
This is the Universal SDP ID associated with the existing Framing Structure
Universal SDP ID to Framing Structure Relationship Start Date
This is the inclusive start date/time of the existing Framing Structure
Universal SDP ID to Framing Structure Relationship End Date
This is the exclusive end date/time of the existing Framing Structure
Part 2: Start the new Framing Structure Service Agreement (This is a required element.)
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)
Version 3.3 – July 7, 2011
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the new Framing Structure ID
Universal SDP ID
This is the Universal SDP ID to be associated with the new Framing Structure
Universal SDP ID to Framing Structure Relationship Start Date
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
Universal SDP ID to Framing Structure Relationship End Date
This field must be null
Record Indicator
“Relationship”
Object 1
The Universal SDP ID that the meter is being added to
Relationship Identifier 1
“SDP”
Object 2
This is the Account ID that is associated with the Universal SDP ID
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
Part 3: If the Framing Structure Change also results in a change of the Energy Service Provider then end the existing relationship between the SDP and the existing Energy Service Provider (Retailer). Start the new relationship between the SDP and the new Energy Service Provider. This is only necessary if the Energy Service Provider must be changed on the SDP Relationship (OPTIONAL)
Relationship (OPTIONAL)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the Energy Service Provider is associated to
Relationship Identifier 1
“SDP”
Object 2
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.
Relationship Identifier 2
“ENERGY SERVICE PROVIDER”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This is the exclusive end date/time of the relationship
Record Indicator
“Relationship
Object 1
This is the Universal SDP ID that the Energy Service Provider is associated to
Relationship Identifier 1
“SDP”
Object 2
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.
Relationship Identifier 2
“ENERGY SERVICE PROVIDER”
Start Date Time
This is the inclusive start date of the relationship
End Date Time
This field must be null
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.7
Business Scenario 7 - Billing Cycle ID Change
File
Field
Notes
Part 1: End the existing Billing Cycle Parameter (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the Billing Cycle is associated to
This is the inclusive start date/time of the existing Billing Cycle ID parameter
End Date Time
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
“Parameter”
UDC ID
This is the Universal SDP ID that the Billing Cycle will be associated to
Param Name
“Billing Cycle ID”
Param Value
This is the new Billing Cycle ID
Start Date Time
This is the inclusive start date/time of the new Billing Cycle ID parameter
End Date Time
This field must be null
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.8
Business Scenario 8 - VEE Service Change
File
Field
Notes
Part 1: End the existing VEE Service Parameter (This is a required element.)
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the VEE Service is associated to
Param Name
“VEE Service”
Param Value
This is the existing VEE Service
Start Date Time
This is the inclusive start date/time of the existing VEE Service parameter
End Date Time
This is the exclusive end date/time of the existing VEE Service parameter
Part 2: Start the new VEE Service Parameter (This is a required element.)
Asset (OPTIONAL)
Version 3.3 – July 7, 2011
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the VEE Service will be associated to
Param Name
“VEE Service”
Param Value
This is the new VEE Service
Start Date Time
This is the inclusive start date/time of the new VEE Service parameter
End Date Time
This field must be null
Record Indicator
“SDP”
Universal SDP ID
This is the Universal SDP ID that was assigned to the SDP ID
SDP ID
This is the SDP ID that resides in the LDC’s system of record
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
“Y” or “N”, depending if the service is connected to the SDP or not
This indicates whether this is a physical or virtual meter.
Interval Length
This is the Interval Length of the existing Meter
Channel Configuration Set
This identifies the set of information channels related to the existing Meter.
Scaling Constant
This is the Scaling Constant for the existing meter.
Record Indicator
“Relationship”
Object 1
The Universal SDP ID that the meter is being added to
Relationship Identifier 1
“SDP”
Object 2
This is the Meter ID that is installed
Relationship Identifier 2
“METER”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Relationship”
Object 1
The Universal SDP ID that the meter is being added to
Relationship Identifier 1
“SDP”
Object 2
This is the Account ID that is associated with the Universal SDP ID
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
connected to the meter or not
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)
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.9
Business Scenario 9 - CT/PT Multiplier Change
File
Field
Notes
Part 1: End the existing CT/PT Multiplier Parameter (This is a required element.)
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the CT/PT multiplier is associated to
Param Name
“CT/PT Multiplier”
Param Value
This is the existing CT/PT multiplier
Start Date Time
This is the inclusive start date/time of the SDP to CT/PT Multiplier relationship
End Date Time
This is the exclusive end date/time of the SDP to CT/PT Multiplier relationship
Part 2: Start the new CT/PT Multiplier Parameter (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Parameter”
UDC ID
This is the Universal SDP ID that the CT/PT multiplier will be associated to
This is the inclusive start date/time of the CTPT relationship
End Date Time
This field must be null
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.10
Business Scenario 10 - Account Change
File
Field
Notes
Part 1: End relationship between the SDP and the existing Account Relationship (This is a required element.)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the existing account is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the Account ID that is currently associated to the SDP
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This is the exclusive end date/time of the relationship
Part 2: Start relationship between the SDP and the new Account Relationship (This is a required element.)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new account is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the new Account ID that is to be associated to the SDP
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
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)
Version 3.3 – July 7, 2011
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the existing Energy Service Provider is associated to
Relationship Identifier 1
“SDP”
Object 2
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.
This is the inclusive start date/time of the SDP to Energy Service Provider relationship
End Date Time
This is the exclusive end date/time of the SDP to Energy Service Provider relationship
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the Energy Service Provider is associated to
Relationship Identifier 1
“SDP”
Object 2
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.
Relationship Identifier 2
“ENERGY SERVICE PROVIDER”
Start Date Time
This is the inclusive start date/time of the SDP to Energy Service Provider relationship
End Date Time
This field must be null
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the Framing Structure ID.
Universal SDP ID
This is the Universal SDP ID associated with the Framing Structure
Universal SDP ID to Framing Structure Relationship Start Date
This is the inclusive start date/time of the relationship
Universal SDP ID to Framing Structure Relationship End Date
This field must be null
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.11
File
Business Scenario 11 - Billing Agent Change
Field
Notes
Part 1: End relationship between the SDP and the existing Billing Agent Asset (OPTIONAL)
Version 3.3 – July 7, 2011
Record Indicator
“SDP”
Universal SDP
This is the Universal SDP ID associated with the SDP where the Billing Agent change is taking place
SDP ID
This is the SDP ID associated with the SDP where the Billing Agent change is taking place
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
This is whatever Service Status is associated with the SDP
Notes This is whatever Load Status is associated with the SDP
Record Indicator
“Meter”
Meter ID
This is the meter ID of the existing meter
Type
“P” or “V”, depending on whether the Meter is Physical or Virtual
Interval Length
This is the Interval Length of the existing meter
Channel Configuration Set
This identifies the set of information channels associated with the existing meter.
Scaling Constant
This is the Scaling Constant for the existing meter
Asset (only applicable to Communication Modules related to Physical Meters) (OPTIONAL)
Record Indicator
“Communication Module”
AMCD ID
This is the AMCD ID
AMCC Type
This is the AMCC Type that is associated with the AMCD ID
Relationship (This is a required element.)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the existing Billing Agent is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the Billing Agent’s 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.
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This is the exclusive end date/time of the relationship
Part 2: Start relationship between the SDP and the new Billing Agent Relationship (This is a required element.)
Relationship (OPTIONAL)
Version 3.3 – July 7, 2011
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new Billing Agent is being associated to
Relationship Identifier 1
“SDP”
Object 2
This is the new Billing Agent’s 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.
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field must be null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the AMI Operator is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the existing AMI Operator’s Organization ID that is associated to the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
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)
Relationship (only applicable to Communication Modules related to Physical Meters) (OPTIONAL)
Field
Notes
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time of the existing AMI Operator relationship
End Date Time
This field must be null
Record Indicator
“Relationship”
Object 1
The Universal SDP ID that the meter is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the existing Meter ID that is associated to the SDP
Relationship Identifier 2
“METER”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new Billing Agent is being associated to
Relationship Identifier 1
“SDP”
Object 2
This is the Account ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Relationship”
Object 1
This is the Meter ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to
Relationship Identifier 1
“METER”
Object 2
This is the AMCD ID that is currently associated with the Meter ID that is currently associated with the Universal SDP ID that the new Billing Agent is being associated to
Relationship Identifier 2
“COMMUNICATION MODULE”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.1 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Part 1: End relationship between the SDP and the existing AMI Operator Asset (OPTIONAL)
Record Indicator
“SDP”
Universal SDP
This is the Universal SDP ID associated with the SDP where the AMI Operator change is taking place
SDP ID
This is the SDP ID associated with the SDP where the AMI Operator change is taking place
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
This is whatever Service Status is associated with the SDP
Load Status
This is whatever Load Status is associated with the SDP
Record Indicator
“Meter”
Meter ID
This is the Meter ID associated with the SDP where the AMI Operator change is taking place
Type
“P” or “V”, depending on whether the Meter is Physical or Virtual
Interval Length
This is the Interval Length of the existing meter
Channel Configuration Set
This identifies the set of information channels associated with the existing meter.
Scaling Constant
This is the Scaling Constant for the existing meter
Asset (only applicable to Communication Modules related to Physical Meters) (OPTIONAL)
Record Indicator
“COMMUNICATION MODULE”
AMCD ID
This is the AMCD ID
AMCC Type
This is the AMCC Type that is associated with the AMCD ID
Relationship (This is a required element.)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the existing AMI Operator is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the AMI Operator’s 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.
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This is the exclusive end date/time of the relationship
Asset (OPTIONAL)
Part 2: Start relationship between the SDP and the new AMI Operator Relationship (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new AMI Operator is being associated to
Relationship Identifier 1
“SDP”
Object 2
This is the new AMI Operator’s Organization ID that is to be associated to
Notes the SDP. NOTE: Either the LDC Org ID or its AMI Operator Org ID must be in-effect.
Relationship (OPTIONAL)
Relationship (OPTIONAL)
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)
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field must be null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the Billing Agent is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the existing Billing Agent’s Organization ID that is associated to the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect.
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time of the existing Billing Agent relationship
End Date Time
This field must be null
Record Indicator
“Relationship”
Object 1
The Universal SDP ID that the meter is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the existing Meter ID that is installed
Relationship Identifier 2
“METER”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new AMI Operator is being associated to
Relationship Identifier 1
“SDP”
Object 2
This is the Account ID that is associated with the Universal SDP ID the new AMI Operator is being associated to
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This field is left null
Relationship (only applicable to Communication Modules related to Physical Meters)
Record Indicator
“Relationship”
Object 1
This is the existing Meter ID that is installed
Relationship Identifier 1
“METER”
(OPTIONAL)
Object 2
This is the existing AMCD ID that is installed
Relationship Identifier 2
“COMMUNICATION MODULE”
Start Date Time
This is the inclusive start date/time of the relationship
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.13
Business Scenario 13 – Energy Service Provider (Retailer) Change
File
Field
Notes
Part 1: End relationship between the SDP and the existing Energy Service Provider Relationship (This is a required element.)
Service Agreement (only end the existing Framing Structure if Framing Structure is changing when the Energy Service Provider relationship is changing) (OPTIONAL)
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the existing Energy Service Provider is associated to
Relationship Identifier 1
“SDP”
Object 2
This is the Energy Service Provider’s 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.
Relationship Identifier 2
“ENERGY SERVICE PROVIDER”
Start Date Time
This is the inclusive start date/time of the relationship
End Date Time
This is the exclusive end date/time of the relationship
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the existing Framing Structure ID
Universal SDP ID
This is the Universal SDP ID associated with the Framing Structure
Universal SDP ID to Framing Structure Relationship Start Date
This is the inclusive start date/time of the relationship
Universal SDP ID to Framing Structure Relationship End Date
This is the exclusive end date/time of the relationship
Part 2: Start relationship between the SDP and the new Energy Service Provider Relationship (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that the new Energy Service Provider is being associated to
Relationship Identifier 1
“SDP”
Object 2
This is the new Energy Service Provider’s 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.
This is the inclusive start date/time of the new SDP to Energy Service Provider relationship
End Date Time
This field must be null
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the Framing Structure ID associated with the SDP that the new Energy Service Provider is being associated with. If the Framing Structure was not ended in the previous step, then this will be the existing Framing Structure ID and it’s Start Date will be it’s existing start date/time. If the Framing Structure was ended in the previous step, then this is the new Framing Structure ID and the Start Date will be the new start date/time.
Universal SDP ID
This is the Universal SDP ID that the Framing Structure will be associated with
Universal SDP ID to Framing Structure Relationship Start Date
This is the inclusive start date/time of the relationship
Universal SDP ID to Framing Structure Relationship End Date
This field must be null
Part 3: (OPTIONAL) Provide any or no other element of the existing SDP definition – see Table 2.3.14 (Providing all elements that define the existing SDP is the choice of the organization sending the I-Sync file set.)
Table 2.3.14 Business Scenario 14 – Provide all elements that define an SDP in order to either: Create a New SDP; OR Provide the definition of an existing SDP.
File
Field
Notes
Part 1: Provide Assets: SDP, Meter and Communication Module Asset (This is a required element.)
Asset (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“SDP”
Universal SDP ID
This is the Universal SDP ID that was assigned to the SDP ID
SDP ID
This is the SDP ID that resides in the LDC’s system of record
Type
“P” or “V”, depending on whether the SDP is Physical or Virtual
Service Status
“Y” or “N”, depending if the service is connected to the SDP or not
Load Status
“Y” or “N”, depending if there is load connected to the meter or not
Record Indicator
“Meter”
Meter ID
This is the meter ID of the new or existing meter associated with the Universal SDP ID being provided under this scenario
Type
“P” or “V”, depending on whether the Meter is Physical or Virtual
Interval Length
This is the Interval Length of the new or existing meter
Channel Configuration Set
This identifies the set of information channels associated with the new or existing meter. Optional – defaults to ‘01’ – kWh related channels only.
This is the inclusive start date/time for the number of Dials associated with this new or existing Meter
End Date Time
This must be null
Part 4: Provide Framing Structure for new or existing SDPs Service Agreement (This is a required element.)
Record Indicator
“Service Agreement”
Commodity
“E”
Framing Structure ID
This is the Framing Structure that will be associated with the SDP
Universal SDP ID
This is the Universal SDP ID that the Framing Structure will be associated with
Universal SDP ID to Framing Structure Relationship Start Date
This is the inclusive start date/time for the new or existing Framing Structure
Universal SDP ID to Framing Structure Relationship End Date
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.)
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.
Relationship (only applicable to Communication Modules related to Physical Meters) (This is a required element.)
Version 3.3 – July 7, 2011
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that will be associated with the new or existing meter
Relationship Identifier 1
“SDP”
Object 2
This is the new or existing Meter ID that will be associated with the SDP
Relationship Identifier 2
“METER”
Start Date Time
This is the inclusive start date/time for the new or existing relationship
End Date Time
This must be null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that will be associated with the new or existing account
Relationship Identifier 1
“SDP”
Object 2
This is the new or existing Account ID, or other value that the LDC determines will be associated with the SDP
Relationship Identifier 2
“ACCOUNT”
Start Date Time
This is the inclusive start date/time for the new or existing relationship
End Date Time
This must be null
Record Indicator
“Relationship”
Object 1
This is the Meter ID that will be associated with the Communications Module
Relationship Identifier 1
“METER”
Object 2
This is the AMCD ID that will be associated with the new or existing Meter
Relationship Identifier 2
“COMMUNICATION MODULE”
Start Date Time
This is the inclusive start date/time for the new or existing relationship
This is the Universal SDP ID that will be associated with the new or existing Billing Agent
Relationship Identifier 1
“SDP”
Object 2
This is the Billing Agent Organization ID that will be associated with the SDP. NOTE: Either the LDC Org ID or its Billing Agent Org ID must be in-effect.
Relationship Identifier 2
“BILLING AGENT”
Start Date Time
This is the inclusive start date/time for the new or existing relationship
End Date Time
This must be null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that will be associated with the new or existing AMI Operator
Relationship Identifier 1
“SDP”
Object 2
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.
Relationship Identifier 2
“AMI OPERATOR”
Start Date Time
This is the inclusive start date/time for the new or existing relationship
End Date Time
This must be null
Record Indicator
“Relationship”
Object 1
This is the Universal SDP ID that will be associated with the new or existing Energy Service Provider
Relationship Identifier 1
“SDP”
Object 2
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.
Relationship Identifier 2
“ENERGY SERVICE PROVIDER”
Start Date Time
This is the inclusive stat date/time for the new or existing relationship
End Date Time
This must be null
(OPTIONAL)
Part 6: Create new or provide existing Component SDP related elements of Virtual SDPs Channel to Channel Relationship (Only applicable to Virtual SDPs.)
Version 3.3 – July 7, 2011
Record Indicator
“Channel to Channel”
Parent Universal SDP ID
This is the Parent Universal SDP ID associated with the contributing Member Universal SDP ID below.
Parent Unit of Measurement
This is the unit of measurement for the Parent of the Channel to Channel
Notes Relationship. The Parent is always a Virtual Interval Channel.
Channel to Formula Relationship (Only applicable to Virtual SDPs.)
Version 3.3 – July 7, 2011
Parent Interval Length
This is the interval length for the Parent of the Channel to Channel Relationship. The Parent is always a Virtual Interval Channel.
Member Universal SDP ID
The contributing Member of the Channel to Channel Relationship can be either a Physical Interval Channel which can exist on a physical SDP or a Virtual Interval Channel existing on a Physical SDP or Virtual SDP depending on the specified Meter Asset – “Channel Configuration Set”.
Member Unit of Measurement
This is the unit of measurement for the contributing Member of the Channel to Channel Relationship.
Member Interval Length
This is the interval length for the contributing Member of the Channel to Channel Relationship. The contributing Member can be a Physical Interval Channel or a Virtual Interval Channel.
Member Alias
This is a symbolic name for the contributing Member of the Channel to Channel Relationship. The Alias is used in the “Formula Expression” provided in the related “Channel to Formula” record.
Channel to Channel Relationship Start Date
This is the inclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship starts.
Channel to Channel Relationship End Date
This is the exclusive date/time for which the Parent Interval Channel to contributing Member Interval Channel relationship ends.
Record Indicator
“Channel to Formula”
Parent Universal SDP ID
This is the Parent Universal SDP ID associated with the Parent Interval information channel.
Parent Unit of Measurement
This is the unit of measurement for the Parent of the Channel to Formula Relationship. The Parent is always a Virtual Interval Channel.
Parent Interval Length
This is the interval length for the Parent of the Channel to Formula Relationship. The Parent is always a Virtual Interval Channel.
Formula Type
This field identifies the type of calculation to be performed with the result stored in the identified Parent Interval Information Channel.
Channel to Formula Relationship Start Date
This is the inclusive date/time for which the Parent Interval Channel to Formula relationship starts.
Channel to Channel Relationship End Date
This is the exclusive date/time for which the Parent Interval Channel to Formula relationship ends.
Formula Expression
This is the Formula Expression that will be evaluated when the Formula Type is specified as ‘Expression’.
Billing Service Standard Interface - Request Note: This new Billing Service Standard Interface Request will replace the existing Billing Quantity Request and will be developed and deployed to support the MDM/R Universal Solution for verification and reconciliation of billing quantities based on Measurement Canada approved meter registrations.
2.4.1
Description The EnergyIP Billing Service Standard Interface is used to retrieve Billing Quantity data for an SDP for a specific time span. Using this interface an LDC or its Billing Agent can schedule an on-cycle billing request, schedule an off-cycle billing request, retrieve billing determinants for billing purposes or for information only. The MDM/R supports two methods for preparing Billing Quantity data to send to LDCs or their billing agents. An LDC or its billing agent may choose to use one or the other method based on operational requirements: §
Request-Response Billing Data Service (request-response) method delivers Billing Quantity data in response to a request from the LDC or its billing agent using this EnergyIP Billing Service Standard Interface RequestMessage. This method is used for requesting Billing Quantity data for both on-cycle and off-cycle billing.
§
Scheduled Billing Data Service (PUSH) method, which provides the Billing Quantity data automatically based on a billing cycle attribute attached to the SDP. This method can be used for scheduled billing cycles only where the SDP data required to properly prepare the billing quantities has been synchronized by the LDC or its billing agent with the MDM/R. The EnergyIP Billing Service Standard Interface RequestMessage is not required to be used by this method.
2.4.2
Integration
2.4.2.1
File Direction
LDC or their Billing Agent to the MDM/R 2.4.2.2
Characteristics
This is a batch process involving the transfer and processing of the EnergyIP Billing Service Standard Interface RequestMessage files in an .xml file format using the EnergyIP BillingXmlFileImportAdaptor.
2.4.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
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 (if specified) and 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 and the Request 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 in the RequestMessage / Request. In this case the for the request will equal the date and time of the 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 and the billing service properties. •
The Request 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 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 within which a register reading is valid for billing quantity processing.
5. For each request the Execution Window is determined by the Request and the following combinations of the billing service properties and the RequestMessage processStartDate and processEndDate. i. The Request sets the Execution Window start date and time. The Execution Window end date and time is set by the Request 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 and Request as follows: ii. The Request 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 without a , the end date and time of the Execution Window is the Request plus the LatestReportDays (for on-cycle requests) or the OffCycleLatestReportDays (for off-cycle requests). iii. If the Request and 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 and the end date and time of the Execution Window is the Request . When both Request and 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 and the following combinations of the billing service properties and the Request and . i. The start date and time for the billing exception process is set by the Request 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 and as follows: ii. The Request 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 without a , the start date and time of the billing exception handling process is the Request plus the TriggerAfterDaysDays (for on-cycle requests) or the OffCycleTriggerAfterDays (for off-cycle requests). iii. When the Request and is specified by the LDC (or its Billing Agent) the date time for the Request must be greater than the date and time of the Request plus the TriggerAfterDays (for on-cycle requests) or the Request plus the OffCycleTriggerAfterDays (for off-cycle requests). The billing exception handling process will not initiate if the Request is less than the Request plus the TriggerAfterDays (for on-cycle requests) or the Request 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
submitted at a time later than the end date/time of the Execution Window as determined by the Request plus the LatestReportDays (for on-cycle requests) or by the Request 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 . i. To provide a non-zero Execution Window the Request must be specified by the LDC (or its Billing Agent) at a date/time later than the RequestMessage / Header 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 and the in accordance with Business Rule 5.iii. ii. To provide billing exception handling the Request must be specified by the LDC (or its Billing Agent) at a date/time later than the RequestMessage / Header 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 and the 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 . f.
EnergyIP detects exceptions when the billing quantity Request or malformed or is an invalid date.
g. EnergyIP detects exceptions when the Request 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
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.
10. 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).
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:
2.4.5
§
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.
Post-conditions The following outcome results from the file being processed through the interface:
2.4.6
§
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.
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 and Timing 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
File Name Record for the Billing Service RequestMessage 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.4.1
FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.5500.00.20070214221345.DAT 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: • • • • • •
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 element to accommodate one or many requests in a single Billing Quantity request file. The XML
version and character encoding declaration and element should immediately follow the File Name Record. Data Type/ Length
Format
Required
Description
Y
XML declaration. Defines the XML version and the character encoding used in the document.
For namespace binding ‘DefaultAttName’ = “xmlns” use:
Y
Defines the opening of a request file consisting of one or multiple billing requests.
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
REQUEST MESSAGE HEADER – RequestMessage/Header Data Type/ Length
Format
Required
Description
The records are organized into repeating blocks for each requested Billing Period for each Universal SDP ID in the Billing Service Standard Interface Request file.
Y
Defines the request message element for each billing request for a single Universal SDP ID.
String
Specific Usage: “create”
Y
Must be set to the literal “create”.
String
Specific Usage” One of: “ReadsForBilling” or “ReadsForBillingInform ational”
Y
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
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.
String
Specific Usage: “2”
Y
Revision level of message type. The version of the request message xml. Must be set to “2”.
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”
N
The date/time when the request was initiated in EST
Varchar (100)
Specific Usage: Must always be “Billing_Import_Adapte r_IESO”
Y
This value will be populated in the ‘LAST_UPD_BY’ field of ‘billing_request’ table. = “Billing_Import_Adapter_IESO” will enable the SDP to Billing Agent Relationship validation.
Varchar (30)
General: AAAAAAAAAAA
N
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.
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
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’.
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Y
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.
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
N
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 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.
Varchar (30)
General : AAAAAAAA
N
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.
Varchar (30)
General : AAAAAAAA Specific Usage: “SDP_X_UNIVERSAL _ID”
Y
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 . “SDP_X_UNIVERSAL_ID” will always be used
Char (8)
AAAAAAAA Example: ORG12345
Y
The organization identifier assigned to the LDC during the MDM/R Registration/Enrolment process. Value that uniquely identifies the . Value must be the ORG_ID assigned to the LDC that owns the SDP.
Specific usage Only for off-cycle requests: “true”
N
If set to true, indicates the request is an off-cycle request. For off-cycle requests the attribute value must be “true”. For on-cycle requests the attribute may be set to “false” or the attribute may be omitted i.e. not be present.
Char (8)
General: AAAAAAAAA Example: ORG12345
Y
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.
Char (30)
General : AAAAAAAA Example : ORG83462
Y
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 LDC’s Organization Identifier must be placed in this field. The value is validated against the in-effect SDP to Billing Agent Relationship. If this validation fails the ReplyMessage will be returned with the Header/ = “8” and Reply/ = the Request/ with no billing quantity values.
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”
N
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 must be specified in accordance with Section 2.4.3, Business Rule #7 for retroactive billing requests if billing exception handling is required.
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|-
N
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.
Defines the closing of a request file consisting of one or multiple billing requests.
]TZH:TZM] Example: “2008-04-31T12:00:0005:00”
Table 2.4.5
INPUT FILE MESSAGES ELEMENT Data Type/ Length
Format
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. ORG12345.ORG12345.5500.00.20100819233017.DATcreateReadsForBilling22010-08-20T09:30:15-05:00Billing_Import_Adapter_IESO68882812010-05-14T00:00:00-05:002010-07-01T00:00:00-05:00123456 SDP_X_UNIVERSAL_IDORG1234512345678trueORG12345ORG123452010-08-20T11:00:00-05:002010-08-20T11:30:00-05:00create Version 3.3 – July 7, 2011
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
Integration
2.5.2.1
File Direction
MDM/R to the LDC or Billing Agent 2.5.2.2
Characteristics
This is a batch process involving the transfer and processing of the EnergyIP Billing Service Standard Interface ReplyMessage files in an .xml file format using the EnergyIP BillingXmlFileExportAdaptor.
2.5.3
Business Rules 1. Billing Quantity data are computed based on the and 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).
a. The Billing Service Standard XML Interface will support a Request or 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 and 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.
i. A minimum one-interval gap in time must exist between the of the removed meter request and 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 for the removed meter and at the request 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.
Pre-conditions The following must exist for the input file to be processed through the interface:
2.5.5
§
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.
Post-conditions The following outcome results from the file being processed through the interface:
2.5.6
§
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.
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 and Timing 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 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
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.
File Name Record for the Billing Quantity ReplyMessage 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.5.1
FILE NAME RECORD FOR THE BILLING QUANTITY REPLY MESSAGE FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.6500.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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: • • • • • •
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 element to accommodate one or many replys in a single Billing Quantity reply file. The XML version and character encoding declaration and element will immediately follow the File Name Record. Version 3.3 – July 7, 2011
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.
Y
Defines the opening of a reply file consisting of one or multiple billing requests.
The ReplyMessage portion of the EnergyIP standard billing service interface includes the three elements listed below. Refer to the diagram that follows for an XML schema view of these elements. §
Header – Contains descriptive information about the message.
§
Reply – Contains the details regarding the reply.
§
MeterReadings
Table 2.5.3
REPLY MESSAGE HEADER – ReplyMessage/Header Data Type/ Length
Format
Required
Description
The records are organized into repeating blocks for each requested Billing Period for each Universal SDP ID in the Billing Service Standard Interface Reply file.
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.
String
Specific Usage: “reply”
Y
Always will be the literal “reply.”
String
Specific Usage” One of: “ReadsForBilling” or “ReadsForBilling Informational”
Y
Main subject of message. Set to the literal “ReadsForBilling” or “ReadsForBilling Informational” if request was for information.
Description Note 1: The ReplyMessage literal “ReadsForBilling Informational” includes a ‘space’. Note 2: Billing Validation Sum Check is not performed for “ReadsForBilling Informational” requests.
String
Specific Usage: “2”
Y
Revision level of message type. The version of the reply message xml. Currently revision of the xml specification is set to “2”.
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”
N
The date/time when this response was generated in EST. Note: EnergyIP Release 7.2 does not support this attribute. The ReplyMessage / Header / dateTime is “Reserved for future use.”
Varchar (100)
Example: “ABC8642”
Y
This value is populated from the ‘LAST_UPD_BY’ field of ‘billing_request’ table. The in each reply will be populated with the ORG_ID assigned to the LDC that owns the SDP.
Required
Description
Table 2.5.4
REPLY MESSAGE – ReplyMessage/Reply
Data Type/ Length
Varchar (30)
General: AAAAAAAAAAA
N
Populated with the 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.
String
General: NN Specific usage: One of “0”, “1”, “2”, “8”, “9” “10”, “11”, “12”, “15’, “16”, “17”, “18”
Y
Populated with 0 for success and non zero for an error response. Codes and values include:
Format
Version 3.3 – July 7, 2011
· 0 – Successful read · 1 – Lookup failure, for example invalid SDP ID in the request
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. / = 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
Number (50)
Boolean
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.
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’
Version 3.3 – July 7, 2011
Specific usage For off-cycle requests: “true” For on-cycle requests: “false” For ‘ReadsForBilling Informational’ requests (both on-cycle and offcycle): “true”
Description requests: value = “P” For off-cycle and on-cycle ‘ReadsForBilling Informational’ requests: value = “I”
Varchar (30)
General : AAAAAAAA
N
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.
Char (30)
General : AAAAAAAA Example : ORG83462
Y
This is the value submitted in the RequestMessage/Request/ . 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 = “8” will be returned in the reply.
Table 2.5.5
REPLY MESSAGE – ReplyMessage/MeterReadings
Data Type/ Length
Date/Time
Date/Time
Format
Required
Description
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”
Y
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.
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Y
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
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.
Fixed Number (8)
General: NNNNNNNN Example: ‘00037483
Y
This is the Universal SDP ID. (Physical or Virtual)
String
Specific usage: ‘SDP_X_UNIVERSAL_ ID’
Y
Object ID Type. For Universal SDP ID Value = ‘SDP_X_UNIVERSAL_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).
String
Specific usage: ‘METER_X_UNIVERS AL_ID’
Y
Object ID Type. For Meter ID Value = ‘METER_X_UNIVERSAL_ID’
Y
The MDM/R Synchronization Staging Table Loader populates the Premise ID with the SDP ID on the creation of the Premise master data records.
Object ID Type. For Premise ID Value = ‘X_CLIENT_PRMSE_ID’
String
No format prescribed
N
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 record will not be present.
String
Specific usage: ‘X_UDC_ACCNT_ID’
N
Object ID Type. For CustomerAccount ID Value = ‘X_UDC_ACCNT_ID’
The reply records are organized into the following repeating blocks for TOU or Periodic billing quantities and related Start and End Register Readings
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”
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.
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”
N
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.
Number (21,6)
General: NNNNNNNNNNN.NN For example: “924.061352”
N
The quantity value related to the
String
General: AAAAAAA Specific usage: For TOU/CPP, Periodic and Demand: ‘Framer’ For Meter Reads
N
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
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’
Interfaces: One of ‘MAS’, ‘SENSUS’, ‘SmartSynch’, ‘Tantalus’, ‘Trilliant’ For estimated Register Reads: ‘eMeter’
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’
Version 3.3 – July 7, 2011
Description
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 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 value for each usage reading. To be delivered with EnergyIP Release 7.2 SP7. For CPP Billing Quantities, value is: ’KWH CPP1 Usage BC’
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 / = “ReadsForBilling Informational”. Thus codes 6 and 7 will not be present. The 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 attribute will be present for for = “KWH Usage BC” • the attribute will not be present for register readings associated with usage determinants
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
N
Demand peak time. Applicable to demand measurement only.
N
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
Version 3.3 – July 7, 2011
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
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 to produce the original billing quantity response.
Boolean
Specific usage For a no data condition: ‘true’
N
If any billing determinant (i.e. ) is not available for billing for the billing period, then = “true” for all billing determinants and the will not be present for every in the reply. The 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).
String
Specific usage: One of: ‘VAL’ ‘EST’
N
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 will be set to EST. Otherwise the = VAL. For register readings – = VAL for all register readings processed through the Meter Reads interfaces. = EST for register readings calculated by the Register Read Calculator.
Number (21,6)
General: NNNNNNNNNNN.NN For example: “14.000000” “0”
N
The total kWh quantity of estimated interval data associated with each usage reading value related to the . 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 = 0 Note: The for the = ‘KWH
Description Usage BC’ is a total of the kWh for each estimated interval, whereas the sum of Hourly values with a = EST may overstate the estimated kWh if the meter interval length is less than 60 minutes.
numEstIntervals
String
General: AAAA Example: “12”
N
(Reserved for future use.)
numIntervals
String
General: AAAA Example: “2160”
N
(Reserved for future use.)
reply records provide the response for Hourly Billing Quantities
Varchar (50)
General: AAAAAAA
N
Specific usage for Hourly: ‘KWH Interval 60 Minutes’
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’
The 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 block of the reply message. Note 2: ‘KWH Usage BC’ and associated associated with each Hourly reply will be found in the block of the reply message.
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”
N
The startTime attribute will not be present for Hourly billing quantities.
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”
N
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).
Specific usage: For Hourly billing quantities always ‘3600”
N
Interval length, in seconds, if applicable to measurement. Value will always be ‘3600’ for SDPs for which the Framing Structure is “Hourly”.
Number (21,6)
General: NNNNNNNNNNN.NN For example: “924.061352”
N
The quantity value related to the
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
N
Demand peak time. Applicable to demand measurement only.
String
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’
N
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’
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
N
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.
String
Specific usage: One of: ‘VAL’ ‘NV’ ‘EST’
N
Validation status of the interval read. For Hourly billing quantity data aggregated from interval data of interval length less than 60 minutes the 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)
String
Specific usage: One of: ‘ESA’ ‘ESB’ ‘ESC’ ‘ESD’ ‘ESE’ ‘ESF’ ‘ESG’ ‘ESZ’ ‘EDT’ ‘EDC’
N
Change method used for estimation. The attribute will be present when = EST. For Hourly billing quantity data based on interval data of interval length equal to 60 minutes the 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 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.
If any billing determinant (i.e. ) is not available for billing for the billing period, then = “true” for all billing determinants and the will not be present for every in the reply. The 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).
Boolean
Specific usage For the MDM/R always: ‘false’
N
Indicates if the interval data is locked from any further updates. = “true” if interval data is locked. = “false” if interval data is not locked.
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 / = “ReadsForBilling Informational”. Thus codes 6 and 7 will not be present. The attribute will not be present if there is not a data delivery service validation failure.
N
The 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 or coincides with the dateTime of the event or events. Valid values are:
String
AAAAAAAA Specific usage: One of: ‘6’, ‘7’
Version 3.3 – July 7, 2011
String
Specific usage, one of: ‘Price Change’ ‘Meter Installed’ ‘Meter Removed’ ‘Move Out’ ‘Move In’ ‘New Transformer Ratio’ ‘Rate Change’
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 element will be present in the first segment for values: ‘Meter Removed’ ‘Move Out’ The element will be present in the second segment for values: ‘Meter Installed’ ‘Move In’ ‘Price Change’ ‘Rate Change’ ‘Retailer Change’ ‘New Transformer Ratio’
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”
Y
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.
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Y
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
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.
String
For example: ‘1.0’
N
CT/PT Multiplier
String
For example: ‘ORG98364’
N
The value in the 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’
Y
Defines the end of a reply message element for each billing reply for a single Universal SDP ID.
Required
Description
Y
Defines the closing of a reply file consisting of one or multiple billing reply.
Table 2.5.6
OUTPUT FILE MESSAGES ELEMENT Data Type/ Length
Format
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. ORG12345.ORG12345.6500.00.20100820093117.DATreplyReadsForBilling
2ABC86426888281113090238true123456ORG123452010-05-14T00:00:00-05:002010-07-01T00:00:00-05:0012345678SDP_X_UNIVERSAL_IDMeter654321METER_X_UNIVERSAL_IDSdp12345678X_CLIENT_PRMSE_IDACCOUNT87654321X_UDC_ACCNT_ID718.693570FramerKWH Off Peak Usage BC62010-07-01T04:11:26.000-05:00EST14.654321196.545791FramerKWH On Peak Usage BC62010-07-01T04:11:26.000-05:00EST0
294.497500FramerKWH Mid Peak Usage BC62010-07-01T04:11:26.000-05:00EST7.3210001209.736861FramerKWH Usage BC62010-07-01T04:11:26.000-05:00EST21.9753212010-05-14T00:00:00-05:00294.497500TrilliantKWH RR Cum BC Start Register2010-07-01T04:11:26.000-05:00EST2010-07-01T00:00:00-05:001796.000000TrilliantKWH RR Cum BC2010-07-01T04:11:26.000-05:00EST2010-05-14T00:00:00-05:002010-07-01T00:00:00-05:001.0
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
Integration
2.6.2.1
File Direction
LDC or their Billing Agent to the MDM/R 2.6.2.2
Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files.
2.6.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.
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: §
Version 3.3 – July 7, 2011
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).
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:
2.6.5
§
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.
Post-conditions The following outcome results from the file being processed through the interface:
2.6.6
§
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.
Assumptions None
2.6.7
Frequency and Timing 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
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:
FILE NAME RECORD FOR THE BILLING QUANTITY REQUEST FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.5000.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.6.8.2
Billing Quantity Request File Header Record Table 2.6.2 BILLING QUANTITY REQUEST HEADER RECORD
Field
Data Type/Length
Format
Required
Description
Record Type Identifier
Char(2)
General: AA Specific Usage: RH
Y
To indicate that this record is “Request Header” record in the LDC or Billing Agent’s Billing Quantity Request file. Value must be: “RH”
Request File Format Version
Fixed Number(2)
General: NN Specific Usage: “00”
Y
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.
LDC Organization Identifier
Char(8)
General : AAAAAAAA Example : ORG83462
Y
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.
Data Delivery Service Organization Identifier
Char(8)
General : AAAAAAAA Example : ORG83462
Y
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 LDC’s Organization Identifier would be placed in both fields.
Request File Identifier
Varchar (30)
AAAAAAAAAAA
Y
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
Billing Quantity Request Detail Record Table 2.6.3 BILLING QUANTITY REQUEST DETAIL RECORDS
Field
Data Type/Length
Format
Required
Description
Record Type Identifier
Char(2)
General: AA Specific Usage: RD
Y
To indicate that this record is “Request Detail” record in the LDC or Billing Agent’s Billing Quantity Data Delivery Request file. Value must be: “RD”
Request Detail Identifier
Varchar(30)
AAAAAA
N
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)
Request Daily Read Period Start Date (Optional on PULL Request)
Date
yyyyMMdd
N
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.
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’
Y
The LDC/Billing Agent must provide the specific Universal SDP IDs that are to be reported on by the Billing Data Interface.
Request Type
Char(1)
General : A Specific : P,O, or S
Y
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)
Request Version Date Time
Date/Time
yyyyMMddHHmmss
N
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.
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
Integration
2.7.2.1
Direction
MDM/R to the LDC or their Billing Agent 2.7.2.2
Characteristics
This is a batch process involving the transfer of pipe (|) delimited text files.
2.7.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:
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
2.7.5
§
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.
Post-conditions The following outcome results from the file being processed through the interface:
2.7.6
§
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.
Frequency and Timing 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.
Initially, the Billing Service Global Parameters of FileIdle and MaxRecords are set to 60 seconds and 10,000 records. Based on experienced gained during initial operations of the MDM/R, these parameters may be modified to meet operational requirements. Service Levels: The Billing Quantity Response File is provided within the following timeframes, based on the Billing Service Global Parameters of AllowableReadAge of 0 calendar days and LatestReportDays of 3 business days: §
For the Scheduled Billing Service - Billing Quantity data will be provided by 21:05 through the third business day after Day N for all SDPs that have successfully completed the VEE process by 15:00 on any subsequent day through the third business day after Day N.
§
For the Request-Response Billing Service - Billing Quantity data will be provided within six hours of the timestamp of the receipt of the Billing Quantity Request for all SDPs that have successfully completed the VEE process by that time. Where the Billing Quantity Request includes Request Daily Read Period End Dates that are in the future, the Billing Quantity data will be provided within six hours of the Request Daily Read Period End Date based on the Billing Quantity process runs on the Request Daily Read Period End Date. For SDPs that complete the VEE process after the Request Daily Read Period End Date, the Billing Quantity Response will be provided on any subsequent day through the third business day after Day N (the exclusive end date for the Billing Quantity Request).
§
In both cases, Scheduled Billing Service and Request-Response Billing Service, if the process is unable to provide a Billing Quantity response by the end of the billing window (being the exclusive end date plus the LatestReport Days) then on the first run of the Billing Quantity processing after the close of the billing window a “no data available” Billing Quantity response record will be delivered for each SDP for which Billing Quantity values can not be produced.
2.7.8
File Format
2.7.8.1
TOU/CPP & Periodic Billing Quantity Response File
2.7.8.1.1 File Name Record for the TOU/CPP & Periodic Billing Quantity Response File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.7.1 FILE NAME RECORD FOR THE TOU/CPP & PERIODIC BILLING QUANTITY RESPONSE FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record Version 00 would be: ORG11111.ORG22222.6000.00.20070214221345.DAT 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
Format
Required
Description
Record Type Identifier
Char(2)
General: AA Specific Usage: HR
Y
To indicate that this record is the “Header of the Response” in the LDC or Billing Agent’s Billing Quantity Response file. Value must be: “HR”
Response File Format Version
Char(2)
AA
Y
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.
LDC Organization Identifier
Char(8)
General : AAAAAAAA Example : ORG82357
Y
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.
Data Delivery Service Organization Identifier
Char(8)
General : AAAAAAAA Example : ORG82357
Y
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.
Response File Created Date Time
Date/Time
yyyyMMddHHm mss
Y
Provides the date time when the Response File was created by the MDM/R – EnergyIP. This is not the date time of the delivery.
2.7.8.1.3 TOU/CPP & Periodic Billing Quantity Response Detail Record Table 2.7.3 TOU/CPP BILLING QUANTITY RESPONSE DETAIL RECORD
Field Record Type Identifier
Data Type / Length Char(2)
Format
Required
Description
General: AA
Y
To indicate that this record is TOU Response Detail record in the LDC or Billing Agent’s Billing Quantity Response file.
Specific Usage: TR Request File Identifier
Version 3.3 – July 7, 2011
Varchar (30)
AAAAAAAAAA
Value must be: “TR” For PULL Billing Quantities, Y if
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.
For PUSH Billing Quantities, N Request Detail Identifier
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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.
Response Daily Read Period Start Date
Date
yyyyMMdd
Y
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.
Response Daily Read Period End Date
Date
yyyyMMdd
Y
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)
Billing Cycle Identifier (for PUSH only)
Varchar(3)
AAA
N
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.
Route Identifier (for PUSH only)
Varchar(11)
AAAAAAAAAA A
N
Scheduled “PUSH” responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDC’s Organization ID+the Billing Cycle ID. Requested “PULL” responses will contain a null value in this field.
Universal SDP ID
Fixed Number (8)
NNNNNNNNNN
Y
The Universal SDP ID that is associated with the Billing Quantity.
Framing Structure
Varchar (12)
General: AAAAAAAAA
Y
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.
Y
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
Specific: TOU/CPP(EST) Or TOU/CPP(CST) Request Type
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
Y
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response.
Response Version Date Time
Date/Time
yyyyMMddHHm mss
Y
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.
Transaction Status
Fixed Number(2)
General: NN
Y
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
For EnergyIP Release 6.3 and 7.0, One of “00”, “01”, “02”, “06”, “07”, “08”, “09”, “10”, “12”, “15”, “16”, “17”, “18”
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
Version 3.3 – July 7, 2011
Varchar (15)
General: AAAAAAA
Y
Provides the Unit of Measure applicable to the Billing Quantities
Specific Usage for TOU/CPP: “KWH” Estimated Energy Consumption
Number 2 (12,2)
NNNNNNNNNN NN.NN
Description being provided in this response record. Valid values for energy: KWH
Y
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
Y
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.
Billing Quantity 1 Identifier
Varchar(9)
General: AAAAAAA
Y
To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak
Example: On Peak
Billing Quantity 1
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 2 Identifier
Varchar(9)
General: AAAAAAA
Y
To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak
Y
To hold the Billing Quantity related to the associated “Billing Quantity
Example: Mid Peak
Billing Quantity 2
Number (12,2)
NNNNNNNNNN NN.NN
2
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
To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak
Identifier” Billing Quantity 3 Identifier
Varchar(9)
Example: Off Peak
Billing Quantity 3
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 4 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Example: CPP-08.90
Billing Quantity 4
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 5 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Example : CPP-08.92
Billing Quantity 5
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 6 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Example: CPP-08.94
Billing Quantity 6
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 7 Identifier
Varchar(9)
General: AAAAAAA
Y
To identify the associated Billing Quantity. Values: On Peak Mid Peak Off Peak Or to identify the specific CPP Event
Description by its pricing. E.g. “CPP-xx.xx” where “xx.xx” would identify the CPP Event Pricing.
Billing Quantity 7
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 8 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Example: CPP-08.98
Billing Quantity 8
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 9 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Example: CPP-90.00
Billing Quantity 9
Number (12,2)
NNNNNNNNNN NN.NN
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Billing Quantity 10 Identifier
Varchar(9)
General: AAAAAAA
Y
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.
Y
To hold the Billing Quantity related to the associated “Billing Quantity Identifier”
Example: CPP-09.02
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
Billing Service Condition / Cause of Exception
EnergyIP Release
Response completed successfully
Billing Service successfully processed the Billing Quantity Request
Unable to process the request – general configuration error
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’
All
02
No data available, billing window expired.
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
All
06
Billing Validation Sum Check failed – ‘ThresholdValue’ exceeded
‘ThresholdValue’ was exceeded for the VEE Service applied to the SDP
6.3, 7.0
07
Billing Validation Sum Check skipped –
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.
6.3, 7.0
08
Billing Quantity value is not provided in the response
Requesting organization does not match active Billing Agent
6.3, 7.0
09
Invalid Billing Determinant
Billing Quantity Request placed on HOLD
6.3, 7.0
10
Missing DDS Parameter
Configuration Error - a Data Delivery Service parameter is missing
6.3, 7.0
11
Validation Failed, Data Delivery Service Hi-Low Check and Consecutive Estimation Check
(Disabled for the MDM/R)
n/a
12
Meter Gap – Events Handling
Meter not found for a segment or billing period
6.3, 7.0
13
No Dates In Data Delivery Cycles Table
(Disabled for the MDM/R)
n/a
14
Missing Route Cycle ID
(Disabled for the MDM/R)
n/a
15
Request Cancelled
Billing Quantity Request cancelled via the GUI
6.3, 7.0
16
Invalid Measurement Profile
Configuration error – § No measurement attached to the Measurement Profile, or § Measurement Profile Name is null in the Data Delivery Service
Coincident Peak Demand measurement is missing, or When using tie breaking to determine the peak demand, the coincident peak demand is missing
•
18
Reference not found for a calculated billing determinant
EnergyIP Release
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 Record Type Identifier
Data Type / Length Char(2)
Format
Required
Description
General: AA
Y
To indicate that this record is Periodic Billing Quantity Response Detail record in the LDC or Billing Agent’s Billing Quantity Data Delivery Response file. Value must be: “PR”
For PULL Billing Quantities, Y if supplied
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.
Specific Usage: PR Request File Identifier
Varchar (30)
AAAAAAAAAA
For PUSH Billing Quantities, N Request Detail Identifier
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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.
Response Daily Read Period Start Date
Date
yyyyMMdd
Y
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.
Response Daily Read Period End Date
Date
yyyyMMdd
Y
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)
Billing Cycle Identifier (for PUSH only)
Varchar(3)
AAA
N
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.
Description provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDC’s Organization ID+the Billing Cycle ID This field will contain a null value for Requested “PULL” responses.
Universal SDP ID
Fixed Number (8)
NNNNNNNNNN
Y
The Universal SDP ID that is associated with the Billing Quantity.
Framing Structure
Varchar(12)
General: AAAAAAA
Y
The Framing Structure associated with the Service Delivery Point. In this record the value should indicate “PERIODIC”
Specific Usage: PERIODIC Request Type
Char(1)
A
Y
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
Request Version Date Time
Date/Time
yyyyMMddHHm mss
For PULL Billing Quantities, Y if supplied
To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request.
For PUSH Billing Quantities, N Response Detail Identifier
Varchar (30)
AAAAAAAAAA
Y
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response.
Response Version Date Time
Date/Time
yyyyMMddHHm mss
Y
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.
Transaction Status
Fixed Number(2)
General: NN
Y
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
For EnergyIP Release 6.3, and 7.0 One of “00”, “01”, “02”, “06”, “07”, “08”, “09”, “10”, “12”, “15”, “16”, “17”, “18”
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”
Y
Provides the Unit of Measure applicable to the Billing Quantities being provided in this response record. Valid values for energy: KWH
Estimated Energy Consumption
Numeric (12,2)
NNNNNNNNNN NN.NN
Y
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’
Periodic Billing Quantity
2.7.8.2
Numeric (12,2)
NNNNNNNNNN NN.NN
Y
To hold the single Billing Quantity for the period.
Hourly Billing Quantity Response File
2.7.8.2.1 File Name Record for Hourly Billing Quantity Response
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.7.6
Field Name
Version 3.3 – July 7, 2011
FILE NAME RECORD FOR THE HOURLY BILLING QUANTITY RESPONSE FILE
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.6100.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.7.8.2.2 Hourly Billing Quantity Response File Header Record Table 2.7.7 HOURLY BILLING QUANTITY RESPONSE FILE HEADER RECORD
Field Record Type Identifier
Data Type / Length Char(2)
Format
Required
Description
General: AA
Y
To indicate that this record is the “Header of the Response” in the LDC or Billing Agent’s Billing Quantity Response file. Value must be: “HR”
Specific Usage: HR Response File Format Version
Char(2)
AA
Y
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.
LDC Organization Identifier
Char(8)
General : AAAAAAAA
Y
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.
Y
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.
Y
Provides the date time when the Response File was created by the MDM/R – EnergyIP. This is not the date time of the delivery.
Example : ORG82357
Data Delivery Service Organization Identifier
Char(8)
Response File Created Date Time
Date/Time
General : AAAAAAAA Example : ORG82357
yyyyMMddHHm mss
2.7.8.2.3 Hourly Billing Quantity Response Detail Record Table 2.7.8 HOURLY BILLING QUANTITY RESPONSE DETAIL RECORD
Billing Quantity Response Detail record in the LDC or Billing Agent’s Billing Quantity Data Delivery Response file. Value must be: “SR”
Specific Usage: SR Request File Identifier
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
Request Detail Identifier
Varchar (30)
AAAAAAAAAA
Description
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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.
Response Daily Read Period Date
Date
yyyyMMdd
Y
The Response Daily Read Period date for this specific HOURLY Billing Quantity Response Record for the requested SDP.
Billing Cycle Identifier (for PUSH only)
Varchar(3)
AAA
N
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.
Route Identifier (for PUSH only)
Varchar(11)
AAAAAAAAAAA
N
Scheduled “PUSH” responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDC’s Organization ID+the Billing Cycle ID This field will contain a null value for Requested “PULL” responses.
Universal SDP ID
Fixed Number (8)
NNNNNNNN
Y
The Universal SDP ID that is associated with the Billing Quantity.
Framing Structure
Varchar (12)
General: AAAAAA
Y
The Framing Structure associated with the Service Delivery Point. In this record the value should indicate “HOURLY”
Y
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
For PULL Billing Quantities, Y if supplied
To feedback the Request Version Date Time if provided by the LDC or Billing Agent as part of a Special OffCycle Billing Quantity Request.
Specific: HOURLY Request Type
Char(1)
General : A Specific : P, O, or S
Request Version Date Time
Date/Time
yyyyMMddHHm mss
For PUSH Billing Quantities, N Response Detail Identifier
Version 3.3 – July 7, 2011
Varchar (30)
AAAAAAAAAA
Y
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.
Transaction Status
Fixed Number(2)
General: NN
Y
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.
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”
Y
Provides the Unit of Measure applicable to the Billing Quantities being provided in this response record. Valid values for energy: KWH
Estimated Energy Consumption
Numeric (12,2)
NNNNNNNNNN NN.NN
N
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
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
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 01:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 02
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 02:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 03
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 03:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 04
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 04:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 05
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 05:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 06
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 06:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 07
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 07:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 08
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 08:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 09
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 09:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 10
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 10:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 11
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 11:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 12
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 12:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 13
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 13:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 14
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 14:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 15
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 15:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 16
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 16:00:00 EST on the
The Billing Quantity for the Hour Ending 17:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 18
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 18:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 19
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 19:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 20
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 20:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 21
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 21:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 22
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 22:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 23
Numeric (12,2)
NNNNNNNNNN NN.NN
N
The Billing Quantity for the Hour Ending 23:00:00 EST on the Response Daily Read Period Date.
Billing Quantity Hour Ending 00
Numeric (12,2)
NNNNNNNNNN NN.NN
N
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).
Description 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 2.7.10.2 Characteristics
This is a batch process involving the transfer of pipe (|) delimited text files.
2.7.11 Business Rules A) General Meter Read Data 1. The physical meters for the SDP or the meters contributing to the SDP must be delivering Meter Read data to the MDM/R to be processed as required to populate the configured interval data channels. 2. The Meter Read data from physical meters and calculated interval data for virtual channels must be complete for all intervals for all days of the billing period and the latest versions of this data must be used. i. kW calculations and the determination of Peak kW Demand related Billing Quantity data must not be performed if any of the kWh intervals within billing period has a Validation Status of “NVE”. ii. kVA calculations and the determination of Peak kVA Demand related Billing Quantity data must not be performed if any of the kVAh or kVARh intervals within billing period has a Validation Status of “NVE”. iii. Neither kWh energy nor kW or kVA demand Billing Quantity responses will be delivered if any of the related kWh, kVAh or kVARh interval data within a billing period has a Validation Status of “NVE”. 3. Intervals used in all demand calculations must be calculated from interval data within the billing period (defined as intervals with end date/times greater than the Request Daily Read Period Start Date and less than or equal to the Request Daily Read Period End Date). 4. All derived quantity and peak demand determinations, except calculation of kW77 Peak Demand, will be performed for the billing period in EST for all SDPs throughout Ontario. 5. The SDP must have a Framing Structure that specifies the framing of interval data into derived kW and kVA quantities in addition to TOU/CPP, Periodic or Hourly kWh energy quantities. The applicable Framing Structures (as specified in the Technical Interface Specifications, Section 2.2.8, Table 2.2.13) that provide such framing are listed below. For the Eastern Time Zone: § TOU/CPP 15 minute Block (EST) § TOU/CPP 60 minute Block (EST) § TOU/CPP 15 minute Rolling (EST) § TOU/CPP 60 minute Rolling (EST) § Periodic 15 minute Block (EST) § Periodic 60 minute Block (EST) § Periodic 15 minute Rolling (EST) § Periodic 60 minute Rolling (EST) § Hourly 15 minute Block (EST) § Hourly 60 minute Block (EST) § Hourly 15 minute Rolling (EST)
§ Hourly 60 minute Rolling (EST) For the Central Time Zone: § TOU/CPP 15 minute Block (CST) § TOU/CPP 60 minute Block (CST) § TOU/CPP 15 minute Rolling (CST) § TOU/CPP 60 minute Rolling (CST) § Hourly 15 minute Block (CST) § Hourly 60 minute Rolling (CST) § Hourly 15 minute Rolling (CST) § Hourly 60 minute Block (CST) § Periodic 15 minute Block (CST) § Periodic 60 minute Block (CST) § Periodic 15 minute Rolling (CST) § Periodic 60 minute Rolling (CST) 6. Meter Read data or calculated data for the kWh or kVAh interval channels must have been framed (according to the rules associated with the Framing Structure for the SDP for the billing period) into the appropriate derived kW or kVA quantities before the determination of the kW or kVA Demand related Billing Quantities. 7. Derived kW and kVA quantities will not be stored. Underlying versions of kWh, kVAh and kVARh interval data will support Billing Quantity version traceability. B) kW Demand Determinations The following MMD master data condition must exist for the calculation of kW demand quantities: The SDP must have a physical or virtual meter configured with a Channel Configuration Set that supports the derivation of kW demand quantities. These would be Channel Configuration Sets as specified in the Technical Interface Specifications, Section 2.2.10, Table 2.2.28 – specifically, one of: § ‘01’ – Physical Meter, Physical Channels (establishing Interval Channels for Physical kWh), or § ‘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
§ ‘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
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).
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.
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.
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 SDP’s assigned a “Framing Structure ID” code ‘05’ through ‘28’ in the synchronization process. 2.7.16.1.1 File Name Record for Demand Billing Quantity Response
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.7.9
FILE NAME RECORD FOR THE DEMAND BILLING QUANTITY RESPONSE FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.6200.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number.
2.7.16.1.2 Demand Billing Quantity Response File Header Record Table 2.7.10 DEMAND BILLING QUANTITY RESPONSE FILE HEADER RECORD
Data Type / Length
Field Record Type Identifier
Char(2)
Format
Required
Description
General: AA
Y
To indicate that this record is the “Header of the Response” in the LDC or Billing Agent’s Billing Quantity Response file. Value must be: “HR”
Specific Usage: HR Response File Format Version
Char(2)
AA
Y
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.
LDC Organization Identifier
Char(8)
General : AAAAAAAA
Y
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.
Y
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.
Y
Provides the date time when the Response File was created by the MDM/R – EnergyIP. This is not the date time of the delivery.
Example : ORG82357
Data Delivery Service Organization Identifier
Char(8)
Response File Created Date Time
Date/Time
General : AAAAAAAA Example : ORG82357
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
Format
Required
Description
Record Type Identifier
Char(2)
General: AA Specific Usage: DR
Y
To indicate that this record is Demand related Detail record in the LDC or Billing Agent’s Billing Quantity Response file. Value must be: “DR”
Request File Identifier
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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.
Request Detail Identifier
Varchar (30)
AAAAAAAAAA
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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.
Response Daily Read Period Start Date
Date
yyyyMMdd
Y
The first Daily Read Period date included in the demand related Billing Quantity Response Record for the
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.
Response Daily Read Period End Date
Date
yyyyMMdd
Y
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)
Billing Cycle Identifier (for PUSH only)
Varchar(3)
AAA
N
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.
Route Identifier (for PUSH only)
Varchar(11)
AAAAAAAAAAA
N
Scheduled “PUSH” responses will provide the Route Identifier associated with the SDP in the MMD. This value will be equal to the LDC’s Organization ID+the Billing Cycle ID. Requested “PULL” responses will contain a null value in this field.
Universal SDP ID
Fixed Number (8)
NNNNNNNNNN
Y
The Universal SDP ID that is associated with the Billing Quantity.
Framing Structure
Varchar (12)
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
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).
‘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)’ Request Type
Char(1)
General: A Specific Usage: P, O, or S
Y
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
Request Version Date Time
Date/Time
yyyyMMddHHmmss
For PULL Billing Quantities, Y if supplied For PUSH Billing Quantities, N
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
Y
To feedback an MDM/R unique identifier that is used within MDM/R for the Billing Quantities reported in this response.
Response Version Date Time
Date/Time
yyyyMMddHHmmss
Y
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.
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”,
Y
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
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’
Y
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
Peak 1 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 1 Coincident Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
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
Y
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 2 Quantity Identifier
Varchar (10)
General: AAAAAAA Specific Usage: One of ‘Peak kW’, or ‘Peak kVA’ or ‘Peak kW77’, or ‘Peak kVA77’
Y
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
Peak 2 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 2 Coincident Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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
Description Business Rules. NOTE 3: Coincident kW quantities can only be determined if the Peak kVA Demand Quantity has been determined.
Peak 2 End Date Time
Date/Time
yyyyMMddHHmmss
Y
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 3 Quantity Identifier
Varchar (10)
General: AAAAAAA Specific Usage: One of ‘Peak kW’, or ‘Peak kVA’ or ‘Peak kW77’, or ‘Peak kVA77’
Y
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
Peak 3 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 3 Coincident Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 3 End Date Time
Date/Time
yyyyMMddHHmmss
Y
The date time of the peak kW/coincident kVA pair, or the peak kVA/coincident kW pair.
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.
Peak 4 Quantity Identifier
Varchar (10)
General: AAAAAAA Specific Usage: One of ‘Peak kW’, or ‘Peak kVA’ or ‘Peak kW77’, or ‘Peak kVA77’
Y
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
Peak 4 Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 4 Coincident Quantity
Number (12,2)
NNNNNNNNNNNN. NN
Y
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.
Peak 4 End Date Time
Date/Time
yyyyMMddHHmmss
Y
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.
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
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record Version 01 would be: ORG11111.ORG22222.6000.01.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.7.17.1.2 File Name Record: Hourly Billing Quantity Response File
An example of this record Version 01 would be: ORG11111.ORG22222.6100.01.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.7.17.1.3 File Name Record: Hourly Billing Quantity Response File
An example of this record Version 01 would be: ORG11111.ORG22222.6200.01.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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
remaining fields in this record will contain the same values as found in the header record of the file. The EOF Record will be present in each Version 01 Billing Quantity response file for the following FTS File Types: •
File ID 6000 Billing Quantity Response – TOU/CPP & Periodic
•
File ID 6100 Billing Quantity Response – Hourly
•
File ID 6200 Billing Quantity Response – Demand
Table 2.7.13 FILES
END-OF-FILE RECORD FOR VERSION 01 BILLING QUANTITY RESPONSE
Data Element
Data Type/Length
Format
Required
Comments
Record Type Identifier
Char(2)
General: AA Specific usage: ‘ER’
Y
This field indicates that this record is the last or end-of-file record of the response file. Value must be ‘ER’
Response File Format Version
Char(2)
General: AA Specific usage: ‘01’
Y
This field indicates that this record is the last or end-of-file record of the response file. Value must be ‘ER’
LDC Organization Number
Char(8)
General: AAAAAAAA Example: ‘ORG23153’
Y
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.
Data Delivery Service Organization Identifier
Char(8)
General : AAAAAAAA Example : ORG82357
Y
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.
Response File Created Date Time
Date/Time
yyyyMMddHHmmss
Y
Provides the date time when the Response File was created by the MDM/R – EnergyIP. This is not the date time of the delivery.
Sample End-Of-File Record – Version 01 Billing Quantity Response Types: 6000, 6100, 6200 ER|01|ORG70000|ORG70000|20100910150721
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/R’s functionality is not impeded if the system does not have access to the LDC’s Billing Cycle Schedule. Hence, updating the MDM/R with Billing Cycle Schedule data is optional and is only required when the Scheduled Billing Data Service is used to ‘push’ Billing Quantity data to the LDC on the appropriate bill days for each SDP, rather than using the Request-Response Billing Data Service. Only files that have passed the initial file checks will be processed by this interface. The 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
Schedule, then a single file containing both the 2007 and 2008 Billing Cycle Schedules beyond the change date would need to be submitted.) At the end of the process, the file is moved from the incoming directory to the Processed/Utility/MRSchedule directory and a message is written to the Cycle Synchronization log file which will show a message similar to the output below: INFO - No. of Billing Cycles Not found in the No Change Time Frame: 0 INFO - No. of Extra Billing Cycles Not found in the No Change Time Frame: 0 INFO - No. of Reading Cycles Not found in the No Change Time Frame: 0 INFO - No. of Extra Reading Cycles Not found in the No Change Time Frame: 0 INFO - No. of Billing Cycle Records Inserted: 62 INFO - No. of Reading Cycle Records Inserted: 37
2.8.2
Integration
2.8.2.1
Direction
LDC to the MDM/R 2.8.2.2
Characteristics
This is a batch process involving the transfer and processing of pipe (|) delimited text files. The file will contain ALL LDC billing cycles and the dates associated with them. (i.e.: only one file is required to update all billing cycles)
2.8.3 Business Rules 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 system’s standard output and written to the Cycle Synchronization log file.
A confirmation will be sent to the LDC in Report IR03, Billing Cycle Schedule Exceptions Report, indicating a successful or failed load. NOTE: In the event of a load failure, the pre-existing Billing Cycle Schedule may have been corrupted and remedial action will need to be taken by the LDC and/or its designated agents in association with the SME/OSP. As this corruption will effectively remove all future Billing Cycle dates, the OSP will retain and reinstate the most recent copy of the LDC’s Billing Cycle Schedule.
2.8.4
Pre-conditions The following must exists for the input file to be processed through the interface:
2.8.5
§
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.
Post-conditions The following outcomes result from the file being processed through the interface:
2.8.6
§
The EnergyIP calendar is populated with the LDC’s scheduled Billing Dates for generating billing quantities.
§
The LDC has received the exceptions (if any) from the MDM/R Administrator.
Assumptions None
2.8.7
Frequency and Timing 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
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:
FILE NAME RECORD FOR THE BILLING CYCLE SCHEDULE FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.8000.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.8.8.2
Billing Cycle Schedule File Table 2.8.2
BILLING CYCLE SCHEDULE FILE
Field
Data Type/Length
Format
Required
Description
Read Date
Date
DDMMYYYY
Y
This is the exclusive end date for a given billing period within a billing cycle. It represents the first date that will NOT be framed into billing quantities for SDP’s associated with this billing cycle ID. Note: The date format does not conform to the Section 1.7 date format specification.
Day of week
Varchar (3 )
General: AAA
Y
This is the 3 character abbreviation for the day of the week for the given cycle date all in caps.
Y
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 LDC’s identifier for a group of SDP’s that have the same billing period.
Description The MDM/R supports the aggregation of interval consumption data on an hourly basis for each LDC based on the Loss Factor Classifications for each SDP for a Daily Read Period date. These aggregations are provided to support LDC’s requirements for settlement in the following areas: •
Net System Load Shape Calculations; and
•
RPP Variance Account Management.
This aggregated data will be provided to the LDC as a scheduled production of a file on a daily basis.
2.9.2
Integration
2.9.2.1
Direction
MDM/R to the LDC 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)
6. Using the gathered interval consumption data (from previous step) compute the hour-by-hour aggregations for each Loss Factor Classification for each LDC. Hour-by hour aggregations will include: •
Total Aggregated Consumption including intervals with Validation Status VAL; NV; EST, and NVE
•
Validated Aggregated Consumption including intervals with Validation Status VAL (all Change Methods) and NV
•
Estimated Aggregated Consumption including intervals with EST (all Change Methods)
•
NVE Aggregated Consumption including intervals with Validation Status NVE
7. A daily Data Aggregations File is generated for each LDC for Daily Read Period date “N” will include for each of the 24 hours of the Daily Read Period: •
Aggregation Version Date Time which is the latest insert time of the interval data set used each hourly aggregation
•
Loss Factor Classification
•
The hour-by-hour aggregations specified in Item 6 above
•
The actual SDP count for each hour-by-hour aggregation
•
The actual interval count for each hour-by-hour aggregation specified in Item 6 above
•
The count of interval expected to contribute to each hour-by-hour aggregation
8. A Data Aggregations Contributors File will be created with the following detail: •
Universal SDP ID (all active Universal SDP IDs with the associated Loss Factor Classification must be listed in the report even if they don’t have a meter associated with them.)
•
Loss Factor Classification (Aggregation Classification)
•
For all Interval Consumption data related to the SDP for day “N” includes the following details for each unique SDP_Ref, Channel_Ref, Meter_Ref: a. Meter ID (associated with the Meter_Ref) b. Channel Ref c. Interval Length d. Number of intervals (number of intervals found with any validation status) e. Number of Validated Intervals (number of intervals with validation status (‘NV’ or ‘VAL’) f.
Version 3.3 – July 7, 2011
Number of Estimated Intervals (number of intervals with validation status (‘EST’)
g. Number of Needs Verification Editing Intervals (number of intervals with validation status (‘NVE’)
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. •
2.9.5
One or more SDPs with an assigned Loss Factor Classification.
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. •
2.9.6
Assumptions •
2.9.7
The Data Aggregation File and the related Data Aggregation Contributors File are retained within the MDM/R.
Only kWh interval consumptions will be included in this data aggregation process.
Frequency and Timing Frequency: The Data Aggregation process is run daily. Timing: The Data Aggregation file and the related Data Aggregation Contributors File are produced for each Daily Read Period date “N” on day “N” + 3 calendar days and sent to the LDC.
2.9.8
File Format
2.9.8.1
Data Aggregation File
2.9.8.1.1 File Name Record for the Data Aggregation File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.9.1
FILE NAME RECORD FOR THE DATA AGGREGATION FILE
Field Name
Data Type/Length
Prefix
Format
Required
Description
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system
An example of this record for Version 00 would be: ORG11111.ORG22222.9000.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.9.8.1.2 Data Aggregation File Header Record Table 2.9.2
Data Aggregation Header Record
Data Type / Length
Format
Description
Record Type Identifier
Char (1)
A
To indicate that this record is “Header” record in the Data Aggregation file.
File Format Version
Char (2)
NN
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.
LDC Organization ID
Char (8)
NNNNN
The identifier assigned to the LDC during the MDM/R Registration/Enrollment process. The LDC creates SDPs and thus owns those Service Delivery Points.
yyyyMMdd
The Daily Read Period date that is being processed through the Data Aggregation process.
Field
Value could shall be: “H”
Example: ORG82357 Daily Read Period Date
Date
This is the 24-hour period including all intervals of the hour ending 01:00:00 of the Daily Read Period date N th and extending through all intervals of the 24 hour ending 00:00:00 on date N+1 Data 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
Data Type / Length
Format
Description
Record Type Identifier
Char(1)
A
To indicate that this record is “Detail” record in the Data Aggregation file.
Aggregation Version Date Time
Date/Time
yyyyMMddHHmm ss
This is the latest insert time of the set of intervals underlying each hourly aggregation value
Loss Factor Classification
Number (2)
NN
The Loss Factor Classification is an LDC supplied attribute for physical SDPs supplied via the synchronization process.
Aggregated Consumption Hour Ending Date/Time
Date/Time
yyyyMMddHHmm ss
Total Aggregated Consumption Hour Ending HH
Numeric (12,2)
Field
Value shall be: “D”
Valid values: 01 through 12
Version 3.3 – July 7, 2011
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
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
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
SDP Count for Hour Ending HH
Number (8)
NNNNNNNN
Actual count of physical SDPs contributing to the Total Aggregated Consumption Hour Ending HH.
Total Interval Count for Hour Ending HH
Number (10)
NNNNNNNNNN
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
Valid Interval Count for Hour Ending HH
Number (10)
Estimated Interval Count for Hour Ending HH
Number (10)
NVE Interval Count for Hour Ending HH
Number (10)
NNNNNNNNNN
Actual count of intervals within hour ending HH with validation status NVE.
Expected Interval Count for Hour Ending HH
Number (10)
NNNNNNNNNN
Count of intervals expected to contribute within hour ending HH.
Version 3.3 – July 7, 2011
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.
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
For example an hourly channel is expected to contribute 1 interval; a 15 minute channel is expected to contribute 4 intervals.
2.9.8.2.1 File Name Record for the Data Aggregation Contributors File
The first record in this interface file is used to store the name of the file as specified in Section 1.8. This record is used in the event that the original file name is modified during the transfer between the MDM/R and an Organization. The first record of the interface file contains the following three elements: Table 2.9.4
FILE NAME RECORD FOR THE DATA AGGREGATION CONTRIBUTORS FILE
Field Name
Data Type/Length
Prefix
Format
Required
Description
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.9100.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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
Data Type / Length
Format
Description
Char (1)
A
To indicate that this record is “Header” record in the Data Aggregations Contributors Report file. Value shall be: “H”
File Format Version
Char (2)
NN
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.
LDC Organization Identifier
Char (8)
NNNNN
The identifier assigned to the LDC during the MDM/R Registration/Enrollment process. The LDC creates SDPs and thus owns those Service Delivery Points.
Daily Read Period Date
Date
yyyyMMdd
The date of the Daily Read Period that is being processed through the Settlement Aggregation process.
Example: ORG82357
This is the 24-hour period including all intervals of the hour ending 01:00:00 of the Daily Read Period date N th and extending through all intervals of the 24 hour ending 00:00:00 on date N+1 Data Aggregation End Date Time
Version 3.3 – July 7, 2011
Date Time
yyyyMMddH Hmmss
The date time when the Data Aggregation process and Data Aggregation Contributors Report process ended. (In EST)
2.9.8.2.3 Data Aggregation Contributors File Detail Records There will be one detailed record per SDP, Loss Factor Classification, Meter combination that contributed to the aggregations in an LDC’s Data Aggregations file for the specified Daily Read Period date. Table 2.9.6
Data Aggregation Contributors File Detail Records
Field Record Type Identifier
Data Type / Length
Format
Description
Char(1)
A
To indicate that this record is “Detail” record in the Data Aggregation Contributors Report file. Value shall be: “D”
Universal SDP ID
Number (8)
NNNNNNNN
The Ontario-wide unique identifier assigned by the Universal SDP ID Assignment Request/Response process.
Loss Factor Classification
Number (2)
NN
The Loss Factor Classification is an LDC supplied attribute for physical SDPs supplied via the synchronization process.
SDP ID
Varchar (50)
No format prescribed
Valid values: 01 through 12 This identifier is maintained in the LDC systems and uniquely identifies the SDP.
For Universal SDP IDs with an associated Loss Factor Classification and No associated meter the following fields will be empty. Meter ID
Varchar (50)
No format prescribed
This is an identifier of the installed meter that was supplied by the LDC and must be unique within an LDC.
Channel_Ref
Varchar (15)
NNNNNNNNNNN NNNN
This is an internal system identifier within EnergyIP for the channel associated with an SDP.
Interval Length
Number (4)
NNNN
Channel interval length in seconds
Version Date Time
Date/Time
yyyyMMddHHmm ss
This is the latest insert time of the set of intervals for this meter channel on this Daily Read Period date
Interval Count
Number (4)
NNNN
Actual count of intervals found for this meter channel on this Daily Read Period date with validation status VAL; NV; EST, or NVE. Intervals with validation status VAL will include Change Methods: NULL or VER. Intervals with validation status EST will include Change Methods: NULL; ESA: ESB; ESC; ESD; ESE; ESF; or EDT
Valid Interval 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
Version 3.3 – July 7, 2011
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)’
2.10.1 Description The purpose of this interface is to provide MDM/R users (LDCs, AMI Operators, Billing Agents, Retailers, and other Customer contracted agents) with interval consumption data and daily Billing Quantity data for a specified timeframe requested for one Universal SDP ID at a time. This interface differs from the other interfaces specified in this document in that it is not file based. The web services interface is a synchronous interface between the MDM/R and LDCs, AMI Operators, Billing Agents, Retailers or other Customer contracted agents. This interface may be used for web presentment, and is also described in Section 13.1 of the MDM/R Detailed Design Document, Web Services Interface.
2.10.2 Integration 2.10.2.1 Direction
MDM/R Users to the MDM/R MDM/R to the MDM/R Users 2.10.2.2 Characteristics
The Web Services Request is a single request in an .xml file format The Web Services Response is a single response in an .xml file format 2.10.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 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 user’s web presentment portal application must be capable of issuing multiple web services calls to gather the required range of data.
2.10.3 Business Rules 1. The LDC, AMI Operator, Billing Agent, Retailer, or other Customer Contracted Agent, is authorized to receive web services.
3
The addition of register readings is planned for deployment as part of EnergyIP Release 7.2
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
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’).
2.10.4 Pre-conditions §
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.
2.10.5 Post-conditions The following outcome will result from the file being processed through the interface: §
The requested interval consumption data or Billing Quantity data for the identified Universal SDP ID for the specified date range has been generated and delivered to the requesting LDC or Authorized Interested Party.
§
The response message contains zero data records if: – The Universal SDP ID is not recognized by the MDM/R – No data records are available between the request start time and end time. – The measurementProfile is invalid.
2.10.6 Assumptions Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MM-DDTHH:MI:SS.sss[[+|-]TZH:TZM] Date/Time fields must always be expressed in Eastern Standard Time (EST)
2.10.7 Frequency and Timing 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
Header – Contains descriptive information about the message
§
Request – Contains the details regarding the request.
Table 2.10.1
REQUEST MESSAGE ATTRIBUTES
Data Type/ Length
Format
Required
Description
XML declaration
Specific Usage:
Y
Defines the XML version and the character encoding used in the document
Y
Location of the xml name space
Specific Usage: xmlns:met =“http:/www.emeter.co m/energyip/meterreadi nterface”
Specific Usage: “get”
Y
The only value displayed under this Tag is “get”
Specific Usage” “MeterRead”
Y
The only value displayed under this Tag is “MeterRead”
Specific Usage: “1”
Y
This Tag indicates the version of the message The only value is “1”
Date/ Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Y
The date/time of the request in EST
Varchar (30)
AAAAAAAAA
N
The unique ID for the message. This will be populated as in the response if supplied in the request.
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
Version 3.3 – July 7, 2011
Date/ Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM] For example:
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
UTC – 5 (EST) would be: 1994-1105T08:15:30.00005:00 UTC would be: 1994-11-05T13:15:30Z
Version 3.3 – July 7, 2011
Date/ Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
Description
Y
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
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
N
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.
Varchar (30)
General : AAAAAAAA Specific Usage: “SDP_X_UNIVERSAL _ID”
Y
This field should be hard-coded to indicate that SDP_X_UNIVERSAL_ID will always be used
Varchar (30)
AAAAAAAA
Y
Universal SDP ID (Physical or Virtual)
Varchar (30)
General: AAAAAAAAA Specific usage: One of ‘MP01’ ‘MP02’ ‘MP03’ ‘MP04’
N
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
Varchar (30)
General: AAAAAAAAA Example: ORG12345
Y
Organization ID of the requestor. Used for authorization.
getMeterRead12007-04-10T09:30:15-05:00TXN123452007-04-01T00:00:00-05:002007-04-03T00:00:00-05:00SDP_X_UNIVERSAL_ID1234567890ORG12345 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 reply records are organized into repeating blocks for each in the reply.
Defines the XML version and the character encoding used in the document
Location of the xml name space
Specific Usage: xmlns:met=“http:/www. emeter.com/energyip/ meterreadinterface”
Specific Usage: “reply”
The value displayed under this Tag is ‘reply’
Specific Usage: “MeterRead”
The value displayed under this Tag is ‘MeterRead’
Specific Usage: “1”
This Tag indicates the version of the message The only value is “1”
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS.sss[[+|]TZH:TZM]
The date/time of the reply in EST
Date/Time
Varchar (30)
AAAAAAAAA
The unique ID for the message. This will be populated as from the request.
Varchar (2)
General: AA Specific Usage 0, 1, 2, 3, -1
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
Varchar (50)
AAAAAAAAAAAAAAA Specific Usage: One of “SUCCESS” “Sdp not found” “Request not authorized” “Invalid Request – [ ]
The text error message associated with the replyCode
The internal Siebel reference for the SDP, specifically the SDP-Ref.
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
Date Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM]
The start time and date in EST for the data within this data set. This is not provided with interval data records
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM]
End date/time in EST of the data set.
Number (10)
NNNNNNNNNN (Ex. 3600 for 1 hour interval)
Length in seconds of the data set. This field will only be populated if the readingTypeID field is populated with “KWH Interval 60 Minutes”
Number 5 (12,5)
AAAAAAAAAAAA.AA
Value reported for the period
Date/Time
Standard XML ISO8601 Date format with full timezone qualification will be used: YYYY-MMDDTHH:MI:SS[[+|]TZH:TZM]
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.
Varchar(3)
AAA
Can take the following values: NV – No Validation performed VAL – Interval has been Validated EST – Interval has been Estimated or Edited NVE – Interval requires Validation or Editing
Number(10)
NNNN
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
5
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
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’.
Char (4)
General: AAAA Specific Usage: true
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”
Char(4)
General: AAAA Specific Usage: true
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
Char(4)
General: AAAA Specific Usage: true
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”
Char(4)
General: AAAA Specific Usage: true
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”
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 codes that will be returned in the Reply message for each measurement included in the requested (in the Reply and elements) Table 2.10.3
Measurement Profiles
measurementProfile
readingTypeIds returned
readingTypeId Description
MP01
KWH Usage KWH Est Usage COUNT KWH Est Intervals KWH RR Cum
Total daily KWH consumption Total daily estimated KWH consumption Total number of estimated intervals in the day Register reading data for the period
MP02
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
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
MP03
KWH Interval 60 Minutes KWH RR Cum
Interval data for the period Register reading data for the period
MP04
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
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
Table 2.10.4 defines the integer and hex-based codes representing validation and estimation failure types that will be present in the attribute when the is not ‘VAL’. The code returned can include the addition of the listed integer values.
Interval is currently pending Watt-VAR validation.
WVP
262144
0x40000
Interval skipped Watt-VAR validation.
WVS
524288
0x80000
Class Load Profile data not found.
CLP
1048576
0x100000
EnergyIP DC_DATA_ESTIMATION flag set. Interval data estimated by external data collection system.
EDC
0x200000
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.)
AMI
2097152 4194304
0x400000
EnergyIP POWER_OFF flag set for interval.
OUT
8388608
0x800000
EnergyIP CRC_ERROR flag set for interval.
CRC
16777216
0x1000000
EnergyIP PHASE_FAILURE flag set for interval.
PHA
33554432
0x2000000
EnergyIP PARTIAL_INTERVAL flag set for interval.
PRT
67108864
0x4000000
Estimation error – could not estimate using any specified method
EER
134217728
0x8000000
Interval is part of a detected Number of Zeros validation failure.
NMZ
268435456
0x10000000
Interval failed HI-LO validation.
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.
2.11.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the Sensus AMCC Meter Read interface. This interface processes both automated AMCC interface files (i.e. those that are generated by the AMCC system) and files that may be produced by the LDC or its AMI Operator in the AMCC format but that contain either manual Meter Reads and/or updated Meter Reads. The files are processed in the order that they are received from the AMCC. All files are processed by this interface in the same manner, no matter the source of the data (i.e. automated or manual). 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.2 Integration 2.11.2.1 Direction
AMCC to the MDM/R 2.11.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data (including all initial and subsequent transmissions of meter read data) received from the AMCC shall contain: §
A register read for the end of the Meter Transfer Block
§
A series of interval data
§
Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. The Sensus implementation will include both a register read at the beginning of the first interval of the Meter Transfer Block and a register read at the end of the last interval of the Meter Transfer Block. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’ value is limited to a maximum of 48 sets of data triplets per record (see Table 2.11.2 – “Count”). This maximum establishes the longest Meter Transfer Block permissible
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.
2.11.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 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 LDC’s Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 6. Meter Reads exception reports are created: §
The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications).
§
The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R 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.
2.11.4 Pre-conditions The following must exist for the input file to be processed through the interface: §
The LDC is enrolled and has an Organization ID assigned.
§
The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File.
§
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.11.5 Post-conditions The following outcome results from the file being processed through the interface: §
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database.
§
Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing.
§
The LDC and/or its designated agent (s) receive interim and final summary and detailed exception reports as outlined in Section 2.11.3 via File Transfer Services.
2.11.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.11.7 Frequency and Timing 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
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:
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.7000.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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
Data Type/Length
Record Type
Varchar (7)
Format
Required
Description
General : AAAAAAA
Y
This field will always contain “MEPMD01”
Y
This field will contain the CMEP version date. The current version being supported is “19970819”
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
Specific Usage: ‘Sensus’ Sender Customer ID
Char (8)
General: AAAAAAAA
Y
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process.
Y
This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Y
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with.
Example: ‘ORG83729’ Receiver ID
Char (8)
General: AAAAAAAA Specific Usage The MDM/R will only recognize ‘ORG29738’
Receiver Customer ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Time Stamp
Date/Time
yyyyMMddHHmm
Y
This field Is populated with the date and time that this record was created. This time must be reported in EST
Meter ID
Varchar (50)
No format prescribed
Y
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
Purpose
Varchar (8)
General: AAAAAAAA
Y
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
Y
Describes what commodity type is being delivered “E” – Electricity “G” – Gas “W” – Water “S” - Steam
Specific Usage: The MDM/R will only recognize “OK”, “RESEND”
Commodity
Char(1)
General: A Specific Usage: The MDM/R will only recognize “E”
General: AAAAAA Specific Usage: ‘KWH’ and ‘KWHREG’,
Y
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.
‘KVAH’ and ‘KVAHREG’, ‘KVARH’ and ‘KVARHREG’
Calculation Constant
Number (1,0)
General: N Specific Usage: ‘1’
Y
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.
Interval
Time Interval
MMDDhhmm
Y
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.
Example: ‘00000100’ indicates a time interval of one hour ‘00000015’ indicates a time interval of 15 minutes
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
Example: If Units = ‘KWHREG”, Count = ‘2’ If Units = ‘KWH’, Count = ‘12’ for a transmission of 12 intervals.
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.
General: AAAAAAA (7 characters including a space at the second and fifth character position)
Y
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:
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’
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.
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
Format
Required
Description
General: NNNNNNNNNNN N.NNNNN
Y
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)
Specific: 123456789012.34
Table 2.11.3 describes the action taken by the EnergyIP application in processing the simple protocol text quality flags for interval consumption data provided for each data triplet within the Sensus CMEP file, and the setting of EnergyIP flags as applicable. The same protocol text quality flags are recognized and processed for KWH, KVARH, and KVAH interval data. Table 2.11.3
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus
Bit Value
Sensus Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
00 00
Sensus – Indicates an error free interval No EnergyIP flag is set, data will be treated as normal data
R 00 00
null
00 01
Sensus – Communication failure (meter could not be read) No EnergyIP flag is set, data will be treated as normal data
R 00 01
null
00 02
Sensus – Power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done
R 00 02
POWER_OFF
Bit 2
00 04
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
R 00 04
POWER_ON
Bit 3
00 08
Sensus – Voltage sag No EnergyIP flag is set, data will be treated as normal data
R 00 08
null
Bit 4
00 10
Sensus – Voltage swell No EnergyIP flag is set, data will be treated as normal data
R 00 10
null
Bit 5
00 20
Sensus – Missing data EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check
N 00 20
NO_DATA
Bit 6
00 40
Sensus – Daylight savings in effect No EnergyIP flag is set, data will be treated as normal data
R 00 40
null
Bit 7
00 80
Sensus – Meter was out of service No EnergyIP flag is set, data will be treated as normal data
R 00 80
null
Bit
Bit 0
Bit 1
6
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
The EnergyIP CMEP adaptor for Sensus will support the combination or addition of multiple hexadecimal data quality flags up to the 256 hexadecimal code values involving Bit 0 through Bit 7.
2.12.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the 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.2 Integration 2.12.2.1 Direction
AMCC to the MDM/R 2.12.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data (including all initial and subsequent transmissions of meter read data) received from the AMCC shall contain: §
A register read for the end of the Meter Transfer Block
§
A series of interval data
§
Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. The Sensus implementation will include both a register read at the beginning of the first interval of the Meter Transfer Block and a register read at the end of the last interval of the Meter Transfer Block. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’ value is limited to a maximum of 48 sets of data triplets per record (see Table 2.12.2 – “Count”). This maximum establishes the longest Meter Transfer Block permissible Version 3.3 – July 7, 2011
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.12.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.
2.12.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 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 LDC’s Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. d. The MDM/R detects exceptions when interval data of an unexpected interval is received from the AMCC. 6. Meter Reads exception reports are created: §
The Interim and Final AMCC Data Collection Summary Exception Reports provide a summary of all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Reports DC06 and DC16 in Sections 2.2.7 and 2.2.11 of the MDM/R Reports Technical Specifications).
§
The Interim and Final AMCC Data Collection Detailed Exception Reports list all exceptions at the meter level, encountered during the processing of the Meter Read files delivered from the AMCCs (Refer to Report DC07 and DC17 in Sections 2.2.8 and 2.2.12 of the MDM/R 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.
2.12.4 Pre-conditions The following must exist for the input file to be processed through the interface: §
The LDC is enrolled and has an Organization ID assigned.
§
The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File.
§
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.5 Post-conditions The following outcome results from the file being processed through the interface: §
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database.
§
Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing.
§
The LDC and/or its designated agent (s) receive interim and final summary and detailed exception reports as outlined in Section 2.12.3 via File Transfer Services.
2.12.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.12.7 Frequency and Timing 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.12.8 File Format 2.12.8.1 File Name Record for the Sensus2 CMEP 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:
This field contains the name of the file on the originating system, as defined in Section 1.8
Suffix
Char (8)
Specific Usage:
Y
This field always contains the record type “”
An example of this record for Version 00 would be: ORG11111.ORG22222.7001.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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
Data Type/Length
Record Type
Varchar (7)
Format
Required
Description
General : AAAAAAA
Y
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”
Specific Usage: “MEPMD01” The MDM/R will load only “MEPMD01” data.
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”.
N
This field will always contain “Sensus”.
Example: 19970819 or “null” Sender ID
Varchar (10)
General: AAAAAAAAAA
NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Sensus2: FILE ID = 7001
Specific Usage: ‘Sensus’ Sender Customer ID
Char (8)
General: AAAAAAAA
Y
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process.
Y
This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Y
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with.
Example: ‘ORG83729’ Receiver ID
Char (8)
General: AAAAAAAA Specific Usage The MDM/R will only recognize ‘ORG29738’
Receiver Customer ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Time Stamp
Date/Time
yyyyMMddHHmm
Y
This field Is populated with the date and time that this record was created. This time must be reported in EST
Meter ID
Varchar (50)
No format prescribed
Y
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
Purpose
Varchar (8)
General: AAAAAAAA
Y
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
Specific Usage: The MDM/R will only recognize “OK”, “RESEND”
Describes what commodity type is being delivered “E” – Electricity “G” – Gas “W” – Water “S” - Steam
Y
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.
Specific Usage: The MDM/R will only recognize “E” Units
Char (6)
General: AAAAAA Specific Usage: ‘KWH’ and ‘KWHREG’, ‘KVAH’ and ‘KVAHREG’, ‘KVARH’ and ‘KVARHREG’
Calculation Constant
Number (1,0)
General: N Specific Usage: ‘1’
Y
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.
Interval
Time Interval
MMDDhhmm
Y
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.
Example: ‘00000100’ indicates a time interval of one hour ‘00000015’ indicates a time interval of 15 minutes
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
Example: If Units = ‘KWHREG”, Count = ‘2’ If Units = ‘KWH’, Count = ‘12’ for a transmission of 12 intervals.
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.
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:
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’
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.
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
Format
Required
Description
General: NNNNNNNNNNN N.NNNNN
Y
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)
Specific: 123456789012.34
Table 2.12.3 describes the action taken by the EnergyIP application in processing the simple protocol text quality flags for interval consumption data provided for each data triplet within the Sensus2 CMEP file, and the setting of EnergyIP flags as applicable. The same protocol text quality flags are recognized and processed for KWH, KVARH, and KVAH interval data. Table 2.12.3
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Sensus2
Bit Value
Sensus Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
00 00
Sensus – Indicates an error free interval No EnergyIP flag is set, data will be treated as normal data
R0
null
Bit 0
00 01
Sensus – Communication failure (meter could not be read) No EnergyIP flag is set, data will be treated as normal data
R1
null
Bit 1
00 02
Sensus – Power outage EnergyIP PwrFail flag is set in GUI, Missing Interval Validation check NO_DATA flag is cleared, no estimation is done
R2
POWER_OFF
Bit 2
00 04
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
R4
POWER_ON
Bit 3
00 08
Sensus – Voltage sag No EnergyIP flag is set, data will be treated as normal data
R8
null
Bit 4
00 10
Sensus – Voltage swell No EnergyIP flag is set, data will be treated as normal data
Not used for interval data
null
Bit 5
00 20
Sensus – Missing data EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check
N32
NO_DATA
Bit 6
00 40
Sensus – Daylight savings in effect No EnergyIP flag is set, data will be treated as normal data
R64
null
Bit 7
00 80
Sensus – Meter was out of service No EnergyIP flag is set, data will be treated as normal data
Not used
null
Bit
7
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
Sensus Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
Bit 8
01 00
Sensus – Time Adjustment (direction unspecified) EnergyIP flag TimeChg is set in GUI, data is subject to the Time Change Validation check
R256
TIME_CHANGE
Bit 9
02 00
Sensus – Overflow EnergyIP Overflow flag is set in GUI, data is subject to Pulse Overflow Validation check
R512
PULSE_OVERFLOW
Bit 10
04 00
Sensus – Long interval EnergyIP LongInt flag is set in GUI, data will be treated as normal data
R1024
LONG_INTERVAL
Bit 11
08 00
Sensus – Short interval EnergyIP ShortInt flag is set in GUI, data will be treated as normal data
R2048
SHORT_INTERVAL
Bit 12
10 00
Sensus – Test mode EnergyIP TestMode flag is set in GUI, data is subject to Test Mode Validation check
R4096
TEST_MODE
Bit 13
20 00
Sensus – Register rollover detected No EnergyIP flag is set, data will be treated as normal data
Not used for interval data
null
Bit 14
40 00
Sensus – Register reset detected No EnergyIP flag is set, data will be treated as normal data
Not used for interval data
null
Bit 15
80 00
Sensus – Clock out of sync EnergyIP flag TimeChg is set in GUI, data is subject to the Time Change Validation check
R32768
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.
2.13.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the 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.2 Integration 2.13.2.1 Direction
AMCC to the MDM/R 2.13.2.2 Characteristics
This is a batch process involving the transfer and processing of XML files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data received from the AMCC shall contain: §
A series of interval data
§
A register read within or at the end of the Meter Transfer Block
§
Data quality indicators
All Scheduled Read and On Request transmissions will include interval data accompanied by the associated register read in a single data transmission. It is preferred to have the register read occur as close to the end of the Meter Transfer Block as possible. For REX Meter deployments that support the collection of the meter’s end of interval register snapshot value with the collected interval data, the Elster MAS /EA_MS system should be configured to export the End Of Interval Snapshot (EOI Snapshot) register readings. 2.13.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 Version 3.3 – July 7, 2011
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.
2.13.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported. 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters 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
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. Rules Affecting Meter Read Processing for SDPs Requiring Demand Determination
8. The SDP must be assigned a Channel Configuration Set through the synchronization processes that establishes the data channels by unit of measurement and type necessary to support the receipt of interval consumption data and register read data transmitted by the meter. 9. For meters not used for net metering and used for the determination of demand, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 10. For meters not used for net metering and used for the determination of demand, if programmed to record kilovolt-ampere-reactive hours, meters will be programmed to measure active kVARh quantities delivered, Power Factor lagging (inductive), transmitted as positive quantities. This will apply to both interval consumption data and register read data. 11. For meters not used for net metering and used for the determination of demand, if programmed to record kilovolt-ampere hours, meters will be programmed such that the sum of the values of the kilovolt-ampere hours delivered and the kilovolt-ampere hours received will be transmitted as the total delivered kilovolt-ampere hours. This will apply to both interval consumption data and register read data.
2.13.4 Pre-conditions The following must exist for the input file to be processed through the interface:
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.
2.13.5 Post-conditions The following outcome results from the file being processed through the interface: § §
§
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database. Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing. The LDC and/or its designated agent(s) receive interim and final summary and detailed exception reports as outlined in Section 2.13.3 via File Transfer Services.
2.13.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.13.7 Frequency and Timing 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.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
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record for Version 00 would be: ORG11111.ORG22222.7100.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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
Required
Description
Y
Date and time that the data was collected. This is to be delivered in EST
AMRDEF Reference (Release 6.0) Element/Attribute Name
Data Type/Length
Format
AMRDEF. MeterReadings. Meter. MeterName
Varchar (50)
AMRDEF. MeterReadings. Meter. MeterType
AMRDEF. MeterReadings. Meter. SdpIdent
Required
Description
No format prescribed
Y
This is the LDC’s 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
Varchar (15)
General: AAAAAAAAAAAAAA Specific Usage: One of “A3”, “A3_ILN”, “A3_Collector” or “REX”
Y
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
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Y
This field is populated with the assigned Universal SDP ID.
Y
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”
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”
AMRDEF Reference (Release 6.0) Element/Attribute Name
Data Type/Length
Format
Required
Description
AMRDEF. MeterReadings. ConsumptionData. ConsumptionSpec. 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.
N
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
General: AAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R only recognizes and loads ‘Total’ values.
N
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.
General: AAAAAAAAAAAAAAAA AAAAAAAA Specific Usage: Domain of values as per AMRDEF Export Format. The MDM/R recognizes and loads ‘Current’ and ‘EndOfIntervalSnapshot’ values.
N
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).
8
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
The reading value. As per the “AMRDEF.MeterReadings. ConsumptionData. ConsumptionSpec.UOM” attribute.
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
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
Required
Description
Y
Date and time that the data was collected. This is to be delivered in EST
Y
This is the LDC’s 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
AMRDEF. MeterReadings. CollectionTime
Date/Time
As per AMRDEF Export Format: yyyy-mm-dd hh24:mi:ss
AMRDEF. MeterReadings. Meter. MeterName
Varchar (50)
No format prescribed
9
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
AMRDEF Reference (Release 6.0) Element/Attribute Name
Data Type/Length
Format
Required
Description
AMRDEF. MeterReadings. Meter. MeterType
Varchar (15)
General: AAAAAAAAAAAAAAA Specific Usage: One of “A3”, “A3_ILN”, “A3_Collector” or “REX”
Y
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
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”
Y
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”.
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
N
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
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
The reading value per the “AMRDEF.MeterReadings. IntervalData.IntervalSpec.UOM” attribute for load profile interval as identified by the “AMRDEF. MeterReadings.IntervalData. Reading.TimeStamp”.
The meter’s 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 meter’s 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.
10
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
The meter’s 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 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
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
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
12
As of September 2007 the “SkippedInterval” flag is not produced by any Elster meter deployed in Ontario. Elster’s provision of this quality flag is to accompdate possible future deployment of meter types that may provide this flag. Version 3.3 – July 7, 2011
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
Required
Description
AMRDEF. MeterReadings. ReadingQualityIndicator. Name
Varchar (12)
AMRDEF. MeterReadings. ReadingQualityIndicator. Value
Varchar (5)
General: AAAAAAAAAAA
N
This indicates that the data read from the meter may be suspect. The only valid entries are “Tamper Alert” and “Meter Health”
N
If True, the meter reported a condition that affects the meter’s health.
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.
Specific Usage : “Tamper Alert” OR “Meter Health” General: AAAAA Specific Usage : “True” OR “False”
EnergyIP captures the ReadingQualityIndicator.Name and for every Status that has a Status.Category = ReadingQualityIndicator.Name and ReadingQualityIndicator.Value = True, the EnergyIP METER_RESET flag is set for each Status.Name designated in Tables 2.13.5, 2.13.6, and 2.13.7. These tables outline the Status elements designated by Elster to identify Meter Read data that should not be used for billing. Table 2.13.5 lists the Status elements specific to A3 ALPHA meters. Table 2.13.6 lists the Status elements specific to A3 ALPHA Node meters. Table 2.13.7 lists the Status elements specific to REX meters. Table 2.13.5 A3 ALPHA Meter Status indicating Data that Should Not be used for Billing (MeterType = “A3” and “A3_Collector”)
“ID”
“Category”
“Name”
EnergyIP Action
2
Meter Health
Configuration error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
4
Meter Health
RAM failure
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
6
Meter Health
Registered memory error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
7
Meter Health
Clock error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
15
Meter Health
Crystal oscillator error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
21
Meter Health
EEPROM access error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
22
Meter Health
Internal Communication /IC2 error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
23
Meter Health
Tariff EE write error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
24
Meter Health
Tariff EE read error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
25
Meter Health
DSP download error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
26
Meter Health
Table CRC Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
91
Meter Health
Internal meter warning (latched)
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”
“Category”
“Name”
EnergyIP Action
16
Meter Health
ILC Configuration Error
EnergyIP MtrDiagError/METER_RESET is set, data is subject to the Meter Diagnostic Validation check.
19
Meter Health
Meter Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
20
Meter Health
Configuration Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
21
Meter Health
RAM Failure
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
22
Meter Health
ROM Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
23
Meter Health
Registered Memory Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data is subject to the Meter Diagnostic Validation check.
24
Meter Health
Clock Error
EnergyIP MtrDiagError/METER_RESET Flag is set, data
2.14.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the 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.2 Integration 2.14.2.1 Direction
AMCC to the MDM/R 2.14.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data received from the AMCC shall contain: §
A register read for the end of the Meter Transfer Block
§
A series of interval data
§
Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’ value is limited to a maximum of 48 sets of data triplets per record (see Table 2.14.2 – “Count”). This maximum establishes the longest Meter Transfer Block permissible when using a CMEP interface and, if this maximum is used, requires a register read record corresponding to the end of each interval data record of a maximum length of 48 interval data triplets.
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.14.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.
2.14.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 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 LDC’s Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. Version 3.3 – July 7, 2011
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).
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 kilovoltampere hours. This will apply to both interval consumption data and register read data.
2.14.4 Pre-conditions The following must exist for the input file to be processed through the interface: §
The LDC is enrolled and has an Organization ID assigned.
§
The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File.
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.14.5 Post-conditions The following outcome results from the file being processed through the interface: §
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database.
§
Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing.
§
The LDC and/or its designated agents receive interim and final summary and detailed exception reports as outlined in Section 2.14.3 via File Transfer Services.
2.14.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.14.7 Frequency and Timing 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.14.8 File Format 2.14.8.1 File Name Record for the Trilliant CMEP 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.14.1
FILE NAME RECORD FOR THE TRILLIANT CMEP FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record for Version 00 would be: ORG11111.ORG22222.7200.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 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: §
"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.14.2
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TRILLIANT
CMEP Field Name
Data Type/Length
Record Type
Varchar (7)
Format
Required
Description
General : AAAAAAA
Y
This field will always contain “MEPMD01”
Y
This field will contain the CMEP version date. The current version being supported is “19970819”
N
This field will always contain “Trilliant”.
Specific Usage: “MEPMD01” Record Version
Date
General: yyyyMMdd Specific Usage: 19970819
Sender ID
Varchar (10)
General: AAAAAAAAAA
NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Trilliant: FILE ID = 7200
Specific Usage: ‘Trilliant’ Sender Customer ID
Char (8)
General: AAAAAAAA Example: ‘ORG83729’
Version 3.3 – July 7, 2011
Y
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
Y
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with.
Specific Usage: The MDM/R will only recognize ‘ORG29738” Receiver Customer ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Time Stamp
Date/Time
yyyyMMddHHm m
Y
This field Is populated with the date and time that this record was created. This time must be reported in EST
Meter ID
Varchar (50)
No format prescribed
Y
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
Purpose
Varchar (8)
General: AAAAAAAA
Y
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
Y
Describes what commodity type is being delivered “E” – Electricity “G” – Gas “W” – Water “S” - Steam
Specific Usage: The MDM/R will only recognize “OK”, “RESEND"
Commodity
Char(1)
General: A Specific Usage: The MDM/R will only recognize “E”
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.
Y
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.
Y
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.
Specific Usage: ‘KWH’ and ‘KWHREG’, ‘KVAH’ and ‘KVAHREG’, ‘KVARH’ and ‘KVARHREG’
Calculation Constant
Number (1,0)
General: N Specific Usage: ‘1’
Interval
Time Interval
MMDDhhmm Example: ‘00000100’ indicates a time interval of one hour ‘00000015’ indicates a time interval of 15 minutes
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
Example: If Units = ‘KWHREG”, Count = ‘1’ If Units = ‘KWH’, Count = ‘12’ for a transmission of 12 intervals.
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.
General: AAAAAAA (7 characters including a space at the second and fifth character position)
Y
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:
Examples: For a simple code A raw interval read for which a power outage occurred during the interval is ‘R 00 40’.
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.
For a compound code A raw interval read for which a power outage occurred concurrent with a RAM error would be ‘R 02 40’
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. Numeric floating point
Number (12,5)
13
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
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)
13
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
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
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Trilliant
Bit Value
Trilliant Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
00 00
Trilliant – No data quality problems No EnergyIP flag is set, data will be treated as normal data
R 00 00
null
Bit 0
00 01
Trilliant – Manually entered or modified EnergyIP DCEstimated flag is set in GUI, Validation status set to ‘EST’, Change Method set to ‘EDC’
R 00 01
DC_DATA_ESTIMATION
Bit 1
00 02
Trilliant – Automatically estimated EnergyIP DCEstimated flag is set in GUI, Validation status set to ‘EST’, Change Method set to ‘EDC’
R 00 02
DC_DATA_ESTIMATION
Bit 2
00 04
Trilliant – Missing data for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check
N 00 04
NO_DATA
Bit 3
00 08
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
R 00 08
PULSE_OVERFLOW
Bit 4
00 10
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
R 00 10
SHORT_INTERVAL
Bit 5
00 20
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
R 00 20
LONG_INTERVAL
Bit 6
00 40
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
R 00 40
POWER_OFF
Bit 7
00 80
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
R 00 80
POWER_ON
Bit 8
01 00
Trilliant – Clock error: Clock time was messed up EnergyIP TimeChg flag is set in GUI, data is subject to the Time Change Validation check
R 01 00
TIME_CHANGE
Bit 9
02 00
Trilliant – Diagnostic error: RAM or memory error EnergyIP MtrDiagError flag is set in GUI, data is subject to the Meter Diagnostic Validation check
R 02 00
METER_RESET
Bit
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.
Meter Read Transformation for Transmission via Trilliant CMEP Interface
2.15.1 Description The use of a CMEP file format to transmit Meter Read data sourced from AMI systems other than the source AMI system is possible. LDCs may elect to transform Meter Read data as retrieved by the source Advanced Metering Control Computer (AMCC) to a CMEP format when correction of Meter Read data in the past is required, or to utilize the interval data Data Collection Estimation data quality flag available only via the Trilliant Meter Read Interface. LDCs electing to transform Meter Read data to a CMEP format must transmit such transformed data in the Trilliant CMEP format. The Trilliant CMEP format provides the greatest parity regarding transmission of interval data, register read data, and related data quality flags available from other AMI systems deployed as part of the Ontario Smart Metering System. The purpose of this specification is to define the requirements for data transformations applied to Meter Read data collected by non-Trilliant AMI Advanced Metering Control Computers (AMCC) and transformed by an LDC’s meter read translator prior to transmission to the MDM/R via the Trilliant Meter Read Interface. This specification anticipates that such data transformations may be used to process data on an exception basis for Meter Read data correction, or may be used for daily production transmission of Meter Read data to the MDM/R for each Daily Read Period for an LDC’s entire smart meter population.
2.15.2 Integration 2.15.2.1 Direction
AMCC to Meter Read Translator to the MDM/R Trilliant Meter Read Interface 2.15.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC and transformed by the LDC’s meter read translator for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data received from the Meter Read Translator will contain: § § §
A register read for each Meter Transfer Block subject to the requirements of sub-section 2.15.2.3 below. A series of interval data Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. All register readings will have a date/time inside the date/time range of the interval data set. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. Version 3.3 – July 7, 2011
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. 2.15.2.4 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. 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
‘MaxRegisterRange’ hours of the billing period start date/time or billing period end date/time.
2.15.3 Business Rules 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 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 is collected predominantly at mid-interval and does not coincide with the end date/time of any interval data block. LDC’s deploying REX2 (R2S) Meters or REX1 (R1S) Meters with firmware 4.1 or higher and operating EnergyAxis Metering Automation Server (MAS) Release 6.2 or EnergyAxis Management System (EA_MS) Release 7.0 can expect the AMRDEF Export XML interval data records to be accompanied by an record. This “End Of Interval Snapshot” is a register read coinciding with the end date/time of each collected interval data block. 1. Register readings included in each Meter Transfer Block should be sourced from the “End Of Interval Snapshot” if available and should be at the end of the Meter Transfer Block or as late as possible within the date/time range of the interval data set. 2. Register readings included in each Meter Transfer Block sourced from “Consumption Data” should be as late possible within the date/time range of the interval data set.
2.15.4 Pre-conditions Please see Section 2.14.4 – Pre-Conditions for the Meter Read Interface (Trilliant).
2.15.5 Post-conditions 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).
2.15.7 Frequency and Timing 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 and to Trilliant CMEP
The Elster MAS AMRDEF provides data quality information using two differing tag types namely the tags and tags. These data quality indicators should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.1. Table 2.15.1
Mapping of Elster Quality Flags to Trilliant Protocol Text Codes Trilliant Data Quality Flag Description
Elster Tag Note 1.
Required CMEP Flag
EnergyIP Flag
No data quality problems
R 00 00
null
Manually entered or modified
R 00 01
DC_DATA_ESTIMATION
Automatically estimated
R 00 02
DC_DATA_ESTIMATION
Missing data for the interval
N 00 04
NO_DATA
Overflow consumption
R 00 08
PULSE_OVERFLOW
Partial data in the interval
R 00 10
PARTIAL_INTERVAL
Too much pulse content
R 00 20
LONG_INTERVAL
Start of power outage
R 00 40
POWER_OFF
Power is restored
R 00 80
POWER_ON
Clock error
R 01 00
TIME_CHANGE
For A3 ALPHA Meter see Table 2.13.5
Diagnostic error, Ram or memory error
R 02 00
METER_RESET
(not available) (not available) (not available)
Version 3.3 – July 7, 2011
Note 2.
264
Meter Data Management and Repository
MDM/R Technical Interface Specifications IESO_SPEC_9027 Trilliant Data Quality Flag Description
Elster Tag
Required CMEP Flag
EnergyIP Flag
For A3 ALPHA NODE see Table 2.13.6 For REX Meters see Table 2.13.7
Note 3.
Note 4.
(not available)
N 00 04
(not available)
-
NO_DATA TEST_MODE
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
Note 1: Interval data submitted for which there are no data quality problems must be submitted in the CMEP format with the Protocol Text code of “R 00 00”. Note 2: The tag is not produced by any Elster Energy Axis AMI system deployed in Ontario and the AMRDEF Export XML does not include records for missing interval data. Elster’s specification of the “Skipped Interval” data quality flag is to accommodate possible future deployment of meter types that may provide this flag. Missing intervals from Elster meters transmitted in the Trilliant CMEP format should include the “N 00 04” Protocol text code. Note 3: EnergyIP Release 7.0 as deployed for the MDM/R will process interval data readings marked with the 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 ) and not differentiated by the tag will not be loaded by the MDM/R. 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 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 tag. The MDM/R sets the METER_RESET flag indicating a meter diagnostic error only for those 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
and 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 to a value of “1” if the condition occurs and also by setting the and tags in the same data transmission. The equivalent Trilliant function is accomplished by the use of compound hexadecimal codes. The Trilliant Meter Read Interface supports the combination of multiple data quality flags up to the possible 1024 code values resulting from the hexadecimal addition of the CMEP codes. If your proposed translation of Elster meter read data is intended to provide the Data Collection Estimation codes (i.e. “Manually entered or modified”, or “Automatically estimated”) we recommend that these simple codes be used for any combination data quality condition corrected by manual editing or automatic estimation. 2.15.9.2 Translation of Sensus CMEP to Trilliant CMEP
Transformation of the Sensus CMEP Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.2. Table 2.15.2
Mapping of Sensus Protocol Text Codes to Trilliant Protocol Text Codes
Sensus Data Quality Flag Description Error free interval
Sensus CMEP Flag R 00 00
Trilliant Data Quality Flag Description
Required CMEP Flag
EnergyIP Flag
No data quality problems
R 00 00
null
(not available)
-
Manually entered or modified
R 00 01
DC_DATA_ESTIMATION
(not available)
-
Automatically estimated
R 00 02
DC_DATA_ESTIMATION
Missing data
Missing data for the interval
N 00 04
NO_DATA
(not available)
N 00 20 -
Overflow consumption
R 00 08
PULSE_OVERFLOW
(not available)
-
Partial data in the interval
R 00 10
PARTIAL_INTERVAL
(not available)
-
Too much pulse content
R 00 20
LONG_INTERVAL
Power outage
R 00 02
Start of power outage
R 00 40
POWER_OFF
Power restoral
R 00 04
Power is restored
R 00 80
POWER_ON
(not available)
-
Clock error
R 01 00
TIME_CHANGE
(not available)
-
Diagnostic error, Ram or memory error
R 02 00
METER_RESET
Communication failure
R 00 01
(not available)
-
null
Voltage sag
R 00 08
(not available)
-
null
Voltage swell
R 00 10
(not available)
-
null
Daylight savings in effect
R 00 40
(not available)
-
null
Meter was out of service
R 00 80
(not available)
-
null
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
2.15.9.3 Translation of Sensus2 CMEP to Trilliant CMEP
Transformation of the Sensus FlexNet extended file CMEP format Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.3. Table 2.15.3
Mapping of Sensus2 Protocol Text Codes to Trilliant Protocol Text Codes
Sensus2 Data Quality Flag Description Error free interval
Sensus2 CMEP Flag R0
(not available) (not available)
Trilliant Data Quality Flag Description
Required CMEP Flag
EnergyIP Flag
No data quality problems
R 00 00
null
-
Manually entered or modified
R 00 01
DC_DATA_ESTIMATION
-
Automatically estimated
R 00 02
DC_DATA_ESTIMATION
Missing data
N32
Missing data for the interval
N 00 04
NO_DATA
Overflow
R512
Overflow consumption
R 00 08
PULSE_OVERFLOW
Partial data in the interval
R 00 10
PARTIAL_INTERVAL
Too much pulse content
R 00 20
LONG_INTERVAL
(not available)
-
Long interval
R1024
Short interval
R2048
Power outage
R2
Start of power outage
R 00 40
POWER_OFF
R4
Power is restored
R 00 80
POWER_ON
Clock error
R 01 00
TIME_CHANGE
Diagnostic error, Ram or memory error
R 02 00
METER_RESET
Power restoral Time Adjustment
R256
(not available)
-
Communication failure Voltage sag
(not available)
-
SHORT_INTERVAL
R1
(not available)
-
null
R8
(not available)
-
null
Not used
(not available)
-
null
Daylight savings in effect
R64
(not available)
-
null
Meter was out of service
Not used
(not available)
-
null
R4096
(not available)
-
TEST_MODE
-
null
Voltage swell
Test mode Register rollover detected
Not used
Clock out of sync
R32768
(not available) Clock error
R 01 00
TIME_CHANGE
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
2.15.9.4 Translation of Tantalus CMEP to Trilliant CMEP
Transformation of the Tantalus CMEP Protocol Text flags should map to the Trilliant CMEP Protocol Text flags as specified in Table 2.15.4. Table 2.15.4
Mapping of Tantalus Protocol Text Codes to Trilliant Protocol Text Codes
Tantalus Data Quality Flag Description Normal raw data (not available) (not available) Consumption reading missing for this interval
of the interval Power was restored during this interval (not available)
R 00 04 -
Power is restored
R 00 80
POWER_ON
Clock error
R 01 00
TIME_CHANGE
Diagnostic error, Ram or memory error
R 02 00
METER_RESET
The meter has failed
R 01 00
Communication failure within the meter
R 00 01
(not available)
-
null
Voltage sag was in effect for all or part of the interval
R 00 08
(not available)
-
null
Voltage swell was in effect for all or part of the interval
R 00 10
(not available)
-
null
Daylight savings was in effect
R 00 40
(not available)
-
null
Meter was out of service for all or part of the interval
R 00 80
(not available)
-
Null
Meter was unavailable due to maintenance by the utility
R 02 00
(not available)
-
null
Valid Trilliant CMEP Protocol Text codes may also be applied to register read data. Only Power outage “R 00 40” will be stored in the Meter Data Database setting the EnergyIP POWER_OFF flag in the Register Read table and viewed in the GUI as Power Off. Other valid flags assigned to register read data will be ignored.
2.16.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the 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.2 Integration 2.16.2.1 Direction
AMCC to the MDM/R 2.16.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data received from the AMCC shall contain: §
A register read for the end of the Meter Transfer Block
§
A series of interval data
§
Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’ value is limited to a maximum of 48 sets of data triplets per record (see Table 2.16.2 – “Count”). This maximum establishes the longest Meter Transfer Block permissible when using a CMEP interface and, if this maximum is used, requires a register read record corresponding to the end of each interval data record of a maximum length of 48 interval data triplets.
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.16.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 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.
2.16.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported. 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 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 LDC’s Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. Version 3.3 – July 7, 2011
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).
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.
2.16.4 Pre-conditions The following must exist for the input file to be processed through the interface: §
The LDC is enrolled and has an Organization ID assigned.
§
The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File.
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.16.5 Post-conditions The following outcome results from the file being processed through the interface: §
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database.
§
Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing.
§
The LDC and/or its designated agent (s) receive interim and final summary and detailed exception reports as outlined in Section 2.16.3 via File Transfer Services.
2.16.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.16.7 Frequency and Timing 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.16.8 File Format 2.16.8.1 File Name Record for the Tantalus CMEP 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.16.1
FILE NAME RECORD FOR THE TANTALUS CMEP FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record for Version 00 would be: ORG11111.ORG22222.7300.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.16.8.2 Tantalus 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: §
"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.16.2
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR TANTALUS
CMEP Field Name
Data Type/Length
Record Type
Varchar (7)
Format
Required
Description
General : AAAAAAA
Y
This field will always contain “MEPMD01”
Y
This field will contain the CMEP version date. The current version being supported is “19970819”
N
This field will always contain “Tantalus”.
Specific Usage: “MEPMD01” Record Version
Date
General: yyyyMMdd Specific Usage: 19970819
Sender ID
Varchar (10)
General: AAAAAAAAAA
NOTE: The function of this field has been replaced by use of the MDM/R FTS file name. For Tantalus: FILE ID = 7300
Specific Usage: ‘Tantalus’ Sender Customer ID
Char (8)
General: AAAAAAAA Example: ‘ORG83729’
Version 3.3 – July 7, 2011
Y
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
Y
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with.
Specific Usage: The MDM/R will only recognize ‘ORG29738” Receiver Customer ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Time Stamp
Date/Time
yyyyMMddHHm m
Y
This field Is populated with the date and time that this record was created. This time must be reported in EST
Meter ID
Varchar (50)
No format prescribed
Y
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
Purpose
Varchar (8)
General: AAAAAAAA
Y
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
Y
Describes what commodity type is being delivered “E” – Electricity “G” – Gas “W” – Water “S” – Steam
Specific Usage: The MDM/R will only recognize “OK”, “RESEND"
Commodity
Char(1)
General: A Specific Usage: The MDM/R will only recognize “E”
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.
Y
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.
Y
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.
Specific Usage: ‘KWH’ and ‘KWHREG’, ‘KVAH’ and ‘KVAHREG’, ‘KVARH’ and ‘KVARHREG’
Calculation Constant
Number (1,0)
General: N Specific Usage: ‘1’
Interval
Time Interval
MMDDHHMM Example: ‘00000100’ indicates a time interval of one hour ‘00000015’ indicates a time interval of 15 minutes
General: NN Example: If Units = ‘KWHREG”, Count = ‘1’ If Units = ‘KWH’, Count = ‘12’ for a transmission of 12 intervals.
Y
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. 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.
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:
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)
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.
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
Format
Required
Description
General: NNNNNNNNNN NN.NNNNN
Y
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)
Specific: 123456789012.3 4
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
Mapping of Protocol Text Field Quality Flags to EnergyIP Action for Tantalus
Bit Value
Tantalus Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
00 00
Tantalus – Normal raw data No EnergyIP flag is set, data will be treated as normal data
R 00 00
null
00 01
Tantalus – Communication failure within the meter No EnergyIP flag is set, data will be treated as normal data
R 00 01
null
00 02
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
R 00 02
POWER_OFF
Bit 2
00 04
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
R 00 04
POWER_ON
Bit 3
00 08
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
R 00 08
null
Bit 4
00 10
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
R 00 10
null
Bit 5
00 20
Tantalus – Consumption reading was missing for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check
N 00 20
NO_DATA
Bit 6
00 40
Tantalus – Daylight Savings Time was in effect No EnergyIP flag is set, data will be treated as normal data
R 00 40
null
Bit 7
00 80
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
R 00 80
null
Bit 8
01 00
Tantalus – The meter has failed EnergyIP MtrDiagError flag is set in GUI, data is subject to
R 01 00
METER_RESET
Bit
Bit 0
Bit 1
14
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
Tantalus Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
R 02 00
null
the Meter Diagnostic Validation check Bit 9
02 00
Tantalus – The meter unavailable due to maintenance by the utility No EnergyIP flag is set, data will be treated as normal data
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.
2.17.1 Description The purpose of this interface is to deliver Meter Read data for smart meters to the MDM/R. The MDM/R accepts Meter Read data from a number of AMCC systems. It uses specific adaptors that are built to support AMCC systems that are in use by LDCs and/or AMI Operators. This section describes the technical specifications for the 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.2 Integration 2.17.2.1 Direction
AMCC to the MDM/R 2.17.2.2 Characteristics
This is a batch process involving the transfer and processing of CSV files. Meter read data may be received from the AMCC for all meters that are associated to SDP’s that a) have been assigned a Universal SDP ID, b) have been included in the Periodic Audit Synchronization or Incremental Synchronization integrations and c) have all of the attributes associated with the Data Collection Service populated. All meter read data received from the AMCC shall contain: §
A register read for the end of the Meter Transfer Block
§
A series of interval data
§
Data quality indicators
The above data will be sent in a single data transmission. The register read records will precede the interval data records for each SDP in the file transmission. All register read records and interval data records will be ordered within each file transmission in ascending date/time order. The CMEP “Data Triplet” of ‘Date/Time’, ‘Protocol Text’, and ‘Numeric floating point’ value is limited to a maximum of 48 sets of data triplets per record (see Table 2.17.2 – “Count”). This maximum establishes the longest Meter Transfer Block permissible when using a CMEP interface and, if this maximum is used, requires a register read record corresponding to the end of each interval data record of a maximum length of 48 interval data triplets.
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.17.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.
2.17.3 Business Rules 1. Universal SDP ID and AMCD ID must be a valid pair for the LDC’s Organization ID for the Daily Read Period date being reported 2. Where the LDC’s Organization ID, Universal SDP ID and AMCD ID are all associated to the same SDP, the MDM/R records the meter read data from the inbound file against the Universal SDP ID and AMCD ID in the Meter Data Database. If there is no Meter Read data in the record, no value is recorded. 3. For residential meters not used for net metering, meters will be programmed such that the sum of the absolute values of the energy delivered and the energy received will be transmitted as the total delivered energy. This will apply to both interval consumption data and register read data. 4. The processed Meter Read File is placed in the Processed Directory in the MDM/R, which is an internal EnergyIP directory. 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 LDC’s Organization ID values are not known by the system. c. The MDM/R detects exceptions when the AMCD ID values are not known by the system. Version 3.3 – July 7, 2011
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).
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.
2.17.4 Pre-conditions The following must exist for the input file to be processed through the interface: §
The LDC is enrolled and has an Organization ID assigned.
§
The LDC has requested and received Universal SDP IDs for each SDP in the Meter Read File.
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.17.5 Post-conditions The following outcome results from the file being processed through the interface: §
Meter Read data for Universal SDP IDs and AMCD IDs are updated in the Meter Data Database.
§
Meter Read data is not loaded into the Meter Data Database for records with exceptions as described in Section 6 of the MDM/R Detailed Design Document, VEE Processing.
§
The LDC and/or its designated agents receive interim and final summary and detailed exception reports as outlined in Section 2.17.3 via File Transfer Services.
2.17.6 Assumptions §
MDM/R will only process Meter Read data that is related to smart meters.
2.17.7 Frequency and Timing 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.17.8 File Format 2.17.8.1 File Name Record for the SmartSynch CMEP 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.17.1
FILE NAME RECORD FOR THE SMARTSYNCH CMEP FILE
Field Name
Data Type/Length
Format
Required
Description
Prefix
Char (7)
Specific Usage:
Y
This field always contains the record type “”
File Name
Varchar (250)
Refer to Section 1.8
Y
This field contains the name of the file on the originating system, as defined in Section 1.8
An example of this record for Version 00 would be: ORG11111.ORG22222.7400.00.20070214221345.DAT NOTE: Please reference Section 1.8.2 for use of file format version number. 2.17.8.2 SmartSynch 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: §
"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.17.2
FIELD CONVENTIONS FOR THE MEPMD01 RECORD TYPE FOR SMARTSYNCH
CMEP Field Name
Data Type/Length
Record Type
Varchar (7)
Format
Required
Description
General : AAAAAAA
Y
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”
N
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”.
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
Specific Usage: ‘SmartSynch’
Sender Customer ID
Char (8)
General: AAAAAAAA
Y
This field will contain The unique Organization identifier assigned to the LDC during the registration/enrollment process.
Y
This field will contain the unique Organization identifier assigned to the MDM/R This field will always contain ORG29738
Y
This field is populated with the assigned Universal SDP ID that corresponds with the Meter that this reads data is associated with.
Example: ‘ORG83729’ Receiver ID
Char (8)
General: AAAAAAAA Specific Usage: The MDM/R will only recognize ‘ORG29738”
Receiver Customer ID
Fixed Number (8)
General: NNNNNNNN Example: ‘00037482’
Time Stamp
Date/Time
yyyyMMddHHm m
Y
This field Is populated with the date and time that this record was created. This time must be reported in EST
Meter ID
Varchar (50)
No format prescribed
Y
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
Purpose
Varchar (8)
General: AAAAAAAA
Y
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
Y
Describes what commodity type is being delivered “E” – Electricity “G” – Gas “W” – Water “S” - Steam
Specific Usage: The MDM/R will only recognize “OK”, “RESEND"
Commodity
Char(1)
General: A Specific Usage: The MDM/R will only recognize “E”
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.
Y
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.
Y
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.
Specific Usage: ‘KWH’ and ‘KWHREG’, ‘KVAH’ and ‘KVAHREG’, ‘KVARH’ and ‘KVARHREG’
Calculation Constant
Number (1,0)
General: N Specific Usage: ‘1’
Interval
Time Interval
MMDDhhmm Example: ‘00000100’ indicates a time interval of one hour ‘00000015’ indicates a time interval of 15 minutes
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
Example: If Units = ‘KWHREG”, Count = ‘1’ If Units = ‘KWH’, Count = ‘12’ for a transmission of 12 intervals.
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.
General: AAAAAAA (7 characters including a space at the second and fifth character position)
Y
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:
Examples: For a simple code A raw interval read for which a power outage occurred during the interval is ‘R 00 40’.
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.
For a compound code A raw interval read for which a power outage occurred concurrent with a RAM error would be ‘R 02 40’
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. Numeric floating point
Number (12,5)
15
NOTE: Transmitted values exceeding (5) decimal places will be rounded and stored in the Meter Data Database to (5) decimal places
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)
15
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
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 Value
SmartSynch Data Quality Flag Description EnergyIP Action
Required CMEP Flag
EnergyIP Flag
00 00
SmartSynch – No data quality problems No EnergyIP flag is set, data will be treated as normal data
R 00 00
null
Bit 0
00 01
SmartSynch – Manually entered or modified EnergyIP DCEstimated flag is set in GUI, Validation status set to ‘EST’, Change Method set to ‘EDC’
R 00 01
DC_DATA_ESTIMATION
Bit 1
00 02
SmartSynch – Automatically estimated EnergyIP DCEstimated flag is set in GUI, Validation status set to ‘EST’, Change Method set to ‘EDC’
Not used
DC_DATA_ESTIMATION
Bit 2
00 04
SmartSynch – Missing data for this interval EnergyIP NoData flag is set in GUI, data is subject to the Missing Intervals Validation check
N 00 04
NO_DATA
Bit 3
00 08
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
R 00 08
PULSE_OVERFLOW
Bit 4
00 10
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
R 00 10
SHORT_INTERVAL
Bit 5
00 20
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
R 00 20
LONG_INTERVAL
00 40
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
R 00 40
POWER_OFF
Bit 7
00 80
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
R 00 80
POWER_ON
Bit 8
01 00
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
R 01 00
TIME_CHANGE
Bit 9
02 00
SmartSynch – Diagnostic error: RAM or memory error EnergyIP MtrDiagError flag is set in GUI, data is subject to the Meter Diagnostic Validation check
R 02 00
METER_RESET
Bit
Bit 6
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.
2.17.1 Description The purpose of this interface will be to provide a file based mechanism for submission of estimated or valid manual register readings. This interface will be based on a version of the EnergyIP Generic or Universal data import adapter modified to recognize data quality flags applied to register readings. This interface will be developed and deployed to support the MDM/R Universal Solution for verification and reconciliation of billing quantities based on Measurement Canada approved meter registrations.
