MV-STAR. I/O Reference Guide

Transcription

1 T MV-STAR I/O Reference Guide

2 ii Identification TDR /04 MV-STAR Release Trademark Notice Itron is a registered trademark of Itron, Inc. Windows, Windows 95, Windows 98, Windows 2000, and Windows NT are registered trademarks of Microsoft Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape and Netscape Navigator are U.S. trademarks of Netscape Communications Corporation. Oracle is a registered U.S. trademark of Oracle Corporation, Redwood City, California. Sun, Sun Microsystems, and the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. The names wuftpd and wu-ftpd are trademarks of the WU-FTPD Development Group and the Washington University at St. Louis. This product includes software developed by the Apache Software Foundation ( Disclaimer of Warranties and Limitation of Liability There are no understandings, agreements, representations, or warranties, express or implied, including warranties of merchantability or fitness for a particular purpose, other than those specifically set out by any existing contract between the seller and buyer. Any such contract states the entire obligation of seller. The contents of this guide shall not become part of or modify any such prior or existing agreement. The information, recommendations, descriptions, and safety notations are based on Itron experience and judgment. This information should not be considered as all-inclusive or covering all cntingencies. If further information is required, Itron should be consulted. In no event will Itron be responsible to the user in contract, in tort (including negligence), strict liability or otherwise for any special, direct, indirect, incidental, or consequential damage or loss whatsoever; or claims against the user by its customers resulting form use of information, recommendations, descriptions, or safety notations. Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without permission of Itron. Copyright Itron All rights reserved Technical Support [email protected] Website Fax Telephone (The technical support representative will ask for your product serial number located on the CD-ROM case.) The technical support representative may also ask you to provide some or all of the following information: Application Version number Error message text Error message log file Screen name Function performed prior to the problem

3 iii About This Document This document describes file formatting and standards used by the MV-STAR system for reports and files such as Request and Acknowledgement files, EDI reports, and loss equations. This is a generic guide; not all sites use all features of the MV-STAR core product. Revision History Date Chapter Description 06/01 Chapter 3 Loss Factor Equations Related Documents MV-STAR System Administration Guide MV-STAR User Guide Corrected equations in calculations 1-9 in the Transformer equations section. 06/01 Chapter 2 File Format Added Raw DTD Description to the XML File Format section. 07/01 Chapter 2 File Format Added MDEF file format. 07/01 Chapter 2 File Format Added MV-90 Master File format. 08/01 Chapter 2 File Format Added MV-90 Register Read Loader format. 12/01 Chapter 2 File Format Added PAD information (sections Coding Scope through Loading Interval Absolute PAD). 08/02 Chapter 1 EDI867 Specifications 06/04 Chapter 1 EDI867 Specifications 06/04 Appendix B Appendix C Added code 39 to MEA measurements information on page 32. Removed this chapter and incorporated EDI867 implementation to the File Formats chapter (which became Chapter 1). Added the following information to the XML File Format section: XML Enrollment XML Register Read XML Meter Information XML Loss Configuration XML Meter Point XML Physical Allocation Data XML Loss Added Appendix B which discusses Date Truncation. Added Appendix C which contains examples of files exported from or imported into MV-STAR. TDR /04

4 iv How This Document is Organized Chapter/Appendix Chapter 1 EDI867 Specifications Chapter 1 File Formats Chapter 3 Loss Factors Equation Appendix A Appendix B Appendix C Description A proposed interchange standard for EDI-867 implementation. Describes the formatting of MV-STAR files: Request File Formats Acknowledgement File Formats XML File Formats Describes Method 1 and Method 2 of loss equations. Contains third party acknowledgements. Describes date truncation. Lists examples of files exported from or imported into MV-STAR. Note: This document was designed to be distributed electronically and then printed on a laser printer on an as-needed basis. For this reason, the fonts and layout of this document have been chosen for optimal printing rather than for optimal viewing on-screen. To review this document on-screen, however, simply increase the magnification using the magnification box at the bottom of the window.

5 v Notes TDR /04

6 vi

7 Contents v FILE FORMATS... 1 Acknowledgement File Format... 2 Successful Parse Format... 2 Example successful parse format:... 2 Example Example Unsuccessful Parse Format... 3 Example Unsuccessful Parse Format... 4 Request File Format... 5 General Rules... 6 Example... 6 Request File Required Fields... 6 Password... 6 Report_type... 6 Request_reference... 7 Request File Report-Specific Fields... 7 EDI867REP... 8 meter_id... 8 meter_type... 9 start_datetime and end_datetime... 9 loss_flag... 9 version... 9 participant_role redundant_dtm_flag settlement_date associated_id EDI867 FILE REQUEST FORMAT EXAMPLE Register Report Request File XML File Special Handling Output Register Report Format EDI867 Specifications IESO EDI-867 Implementation Document Convention Loop Structure Element Structure Product Transfer and Resale Report ISA Interchange Control Header TDR /04

8 vi Element Summary GS Functional Group Header Semantics Comments Element Summary ST Transaction Set Header Semantics Element Summary BPT Beginning Segment for Product Transfer and Resale Semantics Element Summary N1 Name Syntax Comments Element Summary REF Reference Identification Comments Element Summary PTD Product Transfer and Resale Detail Syntax Comments Element Summary REF Reference Identification Comments Element Summary QTY Quantity Element Summary MEA Measurements Syntax Semantics Comments Element Summary REF Reference Identification Syntax Notes Element Summary DTM Date/Time Reference Syntax Comments Element Summary SE Transaction Set Trailer Comments Element Summary GE Functional Group Trailer Semantics Comments... 45

9 vii Element Summary IEA Interchange Control Trailer Element Summary MDEF File Format File Structure RCODE Meter (Recorder/Site) Header Record Layout Start and Stop Times DST Flag Channel Header Record Layout Start and Stop Times Interval Data Record Layout Channel Status (2 Bytes) Interval Status (2 Bytes) Trailer Record Layout Time Stamp MV-90 Register Read Loader Error Handling MV-90 Master File Format XML File Format Enrollment Interface Enrollment File Rules Register Read Loader Register Read Loader Rules Meter Information Loader Meter Information Loader Rules Loss Configuration Loader Loss Configuration Loader Rules Meter Point Loader Meter Point Loader Rules Physical Allocation Data (PAD) Loader Pad (Physical Allocation Data ) Loader Rules General Business Rules Loss Loader Loss Loader Rules General business rules INTERFACES Table Based Formats Generation Schedule Loader Database Model SCHEDULE_SET SCHEDULE_SET_MEMBER DISPATCH_INT IMO Master File Loader Database Model Generation Schedule Loader Rules TDR /04

10 viii Loading Participant Information Loading Participant Role Information Loading Delivery Points Loading Contract Information LOSS EQUATIONS General Import/Export Rules Transformer Equation Calculated Values Assumed Quantities Assumption Assumption Assumption Calculation Calculation Calculation Calculation Calculation Calculation Calculation Calculation Calculation Volt Ampere Equation APPENDIX A Third Party Acknowledgements The Apache Software License, Version APPENDIX B Date Truncation APPENDIX C Export/Import Files mvstartransaction.dtd ( loss and pad ) Loss File Example PAD File Example MVSTAR_ENROLLMENT.xsd Enrollment Example MVSTAR_SITE_REGISTRATION.xsd Meter Information File Example MVSTAR_REGISTER.xsd Register File Example MVSTAR_LOSS_CONFIGURATION.xsd Loss Configuration Example MVSTAR_METERPOINT.xsd Meter Point File Example

11 1 File Formats This chapter describes the formatting of files that are exported from, or imported into the MV-STAR system: Acknowledgement File Request File EDI 867 MV90 MDEF MV90 Register Read MV90 Master File XML Enrollment XML Register Read XML Meter Information XML Loss Configuration XML Meter Point XML Physical Allocation Data XML Loss

12 2 Acknowledgement File Format Acknowledgement File Format There are two file formats for acknowledgement files. The first format is used for requests or submissions that are parsed successfully; the second format is used when a request could not be parsed. The Acknowledgement file examples given are in response to Request files for meter data, PAD submissions as well as Losses submissions. The Event Symbol and the Event Message will change to appropriately reflect the status of the transaction. Successful Parse Format The file contains the information in fields as shown in the following table. A colon delimits the fields. The Type field indicates the maximum length of the data that the specified field can have. Name Type Description Event Symbol CHAR(20) Describes event Event Type CHAR(1) I informational, W warning, E error Event Message CHAR(900) Textual message describing what happened. Example successful parse format: TASK_START: I: Job SID , Job Type EDI867REP started, CONTEXT StarAppliction starting RUNPARAM: I: Retrieved parameter: start_datetime = RUNPARAM: I: Retrieved parameter: report_type = EDI867REP RUNPARAM: I: Retrieved parameter: debug = y EDI_INFO_SEGMENT: I: Segment < ST> processed. EDI_INFO_SEGMENT: I: Segment < BPT> processed. EDI_INFO_SEGMENT: I: Segment < N1> processed. IFACESUCCESS: I: Interface succeeded Example 1 TASK_START is the Event Symbol. I is the Event Type. In this case informational. Job Sid , Job Type EDI867REP started, CONTEXT StarApplication starting. This is the message describing that an EDI867 report was started by the STAR application.

13 Acknowledgement File Format 3 Example 2 IFACESUCCESS is the Event Symbol. I is the Event Type. Interface succeeded. This is the message. There are close to 1000 Event Symbols possible, Itron has made a conscious decision not to include them in this document. Note: The event message can contain colons(:) within it and in this case are not field delimiters. Unsuccessful Parse Format The following acknowledgement is produced when a submitted request can not be parsed. The request acknowledgement file is a plain ASCII text file with a filename of the form partid_ee.ack where partid is the Participant ID requesting the report and EE is a sequential number to guarantee file name uniqueness. The file contains the request information in the form of fields. All fields are mandatory, and a carriage return character delimits each field. The following table defines the fields. Name Type Description Participant ID CHAR(15) Participant Identification for Participant Request_Reference CHAR(30) Participant request reference Status CHAR(7) FAILURE Error Message CHAR(100) Textual message describing what happened TDR /04

14 4 Acknowledgement File Format Example Unsuccessful Parse Format Participant ID: AGROUP Request_Reference: REF001 Status: FAILURE Error Message: To Datetime: From Datetime: cannot be greater than: (minutes) In this example: The Participant ID is AGROUP The Request_Reference is REF001 The Status is FAILURE The Error Message indicates that the date range was erroneously specified. The format for Datetime is: YYYYMMDDHH24MI where YYYY is the year, MM the month, DD the day, HH24 the hour and MI the minute.

15 Request File Format 5 Request File Format MV-STAR request files enable market participants and other external systems to initiate report jobs in the MV-STAR system and receive the results of these reports without the intervention of an MV-STAR operator. Request files are typically used to permit market participants to request and receive reports on the data within the MV-STAR system. MV-STAR enforces standard data access restrictions for reports that are run via a request file. Request files from users without a participant ID and participant IDs without a participant password will be rejected by MV-STAR. If a participant successfully submits a request file, a job will be scheduled to produce the report. If the report executes successfully, the results, as well as an acknowledgement file, will be sent to the location specified within the MV-STAR system for that participant ID and that report. Typically, the destination for reports is set to a machine owned by the participant or a staging server external to the MV-STAR server but within the organization that administers MV-STAR, such as MV-WEB. If the report fails, an acknowledgement file will be sent to the user with details about why the report failed. The request file contains information that the MV-STAR system uses to identify the user and validate user access to the system. The request file also specifies the report that is being requested and the parameters that should be used by the report. Each line in an MV-STAR request file specifies a parameter name and value. Several parameters are necessary in every request file; other parameters vary from one report to another. The valid parameter names are described later in this document. The request file also may contain comment lines to aid the requester in identifying the request. Comment lines are ignored by the MV-STAR system. Each line in an MV-STAR request file specifies a parameter name and a parameter value or a comment. Comment lines begin with an octothorp (#) and are ignored by MV-STAR. Comments should not be placed on the same line as a name-value pair. All other lines specify a single parameter and its value. White space (tabs and spaces) will be stripped from each line. The parameter name must be formatted exactly as specified in this document, including spelling, case, and underscores. The parameter name is followed by an equal sign and the parameter value. The parameter value must be 100 characters or less. If any parameter value is longer than 100 characters, the request file will be rejected. If either the parameter name or the parameter value is not supplied, the request file will be rejected. The parameter value should be followed by a line feed or a carriage return, line feed pair. For example, lines in a request file that properly follow these rules look like the following: parameter_name1=parameter_value1 parameter_name2=parameter_value2 A sample of an actual request file is given in a later section. TDR /04

16 6 Request File Format General Rules The MV-STAR request file is a plain ASCII text document. The filename should have the form 'YYYYMMDDHH24MI_EE.REQ'. The YYYY, MM, DD, HH24, and MI are the year, month, day, hour, and minute, respectively, of the time when the file was generated. EE is a sequential number to guarantee file name uniqueness when a participant generates multiple request files at the same time. The sequence number may be set to 00 unless the participant is submitting multiple files at once. Example If a participant programmatically generates 3 request files at 3:45 P.M. on the second of January 2000, then their filenames would be _00.REQ, _01.REQ, and _02.REQ. Request File Required Fields The following table defines the fields that are required in all request files. These parameters are used by the MV-STAR system to process the request file. They include information to validate the participant, schedule the correct report, and identify the request in acknowledgment files. Parameter Name Max. Length Format (example) Required/Optional password 20 SCPASSWORD Required report_type 10 EDI867REP Required request_reference 30 REF001 Required Password The password field is the participant's password in MV-STAR. This password is maintained by the MV-STAR operators and can be set in the PARTPASS form, accessed by clicking the "Password " button on the Report Recipient screen. Report_type The report_type is a special value that indicates a job within MV-STAR. Currently the only report types that can be initiated via a request file is EDI867REP, which produces a report formatted according to the EDI867 standard and Register Report which is used for Register Reads only.

17 Request File Format 7 Request_reference The request_reference field is not used directly by the MV-STAR code. This value is included in the acknowledgement file that is sent in response to the request file. The participant can use this value to determine which acknowledgement files correspond to which request files. The requestor can fill the field with any string that fits the size limit. It is especially useful when a participant submits several request files and receives one or more acknowledgement files indicating a rejected request. Note: This field should not contain spaces. Request File Report-Specific Fields The remaining parameters are specific to each report_type. When submitting a request file, check the report-specific parameters for the appropriate report_type. TDR /04

18 8 Request File Format EDI867REP Parameter Name Max. Length Possible Values Required/Optional meter_id 20 Any valid Metering System ID in MV-STAR or any of the following strings: ALL ALLDP - the participant s Delivery Points only ALLSM - the participant s Summary Maps only ALLSP - all Service Points for the participant ALLMP - all Meter Points for the participant Required meter_type 1 I Required start_datetime 12 Any date in a YYYYMMDDHH24MI format end_datetime 12 Any date in a YYYYMMDDHH24MI format Required Required loss_flag 1 Y or N Optional version 16 Current, Current Validated, First, or YYYYMMDDHH24MI participant_role 4 Any valid Market Role in MV-STAR, such as MMP or LDC. Optional Optional redundant_dtm_flag 1 Y or N Optional settlement_date TBD To Be Determined Optional (not implemented) associated_id 15 Any valid participant id Optional meter_id The EDI867 report will include data for the specified meter_id. The meter_id can be the MV-STAR metering system ID for any metering system. The special value "ALL" indicates that the EDI867 report should gather data for all of the participant's meters.

19 Request File Format 9 meter_type The meter_type indicates the type of meter. "I" indicates interval meters and is currently the only supported meter_type. start_datetime and end_datetime The EDI867 report will include data during the time window between the starting date and time and the ending date and time specified by these parameters. The format of these fields can be expressed as YYYYMMDDHH24MI, where YYYY is the year, MM is the month, DD is the date, HH24 is the hour (on a 24 hour clock), and MI is the minute. The year, month, date, hour, and minute portions of the date are all numeric and padded on the left with zeroes if necessary. For example, 1:35 P.M. on Tuesday, January 2, 2001, would be expressed as , and midnight on Wednesday, January 3, 2001, would be expressed as loss_flag The loss_flag specifies whether the reading values in the EDI867 report should include losses when there is an option of whether to apply losses or not. If loss_flag is set to "Y", then losses will be included in the reading values whenever there are losses to apply. If the loss_flag is set to "N" or is not specified, the reading values will not include loss information if readings without losses are permitted by the market rules. If market rules dictate that losses must be applied to a particular metering system, then this flag will be ignored. version The version parameter indicates which version of the data should be included in the report. If the version is not specified, the report will default to the "Current" version. Since the MV-STAR system maintains multiple historical versions of meter reading data, several versions of each meter reading may be available. The version flag may be: One of the strings "Current", "Current Validated", or "First" (without the quotes) A date specified by the date format YYMMDDHH24MI that is used by the start_datetime and end_datetime parameters. For example, the version indicates September 1, 2000, at 1:00 P.M. If version is set to: "Current", the data that is active in MV-STAR at the time the report is run will be used. "Current Validated", the report will use the most recent version that has been accepted by the MV-90 system. "First", the report will use the first version of data loaded for the metering system. If the version specifies the date, then the data will be reported as though the report were run in MV-STAR on that date. That is, MV-STAR's historical record of the data on the specified date will be used. Note: Some metering systems only support a subset of the versions. A Meter Point supports all of the versions. Summary Metering Systems and Delivery Points only support the "Current" and "YYYYMMDDHH24MI" versions. If an invalid version is specified, the report will fail. TDR /04

20 10 Request File Format participant_role The EDI867 report only reports meter readings that the requestor can access through a contract. For example, a market participant to delivery point relationship, where a market participant may have multiple relationships with a delivery point. If the requestor sets the participant_role parameter, then the report will only show the reading values that the requestor can access via contracts of the specified market role. If the requestor does not specify a participant_role, then the report will use all of the requestor's contracts when determining whether the participant has access to view a particular meter reading. redundant_dtm_flag The EDI867 format permits the DTM field to be omitted when the time for an interval reading can be deduced from a previous DTM field and the interval size. Some information systems require a DTM field for every interval although these redundant DTM fields are not required by the EDI867 specification. If the redundant_dtm_parameter is set to "Y", then a DTM field will be included with every interval reading in the EDI867 report file. If this parameter is set to "N" or is not specified, then the EDI867 report will include a DTM field where it is required by the EDI867 format only. Note: Setting this flag to "Y" will result in significantly larger report files. settlement_date The settlement_date flag is not implemented in the current release of MV-STAR. When the settlement_date functionality is implemented, a new revision of this document will be released. associated_id The associated_id is the participant ID of the entity allowing access to this meter's data. For example, if a participant named Frodo were to hold a metered market participant relationship to a meter, he could allow Sam, another participant, to view it. In other words, Frodo would create an "association" on a given meter for Sam. In this case, Sam would submit a request file in which Sam would be the participant (and use Sam's password), while Frodo would be entered as the associated_id. Presuming that Sam has requested data from the time period covered by the association and for meters so covered, he will receive a report identical to that which Frodo would receive, having requested it as the metered market participant. EDI867 FILE REQUEST FORMAT EXAMPLE # This line is a comment line # The next three fields are required in all request files password=password report_type=edi867rep request_reference=ref001 # The following fields are specific to the EDI867REP report_type meter_id=all meter_type=i start_datetime= end_datetime=

21 Request File Format 11 version= participant_role=mmp # The loss_flag has been omitted since it is optional. redundant_dtm_flag=n Register Report The objective of this report is to output register reads XML format for a given request (.req) file. Request File The request file (.req) for a Register Report attributes are: This report is a standard MV-STAR request file oriented report. The file transfer is from CSS to MV-STAR The extension is.req. The content of the Register Report request file must be: Sample register read request file Password = CSSPWD (assigned by MV-STAR) Report type = REGREPORT (assigned by MV-STAR) Request reference = RRCSS01 (alpha-numeric - assigned by CSS) Exact field name (such as meter_id) Exact date format start_datetime= end_datetime= Meter ID = POD0001 Register type: TOTAL_KWH TOTAL_KVARH PEAK_KWH PEAK_KVAR In the request file, any combinations of the four register types are allowed. The four register types that MV-STAR supports are: TOTAL_KWH TOTAL_KVARH PEAK_KWH PEAK_KVAR TOTAL_KWH and TOTAL_KVARH are the consumption reads over a given time period. TDR /04

22 12 Request File Format PEAK_KWH and PEAK_KVAR are the maximum reads over the given time period. XML File The output file (XML) for a Register Report attributes are: The file transfer is from MV-STAR to an external system The file report format is XML Special Handling If there are more than one consumption reads for the given time period, the last read will be reported. If there are more than one peak reads for the given time period, the highest read will be reported. Output Register Report Format The header portion of the report is always the same. The text "RegRptTst" is always the same text value that appears in the REFERENCE_ID element. If no request_reference parameter is given (only possible when scheduling the report via the GUI), the CORELATION_ID begin/end tags will be present without any reference text between. The SCHEMA_VERSION element is MV-Star documentary info that indicates which XML schema version was used to produce the xml report. <?xml version="1.0" standalone="yes"?> <CORELATION_ID>RegRptTst</CORELATION_ID> <REGISTER_TRANSACTION> <SCHEMA_VERSION>1</SCHEMA_VERSION> This line of the report is only generated when the request_reference parameter is present. <REFERENCE_ID>RegRptTst</REFERENCE_ID> Beginning of meter data. If the meter id parameter specifies a valid delivery point meter, the REGISTER_SET element is produced. If the meter id is not a valid delivery point meter, an info log message " meter_id invalid for REGREPORT " is posted and the report skips the REGISTER_SET entirely and the job completes with "Interface succeeded". <REGISTER_SET MeterId="SS_METER1D"> For each register_type parameter in the request file, REGISTER elements are written in the report. Since the types are optional, there may be 0 to 4 REGISTER elements contained in the REGISTER_SET.

23 Request File Format 13 The "Type=" attribute will always be shown, however "Multiplier=" and "MaximumValue=" are optional and only appear when there is corresponding data in the data base. Each REGIS-TER element may or may not contain RELATIVE_READING information. If there is no reading data found within the date range stipulated by the start/end date parameters, the RELATIVE_READING line for its corresponding REGISTER element is omitted. <REGISTER Type="TOTAL_KWH" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read=" " ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="PEAK_KW" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read="3.4425" ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="TOTAL_KVARH" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read=" " ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> <REGISTER Type="PEAK_KVAR" Multiplier="1.1" MaximumValue="1023"> <RELATIVE_READING Read="1.7352" ReadDate=" T07:28:00" Fir-stReading="Y" RolloverCount="0"/> </REGISTER> End of meter data. </REGISTER_SET> This is the report trailer indicating the conclusion of the report (always present). </REGISTER_TRANSACTION> TDR /04

24 14 EDI867 Specifications EDI867 Specifications This proposed interchange standard is based on the EDI-867 implementations already in use in other jurisdictions. This document represents the sub-set of the EDI-867 standard required for transferring interval meter reading data between parties in Ontario's deregulated electric market place. The general parameters for the EDI-867 transfer set for use in the utility industry were developed by the Utility Industry Working Group. Please see for the full EDI-867 specification. IESO EDI-867 Implementation The UIG EDI-867 specification, release 4010 recommends against the use of "ZZ" qualifier. "ZZ" is used to indicate mutually defined identifiers between trading partners. In general avoiding "ZZ" represents a best practice. Rather than create special identifiers, use ones that already exist and are maintained by a neutral third party. Nevertheless, the "ZZ" qualifier is used at several points in this implementation. Generally, when the "ZZ" qualifier is used it represents an identifier which is supplied by the IESO itself, and which market participants must follow in order to exchange data with the IESO. Fields and segments not in use in this implementation guide are not listed. Please note that element reference is positional. Thus, if an element is not included in a segment, element delimiters are still required. For example, if a segment includes the QQ101, QQ103 and QQ104 elements, the output will look like: QQ*Data for 101**Data for 103*Data for 104 Document Convention This document follows several conventions. In each segment description there are columns labeled, Req, Max Use, Repeat, Note, and Usage. These columns are as follows: Loop Structure Req Max Use Repeat Usage Indicates whether a field is Mandatory, Conditional or Optional within the general EDI-867 framework. Mandatory indicates the value is always required for a valid EDI-867. Conditional indicates a value may be required, being dependent on previous values or other conditions. Optional means the value is not required for a valid EDI-867, but may be used. Indicates the maximum number of times an element may be used with a given segment or loop. Indicates the maximum (e.g. 5) or minimum (e.g., > 1) number of times a loop must be present. Indicates the actual usage under this implementation. This field may be "used" or "must use". Must use indicates that the value must be present, regardless of whether it is optional in the broader EDI spec, for proper exchange of data with trading partners under this implementation. "Used" indicates that the value is used by trading partners in this implementation based on the conditions outlined within the specification.

25 EDI867 Specifications 15 Element Structure Req Indicates whether a field is Mandatory, Conditional or Optional within the general EDI-867 framework. Mandatory indicates the value is always required for a valid EDI-867. Conditional indicates a value may be required, being dependent on previous values or other conditions. Optional means the value is not required for a valid EDI-867, but may be used. Type Indicates the type of the value contained within the elements. Types include ID - specifically defined identifier, AN - alphanumeric string, DT - datetime string. Min/Max Usage Indicates the minimum and maximum number of characters within the field. Note: fixed length fields (fields where the maximum and minimum are the same) will be right padded with spaces to the end of the field. Indicates the actual usage under this implementation. This field may be "used" or "must use". "Must use" indicates that the value must be present, regardless of whether it is optional in the broader EDI spec, for proper exchange of data with trading partners under this implementation. "Used" indicates that the value is used by trading partners in this implementation based on the conditions outlined within the specification. 867 Product Transfer and Resale Report This proposed interchange standard contains the format and establishes the data contents of the Product Transfer and Resale Report Transaction Set (867) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to: (1) report information about product that has been transferred from one location to another; (2) report sales of product from one or more locations to an end customer; or (3) report sales of a product from one or more locations to an end customer, and demand beyond actual sales (lost orders). Report may be issued by either buyer or seller. This document describes the implementation to be used for the Ontario electric meter read data transfer. In the Ontario market, meter reading data will be provided by the IESO to market participants when they electronically request it. The format described in this document is the one which will be used to supply this data. Note: 2/010Each use of the PTD loop will represent one meter register (channel). Transaction Control Header Pos ID Segment Name Req Max Use Repeat Notes Usage ISA Interchange Control Header M 1 Must use GS Functional Group Header M 1 Must use TDR /04

26 16 EDI867 Specifications Heading Pos ID Segment Name Req Max Use Repeat Notes Usage 010 ST Transaction Set Header M 1 Must use 020 BPT Beginning Segment for Product Transfer and Resale M 1 Must use LOOP ID - N NI Name 0 3 Must use 120 REF Reference Identification 0 2 Must use Detail Pos ID Segment Name Req Max Use Repeat Notes Usage LOOP ID - QTY QTY Quantity 0 1 Must use 160 ME A Measurements 0 1 Used 190 REF Reference Identification 0 2 Used 210 DT M Date/Time Reference 0 2 Used LOOP ID - PTD PTD Product Transfer and Resale Detail M 1 N2/010 Must use 030 REF Reference Identification O 10 Used

27 EDI867 Specifications 17 Summary Pos ID Segment Name Req Max Use Repeat Notes Usage 030 SE Transaction Set Trailer M 1 Must use Transaction Control Trailer Pos ID Segment Name Req Max Use Repeat Notes Usage GE Functional Group Trailer M 1 Must use IEA Interchange Control Trailer M 1 Must use ISA Interchange Control Header To start and identify an interchange of zero or more functional groups and interchange-related control segments. The ISA segment explicitly uses fixed length fields. TDR /04

28 18 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage ISA01 I01 Authorization Information Qualifier Description: Code to identify the type of information in the Authorization Information field. M ID 2/2 Must use Code Name 00 No Authorization Information present. (No meaningful information in I02.) Note: No other codes are supported in this implementation at this time. ISA02 I02 Authorization Information Description: Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier. (I01) ISA03 I03 Security Information Qualifier Description: Code to identify the type of information in the Security Information field. M AN 10/10 Must use M ID 2/2 Must use Code Name 00 No Security Information present. (No meaningful information in I04.) Note: No other codes are supported in this implementation at this time. ISA04 I04 Security Information Description: This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03). M AN 10/10 Must use

29 EDI867 Specifications 19 Ref ID Element Name Req Type Min/ Max Usage ISA05 I05 Interchange ID Qualifier Description: Qualifier to designate the system/method of code structure used to designate the sender or receiver ID element being qualified. M ID 2/2 Must use Code ZZ Name Mutually Defined Note: No other codes are supported in this implementation at this time. ISA06 I06 Interchange Sender ID Description: Identification code published by the sender for Other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element. ISA07 I05 Interchange ID Qualifier Description: Qualifier to designate the system/method of code structure used to designate the sender or receiver ID element being qualified. M AN 15/15 Must use M ID 2/2 Must use Code ZZ Name Mutually Defined Note: No other codes are supported in this implementation at this time. ISA08 I07 Interchange Receiver ID Description: Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them. ISA09 I08 Interchange Date Description: Date of the interchange. ISA10 I09 Interchange Time Description: Time of the interchange. M AN 15/15 Must use M DT 6/6 Must use M TM 4/4 Must use TDR /04

30 20 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage ISA11 I10 Interchange Control Standards Identifier Description: Code to identify the agency responsible for the control standard used by the message that is enclosed by the interchange header and trailer. M ID 1/1 Must use Code U Name US EDI Community of ASC X.12, TDCC, and UCS Note: No other codes are supported in this implementation at this time. ISA12 I11 Interchange Control Version Number Description: This version number covers the interchange control segments. M ID 5/5 Must use Code Name Draft Standards for Trial Use Approved for Publication by ASC X12 Procedures Review Board through October Note: No other codes are supported in this implementation at this time. ISA13 I12 Interchange Control Number Description: A control number assigned by the interchange sender. ISA14 I13 Acknowledgment Requested Description: Code sent by the sender to request an interchange acknowledgment (TA1). M NO 9/9 Must use M ID 1/1 Must use Code Name 0 No acknowledgement required. Note: No other codes are supported in this implementation at this time.

31 EDI867 Specifications 21 Ref ID Element Name Req Type Min/ Max Usage ISA15 I14 Usage Indicator Description: Code to indicate whether data enclosed by this Interchange envelope is test, production or information. M ID 1/1 Must use Code P T Name Production Data Test Data Note: No other codes are supported in this implementation at this time. ISA16 I15 Component Element Separator Description: The component element separator is a delimiter and not a data element, so "Type" is not applicable. This field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator. The Component Element Separator will always be a colon in this implementation. Composite fields are not used in this implementation. M 1/1 Must use Example ISA^00^ ^00^ ^ZZ^THEIESO ^zz^ ^001213^1740^u^00401^ ^0^p^: GS Functional Group Header To indicate the beginning of a functional group and to provide control information. Semantics 1. GS04 is the group date. 2. GS05 is the group time. 3. The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02. TDR /04

32 22 EDI867 Specifications Comments A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer. Element Summary Ref ID Element Name Reg Type Min/Max Usage GS Functional Identifier Code Description: Code identifying a group of application related transaction sets. M ID 2/2 Must use Code PT Name Product Transfer and Resale Report (867) Note: No other codes are supported in this implementation at this time. GS Application Sender's Code Description: Code identifying party sending transmission; codes agreed to by trading partners. M AN 2/15 Must use GS Application Receiver's Code Description: Code identifying party receiving transmission. Codes agreed to by trading partners. GS Date Description: Date expressed as CCYYMMDD M AN 2/15 Must use M DT 8/8 Must use

33 EDI867 Specifications 23 Ref ID Element Name Reg Type Min/Max Usage GS Time Description: Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99) GS06 28 Group Control Number Description: Assigned number originated and maintained by the Sender GS Responsible Agency Code Description: Code used in conjunction with Data Element 480 to Identify the issuer of the standard. M TM 4/8 Must use M NO 1/9 Must use M ID 1/2 Must use Code X Name Accredited Standards Committee X12 Note: No other codes are supported in this implementation at this time. GS Version / Release / Industry Identifier Code Description: Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed. M AN 1/12 Must use TDR /04

34 24 EDI867 Specifications Ref ID Element Name Reg Type Min/Max Usage Code Name Draft Standards Approved for Publication by ASC X12 Procedures Review Board through October Note: No other codes are supported in this implementation at this time. Example GS*PT*THEIESO*000000* *1740*636*X* ST Transaction Set Header To indicate the start of a transaction set and to assign a control number. Semantics The transaction set identifier (ST01) used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set). Element Summary Ref ID Element Name Reg Type Min/ Max Usage ST Transaction Set Identifier Code Description: Code uniquely identifying a Transaction Set. M ID 3/3 Must use Code Name 867 Product Transfer and Resale Report

