Draft Working Document Version 0.6. Prepared by: The SMI Data Standards Working Group September 27, 2005

Transcription

1 Draft Working Document Version 0.6 Prepared by: The SMI Data Standards Working Group September 27, 2005

2 Disclaimer and Limitation of Liability The information provided by the SMI Data Workflow and Representation Standards Working Group is directed solely to energy industry professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied. This draft working document is provided for review, discussion and comments, and should in no way be taken as a definitive for final draft. While the information contained herein has been prepared from sources deemed to be reliable, The SMI Data Workflow and Representation Standards Working Group reserves the right to revise the information without notice, but has no obligation to do so. Use of the information is at your discretion and The SMI Data Workflow and Representation Standards Working Group makes no representation or warranty that the information is technically accurate or sufficient or conforms to any statute, governmental rule or regulation, and makes no representation or warranty of merchantability or fitness for any particular purpose or against infringement of intellectual property rights. In no event shall The SMI Data Workflow and Representation Standards Working Group or any of its participants be liable for lost profits or other incidental or consequential damages. Any and all use or reliance upon such information, including any selection of products or vendors is solely your responsibility and you assume all risks and liabilities, if any, with respect thereto. Page 2 of 81

3 Table of Contents 1. Revision History Overview Working Group Purpose and Objectives Theoretical Smart Meter System Glossary Functional Components Smart Meter Network Consumer Directory Automatic Meter Reading (AMR) System(s) Validation, Editing and Rebuilding System Meter Data Repository (MDR) Data Aggregation System (DAS) Consumer Information System (CIS)/Billing and Retail Settlement System Web Presentment System Customer Service Representative (CSR) Automated Voice Response (AVR) Support Bill Printing System Audit Reporting Real-time Web Presentment Appendix A Meter Data Access Matrix...38 Revision History...38 Overview...38 Data Access Matrix...38 Overview of Access by Entity Meter Data Access Actors Preconditions Post Condition Success Post Condition Failure The Customer Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Local Distribution Company (LDC) Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other...42 Page 3 of 81

4 6.4. The Retailer Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Customer Agent or Agent-only Retailer Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Ontario Ministry of Energy Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Ontario Power Authority (OPA) Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Ontario Energy Board (OEB) Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other The Independent Electricity System Operator (IESO) Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other...49 Page 4 of 81