35 EDI867 Specifications 25 Ref ID Element Name Reg Type Min/ Max Usage ST Transaction Set Control Number Description: Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set. Note: This number is used to pair the Transaction Set Header with the Transaction Set Trailer. In EDI formats where multiple ST segments can occur, this control number is very important to maintaining the integrity of the file. In this EDI-867 implementation, only one ST loop is allowed per file. Because of this restriction this value will always be M AN 4/9 Must use Example ST*867*0001 BPT Beginning Segment for Product Transfer and Resale To indicate the beginning of the Product Transfer and Resale Report Transaction Set and transmit identifying data. Semantics 1. BPT02 identifies the report number. 2. BPT03 identifies the report date. Element Summary Ref ID Element Name Req Type Min/ Max Usage BPT Transaction Set Purpose Code Description: Code identifying purpose of transaction set. M ID 2/2 Must use Code Name 00 Original TDR /04

36 26 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage Description: Conveys original readings for the account being reported. Use for both Inbound and Outbound transactions 52 Response to Historical Inquiry Description: Response to a request for historical meter reading. Used for Outbound only. This will be used when the response to a request is anything other than current. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. BPT Reference Identification Description: Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier. It is a unique transaction identification number assigned by the originator of this transaction. Note: This number should be unique for every EDI-867 file produced by a given system. If trading partners are using multiple systems, this identifier may not be unique. BPT Date Description: Date expressed as CCYYMMDD. Transaction Creation Date BPT Report Type Code Description: Code indicating the title or contents of a document, report or supporting item. O AN 1/30 Used M DT 8/8 Must use O ID 2/2 Used Code C1 Name Cost Data Summary Description: Interval readings.

37 EDI867 Specifications 27 Ref ID Element Name Req Type Min/ Max Usage Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. BPT Reference information as defined in the 'Request Reference' field of the EDI request file Example BPT*00*636* *C1*****DATAREQUEST17 N1 Name Syntax To identify a party by type of organization, name, and code. 1. N103 is required. N102 is not used for processing purposes. Note: the UIG EDI-867 specification allows for either N102 or N103 to be used. This implementation requires N103 exclusively. 2. If either N103 or N104 are present, then the others are required. Comments 1. This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party. 2. Two N1 segments will be used in this implementation. One identifying the originator of the transaction, the other identifying the receiver of the transaction. This is specific to the Independent Electricity System Operator and differs from the UIG specification. TDR /04

38 28 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage N Entity Identifier Code Description: Code identifying an organizational entity, a physical location, property or an individual. M ID 2/3 Must use Code Name 55 Service Manager Description: Used to identify the party that manages meter data on behalf of another. Meter Service Provider (MSP) 8C EC SJ Consumer Service Provider (CSP) Description: Local Distribution Company (LDC) Exchanger Description: Used to identify the organization running the market. Service Provider Description: Market Participant (MP) Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. N Name Description: Free-form name, this name if used is only for clarity of the transaction. Not used in processing, not verified consistent with N104. This should be the full name of the participant. The IESO itself will be identified by "Independent Electricity System Operator". Note: This field is not used for processing by the IESO. It is not recommended that this field be used for processing by participants. C AN 1/60 Used

39 EDI867 Specifications 29 Ref ID Element Name Req Type Min/ Max Usage N Identification Code Qualifier Description: Code designating the system/method of code structure used for Identification Code (67). C ID 1/2 Must use Code ZZ Name Mutually Defined Description: The Business Associate ID assigned to the entity by the Independent Electricity System Operator. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. N Identification Code Description: Code identifying a party or other code. This will be the Business Associate ID of the participant as assigned by the IESO. The IESO itself will be identified by the code "THEIESO". N Entity Identifier Code Description: Code identifying an organizational entity, a physical location, property or an individual. C AN 2/80 Used O ID 2/3 Must use Code Name 40 Receiver Description: Entity to accept transmission 41 Submitter Description: Entity transmitting transaction set TDR /04

40 30 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage Note: The entity providing the data (in this case the IESO) will always be considered the Submitter. The entity receiving the data (in this case the participant) will always be considered the Receiver. Use of these codes may change with transactions between other trading partners. Example N1*EC*Independent Electricity System Operator*ZZ*THEIESO**41 N1*SJ*Big Electric Co*ZZ*000000**40 Note: The UIG spec allows for the use of N2, N3, and N4 segments. These segments provide additional information regarding address and location. These segments are not used in this implementation. REF Reference Identification To specify identifying information. Comments Only one REF01 code is required. Element Summary Ref ID Element Name Req Type Min/ Max Usage REF Reference Identification Qualifier Description: Code qualifying the Reference Identification M ID 2/3 Must use Code Name

41 EDI867 Specifications 31 Ref ID Element Name Req Type Min/ Max Usage LU Location Number Description: The Metering System identifier as assigned by the IESO. Note: This reference is not necessarily numeric. Alternatively, the world 'ALL' indicating that the transaction set should contain (each in separate PTD loops) all of the delivery data available to the requesting entity for the requesting period. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. REF Reference Identification Description: This represents the Metering System identifier or the word "ALL" for reports on all meters under contract for a given report request range. These IDs are assigned to points by the IESO. C AN 1/30 Must use Example REF*LU*ALL PTD Product Transfer and Resale Detail Syntax If either PTD04 or PTD05 is present, then the other is required. Comments Each PTD loop will represent a meter register, whether demand, monthly, or detailed interval data. TDR /04

42 32 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage PTD Product Transfer Type Code Description: Code identifying the type of product transfer M ID 2/2 Must use Code PM Name Physical Meter Information Description: Individual meter installation. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. PTD Reference Identification Qualifier Description: Code qualifying the Reference Identification. The Reference Identification Qualifier will always be "OZ" for this implementation. C ID 2/3 Used Code OZ Name Product Number Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. PTD Reference Identification Description: Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier C AN 1/30 Used Code EL Name Electric Service

43 EDI867 Specifications 33 Ref ID Element Name Req Type Min/ Max Usage Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. Example PTD*PM***OZ*EL REF Reference Identification To specify identifying information. Comments At least three REF records are required for every PTD loop: LU, MT, and MG if metered service - LU, MT, and SC if un-metered service. Element Summary Ref ID Element Name Req Type Min/ Max Usage REF Reference Identification Qualifier Description: Code qualifying the Reference Identification M ID 2/3 Must use Code 6W Name Sequence Number Description: Optional channel number. Only used when there is more than one channel on a meter measuring the same quantity (e.g. two KWh channels). LU Location Number Description: Required. The Metering System identifier as assigned by the IESO. Note: This reference is not necessarily numeric. TDR /04

44 34 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage MG Meter Number Description: Required. The physical meter serial number or seal number. MT Description: Required. Used to identify the type of consumption measured by this meter and register. Defines the interval between measurements. See REF02 for examples. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. REF Reference Identification Description: Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier User Note 3: When REF01 is MT, the meter type is expressed as a five character field. The first two characters are the type of consumption, expressed as: K3 - Kilovolt Amperes Reactive Hour KH - Kilowatt Hour 68 - Amperes (represented in Ampere Squared Hours) 70 - Volts (represented in Volt Squared Hours) The next three-characters are the metering interval, expressed as: NNN = number of minutes; from 001 to 999 in factors or multiples of 5 C AN 1/30 Must use Examples KHMON Kilowatt hours used during the month. KH060 Hourly intervals data. K1015Highest demand 15 min in which its time stamp in the QTY loop identifies the time that this 15 minute demand took place REF Description: Description: A free form description to clarify the related data elements and their content. C AN 1/80 Used

45 EDI867 Specifications 35 Ref ID Element Name Req Type Min/ Max Usage Example REF*LU* REF*MG*R REF*MT*KH005 QTY Quantity To specify quantity information. Element Summary Ref ID Element Name Req Type Min/ Max Usage QTY Quantity Qualifier Description: Code specifying the type of quantity M ID 2/2 Must use Code Name 87 Quantity Received. Description: Used to indicate power flow into the grid. QD Quantity Delivered Description: Used to indicate power flow out of the grid. Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. QTY Quantity Description: Numeric value of quantity QTY03 C001 Composite Unit of Measure Description: To identify a composite unit of measure. C R 1/15 Must use O Comp Used TDR /04

46 36 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage 355 Unit or Basis for Measurement Code Description: Code specifying the units in which a value is being expressed, or manner in which a measurement has been taken M ID 2/2 Must use Code Name 68 Description: Amperes squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 68 is non-standard. 70 Volts Description: Volts squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 70 is non-standard. K3 Kilovolt Amperes Reactive Hour (KVARH) Description: The total reactive energy delivered to the load, the product of reactive power (kvar) and the length of time (hours). Reactive energy is energy that cannot perform any work. KH Kilowatt Hour (KWH) Description: The total real energy delivered to the load, the accumulation of the product of real power (KW) and time in hours. Real energy is energy that can perform actual work.

47 EDI867 Specifications 37 Ref ID Element Name Req Type Min/ Max Usage Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. Example QTY*QD*152.71*KH MEA Measurements Syntax To specify physical measurements or counts, including dimensions, tolerances, variances, and weights. 1. At least one of MEA03, MEA05, MEA06 is required. 2. If MEA07 is present, then at least one of MEA03, MEA05 or MEA06 is required. Semantics MEA04 defines the unit of measure for MEA03, MEA05, and MEA06. Comments 1. On the MEA record, the beginning and ending read are always provided for all KH and K3 type measurements, except interval reads. 2. On the MEA record, when interval reads are being provided the interval pulse count may be provided in MEA MEA05 and MEA06 will not be used by the Independent Electricity System Operator. 4. The first QTY loop must contain a MEA segment. 5. It is not necessary to provide an MEA segment for each subsequent QTY loop. Add an MEA segment only when the attributes of the measurement change. TDR /04

48 38 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/ Max Usage MEA Measurement Reference ID Code Description: Defines the quality of the meter read defined in MEA05 & MEA06. O ID 2/2 Used Code Name The following four codes are required for monthly usage reads to qualify fields five and six. Not used for interval reads. AA AE EA EE BO Meter reading-beginning actual/ending actual Meter reading-beginning actual/ending estimated Meter reading-beginning estimated/ending actual Meter reading-beginning estimated/ending estimated Meter Reading as Billed Description: Used when billing charges are based on contractual agreements or pre-established usage and not on actual usage. Physical allocations will use this designation. (This field will not be used in data transfers from the Independent Electricity System Operator) MA Measurement Qualifier Description: Code identifying a specific product or process characteristic to which a measurement applies O ID 1/3 Used

49 EDI867 Specifications 39 Ref ID Element Name Req Type Min/ Max Usage Code MU Name Multiplier Required for non -interval usage. PJ Pulse Width Description: Pulse multiplier Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. MEA Measurement Value Description: The value of the measurement and only used if MEA02=MU User Note 1: Represents the meter constant when MEA02 = "MU". When no multiplier is present, use a value of "1". MEA04 C001 Composite Unit of Measure Description: To identify a composite unit of measure C R 1/20 Used C Comp Used 355 Unit or Basis for Measurement Code Description: Code specifying the units in which a value is being expressed, or manner in which a measurement has been taken. This should be the same as that found on the QTY record. M id 2/2 Must use Code Name 68 Amperes TDR /04

50 40 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage 70 Volts Description: Amperes squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 68 is non-standard. Description: Volts squared hours. Note: If this value is reported on multiple channels for the same meter, it can be assumed to be per phase. Also, this usage of Measurement Code 70 is non-standard. K3 Kilovolt Amperes Reactive Hour (KVARH) Description: The total reactive energy delivered to the load, the product of reactive power (kvar) and the length of time (hours). Reactive energy is energy that cannot perform any work. KH Kilowatt Hour (KWH) Description: The total real energy delivered to the load, the product of real power (KW) and length of time (hours). Real energy is energy that can perform actual work. MEA Measurement Significance Code Description: Code used to benchmark, qualify or further define usage conveyed in QTY02. O ID 2/2 Used

51 EDI867 Specifications 41 Ref ID Element Name Req Type Min/ Max Usage Code Name 03 Approximately - used for readings created through meter disaggregation. 22 Actual - normal usage passed validation (included non-metered) 31 Calculated - reading created by PAD 39 Plugging from Redundant Meter 46 Estimated - usage not derived from actual meter reads. 62 Current - current version of data. 68 As Is - used to indicate the first (raw) version of data Good Verified - value appears anomalous but has been verified. 88 Adjusted Note: No other codes are supported in this implementation at this time. The full UIG EDI-867 specification does allow for other codes. Example MEA**MU* *KH***22 REF Reference Identification To specify identifying information. Syntax At least one of REF02 or REF03 is required. TDR /04

52 42 EDI867 Specifications Notes 1. This segment is required when the MEA07 = 46 (estimated) or when MEA07= 31 (calculated). 2. When MEA07 = 46, REF02 must be populated. 3. When MEA07 = 31, REF03 is populated with the Business Associate ID of the party providing the allocation. Element Summary Ref ID Element Name Req Type Min/ Max Usage REF Reference Identification Qualifier Description: Code qualifying the Reference Identification - Estimation Type Code M ID 2/3 Must use Code ESN Name Estimate Sequence Number REF Reference Identification Description: Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier. These codes are specific to the Independent Electricity System Operator. The UIG does not provide a list codes for this field. C AN 1/30 Used When MEA07=46 (estimated), this field contains the type of estimation performed Code Historical Linear Redundant Name Historical Estimation Linear Point to Point Interpolation Data Substituted from Redundant Meter

53 EDI867 Specifications 43 Ref ID Element Name Req Type Min/ Max Usage Check Data Estimated from Check Meter REF Description Description: When MEA07=31, this field contains the Business Associate ID of the party providing the allocation C AN 1/80 Used Example REF*ESN*HISTORICAL* DTM Date/Time Reference Syntax To specify pertinent dates and times. If either DTM05 or DTM06 is present, then the other is required. Note: Date Time Entries are provided in Eastern Standard Time. Comments 1. The first QTY loop must contain a set of DTM segments. 2. It is not necessary to provide a set of DTM segments for subsequent QTY loops. Add a set of DTM segments only when there is a gap in interval data. Element Summary Ref ID Element Name Req Type Min/ Max Usage DTM Date/Time Qualifier Description: Code specifying type of date or time, or both date and time M ID 3/3 Must use Code Name 150 Service Period Start (Interval Start) TDR /04

54 44 EDI867 Specifications Ref ID Element Name Req Type Min/ Max Usage Service Period End (Interval End) DTM Date Time Period Format Qualifier Description: Code indicating the date format, time format, or date and time format C ID 2/3 Must use Code D8 DT Name Date Expressed in Format CCYYMMDD When D8 is used the time is assumed to default to Date and Time Expressed in Format CCYYMMDDHHMM DTM Date Time Period Description: Expression of a date, a time, or range of dates, times or dates and times C AN 1/35 Used Example DTM*150****DT* DTM*151****DT*

55 EDI867 Specifications 45 SE Transaction Set Trailer To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments). Comments SE is the last segment of each transaction set. Element Summary Ref ID Element Name Req Type Min/M ax Usage SE01 96 Number of Included Segments Description: Total number of segments included in a transaction set including ST and SE segments SE Transaction Set Control Number Description: Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set M NO 1/10 Must use M AN 4/9 Must use Example SE*1136*0001 GE Functional Group Trailer To indicate the end of a functional group and to provide control information. Semantics The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06. Comments The use of identical data interchange control numbers in the associated functional group header and trailer is designed to maximize functional group integrity. The control number is the same as that used in the corresponding header. TDR /04

56 46 EDI867 Specifications Element Summary Ref ID Element Name Req Type Min/M ax Usage GE01 97 Number of Transaction Sets Included Description: Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element GE02 28 Group Control Number Description: Assigned number originated and maintained by the sender. M NO 1/6 Must use M NO 1/9 Must use Example GE*1*636 IEA Interchange Control Trailer To define the end of an interchange of zero or more functional groups and interchange-related control segments. Element Summary Ref ID Element Name Req Type Min/M ax Usage IEA01 I16 Number of Included Functional Groups Description: A count of the number of functional groups included in an interchange. IEA02 I12 Interchange Control Number Description: A control number assigned by the interchange sender. M NO 1/5 Must use M NO 9/9 Must use Example IEA*1*

57 MDEF File Format 47 MDEF File Format The MDEF file format defines the file for exchanging data with other systems. The format is designed to support current meter and recorder technology as well as new devices to be developed. The file is built in meter (recorder/site) order sequence so that all channels for a device are output as one group or data set, with any number of channels per metering device. File Structure The following table shows the basic layout of each record. Bytes Field Description 1-2 RLEN Record Length 3-4 RCODE Record Code Data (format based on RCODE) RCODE The record code (RCODE) is used to define several types of records. The types of records and data to be included are defined in the following table. RCODE Description 1 Meter (Recorder/Site) Record (ID, Start/Stop Times, etc.) 10 Channel Header Records (Recorder ID, Meter Readings, Physical Channel Number, etc.) Interval Data Records 9999 Trailer Record (one record per file) The following table defines the organization of the various Record Types in the file. Meter Channel Description 1 -- Meter (Recorder/Site) Header Record 1 1 Channel Header Record (one per channel) 1 1 Data Records (one or more) 1 2 Channel Header Record 1 2 Data Records TDR /04

58 48 MDEF File Format Meter Channel Description 1 Channel 3, channel 4, etc. if applicable 1 Last channel for this ID 1 Last channel for this ID Data Records Channel Header Record Data Records 2 -- Meter (Recorder/Site) Header Record 2 1 Channel Header Recorder 2 1 Data Records 2 2 Channel Header Recorder 2 2 Data Records 2 Last channel for this ID 2 Last channel for this ID Channel Header Record Channel Header Record Last meter in the transfer Last meter in the transfer Last meter in the transfer Last meter in the transfer Last meter in the transfer -- Meter (Recorder/Site) Header Record 1 Channel Header Record 1 Data Records 2 Channel Header Record 2 Data Records Last meter in the transfer Last meter in the transfer Last channel for this ID Last channel for this ID Channel Header Record Data Records

59 MDEF File Format 49 Meter (Recorder/Site) Header Record Layout There will be one meter (recorder/site) header record written for each set of data. The Record Length (RLEN) and Record Code (RCODE) will be binary fields stored in Least Significant Byte (LSB) first. All other fields in the record will be character fields written in ASCII. Bytes Field Type Description RLEN Int Record Length RCODE Int Record Code (Value = 1.) CM_CUSTID A/N Customer ID (optional) CM_NAME A/N Customer Name (optional) CM_ADDR1 A/N Customer Address Line 1 (optional) CM_ADDR2 A/N Customer Address Line 2 (optional) CM_ACCOUNT A/N Customer Account Number (optional) A/N Reserved CM_LOGChanS A/N Total Channels for Customer (optional) A Reserved TA_START N Start Time of data (YYYYMMDDhhmm) TA_STOP N Stop Time of data (YYYYMMDDhhmm) 144 DSTFLAG A Blank = assumes Daylight Savings Time is observed Y = Observes Daylight Savings Time N = Standard Time A/N Reserved Start and Stop Times These times represent the start and stop times for an individual meter's channel data stored after the Meter (Recorder/Site) Header. The interval data for each channel in the file up to the next Meter (Recorder/Site) Header must cover this time period exactly. The last hour of the day is defined as "2400". In the case of a Fall DST change, TA_STOP time can not fall on the 01:00, 02:00, or any interval between 01:00 or 02:00. TDR /04

60 50 MDEF File Format DST Flag The DSTFLAG indicates whether the data observes Daylight Savings Time. In the cases where either one or both TA_START and TA_STOP times have been adjusted for DST, the DSTFLAG must be set to Y. Time adjustments are made based on known clock change days. Thus, during the Standard Time period of the year, the flag may be set to Y or N. Systems observing Standard Time only should set the DSTFLAG to N at all times. If the flag is left blank, Y is assumed. Channel Header Record Layout There will be one channel header record written for each channel of data to be sent to the mainframe. The Record Length (RLEN), Record Code (RCODE), Logical Channel Number (DC_LOGChan), and the KW/KVAR/KVA Set Number (DC_KVASET) will be binary fields stored in Least Significant Byte (LSB) first. All other fields in the record will be character fields written in ASCII. Bytes Field Types Description RLEN Int Record Length RCODE Int Record Code (Value = 10.) DC_CUSTID A/N Customer Id (Optional) DC_RECID A/N Recorder ID (Service Point, known as Meter Point on some systems) A/N Reserved DC_MeterID A/N Meter Number (Optional) TA_START N Start Time (YYYYMMDDhhmm) TA-STOP N Stop Time (YYYYMMDDhhmm) A/N Reserved 93 A/N Reserved DC_PHYSChan N Meter Channel Number DC_LOGChan Int Customer Channel Number (Optional) DC_UMCODE N Unit of Measure Code (See the Glossary in the MV-STAR User Guide.) 100 ChanSTAT A Channel Status Present (Y/N) 101 INSTAT A Interval Status Present (Y/N) STRMTR N Start MEter Reading (Optional) STOPMTR N Stop Meter Reading (Optional)

61 MDEF File Format 51 Bytes Field Types Description 126 A/N Reserved DC_MMULT N Meter Dial Multiplier (3 dec) A/N Reserved 167 DC_SERVTYPE A W = WYE D = Delta + = Lagging P.F. - = Leading P.F. (Optional) A/N Reserved DR_INPHR N Intervals Per Hour A/N Reserved CR-STATUS A Check/Redundant Validation MP = Main meter passed check/redundant meter validation MF = Main meter failed check/redundant meter validation NP = Check/redundant meter falication was not performed NA = Not applicable to meter TA_STATUS A Standard MV-90 Validation NV = Not Validated ED = Edited, awaiting validation RE = Rejected AC = Accepted MA = Manually Accepted A/N Reserved 211 DC_FLOW A Power Flow Direction (Optional) DC_KVASET Int KW/KVAR/KVA Set Number (Optional) 214 TD_ORIGIN A Origin of Data (Optional) T = Translated R = Remote Interrogation I = Imported P = Portable S = Summary File A/N Reserved TDR /04

62 52 MDEF File Format Start and Stop Times Start and Stop times in the Channel Headers should match the Start and Stop times in the Meter (Recorder/Site) Header unless the channel data is being split due to an interval size or Unit of Measure (UOM) change. The Start and Stop times in the Channel Headers should always represent the time span of the Interval Data Records immediately following the header. The last hour of the day is defined as "2400". In the case of a Fall DST change, TA_STOP time can not fall on the 01:00, 02:00, or any interval between 01:00 or 02:00. Note: If the channel data is being split, the Start time in the Channel Header of the first split and the Stop time in the Channel Header of the last split should match the times in the Meter (Recorder/Site) Header. Start and Stop Meter Readings These meter readings will be calculated for the start and stop times based upon actual meter readings retrieved during previous meter interrogations. Interval Data Record Layout Interval data records consist of engineering units data and associated interval and channel status codes. These records meet the following criteria: Each interval data record will contain up to 48 elements (intervals) of data in the four byte IEEE floating point format. The actual number of intervals per data record will depend on the presence of channel and/or interval status data. The status data will be output as two byte unsigned integers for both the channel and interval status. If the last data record for each channel is not completely filled with data, it will be padded to the end of the record with a binary integer value of for each two bytes of the four byte interval value and in each two bytes of the status codes (if status codes are present). Any gaps in data will be resolved by padding the time period of the gap with zero data and setting the interval status to missing data. All channel data records will have data (or values identified as missing) for the time period shown in the Channel Header record. If there are changes in interval length or Unit of Measure (UOM) codes for a channel, the data will be split with a channel header record preceding each part of the channel data. When a channel is split, then all channels for the device should be split at the same interval. All binary data including the two byte record length, two byte record code, two byte customer channel number, four byte IEEE floating point interval values, the two byte interval and channel status data, and the two byte end of record padding values are all stored with the Least Significant Byte (LSB) first. In the case of a Fall DST change where the DSTFLAG in the Meter (Recorder/Site) Header Record is set to 'Y', the second 02:00 interval must follow the first 02:00 interval in succession.

63 MDEF File Format 53 The following table defines the interval data record layout. Bytes Field Type Description RLEN Int Record Length RCODE Int Record Code (Value = ) CM_CUSTID A/N Customer ID (Optional) INTERVAL Float Interval Data in Engineering Units (192 bytes) 48 Intervals - No status Active 32 Intervals - One status Active 24 Intervals - Both status Active The possible storage formats for the interval engineering unit data are defined in the following table. AAAAAAAA... AxAxAxAx... AyAyAyAy... AxyAxyAxy... Channel A data, no status (4 bytes/interval, therefore, 48 intervals per record) Channel A data, w/channel status (6 bytes/interval, therefore, 32 intervals per record) Channel A data, w/interval status (6 bytes/interval, therefore, 32 intervals per record) Channel A data, w/channel and interval status (8 bytes/interval, therefore, 24 intervals per record) The channel header record has flags which will indicate whether status data is present. As can be seen in the preceding table, each interval data value can be accompanied with interval, channel, or both types of status data. The rule is, if the bits of a status type are all zero for all of the intervals for the entire channel, then that status type could (as an option) be omitted from the data records in order to conserve storage space. TDR /04

64 54 MDEF File Format The individual status flags for the Channel and Interval status data are defined in the following tables. Channel Status (2 Bytes) Byte Description 15 Reserved 14 Reserved 13 Reserved 12 Estimation type indicator (Bit 1) 11 Estimation type indicator (Bit 0) 10 Harmonic Distortion 9 Alarm 8 Energy Type (Register Changed) 7 Parity 6 Excluded Data 5 Data Out of Limits 4 Pulse Overflow 3 Estimated Interval (Data Correction) 2 Replaced Interval (Data Correction) 1 Added Interval (Data Correction) 0 Retransmitted/Updated Data

65 MDEF File Format 55 The following table illustrates how bits 11 and 12 of the channel status record will be interpreted. Estimation Type ID Estimation Type Code (Bit 1) (Bit 0) Point to Point Linear Interpolation EL 0 0 Historical Estimation EH 0 0 Check/redundant estimation CK 1 0 Reserved 1 1 TDR /04

66 56 MDEF File Format Interval Status (2 Bytes) Bit Description 15 Not used. 14 Not used. 13 Not used. 12 Load Control 11 Test Mode 10 Time Reset Occurred 9 Watchdog time-out 8 Reset Occurred 7 Clock Error 6 Data Missing 5 ROM Checksum Error 4 RAM Checksum Error 3 CRC Error 2 Long Interval (Missing for Mag Tape) 1 Short Interval (False for Mag Tape) 0 Power Outage Trailer Record Layout The trailer record will be the last record written in a data set and will contain the total number of customers in the file as well as the total records written to the file. Bytes Field Types Description RLEN Int Record Length RCODE Int Record Code (Value = 9999) A/N Reserved TOTREC N Reserved

67 MDEF File Format 57 Bytes Field Types Description A Reserved XF_TSTAMP N Time Stamp (YYYYMMDDhhmm) (Optional) Time Stamp If used, the Time Stamp should represent the time that the Trailer Record was written. TDR /04

68 58 MV-90 Register Read Loader MV-90 Register Read Loader The objective of this interface is to load register reads from the MV-90 system to the MV-STAR system. The attributes for this loader are: The loader is a standard MV-STAR job and it writes to the register_reading table. The file transfer is from MV-90 to MV-STAR via FTP. The incoming file has an extension of.rgr and is a regular flat file. This loader only loads register reads for the register types that are in the REGISTER_TYPE table. (Pre-populated from Itron.) Table 1.1 Sample.rgr data Recorder ID Date Collected 1A14ALPHA PP 1T Total kwh 1F Peak kw Rate A 1F Peak kw Rate B 1F Peak Kw Rate C 1F Peak kw Rate D 1F Total kvarh 0 00 Peak Kvar Rate A 0 00 Peak Kvar Rate B 0 00 Peak Kvar Rate C 0 00 Peak Kvar Rate D 0 00 Only the registers than have readings with these matching types will be loaded onto the MV-STAR system.

69 MV-90 Register Read Loader 59 Each MV-90 output file, generated at the time of each register read, consists of a single Recorder ID and contains the mapped information extracted during the read process. The output file name is XXxxxxxx.rgr. The following table explains the naming convention of this file Component XX xxxxxx.rgr Description Workstation ID 6 digit hexidecimal sequential number set, used for sequential numbering of the debug file. file extension The following table shows the file layout. Field Name Size Description Request Tag 20 The ASCII description of the value being decoded. Status 1 (ASCII value) 1 - information fulfilled 0 - request unsuccessful Format 1 The type of data value being returned by the device. A - string value L - long integer value F - floating point value T - MMDDYYYYhhmmss (length is 14) Blank - no data value is returned by the device Length 2 The length of the decoded data string. Valid data values for the length are from 00 to 32. Decoded Data 32 Data decoded from the meter. Data is left justified, blank padded. Decimal point may be present for floating point data types. Reserved 4 Space reserved for future use. crlf 2 Carriage Return/Line Feed record delimiter. TDR /04