5 6.10. General Public/Companies (Public) Reasons for Access Identifiers Assignment of Rights Limitations of Access Post Condition Failure Normal Flow Other Appendix B Draft Data Workflows Developed To Date Data Import IMP-000 Data Collection Workflows...51 Revision History Data Import Workflow Overview Goal Actors Pre-conditions Post-condition Normal Flow out of a meter Error Flows Metering Service Workflows Smart Meter Network (SMN) Global Data Flow Diagram Configuration Management Collection System Integration Reading, Event, and Tamper Interfaces Calculation/Data Compiling Validation, Editing & Estimation (VEE) Event Management Analytic and Operational Reporting...60 Data Access B2B B2B-001 Request for Historical Usage Reconfiguration Retailer Requests Historical Usage for Consumer (Scenario # 1) Goal in Context Actors Preconditions Post Condition Success Post Condition Failure Normal Flow Retailer Requests Historical Usage for Consumer (Scenario # 2) Goal in Context Actors Preconditions Post Condition Success Post Condition Failure Normal Flow...65 Page 5 of 81

6 7.4. B2B-002 Billable Usage Flow to Retailer LDC Providing Retailers Billable Usage (Non-Interval) Goal in Context Actors Preconditions Post Condition Success Post Condition Failure Normal Flow LDC Provides Retailer Billable Usage (Interval) Goal in Context Actors Preconditions Post Condition Success Post Condition Failure Normal Flow B2B-006 Data Flow from MDR to CIS Billing (Aggregation) CIS Requests Aggregated Usage from Data Aggregation for Billing Assumptions Goal in Context Actors Preconditions Post Condition Success Normal Flow B2B-009 Data Validation (C&I and Residential) General Appendix C Legislation with Potential SMI Implications...79 Bill 210 Amendments to the Act...79 Electricity Gas and Inspection Act (Federal)...79 Retail Settlement Code Section Page 6 of 81

7 1. Revision History Version Date Author Comments 0.1 January 6, 2005 SMI Working Group Initial draft Chair 0.2 January 17, 2005 SMI Working Group Chair Added comments from Tim Fry, Darius Vaiciunas, Johanna Raycraft 0.3 February 3, 2005 SMI Working Group Changed format to include new logo Chair and header. February 16, February 23, 2005 February 27, 2005 February 28, 2005 SMI Working Group Chair Added Issues/Suggested Solution to all Functional Component descriptions Added comments from Dileep Rudran Added Issues/Solutions tables and content for all sections Added revisions sent by Darius Vaiciunas Editing changes throughout Added content to Issues/Solutions tables 0.5 March 9, 2005 SMI Working Group Chair Added disclaimer, overview and active participants sections Added comments from Dileep Rudran on section 5.2.2, 5.3 and issue 1 and 7 in section 5.3 Enhanced glossary Resolved missing diagram captions Added Consumer directory description 0.6 Sept. 23, 2005 OUSM/SMI WG/EDA Altered network diagram to include consumer directory as part of smart meter network Revisions and additions discussed at the joint meeting Page 7 of 81

8 2. Overview Working Group Purpose and Objectives Although there are a number of working groups already dedicated to various aspects of the Smart Meter Initiative (SMI), the SMI Data Workflow and Representation Standards Working Group (SMI Working Group) is the only working group formed to address the vital technology issues of meter data workflow and data representation. The proper and precise definitions of these two elements of the SMI are key to the success of the initiative. In the absence of a clearly-defined set of data representation standards and a workflow model, any data interactions between the initiative s participants will be adhoc at best and chaotic at worst. The SMI Working Group is addressing these concerns by bringing together experts from organizations and stakeholders that have a keen interest in the success of the SMI. The working group will leverage the combined technological and business expertise of these market participants to effectively design the workflow model and data standards required for the SMI. The SMI Working Group is an independent body comprised of a cross-section of market participants with a common interest in the standards related to the SMI. The Ontario Ministry of Energy has recognized the group s forward-looking initiatives, however, at the present time, the SMI Working Group is not affiliated with, or formally endorsed by, the Government of Ontario or any of its agencies, nor does it operate under the auspices of the Ontario Government. Active Participants To Date Active SMI Working Group participants to date include: Bell Canada, BlueWater Power Distribution Corp., COLLUS (Collingwood Utility Services), Direct Energy, Enersource Corporation, Echelon, Enbridge, Enwin, Elster Electricity, Hydro One, Itron, Niagara Falls Hydro Inc., URB Olameter, Util- Assist, Smartsynch, and The SPi Group Inc. 3. Theoretical Smart Meter System For the purposes of discussion and to identify and define smart meter data workflows, we have assembled a theoretical smart meter system (see diagram below). This system would use open data standards to enable communications between the systems functional components across a Smart Meter Network and the existing retail electricity market EBT network (retail EBT network). Open standards will allow commercial participants in the Ontario smart meter market to compete on a level playing field and provide hardware and service provider choice for Ontario s LDCs and retailers. The purpose of using a theoretical smart meter system is to stimulate discussion by documenting a potential system and illustrating the requirements. It is in the best interests of all parties to limit changes to existing infrastructures such as the retail EBT network and the CIS systems used by local distribution companies (LDCs) and retailers wherever possible. Page 8 of 81

9 Theoretical Smart Meter System The high level purpose of a smart meter system is to measure, collect and store smart meter interval data for validation, presentment, reporting and consumer billing/settlement purposes. The system attempts to reflect vendor and technology neutrality and represent each of the functional requirements of a smart meter system. Functional components have been disaggregated to simplify analysis and emphasize the value of open data standards. While some LDCs will employ systems that satisfy their particular business requirements, it is expected that they will use the smart meter system s open standards to communicate within the Smart Meter Network (SMN). Participants may elect to make changes as service providers enter the market and the Smart Meter Network evolves. For clarity, the interface with the Independent Electricity System Operator (IESO) has been excluded from the above diagram. Page 9 of 81

10 ! "#$$ Example Data Workflow, Functional Components and Open Data Standards Page 10 of 81

11 4. Glossary AMR Automatic meter reading systems capable of remotely collecting metered and non-metered data from metering devices and reprogramming TOU/CPP schedules (if necessary), and other meter specific parameters through wired and wireless technologies. Typically AMR systems generate operational and audit reports and retain a limited meter database. Concentrators Concentrators represent mid-level components in an AMR network which collect data from or transport commands to multiple AMR points through wired or wireless technologies. These devices communicate with a higher level in the AMR network hierarchy such as a master station or computer through wired or wireless technologies. Critical Peak Pricing A type of dynamic pricing whereby the majority of Kwh usage is priced on a time-of-use (TOU) basis, but for which certain hours on certain days, when the system is experiencing high peak demand, are subject to higher hourly energy prices that reflect market conditions for peak generation and delivery during peak demand periods. These critical period prices may be known to electricity customers under conditions such as day-ahead or hour ahead markets, and are typically employed a limited number of times per year CIS The customer information system (CIS) describes a set of software components that an Ontario LDC and/or retailer uses to manage their consumers. The CIS system is typically a vendor-supplied set of fully or semi-integrated components. In some cases, the LDC has created their own custom CIS/billing application. CIS/billing systems could include account and service management, bill calculation and preparation, remittance interface, service order management, accounting (AR) interface, reporting, and typically, a handheld meter reading system interface for register meter reading. Billing and retail settlement are sub-systems or components of the CIS. Retail settlement systems manage the difference between the market cost of energy and the price the consumer pays for the energy. These systems ensure that the LDC and retailer are accurately compensated for the transactions on a consumer s energy bill in accordance with the Retail Settlement Code, and are typically an integrated component of the CIS/billing system and interface to accounting systems. Page 11 of 81

12 Data Workflow The term data workflow describes the flow of SMI-related data between two or more related functional components in, or attached to, the system, where the data is represented in an SMI-standard format, and where the functional components transmit the data using SMI-standard interfaces and protocols. Functional Component Functional components are elements of the system that create, consume or process SMI-related data in some way. They will either be an integral part of the system or will be provided by some external entity that specializes in a particular form of SMI data processing or presentment. For example, Web presentment provided by a third-party organization is a functional component. Meter Data Repository (MDR) An MDR represents one or more database systems that form a repository for smart meter data. At a minimum, meter data repositories would store cleaned interval or time-of-use (TOU) data. These MDRs would capture meter data from one or more AMRs, and would make it available to consumers in TOU or interval format via the network and the smart meter data standards. Consumers of this data may include LDCs, retailers, service providers and government bodies. The MDRs may also support additional functionality such as validation, editing and rebuilding (VER). Network Users Any organization or entity that connects to the Smart Meter Network with the purpose of transmitting or accessing SMI-related data is defined as a network user. Market participants who will utilize the network include LDCs, retailers and third-party organizations such as MDR or Web presentment solution providers. Retail EBT Network The XML-based network protocols and standards deployed in the Ontario retail electricity market to allow parties to securely communicate and transfer data, independent of the different operating systems and programming languages used internally or by their OEB-registered trading partners or other market participants. Smart Meter Network (SMN) A province-wide communications infrastructure for the secure storage, tracking and transport of smart meter data between various network users, including retailers, LDCs, service providers (i.e. meter data repositories or Web presentment systems) and the government. Such a network, based on open standards, promotes interoperability, security and ease of data access by all users, while reducing the costs and barriers to SMI participation. Page 12 of 81

13 Time of Use Energy prices that are set for a specific time period on an advance or forward basis, typically not changing more often than twice a year (summer and winter season). Prices paid for energy consumed during these periods are pre-established and known to consumers in advance of consumption, allowing consumers to vary their demand and usage in response to such prices and manage their energy costs by shifting usage to a lower cost period, or reducing consumption overall. The time periods are pre-established, typically including from two to no more than four periods per day and often do not vary in start or stop times. Web Presentment System A system that provides Web-based Internet access to consumer SMI data. In order for consumers to benefit from smart meter data, access to the previous day s consumption pattern would be viewable through several mechanisms including a secure Web interface. Educating consumers by providing Internet-based access to their own energy consumption data is a key component of the Ontario Government s smart meter, conservation and demand management goals. Smart meter data, specifically the hourly energy consumption for the previous day, will be presented to consumers each day by a predetermined deadline. Page 13 of 81

14 5. Functional Components 5.1. Smart Meter Network The Smart Meter Network (SMN) is the central gateway for all parties that need to access the province-wide pool of smart meter data. This data access gateway uses open standards protocols to securely and reliably transport and track all SMI-related data. SMI data is represented in industrystandard XML format and, consequently, its integrity and structure can be automatically validated by the SMN. Since all SMI data will be flowing through the SMN, it is anticipated that the data will be centrally stored in much the same XML document-oriented manner as retail data is in the Ontario retail market. All other functional components are users of this SMN. The SMN s primary responsibility is to provide the efficient, secure, reliable and auditable transport of, and access to, all SMI-related data for all SMN users Consumer Directory The Consumer Directory has two main functions: it acts as the system of reference for all information about the relationships between meters, consumers and SMI participants; and it directs the flow of information between participants. A close companion to the SMN s core document processing systems, the Consumer Directory understands the SMN s XML document content at a transactional level, controlling the routing, access and workflow of all SMI data. An LDC has rights to consumer meter data for billing purposes only, but cannot provide customerspecific data or grant access to it to retailers or service providers without consumer authorization. Conversely, consumers can grant access to their meter data to retailers or service providers but cannot withhold this data from the LDC or deny access to the data. As the director of SMI data workflow, the Consumer Directory will identify and maintain a master list of all external participants (e.g. LDCs, retailers and service providers) that have been granted access to consumer meter data. Page 14 of 81

15 Operations and activities that change the relationships The following table identifies ongoing operations and activities that will change relationships and what data, at a minimum, will change. Operations and activities Consumer moves within LDC Consumer moves from LDC Consumer Account name change Consumer Name Consumer Account # Service Address Meter # LDC Retailer Contract Access to Data No change Change Change Change No change No change No change No change No change Change Change Change Change No change No change Change Change Possible Change No change No change No change No change Possible Change Possible Change Meter exchanges No change No change No change Change No change No change No change No change New Service Address changes Retailer contract changes Provider Requests access to data LDC amalgamation No change Change Change Possible Change No change No change No change No change No change No change No change No change No change No change No change Possible Change No change No change No change No change No change No change Possible Change Smart Meter Processes or Functional Components that Depend on Accurate Relationships Possible Change Possible Change No change Change Possible Change No change Change Change Possible Change The following table identifies the smart meter processes or systems that are impacted by changing data (identified in the table above) caused by ongoing operations and activities. Smart Meter Processes or Functional Components Consumer Name Consumer Account # Service Address Meter # LDC Retailer Contract Web presentment Impact Impact Impact Impact Impact No Impact No Impact Automatic Voice Response Impact Impact Impact Impact Impact No Impact No Impact Retailer requests Impact Impact Impact Impact Impact Impact Impact Consumer Billing Impact Impact Impact Impact Impact Impact Impact Reporting Impact Impact Impact Impact Impact Impact Impact Validation, Editing/ Rebuilding Impact Impact Impact Impact Impact Impact Impact Aggregation Impact Impact Impact Impact Impact Impact Impact Provider Request Impact Impact Impact Impact Impact Impact Impact Smart Meter Processes or Systems Impacted by Changing Data Access to Data Possible Impact Possible Impact Possible Impact Possible Impact Possible Impact Possible Impact Possible Impact Possible Impact Page 15 of 81

16 By identifying a change or possible change for a given data element in the first table, the smart meter processes or functional components impacted by that change can be identified in the second table. A Consumer Directory will retain a record of the relationships between these data elements. As the relationships change, the Consumer Directory will be updated by LDCs to ensure that all smart meter processes or functional components of the Smart Meter Network have access to the correct data on a province-wide basis. It is possible that retailers may not need to participate in, nor be aware of the MDR or Consumer Directory as the retail EBT system could continue to provide the mechanism for accessing consumer information. Retailer may ultimately only submit a request for consumer meter data to the LDC as they do today through the retail EBT network. Issue Suggested Solution Are data exchanges required between LDCs? Further discussion required. Page 16 of 81

17 5.3. Automatic Meter Reading (AMR) System(s) This independent system of components is responsible for interrogating smart meters, collecting and storing meter data, reprogramming TOU/CPP schedules and other meter-specific parameters as required, and generating operational and audit reports. These systems typically have a three-tier hierarchy, in which the highest tier is the data collection master system that communicates with nodes or concentrators that typically have storage capabilities. Concentrators communicate with smart meters to collect the metering data but do not reprogram meter configurations. Concentrators are a conduit used to establish a local communications path to the individual meters. Concentrators are typically a store and forward device. They communicate with both the meter and meter reading system and pass data or instructions back and forth. It is expected that on a regular basis smart meter data collection master systems would interrogate the smart meters either directly or through concentrator devices to retrieve smart meter data. This activity is expected to be scheduled on an ongoing basis due to the volumes of data that must be transported, processed and presented to consumers by the daily deadlines of 8:00 a.m. as recommended by the Ontario Energy Board. The frequency of smart meter interrogation will depend on conditions such as meter storage capacities, concentrator storage capacities (if present), communication infrastructures, number of meters and interval sizes (15 or 60 minutes). Typically AMR systems provide only short-term storage longer term storage is provided by meter data repositories to which the AMR system would send any data collected through the Smart Meter Network. Meter storage capacities will directly impact overall data reliability. Particularly in the early stages of smart meter implementation, intermittent and long-term issues with meter communications systems may be experienced. Meter data storage will be sized to reflect the estimated amount of time required to identify and correct the situation and re-establish proper communications with the meter before data roll-over occurs within the meter. If daily register-to-interval data validation is required, the smart meter data would consist of energy register readings and 15 or 60 minute interval readings for the day. The energy register reading may only be required once per day for daily register to interval data validation. However, the overhead associated with transporting the register read data with each set of interval data may allow for more frequent downloading of the data. The AMR system would transport smart meter data that complies with the smart meter data standards to other functional components for processing. Page 17 of 81

18 In addition to interfaces for transmitting collected meter data, AMR systems also provide interfaces for an LDC s CIS (or other system) to set up and modify meters, collection schedules, and data collection criteria to satisfy billing and other applications. Due to the large meter volumes, it is expected that interfaces that support bulk/high volume transactions would be required. In addition to the basic components, AMR systems may also provide functionality such as: On-demand reads Initial or final billing reads Disconnect/reconnect service at an end point Critical-peak pricing Notification for outages and restorations and other diagnostic information from a metering point Voltage levels Current levels Meter tamper notifications Creation of TOU schedules and assignment and configuration of meters with TOU schedules Some AMR systems provide additional operational information beyond meter readings, such as voltage information, outage notification, tamper detection flags, etc. This operational data may be transferred through the SMN to the LDC rather than to an MDR, or may be stored in an operational layer within the MDR. The SMN s data standards will make provision for the transport of this data between an AMR and an MDR. Page 18 of 81

19 AMR systems consist of computers, data collection/interrogation and reporting software, communications infrastructure (protocols, modems, routers, etc.) and smart meters. AMRs can support two-way communications to allow data requests for such things as load control within a building or remote disconnects. There is no limitation on the number of AMR systems a utility may have. The number of AMRs depends upon the utility s geographic service area and the markets they need to reach (residential, commercial, etc.). Issue Suggested Solution Automatic meter reading conversion to standard format For data transfer to the Smart Meter Network, the data must be raw and should be in a standard format. Need an adapter (converter) Need standardized adapter formats 5.4. Validation, Editing and Rebuilding System Data collected by the AMR system would be validated to ensure that smart meter interval data is complete and correct when compared against energy register and/or historical data. Collected smart meter data would be analyzed by an automated process of validation. The automated process of comparing meter register readings to interval data may be the accepted form of validation. It is expected that approximately 5% of residential and 1% of commercial interval data will be invalid and will require editing and/or estimating. (Although a 99.5% success rate or better should be targeted, 5% represents over 200,000 errors per day). This statistic reinforces the importance of building a quality and robust solution. Invalid data can be missing or bad. In the event of missing data, the AMR system communications infrastructure could be at fault and therefore the data is simply delayed, not missing. If the smart metering system has erred, the data may be lost or corrupted ( bad ). The editing and rebuilding system would utilize historical data to estimate missing data and rebuild corrupted or bad data. Incidents of missing or bad data must be resolved, rebuilt and transported to the MDR for update within three business days. However, it is not expected that all communications issues can be corrected within three days. Timelines should be established to ensure proper corrections are in place for timely bill calculations (10 business days past the trade date). Provision should allow for a secondary feed of proper meter data once the issue is corrected, and the actual data is retrieved from within the meter. It is expected that in some cases the MDR will provide the manual editing function. There are also situations that would allow the data to be manually edited elsewhere, such as by a CIS system. In these cases, the MDR must store and flag the change appropriately. Page 19 of 81

20 A set of rules, to be further defined by other working groups, will determine how the editing and rebuilding system will react when it detects missing or bad data. Currently the Ontario Energy Board Draft Implementation has suggested rules as follows: Cumulative Consumption Meters When estimating for presentment, if either today or yesterday s reading is missing, the daily consumption may be estimated as indicated by the OEB as either: Consumption the day before or, Estimated consumption When Estimating & Rebuilding for billing purposes and the End Reading is missing, the first valid reading (hourly or daily) prior to the billing date shall be used as the end of period reading. Billing for the next period would resume at the new end of period. The result of this calculation would not be marked as estimated since it is based on true meter readings. The beginning of the next billing period must be the same as the ending of the last billing period. If usage periods are missing between the ending of the last billing period and the first valid reading, the consumption between the end of the previous period and the beginning of the current period would be replaced with estimated consumption. The result of the calculation must be marked as estimated. Interval Meters When estimating for presentment, if an interval is missing, the interval consumption may be estimated as indicated by the OEB as either: Consumption in the previous hour or, Estimated consumption Page 20 of 81

21 When Estimating & Rebuilding for billing, for interval durations of one hour or less, linear interpolation may be used to estimate consumption in contiguous 5 or 15 minute intervals. When Estimating & Rebuilding for billing for interval durations over an hour, estimated consumption shall be used for each hour comprising a duration of missing or suspect data. The result of the calculation must be marked as estimated. When truing-up estimations, if cumulative energy registers are available consumption in each hour previously estimated would be scaled to make the consumption over all hours in the period match the cumulative energy register readings for the period. When truing-up estimations, if the meter is fitted with time-of-use registers and critical peak registers, these may be used to calculate the cumulative energy used for true-up. The result of the scaling calculation need not be marked as estimated because true energy consumption is known. The Editing & Rebuilding component is comprised of business rules software that analyzes, validates and estimates (if necessary) the data collected by the AMR system and data storage. Issue Suggested Solution Are manual changes to automated VEE allowed, and how would this function? CSR can perform manual intervention it is done today Data has to be flagged Process change recorded Version Control Functioning Data Audit trail In addition to identifying and correcting missing or bad data, loss adjustment factors (and potentially others) must be applied against consumption values at some point in the process. This has not been defined and requires further discussion and definition. It is important that validation, missing Interval-Fallback position, communication restoration and rules around this data are considered. Please refer to Appendix C for excerpts from various Provincial and Federal Acts that need to be understood in relation to the Smart Meter Initiative. Page 21 of 81

22 5.5. Meter Data Repository (MDR) Meter data repositories are the storage destinations for smart meter data and, at a minimum, should store cleaned interval or time-of-use (TOU) data. Because the SMN provides and enforces the use of the open SMI data standards, many MDRs can be supported in the province, allowing LDCs or commercial vendors to offer MDR services plus other value-added services related to the smart meter data. These services would interface with other functional components using the standard defined SMN interfaces, and would eliminate the risks associated with the use of proprietary MDR solutions. There is a compelling rationale for a single LDC to use more than one MDR: Distributors today already employ different data repositories for commercial/wholesale settlements and mass-market residential meter data. It is unlikely that an LDC would risk modifying their commercial/wholesale MDRs and business processes for the SMI in the early stages of implementation. It is possible that an MDR may store all interval data including flagging missing intervals and bad data, but this would be determined by database design. Data stored in an MDR must be versioned for audit purposes. For example: V1 Raw data from AMR V2 Data with automated validations V3 Data with manual validations The versioning mechanism would be supported by the relevant XML SMN data standard. Versioning may also determine which types of applications can access a specific version of the data. SMN users including LDCs, retailers, service providers and government bodies can access and utilize the data in TOU or interval form using the SMN s data transport and representation standards. This access is managed and controlled by mechanisms within the SMN and the Consumer Directory. It would be preferable for the data storage requirements to be specified by the OEB in the VEE standard. In addition to accepting and storing meter data, the MDRs may also communicate over the SMN to an AMR to support meter management functions such as remote disconnects. Two-way communications over the SMN also exist between the MDRs and the Consumer Directory, data aggregator, Web presentment, LDCs (CIS) and retailers. Page 22 of 81

23 Issue Suggested Solution What is the LDC to retailer interaction for this new data? Use existing Retail Settlement Code for historical billing meter data transfer and Distribution System Code Standards and procedures as minimum standards. Give the retailers the same rights as the consumers they serve. Create new sets of STR transactions and standards so retailers can access interval meter data for the consumers they are serving. Who has rights to data? All meter data related to an enrolled consumer should be available to retailer. All meter data related to consumers within an LDC s territory should be available to the LDC. Special requests for aggregated data (no identifying customer relationship) should be available to all who request it (aggregates of aggregates). How do parties gain access to data? LDC request to MDR, then data to retailer, or: Retailer request to MDR, then data to retailer Create MDR Code and licensing practices that define data ownership. STR transactions showing approvals and updated relationships (meter changes, stopped services, retailer switching, enrolments and drops, corrected bills, etc.) should be updated regularly to the central Consumer Directory. Is the granting of rights to data access a function of the MDR, external consumer directory or CIS? Rights and relationships would be identified by CISs updated to Consumer Directory. Consumer Directory would act as protector of the data and grant access rights. Page 23 of 81

24 How do we establish if a meter starts as a TOU and is changed to interval format? How is it switched to interval? A date and time stamp of a configuration change can be attached to the first read or record and added to the MDR database. TOU meters bring register reads back. Interval meters will bring engineering units back. Would any configuration change happen on a date and time stamped register read? All LDCs may not have TOU and/or interval data available. As per the OEB report first 4 months of operation need to provide consumers with presentment of interval data. After that, it is up to the LDC if interval or TOU data is collected and/or presented. Interval data is required but not required for longer retention periods. Cannot assume that MDR generates data. Request comes through standardized document. Consumers may request meter data from same LDC or different LDC that served them previously. Synchronization process Track consumer relationship Consumer Directory authorization Data to pass within system Does the MDR need to comply with Measurement Canada data storage and type of data storage requirements to allow for dispute tests? Reference Appendix C. Would an MDR provider be a market participant? A separate code should be established setting out the standards and conditions for the interaction between MDRs and all other market participants. Page 24 of 81

25 Will there be licensing for an MDR provider? Need to be certified or self-certified, i.e. hubs don t have OEB numbers. Need to test scalability/throughput. Service needs to meet minimum requirement, which needs to be established. Service must be capable to work through Customer Directory using standard data formats. What terms should be used to reference the different stages of data in the event that it requires rebuilding? The original data (unscrubbed) should be referred to as the "Official Data." Who owns the data? The consumer owns data. Due to the complexity of transactions and the validations that may occur if there is a shared Meter Repository, data has to be properly validated, especially data access rights. A multitude of new STRs would need to be developed along with market rules for timing to allow account/consumer/ premises/meter/data relationships to be validated for consumer and retailer and third party access to correct data. To a large extent, the Consumer Directory will manage these data access rights. Would the MDR provide the algorithms for standard aggregation or would the LDC provide? Enhancement of MDR Official aggregation vs. value-added aggregation. MDR may have the responsibility for standard aggregation once it is better defined. Additional aggregation can be provided by other parties such as data aggregation agents or by the LDCs themselves. What forms of overlays of views of data in aggregated form are required? Data extraction for billing purposes Record of data extraction How are the CIS and MDR, and CIS and AMR synchronized for meter change-out or move-in/out processes? Primary record Synchronization of consumer data Linkage should be tied to Consumer Directory Page 25 of 81

26 The SMI workflow suggests that this consumer data verification access be established outside of the existing CISs to allow for multiple new users requiring access to the data. (Government, OPA, OEB, IESO, etc.) New data and users wishing more frequent access to the data could place a strain on both LDC and retailers existing settlement systems. Those systems should be protected to ensure proper settlements are not impacted during the transition between now and Use existing Retail Settlement Code for billing meter data transfer between LDCs and retailers. The advantage of this approach is that no major changes need to be made initially. Provide additional STR request for interval meter data transfer between retailers and MDRs, which can be passed by the existing retail hubs directly through the Consumer Directory for routing to the appropriate recipient. Provide Web portal for other users requesting aggregated non consumer-specific data. Page 26 of 81

27 5.6. Data Aggregation System (DAS) This system is responsible for grouping data based on available identifiers to fulfil requests by participants for data in a specific format (i.e. time-of-use buckets, by customer class, by date/time range, by specific LDC or retailer). As the MDR would store register and 60 or 15 minute interval data, aggregation is required to roll multiple (24 or 96 per day) interval data units into one or more units of consumed energy that flexible consumer rate plans will require. As rate plan details are not completely defined, the data aggregation solution will need to be flexible in aggregating interval data stored in the MDR into units that may differ from consumer to consumer. As the interval data stored in the MDR is date/time stamped, a data aggregation solution could conceivably eliminate the need for meters to manage TOU buckets or registers. Effectively, the DAS would become a flexible TOU data repository at least to 60 and 15 minute interval levels respectively. Alternatively, time of use metering could be used on a majority of consumer accounts to eliminate or reduce the need for aggregation in the head end. &# * $ ' * ( '( )! %&# #)!#+ # ' $ # $ $$ * $ The data aggregation system will have to aggregate smart meter data according to the billing requirements for each consumer, in support of all energy billing-based calculations including transmission, connection, distribution, global adjustment and any other charges. As the CIS is the source data for the billing requirements for each consumer, a transaction from the CIS will update the data aggregation system with the rollup requirements. The data aggregation system will present data to the CIS when required for billing. As billing must support both on-cycle and off-cycle billings, the CIS will request billing data as required from the meter data repository via the DAS. The aggregation system is comprised of business rules software that compiles the data received from the MDR into units required by the consumer s rate plan. This aggregated smart meter data, in SMI standard-compliant format, would then be sent to the billing and retail settlement solutions. Page 27 of 81

28 Some data aggregation may occur within the MDR or may be handled by a third-party service provider when data is required by more than one MDR. The smart meter system has been designed from a functional perspective to accommodate either scenario. The SMN provides a two-way communications path between the data aggregator and other functional components in the smart meter system. Data aggregation will also be required to provide interval data by rate class or by territory to other users of data. This type of aggregation is different from merely combining interval data into TOU buckets, as it would aggregate depersonalized data of multiple meters and multiple MDRs. A data aggregator could also be used to provide aggregation of specific meters at the request of a consumer with multiple sites spread across the province (i.e.: retail chain stores). Issue Suggested Solution Is aggregated data persistent, offsite? Standard aggregates created by the system can be stored in the MDR, providing quicker access to data. However, this may not be possible due to the fact that the required data may not be present within the MDR (i.e. as in the case when aggregates are required for data residing in more than one MDR). Are TOU schedules preserved at meter point level for consumer access to synchronize with LDC changes? TOU schedules could be part of standard aggregation created by MDR if interval data is used to create buckets. The schedule should come from the OEB codes or the LDC. To what level are aggregates managed by the MDR? Standard aggregates created by an MDR or other system that also provides aggregation. Aggregates of aggregates are outside the scope of the MDR but should be centrally provided for ease of access. Page 28 of 81

29 5.7. Consumer Information System (CIS)/Billing and Retail Settlement System The combination of Consumer Information System (CIS), billing system, and retail settlement system form a set of software components that an LDC and retailer use to manage their consumers. While an LDC will own or have access to each of these systems, it is conceivable that a retailer will not have a billing system. Billing is a sub-system or component of the CIS. The Ontario LDC CIS/billing system is typically a vendor-supplied set of fully or semi-integrated components. In some cases, the LDC has created its own custom CIS/billing application. CIS/billing systems could include account and service management, bill calculation and preparation, remittance interface, service order management, accounting (AR) interface, reporting and, typically, a handheld meter reading system interface for register meter reading. Retail settlement is another sub-system or component of the CIS that the CIS vendor would provide, or in the case of custom CIS/billing applications the LDC would create itself. Retail settlement systems manage the difference between the spot market cost of energy and the price the consumer pays for the energy. These systems ensure that the LDC and retailer are accurately compensated for the transactions on a consumer s energy bill in accordance with the Retail Settlement Code, and are typically an integrated component of the CIS/billing system and interface to accounting systems. In an effort to ensure that existing settlements between LDCs and retailers are not adversely affected, both systems should be isolated as much as possible from the changes related to smart metering. It would be wise to separate meter data functions from settlements functions through the process. A similar concept such as the EBT Hub concept would allow any user with the appropriate authorization to access data. Steps should be taken to ensure that the existing CIS/billing and settlement systems do not become a bottleneck or road block to easy access to meter data. Each LDC and retailer CIS/billing and settlement system would process smart meter data on regularly scheduled billing cycles and as required for off-cycle billing. If distributor consolidated billing (DCB) is performed, aggregated smart meter data could be transported from the data aggregation system to the LDC billing and settlement system. In the event that retailer consolidated billing (RCB) is performed, aggregated smart meter data will be transported over the SMN to the retailer billing and settlement system and to the LDC s billing and settlement system. The current process for sending data to the Retailer for RCB involves additional information for all billing on all services (i.e. monthly charges for distribution, transmission, IESO, water heaters, water, etc.). The interaction between systems also includes the appropriate loss factor information for the consumer. Page 29 of 81

30 The LDC CIS/billing system is currently the authoritative source system for the account/meter relationship. If data is passed over the SMN from the MDR to a consumer for Web presentment, for example, the system must ensure that meter data is only available to the correct consumer. The Consumer Directory will need to maintain an accurate and up to date record of which meter belongs to which consumer. This includes coordination of data following regular meter change-outs for maintenance, upgrades and according to the requirements of Measurement Canada. This functionality would be provided through the SMN s Consumer Directory. The account/meter relationship can have multiple layers. One or more meters measure usage at a service. One or more services are installed at a premise. One or more premises may relate to one account. One or more accounts may relate to a consumer. Only one retailer at a time can relate to one account. However, the EBT rules recognize the rights of a future retailer or agent-only retailer to access certain data relating to a consumer s account. Account/premises/service/meter relationships are complicated by consumers moving. One consumer or one account may have more than one premise for periods of time during a move transaction. An account may have no meter data if the consumer is moving between locations and has no premise for a period of time. However, the account may be active during this time, depending on the LDC s practices. Consumers frequently inform LDCs about their moving transactions after the moves have taken place. Data presented daily over the Web could potentially be presented to the wrong consumer in these cases. Currently billing corrections take place within the CIS/billing system of the LDC. Billing corrections are required for many reasons. Page 30 of 81