70 60 MV-90 Register Read Loader Error Handling If recorder ID is not provided in the file, this job will fail. If Collection Date is not provided in the file, this job will fail. If a wrong register type (the register type that does not exist in register_type table) is specified in the file, this job will fail. If an invalid record is found in the.rgr file, this job will fail. If there are duplicate records in the file, all records will be loaded into the MV-STAR database and the last occurring record will become the current data.

71 MV-90 Master File Format 61 MV-90 Master File Format Master File information created on the MV-90 system and imported into the MV-STAR system uses a specified format and meets the following criteria: Each channel will have one record. Data is in ASCII format. Data types of A or A/N will be left justified with trailing spaces. Data types of N will be right justified. All decimals will be included in the data. Each record will end with carriage return, line feed. In applications where totalizers are used to combine pulses from several meters into a single channel, the channel record will be duplicated and the meter sequence number increased to link the record to a specific meter for the channel indicated. Notes: The Recorder ID (MF_RECID) must be unique to each recorder or register and is the unique ID for that site. The Recorder ID and the Customer ID should be the same unless a recorder contains data for more than one customer or a single customer has data on more than one recorder. The Device ID (MF_DEVID) is the ID used to communicate with a recorder via telephone or as a key when importing data from hand-held readers. The Device ID may be different from the Recorder ID depending upon the type of hardware. When importing Master File data into the MV-90, fields may be left blank to preserve existing data. TDR /04

72 62 XML File Format XML File Format This section discusses MV-STAR file formats that are XML based. XML files are based on complex arrangements of elements and attributes. Visit the W3C ( ) website for help with XML related technologies. XML data files in MV-STAR are all validated against either an XML Document Template Definition (.DTD) or an XML Schema Document (.XSD). The XML data file to be loaded contains a reference to the DTD or XSD needed for validation. DTD and XSD files validate the XML data file using many complex rules. Example files and the XSD/DTD files are included as appendices. XML data file loaders are used to transfer data from a system or database to the MV-STAR system for the purpose of updating existing information. Each type of loader bears a unique extension for identification purposes. XML data file loaders are typical MV-STAR loaders. They follow the general rules for loading data. Whenever records are modified, the MV-STAR system logically deletes the old record and creates a new version for the updated record. Enrollment Interface The Enrollment Interface loads Participant, Delivery Point, and Contract information into the MV-STAR database with an.enr extension. Enrollment File Rules The following rules apply to the XML Enrollment file: Enrollment loader will automatically truncate dates(see Appendix) because of the no overlapping date range rule. When the loader runs, date range truncation will occur in the following: Participant role date range Contract date range Ιf Auto-Generation is On, the Enrollment Interface generates Service Points for consumption meters. Note: If MV-STAR receives a "Delete" action for a Participant element in the XML file, all the records relating to this Participant, Participant Role, Participant Password, and Contract are deleted. Register Read Loader The Register Read loader loads register reads into the MV-STAR system with a.reg extension. The Register Read loader loads two types of register readings Absolute and Relative. Absolute register readings contain a start and end date and are expected to have all computations already applied. Relative register readings are readings that have only a read date and have no calculations applied.

73 XML File Format 63 Register Read Loader Rules The following rules apply to loading Register Read information: If the reading is absolute, the start date and read date is required If the reading is relative, the read date is required firstreading should be true for the first ever relative reading for a meter. All other times, this value should be false. Meter Information Loader The Meter Information loader loads Service Points and Summary Maps into the MV-STAR system with a.mif extension. The Meter Information loader loads data for the meters, the meter s channels, and the meter s intervals sizes. Also, a Service Point s physical meter and a Summary Map s contributors are loadable through this loader. Meter Information Loader Rules The following rules apply to the Meter Information Loader: Meter points cannot be deleted via this loader. Meter channel cannot be deleted via this loader. Interval size of a meter cannot be updated once it exists in the database. There can only be one physical meter and section in the database. If the XML file detects an attempt to add another interval size or physical meter, it will be skipped and a warning will be raised. Deleting a record that does not exist in the database will be skipped and a warning will be raised. When a Delete action is sent to a summary channel, all summary contributors that contribute to the summary channel will be deleted. When a Delete action is sent to a summary channel, if this summary channel is still contributing to another summary map, the channel will NOT be deleted and a warning will be raised. The UOM and channel number of a contributing meter channel cannot be changed without the summary map channel contributor record being removed first. Cannot delete a base profile channel until the channel is removed from the BASE_PROFILE_SOURCE table. If detected, it will be skipped and a warning will be raised. When modifying a meter point s channel s UOM, Power Flow, or channel number, it must not have any interval readings or it will be skipped and a warning will be raised. When loading voltage code, the specified voltage code has to exist in VOLTAGE_CODE table. Otherwise, the entire meter point or summary map record will be rejected. When loading base_profile_id, the specified base profile ID has to exist in BASE_PROFILE_SOURCE table. Otherwise, the entire meter point record will be rejected and a warning will be raised. When loading interval size, the specified interval size has to exist in METER_READING_SECTION table. Otherwise, the entire meter point record will be TDR /04

74 64 XML File Format rejected and a warning will be raised. A main meter point must exist in the file or database before a child meter can establish the parent/child relationship. A child meter must have a meteringtype C or R and must have a parentmeterid that is valid in the file or database. A parent meter must have a meteringtype of M. The parent's meter meteringtype cannot be changed to something other than M until its child records have been disconnected. The summary contributor s order of operation must be unique. The order of operation will be used when determining which contributor is updated or deleted. If a meter maps to a delivery point, it must have a consistent channel configuration for the two meters. Otherwise, it will be skipped and a warning will be raised. Loss Configuration Loader The Loss Configuration Loader loads loss related information into the MV-STAR system with an.xlc extension. The objective of this loader is to provide a means to manage a large number of losses and the required mappings for losses to be useful. The loader will take an XML file and load the Loss information into MV-STAR. This loader should be able to load: Voltage Codes Standing Percentage Losses ( also known as Fixed Losses ) Ιnterval Percentage Losses ( also known as Variable Losses ) Equation Losses Mapping from Voltage Code to Loss (also known as Applied Losses) Mapping from Metering System to Voltage Code Also, a mechanism to copy entire configurations is added. Therefore, it will be easy to maintain a few number of configurations and copy them as needed to expand the functionality over a larger group of losses. The XML Loss Configuration Schema has two interesting but complex features: The ability to autoname losses and automatically attach them to voltage codes. This is done by using a voltage code and REPLACE action when specifying factors. The ability to auto-create losses by copy and by reference. When creating by copy, all existing losses for the target voltage code will be deleted and replaced with new losses that are copies of losses attached to the source voltage code. When creating by reference, all existing losses for the target voltage code will be deleted and directly attached (shared) to the existing losses attached to the source voltage code. Loss Configuration Loader Rules The following rules apply to the Loss Configuration Loader: Voltage Codes may not be deleted unless the Voltage Code is removed from all Metering Systems. Ιf a Voltage Code is deleted, all Loss Codes will be deleted. Losses will remain

75 XML File Format 65 untouched. If Voltage Code is given at the FACTORS element, then the action must be REPLACE. This is the mode for users who do not know the current configuration of the losses underneath a Voltage Code. Names are not required for the losses underneath. All Losses underneath FACTORS element (if voltagecode is given and action = REPLACE), will be hooked to the Voltage Code given. Name attributes must be given in sub-elements of FACTORS element (unless if voltagecode is given and action = REPLACE). Variable losses cannot be edited individually. Variable losses will always be logically deleted when a Variable Loss Span is found. The number of interval percentage losses must be equal to the number expected. The (Start Date End Date) / (Interval Size) will give the number expected. Order of Precedence must be unique among all losses sharing the same Voltage Code. Name and Type are required to uniquely identify a Loss. If a Loss is deleted, all Loss Codes attached to that loss must be deleted. An action of COPY in the VOLTAGE_CODE_COPY element will result in duplicate Loss Codes and Losses created. An action of REFERENCE in the VOLTAGE_CODE_COPY element will result in duplicate Loss Codes created. The Losses will be shared. There will by MV-STAR system parameters LOSS_FACTOR_MODE=UNIQUE and VOLTAGE_CODE_MODE=UNIQUE. The VOLTAGE_CODE_MODE parameter allows whether multiple meters can share the same Voltage Code. The LOSS_FACTOR_MODE controls whether multiple Voltage Codes can share the same Loss Factor. These should be respected. When LOSS_FACTOR_MODE=SHARED and the VOLTAGE_CODE_COPY uses COPY, care must be taken to not create the same loss twice. If the original voltage code shares the same loss, then the new voltage code must shared the same loss. Meter Point Loader The Meter Point loader attaches existing Base Profiles and existing Voltage Codes to an existing Metering System. The Meter Point loader loads this data into the MV-STAR system with a.sit extension. Meter Point Loader s functionality has been replaced by the Meter Information Loader. Meter Point Loader still functions in MV-STAR. Meter Point Loader Rules The following rules apply to loading Meter Point information: Meters cannot be created or deleted through this interface. Meter Point ID is a required. If a voltage code is specified in the XML loader that does not exist on the MV-STAR system, the record will be ignored. Ιf a profile name is specified in the XML loader that does not exist on the MV-STAR system, the record will be ignored. An Update action with an empty value will delete a voltage code or base profile ID. TDR /04

76 66 XML File Format Physical Allocation Data (PAD) Loader The Pad loader loads physical allocation data into the MV-STAR system with a.pad extension. Physical Allocation Data allows one participant to share fractional parts of interval readings with another participant. Pad (Physical Allocation Data ) Loader Rules The following rules apply to loading physical allocation information: General Business Rules One PAD XML file contains PADs information for one allocator. One PAD XML file can contain PAD information for multiple meters and channels. One PAD XML file can contain PAD information for multiple allocatees. Three types of PAD are loaded through this loader: Standing Percentage, Interval Percentage and Interval Absolute. Metering systems given in the PAD file must be delivery points in MV-STAR. Allocator and allocatee have to be valid participant in MV-STAR, and they are distinct participants. Allocator can only load PAD if he has the market role defined by the system parameter MP_ROLE_ID. This is usually defined to be "MMP". Allocatee has to have "ALCT" market role. The associated meter for the given DP must have at least one channel, which matches the power flow and unit of measure given in the XML file. If there is no matching channel or more than one matching channel, the entire job will fail. The PADs provided in the XML file have to be within the date range provided for the allocator at MVSTAR_TRANSACTION level in the XML file. The start date and end date of PHYSICAL_ALLOCATION_SET element must be interval boundary for the metering system. This is verified through channel interval length.( In MV-STAR, the validate interval boundaries are: 00, 15,30,45 for 15 minute interval, 00,05,10,15,20,25.. for 5 minute intervals. ** This loader will logically delete existing PADs if they overlap with the PADs that are given in the XML file, even if existing pads are identical with the PADs that are going to be load. The loader will fail if two PHYSICAL_ALLOCATION_SET elements are submitted with the same information(except date range) but the two have overlapping date ranges. If there is overlap, the overlapping portions should use the same PHYSICAL_ALLOCATION_SET. Any other portion will need to exist in another PHYSICAL_ALLOCATION_SET. The sender of the PAD file must be the person identified in the MVSTAR_TRANSACTION ParticipantID attribute.

77 XML File Format 67 Loading Standing Percentage Pad The value for standing percentage pad has to be greater than or equal to 0 or less than and equal to 1. Standing percentage PAD can only be submitted for the number of future trading days, which is defined by the system parameter ALLOWED_PERCENTAGE_DAYS. Standing percentage PAD for the past is not allowed. Standing percentage PAD will be stored into physical allocation data table directly without breaking into intervals. Standing percentage PAD does not need an Allocator contract on the delivery point when loading. However, the contract must be in place to notice the effects of the PAD in meter readings. Loading Interval Percentage Pad The value for standing percentage pad has to be greater than or equal to 0 or less than and equal to 1. Interval percentage PAD can only be submitted for the number of future trading days. The number is defined by the system parameter ALLOWED_PERCENTAGE_DAYS. Interval percentage PAD for the past is not allowed. If the interval length for PAD submitted is bigger than the interval size of given delivery point, PAD value will be broken into the multiple of PADs with save PAD value. (E.g if the interval length for PAD is 15min and the interval size fore delivery point is 5, one 15min PAD will be broken into 3 PADs with the same value). If the interval length for PAD submitted is smaller than the interval sized of given delivery point, error will be logged and the entire job will fail. Interval percentage PAD will be stored into physical allocation data table on interval basis. Interval percentage PAD does not need an Allocator contract on the delivery point when loading. However, the contract must be in place to notice the effects of the PAD in meter readings. Loading Interval Absolute Pad The value for interval absolute pad has to be a positive number, that is smaller than the value of corresponding interval. Interval absolute PAD can only be submitted up to the number of past trading days(system day). The number is defined by the system parameter ALLOWED_ABSOLUTE_DAYS. Interval Absolute PAD for the future is not allowed. If the interval length for PAD submitted is smaller than the interval size of given delivery point, PAD value will summed based on the multiple of PAD interval length over delivery point interval length. (E.g if the interval length for PAD is 5min, pads submitted are 12, 15,24 for time period between 00:00 to 00:15. If the interval size fore delivery point is 15, the actual PAD value will be stored is 51) If the interval length for PAD submitted is greater than the interval sized of given delivery point, error will be logged and the entire job will fail. Interval absolute PAD will be stored into physical allocation data table on interval basis. Interval absolute PAD must have an Allocator contract on the delivery point when loading. TDR /04

78 68 XML File Format Loss Loader The Loss loader loads register reads into the MV-STAR system with a.los extension. Loss Loader Rules The following rules apply to loading loss information: General business rules One LOSS XML file contains loss information for meters contracted by one participant. One LOSS XML file can contain loss information for multiple meters. Two types of LOSS are loaded through this loader: Standing Percentage(Fixed), Interval Percentage(Variable). Metering systems given in the LOSS file must be service points or summary meters in MV-STAR. The participant given in the LOSS file must be a valid participant in MV-STAR. Participant can only load LOSS if he has the market role defined by the system parameter LDC_ROLE_ID. This is usually defined to be "LDC". The metering system given must have a valid Voltage Code assigned. The losses provided in the XML file have to be within the date range provided for the participant at MVSTAR_TRANSACTION level in the XML file. The start date and end date of LOSS_SET element must be interval boundary for the metering system. This is verified through time period duration of the meter.( In MV-STAR, the validate interval boundaries are: 00, 15,30,45 for 15 min interval, 00,05,10,15,20,25.. for 5 mins interval. ** This loader will logically delete existing Losses & Loss Codes if they fall within the metering system, loss type, and daterange given in the LOSS_SET element. **If different LOSS_SET elements have the same metering system and loss type, but have overlapping dateranges, the later LOSS_SET element will overwrite the first LOSS_SET element. **When a loss is changed on one metering system, it is changed on all metering systems that share the same voltage code. **When deleting a loss that is hooked to multiple loss codes, some of those loss codes will contain corrupted data. The sender of the LOSS file must be the person identified in the MVSTAR_TRANSACTION ParticipantID attribute. New Loss Names will be constructed based on ParticipantId + Loss.getSequence- NameSid() Loading Interval Percentage Loss If the number of LOSS elements do not equal the time difference in the LOSS_SET(EndDate - StartDate), an error will be logged. Interval percentage LOSS will be stored into variable_loss_factor data table on interval basis.

79 2 Interfaces This chapter describes interfaces that are exported from, or imported into the MV-STAR system through some means other than a file: Table Based Formats Generation Schedule Loader IMO Master File

80 70 Table Based Formats Table Based Formats Generation Schedule Loader The Generation Schedule loader allows grouped generation facilities to share a common meter and allocate its readings among different owners based upon their proportion of the scheduled generation. The ABB system will write to a table (DISPATCH_INT) the scheduled generation for each five-minute interval. After committing the values, it will execute a stored procedure (MeteringSystems.LoadDispatch) on MV-STAR s database, which in turn will generate a file initiating a loading process. Each set of generators sharing a common meter (or a summary meter to account for station service) will have their total power generation multiplied by their proportion of the total schedule on an interval by interval (five minute) basis. Each set will be called a scheduling set and each generator will be called a scheduling set member. A scheduling set member will be composed of a delivery point name, an associated summary meter (that will multiply the shared meter s readings by the values stored in the linked service point) and a linked service point (which will hold the proportion of the schedule for this generator). Exactly one of these schedule set members will be considered Primary granting its owner ( contracted participant) access to viewing its contributors. Owners of the other set members will be restricted in that they may only view the data of the delivery point, not its supporting meter systems (e.g. the summary meter contributors). Database Model Tables associated with the schedule sets and their members will be created. SCHEDULE_SET SCHEDULE_SET_SID NOT NULL number SCHEDULE_SET_ID NOT NULL VARCHAR2(40) VERSION NOT NULL number FROM_TX_SID NOT NULL number TO_TX_SID SHARED_METER_SID number number

81 Table Based Formats 71 SCHEDULE_SET_MEMBER SCHEDULE _SET _MEMBER_SID NOT NULL number(10) SCHEDULE _SET _MEMBER_ID NOT NULL varchar2(20) SSM _CHANNEL_NUMBER number(4) SCHEDULE _SET _SID NOT NULL number(10) DELIVERY_POINT_SID NOT NULL number(10) LINKED_SERVICE_POINT_SID LINKED_SP_CHANNEL_NUMBER PRIMARY number(10) number varchar2(1) VERSION NOT NULL number(3) FROM_TX_SID NOT NULL number(12) TO_TX_SID number(12) DISPATCH_INT The table used for accepting these values from ABB will be called DISPATCH_INT and will have the following fields: DELIVERY_POINT_ID NOT NULL VARCHAR2(30) TRADE_DATE NOT NULL DATE TRADE_HOUR NOT NULL NUMBER(2) TRADE_INTERVAL NOT NULL NUMBER(2) UOM NOT NULL VARCHAR2(1) DISPATCH_TYPE NOT NULL VARCHAR2(1) [D R F] MEAS_QTY NOT NULL NUMBER(5,1 ) UPDATED_DATE UPDATED_BY DATE VARCHAR2(12) TDR /04

82 72 IMO Master File Loader IMO Master File Loader The objective of this interface is to load participant, participant role, delivery point, and contract information from the PLC system into MV-STAR. Database Model Tables associated with the schedule sets and their members will be created. No Column Name in PLC system (mf_business_associates) Column name in MV-STAR system (Participant) 1 BUS_ASSOC_ID INTERFACE_ID 2 SHORT_NAME PARTICIPANT_ID 3 NAME PARTICIPANT_NAME 4 ACTIVE_FLG STATUS No Column Name in PLC system (mf_ba_relation_authorizations) Column name in MV-STAR system (Participant_role) 1 RELATIONSHIP_TYPE MARKET_ROLE_SID (after conversion) 2 START_DATE START_DATE 3 BUS_ASSOC_ID PARTICIPANT_SID (after conversion) No Column Name in PLC system (mf_delivery_points table) Column name in MV-STAR system (delivery_point table) 1 RES_ID DELIVERY_POINT_ID 2 RES_NAME DELIVERY_POINT_NAME 3 START_DATE COMMISSION_FROM_DATE 4 END_DATE COMMISSION_TO_DATE

83 IMO Master File Loader 73 No Column Name in PLC system (mf_ba_dp_xrefs) Column name in MV-STAR system (Contract) 1 RES_ID METERING_SYSTEM_SID (after conversion) 2 BUS_ASSOC_ID PARTICIPANT_SID (after conversion) 3 START_DATE START_DATE 4 END_DATE END_DATE 5 RELATIONSHIP_TYPE MARKET_ROLE_SID (after conversion) Generation Schedule Loader Rules Loading Participant Information 1. For each participant (mf_business_associates.bus_assoc_id), this loader will load the latest accepted record (record with latest last_update_date) from those records in the time period between system date and system date minus the number of lookbackdays. Assumption: There will be at most one latest record for each participant. That is, no two records will have the same last_update_date. 2. If the participant does not exist in MV-STAR, a new participant record will be created. If the participant already exists in MV-STAR, and the information from the mf_businesss_associates table is identical to the information in MV-STAR, then the record is ignored. Otherwise, the participant information will be versioned and updated. 3. This loader will not permit deletion of participants from MV-STAR. 4. If a participant record that is loaded by MV-STAR has D as its ACTIVE_FLG, all contracts and participant roles for this participant in MV-STAR and all participant roles that are being loaded for this participant will be logically deleted or terminated while loading this participant. The end_date for the participant role records in MV-STAR will be mf_business_associates.start_date, truncated to midnight, plus one day. If that end_date falls before the record s start_date, the record will be logically deleted. 5. If a participant record that needs to be loaded from the mf_business_associates table has a D active_flg, and this participant does not exist in MV-STAR, the participant will still be loaded as new participant. 6. The loader will still load participant information from the PLC system for a participant that already has a participant.status value of D in MV-STAR. TDR /04

84 74 IMO Master File Loader Loading Participant Role Information 1. For each participant s role, this loader will load the latest accepted record (record with latest last_update_date) from those records in the time period between system date and system date minus the number of lookbackdays. Assumption: There will be at most one latest record for each participant role. That is, no two records with the same bus_assoc_id and relationship_type will have the same last_update_date. 2. Participant role will be only loaded if the participant was a valid participant in MV-STAR before the loader started or will be loaded within the same loading transaction. 3. Only participant roles with an ALCT relationship_type will be loaded into MV-STAR. (This feature is controlled by the market_role.auth_allowed flag.) 4. All participant roles loaded by this job will be open-ended, and the participant_role.end_date will be set to null in MV-STAR. 5. If a participant record already has a D flag in MV-STAR, participant role information will not be loaded. If a candidate record was rejected for this reason, a warning will be logged. 6. Although MV-STAR allows one participant to have the same market role over disjoint date ranges (for example, MMP from 1/1-3/1 and 4/1 --- null for one participant) this interface will assume that each participant has each market role for one continuous date range. If the interface is trying to load a role and detects that MV-STAR has two current disjoint participant role entries for that participant and market role, the loader will reject the role and log a warning. Note that the new role will be rejected even if its date range does not overlap the corresponding roles that exist in MV-STAR. 7. If a participant role already exists and is open-ended in MV-STAR, and the same role has been updated in the PLC system, the role will only be loaded if the PLC s start date is earlier than the start date in MV-STAR. 8. If a participant role already exists and has a non-null end date in MV-STAR, and the same role has been updated in the PLC system, the role information in MV-STAR will be updated. The end_date will be set to null and the start_date will be set to the minimum of the role s start_date in MV-STAR and the start_date in the start_date from the PLC system. 9. If the interface attempts to load a participant role with a non-null end date, and a participant role with an end date already exists for that participant and market role in MV-STAR, the interface will update the role in MV-STAR so that the start_date is the minimum of the two start dates and the end_date will be mf_business_associates.start_date, truncated to midnight, plus one day. The end date of a role loaded by this interface can only be non-null if the active_flg on the participant in the PLC system is a D. Note: Participant and participant role will be saved at the same time, because in MV-STAR, they are parent and child records. The failure of saving participant will cause the failure of saving participant role.

85 IMO Master File Loader 75 Loading Delivery Points 1. For each delivery point, this loader will load the latest accepted record (record with latest last_update_date) from those records in the time period between system date and system date minus the number of lookbackdays. Assumption: There will be at most one latest record for each delivery point. 2. For each delivery point record in the PLC system, the res_id will be used to check for the existence of a delivery point in MV-STAR. If no delivery point with that ID already exists, the loader will create a new delivery point. If a delivery point with the specified ID already exists in MV-STAR, the delivery point information will be updated in MV-STAR to match the record from the PLC system. If the existing information in MV-STAR is the same as the record from the PLC system, the record will be ignored to prevent extraneous versions. 3. This loader will not permit the deletion of delivery points from MV-STAR. 4. The start_date and end_date from the mf_delivery_points table will be truncated to midnight (all hour, minute, and second information will be discarded) before it is loaded into MV-STAR. 5. hen loading a delivery point record from the PLC system, the loader will add one day to the mf_delivery_point.end_date field and store it as commission_end_date in MV-STAR (except as described in number 9). For example, if the end_date given is 3 Feb. 2001, it will be loaded into MV-STAR as 4 Feb If the end_date of a delivery point from mf_delivery_points table has a year value of 5000, this loader will insert a null commission_end_date in MV-STAR. Null means open ended in MV-STAR. 7. This loader will always update the res_name information in MV-STAR, based on the delivery point corresponding to the res_id. 8. If the start_date of the delivery point record from the PLC system is earlier than the commission_from_date of the delivery point record in MV-STAR, the loader will update the commission_from_date and the commission_to_date of the delivery point in MV-STAR to match the dates from the mf_delivery_points table. 9. If the start_date of the delivery point record from the PLC system is the same as the commission_from_date of the delivery point record in MV-STAR, and the end_date from the PLC system is different from the commission_to_date in MV-STAR, the loader will update the commission_to_date to match mf_delivery_points table.end_date. 10. The commission dates of a delivery point in MV-STAR will not be updated if there is a contract on that delivery point whose date range falls outside of the new date range of the delivery point from the PLC system. In this case, a warning will be logged. TDR /04

86 76 IMO Master File Loader Loading Contract Information 1. For each contract, this loader will load the latest accepted record (record with latest last_update_date) from those records in the time period between system date and system date minus the number of lookbackdays. Assumption: There will be at least one current record for each contract. No two records with the same res_id, relationship_type, and start_date will have the same last_update_date. 2. This loader will not permit the deletion of contracts from MV-STAR. 3. This loader will only load contract if the following conditions are true The participant is a valid participant in MV-STAR The delivery point is a valid delivery point in MV-STAR The market role is a valid market role in MV-STAR The date range is within the commission dates of the delivery point. 4. The start_date loaded into MV-STAR will be the start_date from the PLC system, truncated to the day (all hour, minute and second information will be discarded). 5. The end_date loaded into MV-STAR (except as described in number 9) will be the end_date from the PLC system, plus one day, truncated to the day (all hour, minute and second information will be discarded). 6. If the end_date of a contract from the PLC system has a year value of 5000, this loader will insert a null end_date in MV-STAR. The null indicates that the contract is open-ended in MV-STAR. 7. If this interface is loading a contract, but the contract is not within the date range of the corresponding participant role, the interface will adjust participant roles in MV-STAR so that the contract can be loaded. If no participant role with the contract s market role exists, a new open-ended participant role will be created with the same start_date as the contract. If a participant role already exists but its date range is insufficient to cover the contract, the role s date range will be adjusted. The role s start_date will be set to the minimum of the role s existing start_date and the new contract s start_date. The role s end_date will be set to the contract s end_date if the role is not open-ended. 8. A contract will be loaded into/updated in MV-STAR even if the participant.status column in MV-STAR is a D as long as the contract is within the date range of the participant role. 9. If a contract record that needs to be loaded has identical values apart from the end date as an existing current record within MV-STAR, this loader will insert a new record and logically delete the old record. If a contract record from the PLC system is eligible for loading but overlaps with the date range of an existing contract in MV-STAR, the new contract from the PLC system will not be loaded and a warning will be logged.

87 3 Loss Equations This chapter describes the loss factors used when the MV-STAR system applies equation losses to specific service points and summary maps. An Equation Factor calculates losses using voltage and current variables (up to five variables per equation). Depending on meter type, the MV-STAR system uses either the Transformer Equation (Method 1) or the Volt-Ampere Equation (Method 2).

88 78 General Import/Export Rules General Import/Export Rules Both the transformer loss equations Method (V2H & I2H) and the Volt-Ampere Equation method (K1, K2, K3) have been updated to follow these rules when adding losses to zero Kwh channels. If Kwh (import) equal to zero apply losses to Kwh (import) only if Kwh (export) equal to zero If Kwh (import) greater than zero apply losses to Kwh (import) only if Kwh (export) equal to zero If Kwh (import) equal to zero apply losses to Kwh (export) only if Kwh (export) greater than zero. If both Kwh (import and export) greater than zero then apply losses to both.

89 Transformer Equation 79 Transformer Equation A Transformer Equation calculates losses using voltage and current variables (up to five variables per equation). The type 1 losses are calculated based upon the following equation: Loss =A * I4H + B * I2H + C * V4H + D * V2H + E Where: I4H = I2H * I2H * intervals per hour V4H = V2H * V2H * intervals per hour Calculated Values If all the appropriate values are not available (either I or V is not metered) an estimate of its values are calculated based upon other metered and assumed values. All losses are applied only to channels with a unit of measurement KW or MW. Losses may be applied or not in the Graphical User Interface (GUI) at the operators discretion. Losses are applied automatically in some reports (for example, transmission tariff report). If the meter type cannot be determined the number of V2H and I2H channels will be counted for the given interval and the meter type selected based on the following assumption: two channels each (V2H & I2H) for Delta meters 3 channels for the Wye meters Note: For missing components, further calculations are necessary. After deriving the value by using one of the equations 2-9, the result must be multiplied depending on meter type as follows: Multiply the result by 2 for Delta meters Multiply the result by 3 for Wye meters Keep in mind that if both V2H and I2H exist for the interval then no calculations for missing values are needed and the meter type is irrelevant. Assumed Quantities The apply method has been written to calculate losses even if one or more quantities (I2H, V2H, KVARH) are missing. In order to calculate the missing quantity certain assumptions are made as to available parameters such as the CT, PT, power factor, and assumed voltage. Depending on which quantity or quantities are not defined and the meter type the ability to calculate a missing V2H or I2H quantity may be limited. If losses cannot be calculated the interval is flagged with a "?" and no losses applied. TDR /04

90 80 Transformer Equation Assumption 1 Loss coefficients (A, B,, H) are computed so as to calculate meter primary loss values when multiplied by meter secondary voltage and current components. Assumption 2 All kwh and kvarh values used in the loss calculations are meter primary values. Assumption 3 All assumed voltages provided for use in the loss calculations when voltage components are not explicitly measured by the meter will be meter secondary voltages, line to neutral for Wye connected loads and line to line for Delta connected loads. In the following equations, this voltage will be referred to as Vsnom for nominal secondary voltage. Calculation 1 Use this relationship whenever V4H is required: The desired quantity V4 in the equation for Q tran is òv4dt, not (òv2dt)2. Therefore, the equation for Q tran should be: Qtran = C(Ti*(V2HR) 2 + Ti*(V2HY) 2 + Ti*(V2HB) 2 ) + D(I2HR + I2HY +I2HB) where Ti = Number of intervals per hour. For each interval for each phase: V4H = Ti * (V2H) 2, where Ti = number of intervals per hour Calculation 2 4 Wire Wye, 3 Element Meter: V2H not available Calculate missing components as follows for each interval: V2HR = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HR V2HY = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HY V2HB = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HB where CT = current transformer ratio, PT = potential transformer ratio.

91 Transformer Equation 81 Calculation 3 4 Wire Wye, 3 Element Meter: I2H not available Calculate missing components as follows for each interval: I2HR = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HR I2HY = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HY I2HB = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HB Calculation 4 4 Wire Wye, 3 Element Meter: V2H and I2H not available Calculate missing components as follows for each interval: V2HR = V2HY = V2HB = (1/Ti) * (Vsnom) 2, where Ti = Number of intervals per hour. I2HR = I2HY = I2HB = (1000/3) 2 * Ti * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / Vsnom2 Calculation 5 4 Wire Wye, 3 Element Meter: V2H, I2H, and kvarh not available Calculate missing components as follows for each interval: V2HR = V2HY = V2HB = (1/Ti) * (Vsnom) 2, where Ti = Number of intervals per hour. I2HR = I2HY = I2HB = (1000/3) 2 * Ti * (kwh/(ct*pt*pf)) 2 / Vsnom2 where pf is assumed power factor. Calculation 6 3 Wire Delta, 2 Element Meter: V2H not available Calculate missing components as follows for each interval: V2HR = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HR V2HY = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HY V2HB = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / I2HB where CT = current transformer ratio, PT = potential transformer ratio TDR /04

92 82 Transformer Equation Calculation 7 3 Wire Delta, 2 Element Meter: I2H not available Calculate missing components as follows for each interval: I2HR = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HR I2HY = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HY I2HB = (1000/3) 2 * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / V2HB Calculation 8 3 Wire Delta, 2 Element Meter: V2H and I2H not available Calculate missing components as follows for each interval: V2HR = V2HY = V2HB = (1/Ti) * Vsnom2, where Ti = Number of intervals per hour. I2HR = I2HY = I2HB = (1000/3) 2 * Ti * ((kwh/(ct*pt)) 2 + (kvarh/(ct*pt)) 2 ) / Vsnom2 Calculation 9 3 Wire Delta, 2 Element Meter: V2H, I2H, and kvarh not available Calculate missing components as follows for each interval: V2HR = V2HY = V2HB = (1/Ti) * (Vsnom) 2, where Ti = Number of intervals per hour. I2HR = I2HY = I2HB = (1000/3) 2 * Ti * (kwh/(ct*pt*pf)) 2 / Vsnom2 where pf is assumed power factor.

93 Volt Ampere Equation 83 Volt Ampere Equation Volt Ampere Equation (Method 2) losses are computed for each interval based on the active and reactive energy measured by the meter. The equations are as follows: Pactive loss = K1 (vkwh²+ kvarh²)²+ K2 (vkwh²+ kvarh²) + K3 Qreactive loss = K4 (vkwh²+ kvarh²)²+ K5 (vkwh²+ kvarh²) + K6 WHERE: K1, K2, K3, K4, K5, K6 are coefficients provided by the IESO (kwh and kvarh are measured by the meter). At this time, only Pactive loss are discussed. The MV-STAR system can use part of the standard quadratic equation (ax² + bx +cy² +dy +e), in particular cy² + dy + e, where c, d, and e are the coefficients K1, K2, K3 respectively and y = vkwh²+ kvarh². However, the kwh and kvarh readings from MVSTAR can be in different interval periods and K1 and K2 are expressed in terms of kw/mva² and kw/mva respectively. The equation must be modified as follows: Pactive loss = K1/I (vkwh²+ kvarh² I/1000)²? + K2/I (vkwh²+ kvarh² I /1000) + K3/I Or K1 I/ (vkwh²+ kvarh²)²? + K2/1000(vkwh²+ kvarh²) + K3/I Where: I = interval per hour Example: CH1= kwh CH2= kvarh K1= kw/mva² K2= kw/mva Interval= 5 minutes K3= Pactive loss = K1/I (vkwh²+ kvarh² I/1000)²? + K2/I (vkwh²+ kvarh² I /1000) + K3/I =0.0829/12(v ² ² 12/1000)² /12(v ² ² 12/1000) /12 = (50.191) ² (50.191) = TDR /04

94 84 Volt Ampere Equation Notes

95 Appendix A Third Party Acknowledgements The Apache Software License, Version 1.1 Copyright (c) The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software developed by the Apache Software Foundation ( Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Xerces" and "Apache Software Foundation" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected]. 5. Products derived from this software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WAR- RANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DIS- CLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPE- CIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT

96 86 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABIL- ITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OFSUCH DAMAGE. ================================================================== This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was originally based on software copyright (c) 1999, International Business Machines, Inc., For more information on the Apache Software Foundation, please see <

97 Appendix B Date Truncation The following is a list of rules for date truncation: If a new date range overlaps the existing date ranges, the existing date ranges are truncated. If the existing date range overlaps with a new date range and the new date range starts earlier than the existing date range, the existing date range will be deleted and the new date range will be added. If the existing date range overlaps with the new date range and the new date range starts after the existing date range, the existing date range will be truncated. The result will be two date ranges: A date range that begins at the start date of existing date range and ends at the start date of new date range. A new date range. Example Case Existing Date Range New Date Range Result Date Ranges 1 1/1/2001 null 12/20/2000 null 12/20/2000 nul1 2 1/1/2001 null 12/20/2000 5/15/ /20/2000 5/15/ /1/2001 3/31/2001 2/1/2001 5/31/2001 1/1/2001 2/1/2001 2/1/2001 5/31/ /1/2001 3/31/2001 5/1/2002 5/31/2001 1/1/2001 3/31/2001 5/1/2001 5/31/2001

98 88 Notes

99 Appendix C Export/Import Files This appendix contains examples of files exported from or imported into MV-STAR.

100 90 mvstartransaction.dtd ( loss and pad ) <?xml encoding="us-ascii"?> <!-- By convention in this document, elements are in capitals and words in elements are--> <!-- distinguished using underscores. Attributes are in mixed case, and word are --> <!-- distinguished using a capital letter for the beginning of each new word. --> <!-- ============================================================================ ============== --> <!-- The root element for all MV-STAR Transactations is the MVSTAR_TRANSACTION --> <!-- The participant element is not required, as the ParticipantId is a required --> <!-- attribute of the transaction set. At this time MV-STAR Transactions can include --> <!-- either a set of losses or a set of physical allocations. At this time, a file --> <!-- submission can only include loss_sets or physical_allocation_sets, but not both. --> <!ELEMENT MVSTAR_TRANSACTION ( PARTICIPANT?, ( LOSS_SET* PHYSICAL_ALLOCATION_SET* ) ) > <!ATTLIST MVSTAR_TRANSACTION ParticipantID NMTOKEN #REQUIRED StartDateNMTOKEN#REQUIRED EndDateNMTOKEN#REQUIRED > <!-- ParticipantID is the ID assigned to the Participant submitting this file by --> <!-- the market operator. --> <!-- All Dates need to be in the form YYYYMMDDHH24MI. For example, March 1st 1999, at--> <!-- 2:00 pm would be submitted as > <!-- StartDate is the earliest StartDate referenced by any element in this transaction set. --> <!-- EndDate is the latest EndDate referenced by any element in this transaction set.-->

101 91 <!-- ============================================================================ ========== --> <!-- The optional Participant Element contains information about the participant submitting --> <!-- the transaction. Additional Elements may be added to this element in the future. --> <!ELEMENT PARTICIPANT ( CONTACT*, ROLE*) > <!-- ============================================================================ ====== --> <!-- Contacts and their subelements can be given a priority. This is recommended--> <!-- when multiple instances of elements are provided. For example, if a file --> <!-- includes multiple contacts, the priority attribute will allow the operator to--> <!-- determine which contact to contact first.--> <!ELEMENT CONTACT ( LAST_NAME, FIRST_NAME, ( VOICE_PHONE)+, FAX_PHONE* ) > <!ATTLIST CONTACT Priority NMTOKEN #IMPLIED > <!ELEMENT LAST_NAME (#PCDATA)* > <!ELEMENT FIRST_NAME (#PCDATA)* > <!-- address should be an Internet addresses in the form:--> <!-- user@fullyqualifieddomainname --> <!ELEMENT (#PCDATA)* > <!ATTLIST Priority NMTOKEN #IMPLIED > <!-- Phone numbers should include all necessary country codes and area codes --> <!ELEMENT VOICE_PHONE (#PCDATA)* > <!ATTLIST VOICE_PHONE Priority NMTOKEN #IMPLIED > <!ELEMENT FAX_PHONE (#PCDATA)* > <!ATTLIST FAX_PHONE Priority NMTOKEN #IMPLIED > TDR /04

102 92 <!-- ============================================================================ ====== --> <!-- The role element references one of the enumerated market roles which is valid for --> <!-- a marketplace. The "market role" is the type of role a particular company or --> <!-- business unit is playing in the market place. These roles are defined as follows:--> <!--LDCLocal Distribution Company--> <!--REPRetail Electric Provider--> <!--UDC Utility Distribution Company--> <!--MSPMeter Service Provider--> <!--MRSP Meter Reading Service Provider--> <!--ESPEnergy Service Provider--> <!--MMPMetered Market Participant--> <!--DISCODistribution Company--> <!--TRANSCOTransmission Company--> <!-- Note: Only a subset of role designations may be meaningful in a given market.--> <!ELEMENT ROLE EMPTY> <!ATTLIST ROLE Role( LDC REP UDC MSP MRSP ESP MMP DISCO TRANSCO ) #REQUIRED > <!-- ============================================================================ ========== --> <!ELEMENT LOSS_SET ( LOSS* ) > <!ATTLIST LOSS_SET MeteringSystemIDNMTOKEN #REQUIRED MeasurementType( KWH MWH ) #REQUIRED LossType( STANDING_PERCENTAGE INTERVAL_PERCENTAGE ) #REQUIRED StartDateNMTOKEN #REQUIRED EndDateNMTOKEN #REQUIRED ValueNMTOKEN #IMPLIED > <!-- The MeteringSystemID is the market assigned identifier for a given metering --> <!-- point. This point may be a summary map, or a service point.--> <!-- The MeasurementType indicates the Unit of Measure of the meter data channel in-->

103 93 <!-- question. This may be extended in the future to include other types such as KVARH--> <!-- The LossType indicates whether the losses to follow are specified on an interval --> <!-- by interval basis, or are defined for the entire date range. When LossType is--> <!-- set to STANDING_PERCENTAGE, the Value attribute for the LOSS_SET element must be--> <!-- specified, and no LOSS elements can be included. That singular value is used for --> <!-- the entire date range. When LossType is INTERVAL_PERCENTAGE the Value attribute--> <!-- of the LOSS_SET element is ignored. Instead, individual values are provided in a--> <!-- series of LOSS elements. The number of LOSS elements provided must equal the --> <!-- the number of intervals between the StartDate and the EndDate, inclusive of the --> <!-- the StartDate and exclusive of the EndDate. For example, if the StartDate were --> <! and the EndDate were and the interval size for the --> <!-- MeteringSystemID in question is 1 hour, the LOSS_SET element would need to contain--> <!-- exactly 24 LOSS elements. Transactions containing too many or too few LOSS --> <!-- elements will be rejected.--> <!-- StartDate is the StartDate of the range of losses in YYYYMMDDHH24MI format.--> <!-- EndDate is the EndDate of the range of losses in YYYYMMDDHH24MI format.--> <!-- Value is a floating point value between zero and one inclusive indicating the loss--> <!-- percentage (in decimal form) to be applied to the channel. Note: Losses must be --> <!-- approved before they will be included in any calculations. Losses which do not--> <!-- accurately reflect the metering configuration may be summarily rejected. Also, --> <!-- the losses are unsigned. How the loss is applied is determined by the power flow--> <!-- direction of the channel it is applied to.--> TDR /04

104 94 <!-- ============================================================================ ====== --> <!ELEMENT LOSS EMPTY> <!ATTLIST LOSS Value NMTOKEN #REQUIRED > <!-- Value, is as describe above for the LOSS_SET; however it is for a single --> <!-- interval instead of the entire date range--> <!-- ============================================================================ ========== --> <!ELEMENT PHYSICAL_ALLOCATION_SET ( ALLOCATEE+ ) > <!ATTLIST PHYSICAL_ALLOCATION_SET MeteringSystemIDNMTOKEN #REQUIRED MeasurementType( KWH MWH ) #REQUIRED PowerFlow( IMPORT EXPORT ) #REQUIRED AllocationType( STANDING_PERCENTAGE INTERVAL_PERCENTAGE INTERVAL_ABSOLUTE ) #REQUIRED StartDateNMTOKEN #REQUIRED EndDateNMTOKEN #REQUIRED> <!-- The MeteringSystemID is the market assigned identifier for a given metering --> <!-- point. Allocations may only be done at a Delivery Point level.--> <!-- The MeasurementType indicates the Unit of Measure of the meter data channel in--> <!-- question. This may be extended in the future to include other types such as KVARH--> <!-- PowerFlow indicates whether the allocation is from the import or the export --> <!-- channel. That is, PowerFlow indicates whether load or generation is allocated.--> <!-- AllocationType indicates whether the allocation is a percentage based allocation --> <!-- or a absolute allocation, and whether a single value is applied for the entire--> <!-- specified by StartDate and EndDate or whether a set of allocations follows for --> <!-- each individual interval. As in the case of losses, if the allocation

105 95 is done on --> <!-- an interval level, a allocation must be provided for each interval between the --> <!-- StartDate and the EndDate inclusive of the StartDate.--> <!-- Note: Absolute allocations can only be submitted after the Trade Date in question.--> <!-- Percentage allocations can only be submitted before the Trade Date in question.--> <!-- StartDate is the StartDate of the range of allocations in YYYYMMDDHH24MI format.--> <!-- EndDate is the EndDate of the range of allocations in YYYYMMDDHH24MI format.--> <!-- ============================================================================ ====== --> <!-- The ALLOCATEE element indicates to whom a quantity (or set of quantities) is being --> <!-- allocated. In the case of STANDING_PERCENTAGE allocations the Value for the date --> <!-- range for the Participant must be specified, and no PHYSICAL_ALLOCATION elements--> <!-- should be included. In the case of the INTERVAL_PERCENTAGE or INTERVAL_ABSOLUTE--> <!-- allocations, a complete set of PHYSICAL_ALLOCATION elements must be included for --> <!-- each allocatee at a given DeliveryPoint over the specified date range.--> <!ELEMENT ALLOCATEE ( PHYSICAL_ALLOCATION* ) > <!ATTLIST ALLOCATEE ParticipantIDNMTOKEN #REQUIRED ValueNMTOKEN #IMPLIED > <!-- ParticipantID is the Market assigned identifier for the Participant to which--> <!-- this allocation is directed.note: This cannot be the Participant who --> <!-- submitted the transaction set. A Market Participant cannot allocate to itself.--> <!-- Value will only be populated when AllocationType is STANDING_PERCENTAGE. --> <!-- This percentage value must be between zero and one inclusive, and cannot TDR /04

106 96 (when --> <!-- combined with the percentages assigned to other allocatees, exceed one (100%).--> <!-- Note: This restriction may be rescinded in the future.--> <!-- ============================================================================ == --> <!ELEMENT PHYSICAL_ALLOCATION EMPTY> <!ATTLIST PHYSICAL_ALLOCATION Value NMTOKEN #REQUIRED > <!-- Value will be provided for each interval between StartDate and EndDate--> <!-- (as discussed previously) for each ALLOCATEE element, when the Allocation --> <!-- Type is INTERVAL_PERCENTAGE or INTERVAL_ABSOLUTE. In the case of --> <!-- INTERVAL_PERCENTAGE allocations, the allocation for a given interval must --> <!-- be a value between zero and one (inclusive) and, when summed with the --> <!-- values of the corresponding intervals of the other ALLOCATEEs in a given --> <!-- PHYSICAL_ALLOCATION_SET cannot exceed one (100%). In the case of --> <!-- INTERVAL_ABSOLUTE allocations, the sum of the corresponding values for all --> <!-- ALLOCATEES for a given interval cannot exceed the measured quantity with --> <!-- all losses applied at the point specified in the PHYSICAL_ALLOCATION_SET. --> <!-- Value is assumed to be in the unit of measure specified for then set.--> <!-- Value cannot be negative.--> <!-- Note: These restrictions may be modified or rescinded in the future.-->

107 97 Loss File Example <?xml version="1.0" encoding="us-ascii"?> <!DOCTYPE MVSTAR_TRANSACTION SYSTEM "mvstartransaction.dtd"> <!-- Participant and Role for the entire file. All dates in the file must appear within the dates specified here. --> <MVSTAR_TRANSACTION ParticipantID="ALL123" StartDate=" " EndDate=" "> <PARTICIPANT> <ROLE Role="LDC"/> </PARTICIPANT> <!-- Replace all losses with the MeteringSystemID and LossType within the dates specified with the interval percentage loss below --> <!-- INTERVAL_PERCENTAGE losses must appear in the past because the intervals must exist within MV-STAR --> <LOSS_SET MeteringSystemID=" " MeasurementType="KWH" LossType="INTERVAL_PERCENTAGE" StartDate=" " EndDate=" "> <LOSS Value=".01"/> <LOSS Value=".02"/> <LOSS Value=".03"/> <LOSS Value=".04"/> <LOSS Value=".05"/> <LOSS Value=".06"/> <LOSS Value=".07"/> <LOSS Value=".08"/> <LOSS Value=".09"/> <LOSS Value=".10"/> <LOSS Value=".11"/> <LOSS Value=".12"/> <LOSS Value=".13"/> <LOSS Value=".14"/> <LOSS Value=".15"/> <LOSS Value=".16"/> <LOSS Value=".17"/> <LOSS Value=".18"/> <LOSS Value=".19"/> <LOSS Value=".20"/> <LOSS Value=".21"/> <LOSS Value=".22"/> <LOSS Value=".23"/> TDR /04

108 98 <LOSS Value=".24"/> </LOSS_SET> <!-- Replace all losses with the MeteringSystemID and LossType within the dates specified with the standing percentage loss below --> <!-- Standing Percentage losses must appear in the future. --> <LOSS_SET MeteringSystemID=" " MeasurementType="KWH" LossType="STANDING_PERCENTAGE" StartDate=" " EndDate=" "> <LOSS Value=".01"/> </LOSS_SET> <!-- Multiple meters may appear in the file --> <LOSS_SET MeteringSystemID=" " MeasurementType="KWH" LossType="STANDING_PERCENTAGE" StartDate=" " EndDate=" "> <LOSS Value=".01"/> </LOSS_SET> </MVSTAR_TRANSACTION>

109 99 PAD File Example <?xml version="1.0" encoding="us-ascii"?> <!DOCTYPE MVSTAR_TRANSACTION SYSTEM "mvstartransaction.dtd"> <!-- Allocator. The same allocator( participant ) is used throughout the file. --> <!-- All dates in the file must appear between dates specified here. --> <MVSTAR_TRANSACTION ParticipantID="MV90" StartDate=" " EndDate=" "> <!-- Example of INTERVAL_ABSOLUTE pad. --> <!-- Replace all pad that has the same information specified here. --> <!-- Cannot have another PHYSICAL_ALLOCATION_SET in the file with the same information but overlapping dateranges. --> <PHYSICAL_ALLOCATION_SET MeteringSystemID="STV_MIF_DP1" MeasurementType="KWH" PowerFlow="IMPORT" AllocationType="INTERVAL_ABSOLUTE" StartDate=" " EndDate=" "> <ALLOCATEE ParticipantID="STVPART"> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> TDR /04

110 100 <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/>

111 101 <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> <PHYSICAL_ALLOCATION Value="70"/> <PHYSICAL_ALLOCATION Value="80"/> <PHYSICAL_ALLOCATION Value="90"/> <PHYSICAL_ALLOCATION Value="10"/> <PHYSICAL_ALLOCATION Value="20"/> <PHYSICAL_ALLOCATION Value="30"/> <PHYSICAL_ALLOCATION Value="40"/> <PHYSICAL_ALLOCATION Value="50"/> <PHYSICAL_ALLOCATION Value="60"/> </ALLOCATEE> </PHYSICAL_ALLOCATION_SET> <!-- Replace all pad that has the same information specified here. --> TDR /04

112 102 <!-- Cannot have another PHYSICAL_ALLOCATION_SET in the file with the same information but overlapping dateranges. --> <PHYSICAL_ALLOCATION_SET MeteringSystemID="STV_MIF_DP1" MeasurementType="KWH" PowerFlow="IMPORT" AllocationType="STANDING_PERCENTAGE" StartDate=" " EndDate=" "> <ALLOCATEE ParticipantID="STVPART"> <PHYSICAL_ALLOCATION Value=".40"/> </ALLOCATEE> </PHYSICAL_ALLOCATION_SET> <!-- Error - overlapping dateranges.--> <!-- Create three PHYSICAL_ALLOCATION_SET elements 12/1-12/3, 12/3-12/9, 12/9-12/15. Put two ALLOCATEE elements during 12/3-12/9. --> <PHYSICAL_ALLOCATION_SET MeteringSystemID="STV_MIF_DP1" MeasurementType="KWH" PowerFlow="IMPORT" AllocationType="STANDING_PERCENTAGE" StartDate=" " EndDate=" "> <ALLOCATEE ParticipantID="STVPART"> <PHYSICAL_ALLOCATION Value=".40"/> </ALLOCATEE> </PHYSICAL_ALLOCATION_SET> </MVSTAR_TRANSACTION>

113 103 MVSTAR_ENROLLMENT.xsd <?xml version = "1.0" encoding = "UTF-8"?> <!--Generated by XML Authority. Conforms to w3c <xsd:schema xmlns:xsd = " elementformdefault = "qualified"> <!-- Start ENROLLMENT --> <xsd:element name = "ENROLLMENT" type = "enrollmenttype"/> <xsd:complextype name = "enrollmenttype"> <!-- The order of the occurrence of the elements are PARTICIPANT_SET, DELIVERY_POINT_SET and CONTRACT_SET --> <xsd:sequence> <xsd:element name = "SCHEMA_VERSION" type = "xsd:integer" fixed = "1"/> <xsd:element name = "PARTICIPANT_SET" type = "participantsettype" minoccurs = "0"/> <xsd:element name = "DELIVERY_POINT_SET" type = "deliverypointsettype" minoccurs = "0"/> <xsd:element name = "CONTRACT_SET" type = "contractsettype" minoccurs = "0"/> </xsd:sequence> </xsd:complextype> <!-- Finish declaring enrollmenttype --> <!-- Defining PARTICIPANT_SET --> <xsd:complextype name = "participantsettype"> <xsd:sequence> <xsd:element name = "PARTICIPANT" type = "participanttype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "participanttype"> <!-- end of PARTICIPANT_ROLE_SET --> <!-- End of DESTINATION --> <!--Declaration of attributes--> <xsd:sequence> <xsd:element name = "PARTICIPANT_ROLE_SET" minoccurs = "0"> TDR /04

114 104 <!-- end of PARTICIPANT_ROLE --> <xsd:complextype> <xsd:sequence> <xsd:element name = "PARTICIPANT_ROLE" maxoccurs = "unbounded"> <xsd:complextype> <xsd:attribute name = "startdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "enddate" use = "optional" type = "xsd:datetime"/> <xsd:attribute name = "role" use = "required" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontypewithdaterange"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name = "DESTINATION" minoccurs = "0" maxoccurs = "unbounded"> <xsd:complextype> <xsd:attribute name = "reporttype" fixed = "DEFAULT" type = "xsd:string"/> <xsd:attribute name = "host" use = "required" type = "xsd:string"/> <xsd:attribute name = "user" use = "required" type = "xsd:string"/> <xsd:attribute name = "password" use = "required" type = "xsd:string"/> <xsd:attribute name = "directory" use = "required" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name = "participantid" use = "required" type = "xsd:string"/> <xsd:attribute name = "interfaceid" use = "optional" type = "xsd:string"/> <xsd:attribute name = "name" use = "optional" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> </xsd:complextype> <!-- End of PARTICIPANT_SET Declaration --> <!--Defining DELIVERY_POINT_SET --> <xsd:complextype name = "deliverypointsettype"> <xsd:sequence> <xsd:element name = "DELIVERY_POINT" type = "deliverypointtype" maxoccurs = "unbounded"/>

115 105 </xsd:sequence> </xsd:complextype> <xsd:complextype name = "deliverypointtype"> <xsd:sequence> <xsd:element name = "DP_ASSOCIATION_SET" minoccurs = "0"> <xsd:complextype> <xsd:sequence> <xsd:element name = "DP_ASSOCIATION" maxoccurs = "unbounded"> <xsd:complextype> <xsd:attribute name = "startdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "enddate" use = "optional" type = "xsd:datetime"/> <xsd:attribute name = "associatedid" use = "required" type = "xsd:string"/> <xsd:attribute name = "autogenerate" use = "optional" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontypewithdaterange"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name = "deliverypointid" use = "required" type = "xsd:string"/> <xsd:attribute name = "name" use = "optional" type = "xsd:string"/> <xsd:attribute name = "accessrestriction" use = "optional" type = "xsd:string"/> <xsd:attribute name = "weatherzone" use = "optional" type = "xsd:string"/> <xsd:attribute name = "revenueclass" use = "optional" type = "xsd:string"/> <xsd:attribute name = "loadfactor" use = "optional" type = "xsd:string"/> <xsd:attribute name = "loadarea" use = "optional" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> </xsd:complextype> <!-- End of Delivery Point declaration --> <!-- Defining a contract set--> <xsd:complextype name = "contractsettype"> <xsd:sequence> <xsd:element name = "CONTRACT" type = "contracttype" maxoccurs = "unbounded"/> </xsd:sequence> TDR /04

116 106 </xsd:complextype> <xsd:complextype name = "contracttype"> <xsd:attribute name = "startdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "enddate" use = "optional" type = "xsd:datetime"/> <xsd:attribute name = "participantid" use = "optional" type = "xsd:string"/> <xsd:attribute name = "deliverypointid" use = "required" type = "xsd:string"/> <xsd:attribute name = "role" use = "required" type = "xsd:string"/> <xsd:attribute name = "subtype" use = "optional" type = "xsd:string"/> <xsd:attribute name = "reference" use = "optional" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontypewithdaterange"/> </xsd:complextype> <!-- End of contract declaration --> <xsd:simpletype name = "actiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "DELETE"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name = "actiontypewithdaterange"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "DELETE"/> <xsd:enumeration value = "END"/> </xsd:restriction> </xsd:simpletype> </xsd:schema>

117 107 Enrollment Example <?xml version="1.0" encoding="utf-8"?> <ENROLLMENT xmlns:xsi=" xsi:nonamespaceschemalocation="mvstar_enrollment.xsd"> <SCHEMA_VERSION>1</SCHEMA_VERSION> <!-- All participants must appear in this section --> <PARTICIPANT_SET> <!-- This example is a full record of Participant--> <PARTICIPANT participantid="duns0001" interfaceid="duns0001" name="pacificorp" action="update"> <PARTICIPANT_ROLE_SET> <PARTICIPANT_ROLE role="ess" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> <PARTICIPANT_ROLE role="tc" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> </PARTICIPANT_ROLE_SET> <DESTINATION reporttype="default" host="cis1" user="acc0001" password="pass001" directory ="/mvstar/acc0001" action="update"/> </PARTICIPANT> <!-- This example is for creation of Participant without a destination --> <PARTICIPANT participantid="duns0002" interfaceid="duns0002" name="wal-mart" action="update"> <PARTICIPANT_ROLE_SET> <PARTICIPANT_ROLE role="mp" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> <PARTICIPANT_ROLE role="tc" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> TDR /04

118 108 </PARTICIPANT_ROLE_SET> </PARTICIPANT> <!-- Creating participant without participant role or destination --> <PARTICIPANT participantid="sess0001" interfaceid="sess0001" name="wal-mart" action="update"/> <PARTICIPANT participantid="duns0002" interfaceid="duns0002" name="wal-mart" action="update"> <PARTICIPANT_ROLE_SET> <!-- Deleting a participant role --> <PARTICIPANT_ROLE role="mp" startdate=" t00:00:00" enddate=" t00:00:00" action="delete"/> <!-- End an open ended role with the end date provided. Start Date is ignored. --> <PARTICIPANT_ROLE role="mp" startdate=" t00:00:00" enddate=" t00:00:00" action="end"/> </PARTICIPANT_ROLE_SET> </PARTICIPANT> <!-- Deleting a participant --> <PARTICIPANT participantid="duns0003" interfaceid="duns0003" name="wal-mart" action="delete"/> </PARTICIPANT_SET> <!-- All delivery points must appear in this section --> <DELIVERY_POINT_SET> <!-- This example is a full record of Delivery Point. Adding or Updating. --> <DELIVERY_POINT deliverypointid = "PODA1" action="update" weatherzone="w1" revenueclass="residential" loadfactor="0.8" loadarea="z1">

119 109 <DP_ASSOCIATION_SET> <!-- more than one DP_ASSOCIATION can be specified. Autogenerate the meter and give it ID specified. --> <DP_ASSOCIATION associatedid ="SP1" autogenerate="on" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> <!-- The date ranges can not overlap --> <DP_ASSOCIATION associatedid ="SP2" autogenerate="off" startdate=" t00:00:00" enddate=" t00:00:00" action="update"/> </DP_ASSOCIATION_SET> </DELIVERY_POINT> <!-- This example is an example of a Delivery Point with no Association --> <DELIVERY_POINT deliverypointid = "PODA2" action="update" weatherzone="w1" revenueclass="residential" loadfactor="0.8" loadarea="z1"/> <DELIVERY_POINT deliverypointid = "PODA3" action="update" weatherzone="w1" revenueclass="residential" loadfactor="0.8" loadarea="z1"> <DP_ASSOCIATION_SET> <!-- Deleting an Association. --> <DP_ASSOCIATION associatedid ="SP1" startdate=" t00:00:00" enddate=" t00:00:00" action="delete"/> </DP_ASSOCIATION_SET> </DELIVERY_POINT> <!-- This example is an example of deleting a Delivery Point --> <DELIVERY_POINT deliverypointid = "PODA3" action="delete"/> </DELIVERY_POINT_SET> <!-- All delivery points must appear in this section --> <CONTRACT_SET> TDR /04

120 110 <!-- Adding or updating a contract --> <CONTRACT participantid = "DUNS0001" deliverypointid="poda1" role="ess" startdate=" t00:00:00" enddate=" t00:00:00" action ="UPDATE"/> <CONTRACT participantid = "WAL-MART" deliverypointid="poda1" role="mp" startdate=" t00:00:00" enddate=" t00:00:00" subtype="product1" action ="UPDATE"/> <!-- If end date is not specified, it is a open ended contract --> <CONTRACT participantid = "SESS0001" deliverypointid="poda1" role="sess" startdate=" t00:00:00" action ="UPDATE"/> <!-- End an open ended contract with the Participant, Delivery Point, Role with the end date specified. Start Date is ignored. --> <CONTRACT participantid = "DUNS0004" deliverypointid="poda1" role="tc" startdate=" t00:00:00" enddate=" t00:00:00" subtype="product1" action ="END"/> <!-- Delete a contract with the Participant, Delivery Point, Role with the dates specified. --> <CONTRACT participantid = "DUNS0005" deliverypointid="poda1" role="tc" startdate=" t00:00:00" enddate=" t00:00:00" subtype="product1" action="delete"/> </CONTRACT_SET> </ENROLLMENT>

121 111 MVSTAR_SITE_REGISTRATION.xsd <?xml version = "1.0" encoding = "UTF-8"?> <!--Generated by Turbo XML Conforms to w3c <xsd:schema xmlns:xsd = " elementformdefault = "qualified"> <!-- This schema is used by site registration loader and site registration recport--> <!-- Start SITE_REGISTRATION--> <xsd:element name = "METER_INFORMATION" type = "siteregistrationtype"/> <xsd:complextype name = "siteregistrationtype"> <xsd:sequence> <xsd:element name = "SCHEMA_VERSION" type = "xsd:integer" fixed = "1"/> <xsd:element name = "METER_POINT_SET" type = "meterpointsettype" minoccurs = "0"/> <xsd:element name = "SUMMARY_MAP_SET" type = "summarymapsettype" minoccurs = "0"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "meterpointsettype"> <xsd:sequence> <xsd:element name = "METER_POINT" type = "meterpointtype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "summarymapsettype"> <xsd:sequence> <xsd:element name = "SUMMARY_MAP" type = "summarymaptype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "meterpointtype"> <!-- The check/redundant meter id--> <xsd:sequence> <xsd:element name = "METERING_SYSTEM_SECTION" type = "meteringsystemsectiontype" minoccurs = "0"/> <xsd:element name = "METER_CHANNEL_SET" type = "meterchannelsettype" TDR /04

122 112 minoccurs = "0"/> <xsd:element name = "PHYSICAL_METER" type ="physicaltype" minoccurs = "0"/> </xsd:sequence> <xsd:attribute name = "msid" use = "required" type = "xsd:string"/> <xsd:attribute name = "meterpointname" type = "xsd:string"/> <xsd:attribute name = "voltagecode" type = "xsd:string"/> <xsd:attribute name = "noofchannels" type = "xsd:positiveinteger"/> <xsd:attribute name = "meteringtype" type = "metertype"/> <xsd:attribute name = "sitemaximumkw" type = "xsd:double"/> <xsd:attribute name = "siteminimumkw" type = "xsd:double"/> <xsd:attribute name = "recorderid" type = "xsd:string"/> <xsd:attribute name = "recorderserialno" type = "xsd:string"/> <xsd:attribute name = "recordertype" type = "xsd:string"/> <xsd:attribute name = "recordertelnumber" type = "xsd:string"/> <xsd:attribute name = "contactname" type = "xsd:string"/> <xsd:attribute name = "address1" type = "xsd:string"/> <xsd:attribute name = "address2" type = "xsd:string"/> <xsd:attribute name = "address3" type = "xsd:string"/> <xsd:attribute name = "address4" type = "xsd:string"/> <xsd:attribute name = "telephonenumber" type = "xsd:string"/> <xsd:attribute name = "faxnumber" type = "xsd:string"/> <xsd:attribute name = "assumedvoltage" type = "xsd:double"/> <xsd:attribute name = "assumedpowerfactor" type = "xsd:double"/> <xsd:attribute name = "ctratio" type = "xsd:double"/> <xsd:attribute name = "ptratio" type = "xsd:double"/> <xsd:attribute name = "servicetype" type = "xsd:string"/> <xsd:attribute name = "baseprofilename" type = "xsd:string"/> <xsd:attribute name = "parentmeterid" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> </xsd:complextype> <!-- Finish defining meter point--> <xsd:complextype name = "meterchannelsettype"> <xsd:sequence> <xsd:element name = "METER_CHANNEL" type = "meterchanneltype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype>

123 113 <!-- Finish defining meter channel set --> <xsd:complextype name="physicaltype"> <xsd:attribute name = "serialnumber" type = "xsd:string"/> <xsd:attribute name = "metermultiplier" type = "xsd:string"/> <xsd:attribute name = "commissionfromdate" type = "xsd:datetime" use="required"/> <xsd:attribute name = "commissiontodate" type = "xsd:datetime"/> <xsd:attribute name = "action" default = "UPDATE" type = "childactiontype"/> </xsd:complextype> <xsd:complextype name = "meterchanneltype"> <xsd:attribute name = "channelnumber" use = "required" type = "xsd:positiveinteger"/> <xsd:attribute name = "meterregistertype" type = "xsd:string"/> <xsd:attribute name = "unitofmeasure" use = "required" type = "xsd:string"/> <xsd:attribute name = "logicalchannelnumber" type = "xsd:positiveinteger"/> <xsd:attribute name = "pulsemultiplier" type = "xsd:double"/> <xsd:attribute name = "pulseoffset" type = "xsd:double"/> <xsd:attribute name = "metertype" type = "xsd:string" default="m"/> <xsd:attribute name = "dialsize" type = "xsd:positiveinteger"/> <xsd:attribute name = "powerflow" use = "required" type = "powerflowtype"/> <xsd:attribute name = "omitchannelonuploadyn" type = "xsd:string" default="true"/> <xsd:attribute name = "action" default = "UPDATE" type = "childactiontype"/> </xsd:complextype> <xsd:complextype name = "summarymaptype"> <xsd:sequence> <xsd:element name = "METERING_SYSTEM_SECTION" type = "meteringsystemsectiontype" minoccurs = "0"/> <xsd:element name = "SUMMARY_CHANNEL_SET" type = "summarychannelsettype" minoccurs = "0"/> </xsd:sequence> <xsd:attribute name = "msid" use = "required" type = "xsd:string"/> <xsd:attribute name = "voltagecode" type = "xsd:string"/> <xsd:attribute name = "summarymapname" type = "xsd:string"/> TDR /04

124 114 <xsd:attribute name = "commissionfromdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "commissiontodate" type = "xsd:datetime"/> <xsd:attribute name = "contactname" type = "xsd:string"/> <xsd:attribute name = "address1" type = "xsd:string"/> <xsd:attribute name = "address2" type = "xsd:string"/> <xsd:attribute name = "address3" type = "xsd:string"/> <xsd:attribute name = "address4" type = "xsd:string"/> <xsd:attribute name = "postcode" type = "xsd:string"/> <xsd:attribute name = "telephonenumber" type = "xsd:string"/> <xsd:attribute name = "faxnumber" type = "xsd:string"/> <xsd:attribute name = "assumedvoltage" type = "xsd:double"/> <xsd:attribute name = "assumedpowerfactor" type = "xsd:double"/> <xsd:attribute name = "ctratio" type = "xsd:double"/> <xsd:attribute name = "ptratio" type = "xsd:double"/> <xsd:attribute name = "servicetype" type = "xsd:string"/> <xsd:attribute name = "action" type = "fullactiontype"/> </xsd:complextype> <!-- Finishing define summary map --> <xsd:complextype name = "meteringsystemsectiontype"> <xsd:attribute name = "startdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "enddate" type = "xsd:datetime"/> <xsd:attribute name = "intervallength" type = "xsd:integer"/> <xsd:attribute name = "action" default ="UPDATE" type="sectiontype"/> </xsd:complextype> <xsd:complextype name = "summarychannelsettype"> <xsd:sequence> <xsd:element name = "SUMMARY_CHANNEL" type = "summarychanneltype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "summarychanneltype"> <xsd:sequence> <xsd:element name = "SUMMARY_CONTRIBUTOR_SET" type = "summarycontributorsettype" minoccurs="0"/> </xsd:sequence> <xsd:attribute name = "channelnumber" use = "required" type = "xsd:positiveinteger"/>

125 115 <xsd:attribute name = "unitofmeasure" use = "required" type = "xsd:string"/> <xsd:attribute name = "powerflow" use = "required" type = "powerflowtype"/> <xsd:attribute name = "dialsize" type = "xsd:positiveinteger"/> <xsd:attribute name = "setnumber" type = "xsd:integer"/> <xsd:attribute name = "action" default ="UPDATE" type = "childactiontype"/> </xsd:complextype> <!-- FInish defining summary contributor set.--> <xsd:complextype name = "summarycontributorsettype"> <xsd:sequence> <xsd:element name = "SUMMARY_CONTRIBUTOR" maxoccurs = "unbounded"> <xsd:complextype> <xsd:attribute name = "contributorchannelnumber" use = "required" type = "xsd:positiveinteger"/> <xsd:attribute name = "contributormsid" use = "required" type = "xsd:string"/> <xsd:attribute name = "contributionfromdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "contributiontodate" type = "xsd:datetime"/> <xsd:attribute name = "operation" use = "required" type = "xsd:string"/> <xsd:attribute name = "scalefactor" type = "xsd:string"/> <xsd:attribute name = "orderofoperation" type = "xsd:string" use="required"/> <xsd:attribute name = "action" default ="UPDATE" type = "childactiontype"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> <xsd:simpletype name = "metertype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "M"/> <xsd:enumeration value = "C"/> <xsd:enumeration value = "R"/> <xsd:enumeration value = "S"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name = "powerflowtype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "I"/> <xsd:enumeration value = "E"/> </xsd:restriction> </xsd:simpletype> TDR /04

126 116 <xsd:simpletype name = "actiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "REPLACE"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name = "fullactiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "REPLACE"/> <xsd:enumeration value = "DELETE"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name = "childactiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "DELETE"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name = "sectiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> </xsd:restriction> </xsd:simpletype> </xsd:schema>

127 117 Meter Information File Example {\rtf1\ansi\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}} \viewkind4\uc1\pard\lang1033\f0\fs20 <?xml version="1.0" standalone="yes"?>\par <METER_INFORMATION xsi:nonamespaceschemalocation="mvstar_site_registration.xsd" xmlns:xsi=" \par \tab <SCHEMA_VERSION>1</SCHEMA_VERSION>\par \par \tab <!-- All Service Points must appear in this section -->\par \tab <METER_POINT_SET>\par \par \tab\tab <!-- Example of a full Service Point. Add or Update an existing Service Point. Only information present will be added or changed -->\par \tab\tab <METER_POINT msid="dqr_mp1" meterpointname="data Quality Report Regression Testing" noofchannels="4" action="update">\par \par \tab\tab\tab <!-- Interval length -->\par \tab\tab\tab <METERING_SYSTEM_SECTION startdate=" t00:00:00" enddate=" t00:00:00" intervallength="30"/>\par \par \tab\tab\tab <!-- All channels for this meter must appear here -->\par \tab\tab\tab <METER_CHANNEL_SET>\par \par \tab\tab\tab\tab <!-- Add or Update an channel -->\par \tab\tab\tab\tab <METER_CHANNEL channelnumber="1" meterregistertype="v" unitofmeasure="kwh" logicalchannelnumber="1" pulsemultiplier="1.0" pulseoffset="0.0" metertype="main" dialsize="9" powerflow="i" omitchannelonuploadyn="false" action="update"/>\par \par \tab\tab\tab\tab <!-- Delete a channel -->\par \tab\tab\tab\tab <METER_CHANNEL channelnumber="2" meterregistertype="v" unitofmeasure="kvarh" logicalchannelnumber="2" pulsemultiplier="1.0" pulseoffset="0.0" metertype="main" dialsize="9" powerflow="e" omitchannelonuploadyn="false" action="delete"/>\par \par \tab\tab\tab </METER_CHANNEL_SET>\par \par \tab\tab\tab <!-- Physical meter -->\par \tab\tab\tab <PHYSICAL_METER commissionfromdate=" t00:00:00" commissiontodate=" t00:00:00" serialnumber="dqr_mp1" action="update"/>\par \par TDR /04

128 118 \tab\tab </METER_POINT>\par \par \par \tab\tab <!-- Replace all information for this meter with what appears in the file. All sub-element's action attributes will be ignored. -->\par \tab\tab <!-- If the meter had a channel 2, it would not longer appear. Any attributes that do no appear here will not appear in the new meter -->\par \tab\tab <METER_POINT msid="dqr_mp2" meterpointname="data Quality Report Regression Testing" noofchannels="4" action="replace">\par \par \tab\tab\tab <!-- Interval length -->\par \tab\tab\tab <METERING_SYSTEM_SECTION startdate=" t00:00:00" enddate=" t00:00:00" intervallength="30"/>\par \par \tab\tab\tab <!-- All channels for this meter must appear here -->\par \tab\tab\tab <METER_CHANNEL_SET>\par \par \tab\tab\tab\tab <!-- Add or Update an channel -->\par \tab\tab\tab\tab <METER_CHANNEL channelnumber="1" meterregistertype="v" unitofmeasure="kwh" logicalchannelnumber="1" pulsemultiplier="1.0" pulseoffset="0.0" metertype="main" dialsize="9" powerflow="i" omitchannelonuploadyn="false" action="update"/>\par \par \tab\tab\tab\tab <!-- Delete a channel -->\par \tab\tab\tab\tab <METER_CHANNEL channelnumber="3" meterregistertype="v" unitofmeasure="kvarh" logicalchannelnumber="2" pulsemultiplier="1.0" pulseoffset="0.0" metertype="main" dialsize="9" powerflow="e" omitchannelonuploadyn="false" action="update"/>\par \par \tab\tab\tab </METER_CHANNEL_SET>\par \par \tab\tab\tab <!-- Physical meter -->\par \tab\tab\tab <PHYSICAL_METER commissionfromdate=" t00:00:00" commissiontodate=" t00:00:00" serialnumber="dqr_mp1" action="update"/>\par \par \tab\tab </METER_POINT>\par \par \par \tab </METER_POINT_SET>\par \par \tab <!-- All Summary Maps must appear in this section -->\par \tab <SUMMARY_MAP_SET>\par \par

129 119 \tab\tab <!-- Example of a full Summary Map. Add or update a Summary Map -->\par \tab\tab <SUMMARY_MAP msid="dqr_sm1" summarymapname="data Quality Report Regression Testing" commissionfromdate=" t00:00:00" commissiontodate=" t00:00:00" action="update">\par \par \tab\tab\tab <!-- Interval Size -->\par \tab\tab\tab <METERING_SYSTEM_SECTION startdate=" t00:00:00" enddate=" t00:00:00" intervallength="30"/>\par \par \tab\tab\tab <!-- All channels for this meter must appear here -->\par \tab\tab\tab <SUMMARY_CHANNEL_SET>\par \par \tab\tab\tab\tab <!-- Add or update a channel -->\par \tab\tab\tab\tab <SUMMARY_CHANNEL channelnumber="1" unitofmeasure="kwh" dialsize="9" powerflow="i" setnumber="1">\par \par \tab\tab\tab\tab\tab <!-- All contributors for this channel must appear here -->\par \tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR_SET>\par \par \tab\tab\tab\tab\tab\tab <!-- Add or Update c contributor -->\par \tab\tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR contributorchannelnumber="1" contributormsid="dqr_mp1" contributionfromdate=" t00:00:00" contributiontodate=" t00:00:00" operation="+" scalefactor="1.0" orderofoperation="1" action="update"/>\par \par \tab\tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR contributorchannelnumber="1" contributormsid="dqr_mp2" contributionfromdate=" t00:00:00" contributiontodate=" t00:00:00" operation="+" scalefactor="1.0" orderofoperation="2" action="update"/>\par \par \tab\tab\tab\tab\tab\tab <!-- Delete a contributor -->\par \tab\tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR contributorchannelnumber="1" contributormsid="dqr_mp2" contributionfromdate=" t00:00:00" contributiontodate=" t00:00:00" operation="+" scalefactor="1.0" orderofoperation="2" action="delete"/>\par \par \tab\tab\tab\tab\tab </SUMMARY_CONTRIBUTOR_SET>\par \par \tab\tab\tab\tab </SUMMARY_CHANNEL>\par \par \tab\tab\tab\tab <!-- Delete a channel -->\par \tab\tab\tab\tab <SUMMARY_CHANNEL channelnumber="2" unitofmeasure="kwh" dialsize="9" powerflow="i" setnumber="1" action="delete"/>\par TDR /04

130 120 \par \tab\tab\tab </SUMMARY_CHANNEL_SET>\par \par \tab\tab </SUMMARY_MAP>\par \par \par \tab\tab <!-- Replace all information for this meter with what appears in the file. All sub-element's action attributes will be ignored. -->\par \tab\tab <!-- If the meter had a channel 2, it would not longer appear. Any attributes that do no appear here will not appear in the new meter -->\par \tab\tab <SUMMARY_MAP msid="dqr_sm2" summarymapname="data Quality Report Regression Testing" commissionfromdate=" t00:00:00" commissiontodate=" t00:00:00" action="replace">\par \par \tab\tab\tab <!-- Interval Size -->\par \tab\tab\tab <METERING_SYSTEM_SECTION startdate=" t00:00:00" enddate=" t00:00:00" intervallength="30"/>\par \par \tab\tab\tab <!-- All channels for this meter must appear here -->\par \tab\tab\tab <SUMMARY_CHANNEL_SET>\par \par \tab\tab\tab\tab <!-- Add or update a channel -->\par \tab\tab\tab\tab <SUMMARY_CHANNEL channelnumber="1" unitofmeasure="kwh" dialsize="9" powerflow="i" setnumber="1">\par \par \tab\tab\tab\tab\tab <!-- All contributors for this channel must appear here -->\par \tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR_SET>\par \par \tab\tab\tab\tab\tab\tab <!-- Add or Update c contributor -->\par \tab\tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR contributorchannelnumber="1" contributormsid="dqr_mp1" contributionfromdate=" t00:00:00" contributiontodate=" t00:00:00" operation="+" scalefactor="1.0" orderofoperation="1" action="update"/>\par \par \tab\tab\tab\tab\tab\tab <SUMMARY_CONTRIBUTOR contributorchannelnumber="1" contributormsid="dqr_mp2" contributionfromdate=" t00:00:00" contributiontodate=" t00:00:00" operation="+" scalefactor="1.0" orderofoperation="2" action="update"/>\par \par \tab\tab\tab\tab\tab </SUMMARY_CONTRIBUTOR_SET>\par \par \tab\tab\tab\tab </SUMMARY_CHANNEL>\par \par \par

131 121 \tab\tab\tab </SUMMARY_CHANNEL_SET>\par \par \tab\tab </SUMMARY_MAP>\par \par \tab\tab <!-- Delete a Summary Map -->\par \tab\tab <SUMMARY_MAP msid="dqr_sm2" summarymapname="data Quality Report Regression Testing" commissionfromdate=" t00:00:00" commissiontodate=" t00:00:00" action="delete"/>\par \par \tab </SUMMARY_MAP_SET>\par \par </METER_INFORMATION>\par \par \par } TDR /04

132 122 MVSTAR_REGISTER.xsd <?xml version = "1.0" encoding = "UTF-8"?> <!--Generated by XML Authority. Conforms to w3c <xsd:schema xmlns:xsd = " elementformdefault = "qualified"> <xsd:annotation> <xsd:documentation xml:lang = "en"> Register Reading Schema, Developed by Itron-EIS Copyright 2001 Itron, Inc. All rights reserved. </xsd:documentation> </xsd:annotation> <xsd:element name = "REGISTER_TRANSACTION" type = "registertransactiontype"/> <xsd:complextype name = "registertransactiontype"> <xsd:sequence> <xsd:element ref = "SCHEMA_VERSION"/> <xsd:element name = "REFERENCE_ID" type = "xsd:nmtoken" minoccurs = "0"/> <xsd:element name = "REGISTER_SET" type = "registersettype" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <!-- Register sets for one meter --> <xsd:complextype name = "registersettype"> <xsd:sequence> <xsd:element name = "REGISTER" type = "registertype" minoccurs = "0" maxoccurs = "unbounded"/> </xsd:sequence> <xsd:attribute name = "meterid" use = "required" type = "xsd:string"/> </xsd:complextype> <!-- RegisterType declaration --> <xsd:complextype name = "registertype"> <xsd:sequence> <xsd:choice> <xsd:element name = "ABSOLUTE_READING" type = "absolutereadingtype" minoccurs = "0" maxoccurs = "unbounded"/> <xsd:element name = "RELATIVE_READING" type = "relativereadingtype" minoccurs = "0" maxoccurs = "unbounded"/>

133 123 </xsd:choice> </xsd:sequence> <xsd:attribute name = "maximumvalue" use = "optional" type = "xsd:unsignedint"/> <xsd:attribute name = "type" use = "required" type = "xsd:string"/> <xsd:attribute name = "multiplier" use = "optional" type = "xsd:decimal"/> </xsd:complextype> <!-- AbsoluteReadingType declaration --> <xsd:complextype name = "absolutereadingtype"> <xsd:attribute name = "read" use = "required" type = "xsd:double"/> <xsd:attribute name = "readdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "startdate" use = "required" type = "xsd:datetime"/> <xsd:attribute ref = "action" default = "UPDATE"/> </xsd:complextype> <!-- RelativeReadingType declaration --> <xsd:complextype name = "relativereadingtype"> <xsd:attribute name = "read" use = "required" type = "xsd:double"/> <xsd:attribute name = "readdate" use = "required" type = "xsd:datetime"/> <xsd:attribute name = "firstreading" default = "false" type = "xsd:boolean"/> <xsd:attribute name = "rollovercount" default = "0" type = "xsd:unsignedint"/> <xsd:attribute ref = "action" default = "UPDATE"/> </xsd:complextype> <!-- Common Types --> <xsd:element name = "SCHEMA_VERSION" type = "xsd:integer" fixed = "1"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> <xsd:simpletype name = "actiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> <xsd:enumeration value = "DELETE"/> </xsd:restriction> </xsd:simpletype> <xsd:element name = "DATERANGE" type = "mvstardatetype"/> <xsd:complextype name = "mvstardatetype"> <xsd:sequence> <xsd:element name = "startdate" type = "xsd:datetime"/> TDR /04

134 124 <xsd:element name = "enddate" type = "xsd:datetime" minoccurs = "0" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:schema> Register File Example <?xml version="1.0" encoding="utf-8"?> <REGISTER_TRANSACTION xmlns:xsi=" xsi:nonamespaceschemalocation="mvstar_register.xsd"> <SCHEMA_VERSION>1</SCHEMA_VERSION> <REFERENCE_ID>26.5</REFERENCE_ID> <!-- Register Reads for meter POD > <REGISTER_SET meterid="pod0001"> <!-- Multiplier and Maximum value are optional--> <REGISTER type="total_kwh" maximumvalue="999999" multiplier="2.5"> <!-- Absolute readings are calculated readings. All operations have been done. --> <!-- Add the reading if the reading does not exist or update the reading if it exists. --> <!-- <REGISTER_SET meterid, REGISTER type, <ABSOLUTE_READING readdate = unique key --> <ABSOLUTE_READING read="1024" startdate=" t00:00:00" readdate=" t00:00:00" action="update"/> <!-- add or update another reading for the same meter and register type. --> <ABSOLUTE_READING read="1024" startdate=" t00:00:00" readdate=" t00:00:00" action="update"/> </REGISTER> <!-- If you want a reading for the same meter but a different register type. --> <REGISTER type="total_kvarh"> <ABSOLUTE_READING read="1027" startdate=" t00:00:00" readdate=" t00:00:00" action="update"/>

135 125 <!-- If you want to delete a reading. --> <ABSOLUTE_READING read="1027" startdate=" t00:00:00" readdate=" t00:00:00" action="delete"/> </REGISTER> </REGISTER_SET> <!-- If you want to load reading for a different meter --> <!-- Register Reads for meter POD > <REGISTER_SET meterid="pod0002"> <!-- Multiplier and Maximum value are optional--> <REGISTER type="total_kwh" maximumvalue="999999" multiplier="2.5"> <!-- Relative readings are uncalculated readings. No operations have been done. Known as dial reads. --> <!-- Add the reading if the reading does not exist or update the reading if it exists. --> <!-- <REGISTER_SET meterid, REGISTER type, <RELATIVE_READING readdate = unique key --> <RELATIVE_READING read="1024" readdate=" t00:00:00" firstreading="true" rollovercount="0" action="update"/> <!-- add or update another reading for the same meter and register type. --> <RELATIVE_READING read="1024" readdate=" t00:00:00" firstreading="true" rollovercount="0" action="update"/> </REGISTER> <!-- If you want a reading for the same meter but a different register type. --> <REGISTER type="total_kvarh"> <RELATIVE_READING read="1024" readdate=" t00:00:00" firstreading="true" rollovercount="0" action="update"/> <!-- If you want to delete a reading. --> <RELATIVE_READING read="1024" readdate=" t00:00:00" firstreading="true" rollovercount="0" action="delete"/> TDR /04

136 126 </REGISTER> </REGISTER_SET> </REGISTER_TRANSACTION>

137 127 MVSTAR_LOSS_CONFIGURATION.xsd <?xml version = "1.0" encoding = "UTF-8"?> <!--Generated by Turbo XML Conforms to w3c <xsd:schema xmlns:xsd = " elementformdefault = "qualified"> <!-- This schema is used by loss loader--> <!-- Start LOSS_TRANSACTION --> <xsd:element name="loss_transaction" type="losstransactiontype"/> <xsd:complextype name="losstransactiontype"> <xsd:sequence> <xsd:element name="schema_version" type="xsd:integer" fixed="1"/> <xsd:element name="voltage_code_set" type="voltagecodesettype" minoccurs="0"/> <xsd:element name="factor_set" type="factorsettype" minoccurs="0"/> <xsd:element name="applied_loss_set" type="appliedlosssettype" minoccurs="0"/> <xsd:element name="voltage_code_assignment_set" type="voltagecodeassignmentsettype" minoccurs="0"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="voltagecodesettype"> <xsd:sequence> <xsd:element name="voltage_code" type="voltagecodetype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="voltagecodetype"> <xsd:attribute name="voltagecode" use="required" type="xsd:string"/> <xsd:attribute name="description" type="xsd:string"/> <xsd:attribute name="action" default="update" type="childactiontype"/> </xsd:complextype> <xsd:complextype name="factorsettype"> TDR /04

138 128 <xsd:sequence> <xsd:element name="factors" type="factorstype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="factorstype"> <xsd:sequence> <xsd:element name="fixed_loss_factor" type="fixedlossfactortype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="equation_loss" type="equationlosstype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="variable_loss_span" type="variablelossspantype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <!-- This for auto naming. When using this, you must use action=replace --> <xsd:attribute name="voltagecode" type="xsd:string"/> <xsd:attribute name="action" default="update" type="fullactiontype"/> </xsd:complextype> <xsd:complextype name="fixedlossfactortype"> <xsd:attribute name="startdate" use="required" type="xsd:datetime"/> <xsd:attribute name="enddate" type="xsd:datetime"/> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="description" type="xsd:string"/> <xsd:attribute name="factor" use="required" type="xsd:decimal"/> <xsd:attribute name="fixed_loss_type" type="xsd:string"/> <xsd:attribute name="action" default="update" type="childactiontype"/> </xsd:complextype> <xsd:complextype name="equationlosstype"> <xsd:attribute name="startdate" use="required" type="xsd:datetime"/> <xsd:attribute name="enddate" type="xsd:datetime"/> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="description" type="xsd:string"/> <xsd:attribute name="equationtype" use="required" type="xsd:string"/> <xsd:attribute name="coefficienta" use="required" type="xsd:decimal"/> <xsd:attribute name="coefficientb" use="required" type="xsd:decimal"/> <xsd:attribute name="coefficientc" use="required" type="xsd:decimal"/> <xsd:attribute name="coefficientd" use="required" type="xsd:decimal"/>

139 129 <xsd:attribute name="coefficiente" use="required" type="xsd:decimal"/> <xsd:attribute name="coefficientf" use="required" type="xsd:decimal"/> <xsd:attribute name="action" default ="UPDATE" type="childactiontype"/> </xsd:complextype> <xsd:complextype name="variablelossspantype"> <xsd:sequence> <xsd:element name="variable_loss_factor" type="variablelossfactortype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="startdate" use="required" type="xsd:datetime"/> <xsd:attribute name="enddate" type="xsd:datetime"/> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="description" type="xsd:string"/> <xsd:attribute name="intervalsize" use="required" type="xsd:integer"/> <xsd:attribute name="action" default="replace" type="replaceactiontype"/> </xsd:complextype> <xsd:complextype name="variablelossfactortype"> <xsd:attribute name="factor" use="required" type="xsd:decimal"/> </xsd:complextype> <xsd:complextype name="appliedlosssettype"> <xsd:sequence> <xsd:element name="applied_loss" type="appliedlosstype" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="appliedlosstype"> <xsd:choice> <xsd:element name="voltage_code_copy" type="voltagecodecopytype" minoccurs="0"/> <xsd:element name="loss_factor" type="lossfactortype" minoccurs="0" maxoccurs="unbounded"/> </xsd:choice> <xsd:attribute name="voltagecode" use="required" type="xsd:string"/> <xsd:attribute name="action" default="update" type="fullactiontype"/> </xsd:complextype> TDR /04

140 130 <xsd:complextype name="voltagecodecopytype"> <xsd:attribute name="voltagecode" use="required" type="xsd:string"/> <xsd:attribute name="action" default="copy" type="copytype"/> </xsd:complextype> <xsd:complextype name="lossfactortype"> <xsd:attribute name="name" use="required" type="xsd:string"/> <xsd:attribute name="losstype" use="required" type="xsd:string"/> <xsd:attribute name="action" default="update" type="childactiontype"/> </xsd:complextype> <xsd:complextype name="voltagecodeassignmentsettype"> <xsd:sequence> <xsd:element name="voltage_code_assignment" type="voltagecodeassignmenttype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="voltagecodeassignmenttype"> <xsd:attribute name="meteringsystemid" use="required" type="xsd:string"/> <xsd:attribute name="voltagecode" type="xsd:string"/> <xsd:attribute name="action" default="update" type="childactiontype"/> </xsd:complextype> <xsd:simpletype name="fullactiontype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="update"/> <xsd:enumeration value="replace"/> <xsd:enumeration value="delete"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="childactiontype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="update"/> <xsd:enumeration value="delete"/> </xsd:restriction> </xsd:simpletype>

141 131 <xsd:simpletype name="replaceactiontype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="replace"/> <xsd:enumeration value="delete"/> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="copytype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="copy"/> <xsd:enumeration value="reference"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> Loss Configuration Example <?xml version="1.0" encoding="utf-8"?> <LOSS_TRANSACTION xmlns:xsi=" xsi:nonamespaceschemalocation="mvstar_loss_configuration.xsd"> <SCHEMA_VERSION>1</SCHEMA_VERSION> <VOLTAGE_CODE_SET> <!-- This is how to create a new Voltage Code - assume this one does not exist in MV-STAR --> <VOLTAGE_CODE voltagecode="new_voltage_code" description="creating a new Voltage Code" action="update"/> <!-- This is how to modify an existing Voltage Code - assume this one does exist in MV-STAR --> <VOLTAGE_CODE voltagecode="exist_voltage_code" description="modifying the Voltage Code" action="update"/> TDR /04

142 132 <!-- This is how to delete an existing Voltage Code - assume this one does exist in MV-STAR --> <VOLTAGE_CODE voltagecode="exist_voltage_code" description="modifying the Voltage Code" action="delete"/> </VOLTAGE_CODE_SET> <FACTOR_SET> <!-- If you do not know the loss names, then use this form of <FACTORS>. All Losses will be connected to the VoltageCode given. --> <!-- Loss Names will be auto named if no name is given. Action must be "REPLACE". --> <FACTORS voltagecode="exist_voltage_code" action="replace"> <!-- This is how to create a new Fixed Loss - assume this one does not exist in MV-STAR --> <FIXED_LOSS_FACTOR startdate=" t00:00:00" enddate=" t00:00:00" name="new_fixed_loss" description="creating a new Fixed Loss" factor="10.5" action="update"/> <!-- This is how to modify a Fixed Loss - assume this one does exist in MV-STAR --> <FIXED_LOSS_FACTOR startdate=" t00:00:00" enddate=" t00:00:00" name="existing_fixed_loss" description="modifying a Fixed Loss" factor="111.5" action="update"/> </FACTORS> <!-- If you know the loss names, then use this form of <FACTORS> --> <FACTORS> <!-- This is how to create a new Fixed Loss - assume this one does not exist in MV-STAR --> <FIXED_LOSS_FACTOR startdate=" t00:00:00" enddate=" t00:00:00" name="new_fixed_loss" description="creating a new Fixed Loss" factor="10.5" action="update"/> <!-- This is how to modify a Fixed Loss - assume this one does exist in MV-STAR --> <FIXED_LOSS_FACTOR startdate=" t00:00:00" enddate=" t00:00:00" name="existing_fixed_loss" description="modifying a Fixed Loss" factor="111.5" action="update"/>

143 133 <!-- This is how to delete a Fixed Loss - assume this one does exist in MV-STAR --> <FIXED_LOSS_FACTOR startdate=" t00:00:00" enddate=" t00:00:00" name="existing_fixed_loss" description="deleting a Fixed Loss" factor="10.5" action="delete"/> <!-- This is how to create an Equation Loss - assume this one does not exist in MV-STAR --> <EQUATION_LOSS startdate=" t00:00:00" enddate=" t00:00:00" name="new_equation_loss" description="creating a new Equation Loss" equationtype="te1" coefficienta="2.4" coefficientb="6.7" coefficientc="8.9" coefficientd="2.45" coefficiente="0" coefficientf="0" action="update"/> <!-- This is how to modify an Equation Loss - assume this one does exist in MV-STAR --> <EQUATION_LOSS startdate=" t00:00:00" enddate=" t00:00:00" name="existing_equation_loss" description="modifying an Equation Loss" equationtype="te1" coefficienta="112.4" coefficientb="6.7" coefficientc="8.9" coefficientd="2.45" coefficiente="0" coefficientf="0" action="update"/> <!-- This is how to delete an Equation Loss - assume this one does exist in MV-STAR --> <EQUATION_LOSS startdate=" t00:00:00" enddate=" t00:00:00" name="existing_equation_loss" description="deleting an Equation Loss" equationtype="te1" coefficienta="2.4" coefficientb="6.7" coefficientc="8.9" coefficientd="2.45" coefficiente="0" coefficientf="0" action="delete"/> <!-- This is how to create a Variable Loss - assume this one does not exist in MV-STAR --> <VARIABLE_LOSS_SPAN startdate=" t00:00:00" enddate=" t00:00:00" name="new_vari_loss" description="creating the new Variable Loss" intervalsize="60" action="replace"> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> TDR /04

144 134 <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> </VARIABLE_LOSS_SPAN> <!-- This is how to modify a Variable Loss - assume this one does exist in MV-STAR --> <!-- Cannot replace an interval. Must recreate the entire time frame --> <VARIABLE_LOSS_SPAN startdate=" t00:00:00" enddate=" t00:00:00" name="exist_vari_loss" description="modifying a Variable Loss" intervalsize="60" action="replace"> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/>

145 135 <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> <VARIABLE_LOSS_FACTOR factor="10.5"/> </VARIABLE_LOSS_SPAN> <!-- This is how to delete a Variable Loss - assume this one does exist in MV-STAR --> <VARIABLE_LOSS_SPAN startdate=" t00:00:00" enddate=" t00:00:00" name="exist_vari_loss" description="deleting a Variable Loss" intervalsize="60" action="delete"/> </FACTORS> </FACTOR_SET> <APPLIED_LOSS_SET> <!-- This is how to create a new mapping - this voltage code and loss occur in this file --> <APPLIED_LOSS voltagecode="new_voltage_code" action="update"> <LOSS_FACTOR name="new_fixed_loss" losstype="f" action="update"/> </APPLIED_LOSS> <!-- This is how to delete all existing mappings - this voltage code and loss exists --> <APPLIED_LOSS voltagecode="new_voltage_code" action="delete"/> <!-- This is how to replace all existing mappings - this voltage code and loss exists --> <!-- only the mappings listed will exist. Any mappings not listed will be deleted --> <APPLIED_LOSS voltagecode="exist_voltage_code" action="replace"> <LOSS_FACTOR name="new_fixed_loss" losstype="f" action="update"/> </APPLIED_LOSS> <!-- This is how to copy an existing configuration to an existing voltage code --> <!-- any mappings existing under voltage_code2 will be deleted and replaced --> <!-- New losses will be created that are equivalent to the losses from the old voltage code. The new losses will be attached to the new Voltage Code. --> <APPLIED_LOSS voltagecode="new_voltage_code" action="replace"> <VOLTAGE_CODE_COPY voltagecode="exist_voltage_code" action="copy"/> </APPLIED_LOSS> TDR /04

146 136 <!-- This is how to copy an existing configuration to an existing voltage code --> <!-- any mappings existing under voltage_code2 will be deleted and replaced --> <!-- The existing losses from the old voltage code will be attached to the new Voltage Code. --> <APPLIED_LOSS voltagecode="new_voltage_code" action="replace"> <VOLTAGE_CODE_COPY voltagecode="exist_voltage_code" action="reference"/> </APPLIED_LOSS> </APPLIED_LOSS_SET> <VOLTAGE_CODE_ASSIGNMENT_SET> <!-- This is how to add or change a voltage code mapping to a service point or summary map --> <VOLTAGE_CODE_ASSIGNMENT meteringsystemid="exist_mp" voltagecode="exist_voltage_code" action="update"/> <!-- This is how to delete a voltage code mapping to a service point or summary map --> <VOLTAGE_CODE_ASSIGNMENT meteringsystemid="exist_mp" voltagecode="exist_voltage_code" action="delete"/> </VOLTAGE_CODE_ASSIGNMENT_SET> </LOSS_TRANSACTION>

147 137 MVSTAR_METERPOINT.xsd <?xml version = "1.0" encoding = "UTF-8"?> <!--Generated by XML Authority. Conforms to w3c <xsd:schema xmlns:xsd = " elementformdefault = "qualified"> <xsd:element name = "METER_POINT_TRANSACTION" type = "meterpointtranactiontype"/> <xsd:complextype name = "meterpointtranactiontype"> <xsd:sequence> <xsd:element name = "SCHEMA_VERSION" type = "xsd:integer"/> <xsd:element name = "REFERENCE_ID" type = "xsd:nmtoken" minoccurs = "0"/> <xsd:element name = "METER_POINT_SET" type = "meterpointsettype" minoccurs = "0" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name = "meterpointtype"> <xsd:attribute name = "meterid" use = "required" type = "xsd:string"/> <xsd:attribute name = "voltagecode" default = "" type = "xsd:string"/> <xsd:attribute name = "baseprofileid" default = "" type = "xsd:string"/> <xsd:attribute name = "action" default = "UPDATE" type = "actiontype"/> </xsd:complextype> <xsd:simpletype name = "actiontype"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "UPDATE"/> </xsd:restriction> </xsd:simpletype> <xsd:complextype name = "meterpointsettype"> <xsd:sequence> <xsd:element name = "METER_POINT" type = "meterpointtype" minoccurs = "0" maxoccurs = "unbounded"/> </xsd:sequence> </xsd:complextype> </xsd:schema> TDR /04

148 138 Meter Point File Example <?xml version = "1.0" encoding = "UTF-8"?> <METER_POINT_TRANSACTION xmlns:xsi=" xsi:nonamespaceschemalocation="mvstar_meterpoint.xsd"> <SCHEMA_VERSION>1</SCHEMA_VERSION> <REFERENCE_ID>3.4</REFERENCE_ID> <METER_POINT_SET> <!-- Set the voltage code and base profile for meter DPDR_SP1 --> <METER_POINT meterid="dpdr_sp1" voltagecode="s" baseprofileid="bmsprof_1" action="update"/> <!-- Set the voltage code for meter DPDR_SP1 --> <METER_POINT meterid="dpdr_sp2" voltagecode="s" action="update"/> <!-- Set the base profile for meter DPDR_SP1 --> <METER_POINT meterid="dpdr_sp3" baseprofileid="bmsprof_1" action="update"/> <!-- Unset the base profile for meter DPDR_SP1 --> <METER_POINT meterid="dpdr_sp4" baseprofileid="" action="update"/> <!-- Unset the voltage code for meter DPDR_SP1 --> <METER_POINT meterid="dpdr_sp5" voltagecode="" action="update"/> </METER_POINT_SET> </METER_POINT_TRANSACTION>