EC4T Metering Rules Explanatory Note (A) These EC4T Metering Rules set out: (i) the process

for collecting electricity consumption data and other related data from metering equipment installed on trains and supplying it to Network Rail; and the rules which shall apply where metered data is missing or not supplied to Network Rail within the prescribed time,

(ii)

for the purposes of calculating the Traction Electricity Charge. (B) 1. 1.1 This Explanatory Note does not form part of the EC4T Metering Rules. Definitions and Interpretation Unless otherwise defined in these EC4T Metering Rules or the context requires otherwise, words and expressions used in these EC4T Metering Rules shall have the meanings, constructions and interpretation ascribed to them in the Relevant Track Access Contract. In these EC4T Metering Rules, unless the context otherwise requires: Calling Pattern has the meaning ascribed to it in paragraph 1.1 of Schedule 5 of the Relevant Track Access Contract; Consumption Data means data in respect of the amount of electricity consumed (in kWh); Electricity Data means Consumption Data and (where relevant) Regenerative Braking Data; GPS Data means data in respect of geographical location; Infill Value means the value in respect of Consumption Data or Regenerative Braking Data, as the case may be, set out in column 11 of the Journey Look-Up Table or the value in respect of Consumption Data set out in column 4 of the Non-Journey Look-Up Table, as the case may be; Journey means a movement of Specified Equipment which has a designated headcode; Journey Look-Up Table means a table containing Consumption Data and Regenerative Braking Data calculated or otherwise determined in accordance with paragraph 3, a template for which is set out in appendix 1; Journey Time has the meaning ascribed to it in paragraph 1.1 of Schedule 5 of the Relevant Track Access Contract; Look-Up Tables means the Journey Look-Up Table and the Non-Journey Look-Up Table;

1.2

Metered Consumption means the amount of electricity consumed (in kWh) by a train as measured by the On Train Meter or infilled or substituted in accordance with these EC4T Metering Rules; Metered Data means Electricity Data and GPS Data in respect of a train which has been collected from the train's On-Train Meter; Metered Regenerated Electricity means the amount of electricity generated (in kWh) by a train as measured by the On-Train Meter or infilled or substituted in accordance with these EC4T Metering Rules; Network Rail Metering Data Interface Specification means a document which may be updated by Network Rail from time to time, in which Network Rail shall specify the manner and format in which Metered Data shall be provided to it, an example of which is set out in appendix 2; Non-Journey means a period during which the Specified Equipment is parked or laid up for maintenance or other purposes, in relation to which there is no designated headcode; Non-Journey Look-Up Table means a table containing Consumption Data calculated or otherwise determined in accordance with paragraph 3, a template for which is set out in appendix 1; On-Train Meter has the meaning ascribed to it in paragraph 1 of Schedule 7 of the Relevant Track Access Contract; Participating Train Operator means all train operators whose track access contracts incorporate these EC4T Metering Rules; Regenerative Braking Data means data in respect of the amount of electricity (in kWh) generated by braking; Relevant Days means, in relation to a calendar month, all weekdays or all Saturdays or all Sundays falling within such month; Relevant Track Access Contract means the track access contract into which these EC4T Metering Rules are incorporated; Substitution Value means the value in respect of Consumption Data or Regenerative Braking Data, as the case may be, set out in column 9 of the Journey Look-Up Table; Traction Equipment Register means a component of the traction equipment electronics fitted to a train that records data representative of the amount of electricity consumed by the train in regular increments. 2. 2.1 Application of these EC4T Metering Rules The Train Operator shall collect Metered Data from all of its On-Train Meters and shall, subject to paragraph 2.2 below, provide such data to Network Rail within 7 (seven) days of the day on which such data was generated.

2.2

In the event that any Consumption Data, Regenerative Braking Data or GPS Data is missing from the Metered Data collected by the Train Operator, the Train Operator shall provide data calculated in accordance with paragraphs 4, 5 or 6 (as the case may be) in place of such missing data. The data referred to in paragraph 2.1 (including any data calculated in accordance with paragraph 2.2) shall be provided to Network Rail in accordance with the Network Rail Metering Data Interface Specification or as otherwise agreed between the Train Operator and Network Rail. In the event that the Train Operator fails to provide any such data to Network Rail within the 7 (seven) day period referred to in paragraph 2.1, the provisions of paragraph 4.2(C) and 5.1, as applicable, shall apply for the purposes of calculating that part of the Traction Electricity Charge relating to such data. Look-Up Tables

2.3

2.4

3.

Journeys 3.1 3.2 The Train Operator shall create and maintain a Journey Look-Up Table. Subject to paragraph 3.7, in relation to each Journey, the Journey Look-Up Table shall include: (A) the mean value of each of: (1) (2) Consumption Data; and where relevant, Regenerative Braking Data,

recorded by the relevant On-Train Meters, calculated, unless otherwise agreed between the parties, in relation to a calendar month, as the aggregate of the relevant data for Journeys with the same Calling Pattern and Journey Time on the Relevant Days, divided by the total number of such Journeys, which shall be the Substitution Values in relation to Consumption Data and Regenerative Braking Data, as the case may be, for such Journey; and (B) the mean value of each of: (1) (2) Consumption Data; and where relevant, Regenerative Braking Data,

recorded by the On-Train Meter relating to each 5 minute segment of the relevant Journey, which shall be calculated by dividing the Substitution Value in relation to Consumption Data and Regenerative Braking Data for such Journey by the number (rounded up or down, as appropriate) of 5 minute segments within such Journey, which shall be the Infill Values in relation to Consumption Data and Regenerative Braking Data, as the case may be, for such Journey.

Non-Journeys 3.3 3.4 The Train Operator shall create and maintain a Non-Journey Look Up Table. Subject to paragraph 3.7, in relation to Non-Journeys at each location, the Non-Journey Look-Up Table shall include the mean value of Consumption Data relating to each 5 minute segment of each relevant Non-Journey, which shall be calculated either: (A) by dividing the total value of Consumption Data recorded by On-Train Meters in relation to the relevant Non-Journeys at a particular location over a 12-month period by the total number of 5 minute segments within such Non-Journeys over the relevant 12-month period; or subject to agreement by Network Rail (such agreement not to be unreasonably withheld or delayed) by dividing the total value of Consumption Data recorded by On-Train Meters in relation to NonJourneys at all locations over a 12-month period by the total number of 5 minute segments within such Non-Journeys over the relevant 12month period,

(B)

which shall be the Infill Value in relation to Consumption Data for a NonJourney at such location. General 3.5 The Train Operator shall update the Look-Up Tables as soon as reasonably practicable after the start of each Relevant Year. The form and content of the Look-Up Tables shall be as set out in appendix 1 unless otherwise agreed between the parties. ORR approval shall not be required for the creation or updating of the LookUp Tables. Where Consumption Data and, where relevant, Regenerative Braking Data collected from On-Train Meters of the relevant Specified Equipment for a 12month period is not available: (A) appropriate values in relation to Journeys and Non-Journeys for which actual historic data is not available may be agreed between the parties and following any such agreement, such agreed values shall apply until such time as actual historic data is available, when such data shall be used to populate the Look-Up Tables, or the parties cease to agree, in which case paragraph 3.7(B) shall apply, in the absence of agreement between the parties in accordance with paragraph (A) above, modelled Consumption Data and, where relevant, the modelled consumption rate in respect of regenerative braking for the relevant Specified Equipment shall be used in respect of each calendar month for which actual historic data is not available until such time as actual historic data is available, when such data shall be used to populate the Look-Up Tables.

3.6 3.7

(B)

3.8

In addition to any other rights of Network Rail whether contained in the Relevant Track Access Contract or otherwise, copies of the current Look-Up Tables shall be made available by the Train Operator to Network Rail at all reasonable times. Infilling or substitution of missing Metered Data for Journeys If, in respect of a Journey for a particular day: (A) (B) up to 25% of Consumption Data is missing from the Metered Data; or up to 25% of the Regenerative Braking Data is missing from the Metered Data

4. 4.1

then each 5 minute segment of missing Consumption Data or Regenerative Braking Data (as the case may be) in respect of such Journey, shall be infilled with the relevant Infill Values contained in column 11 of the Journey Look-Up Table. 4.2 If, in respect of a Journey for a particular day: (A) (B) (C) more than 25% of Consumption Data is missing from the Metered Data; or more than 25% of the Regenerative Braking Data is missing from the Metered Data; or the Metered Data is not provided by the Train Operator to Network Rail within 7 days (pursuant to paragraph 2.1 above),

the entire Consumption Data or Regenerative Braking Data (as the case may be) in respect of such Journey, shall be substituted with the relevant Substitution Values contained in column 9 of the Journey Look-Up Table. 5. 5.1 Infilling of missing Metered Data for Non-Journeys If, in respect of a Non-Journey for a particular day, any Consumption Data is missing from the Metered Data in respect of such Non-Journey, or such data is not provided by the Train Operator to Network Rail within 7 days (pursuant to paragraph 2.1 above), then each 5 minute segment of missing Consumption Data in respect of such Non-Journey, shall be infilled with the relevant Infill Value contained in column 4 of the Non-Journey Look-Up Table. Missing GPS Data If, in respect of a Journey for a particular day any GPS Data is missing, the missing GPS Data shall be interpolated using the actual recorded GPS Data immediately adjacent to both sides of the missing GPS Data. If in respect of a Non-Journey for a particular day any GPS Data is missing, the missing GPS Data shall be the standing location of the relevant train.

6. 6.1

6.2

7. 7.1

Consequences of more than 30% of Electricity Data being missing for one Period If in any Period more than 30% of Electricity Data is missing from the Metered Data, all Infill Values and Substitution Values, as applicable, used in the calculation of the Traction Electricity Charge during such Period shall be amended as follows: (A) (B) the Infill Values and Substitution Values, as applicable, in relation to Metered Consumption shall be increased by 10%; and the Infill Values and Substitution Values, as applicable, in relation to Metered Regenerated Electricity shall be reduced by 10%.

8. 8.1

Traction Equipment Register Values Where such equipment is fitted to the Specified Equipment and where reasonably requested by Network Rail from time to time, the Train Operator shall use its reasonable endeavours at the next scheduled train heavy maintenance event to record and provide to Network Rail the Traction Equipment Register values and interval data (as appropriate) for the relevant train in respect of which the Train Operator provides Metered Data to Network Rail. Changes to these EC4T Metering Rules

9.

Entitlement to make Proposed Metering Rules Change 9.1 Any Participating Train Operator, Network Rail or the Office of Rail Regulation (the Proposing Party) shall be entitled to make a proposal to change the EC4T Metering Rules (a Proposed Metering Rules Change) for consideration and approval by other Participating Train Operators, Network Rail, (the Other Parties) and the Office of Rail Regulation (ORR), as applicable. Any such proposal shall: (A) (B) (C) be sent to Network Rail (except where Network Rail is the Proposing Party); be in writing; specify the wording of the Proposed Metering Rules Change and the date or series of dates on which it is proposed that it come into effect, if other than the period of 14 days after any approval notified by the Office of Rail Regulation pursuant to 9.16 below; and be supported by an explanation in reasonable detail of the reasons for the Proposed Metering Rules Change.

9.2

(D)

Notice of Proposed Metering Rules Change

9.3

Network Rail shall, within 7 days following receipt of a Proposed Metering Rules Change, or, if later, within 7 days following receipt of any clarification that Network Rail may reasonably request from the Proposing Party: (A) give notice of that Proposed Metering Rules Change to the Other Parties and the ORR, as applicable, unless any such person has notified Network Rail that it does not wish to receive notice of a Proposed Metering Rules Change; and invite the submission to Network Rail of written representations in respect of that proposal within such period as is reasonable in all the circumstances (the Consultation Period), being a period of not less than 30 days from the date of notification under paragraph (A) above.

(B)

9.4 9.5

The Proposing Party shall promptly comply with all reasonable written requests of Network Rail for further clarification of the proposal. Paragraphs 9.1 to 9.4 above shall not require that any modification to which paragraphs 9.23 to 9.30 below applies shall first have been proposed by the ORR under these paragraphs 9.1 to 9.4 above.

Approval of Proposed Metering Rules Change 9.6 The Other Parties shall consider and, if thought fit, approve each Proposed Metering Rules Change. A Proposed Metering Rules Change shall have been approved only if: (A) a majority of the Other Parties are in favour of the relevant Proposed Metering Rules Change, provided that the failure of an Other Party timeously to submit representations pursuant to paragraph 9.3(B) above or an Other Party intimating its abstention shall be treated as a vote in favour of the proposal; and no Other Party objects to the Proposed Metering Rules Change on the grounds that it is likely to have a material and adverse effect on its interests within the period set out in paragraph 9.3(B) above (the exercise of a veto, and all cognate terms and expressions shall be construed accordingly).

(B)

9.7

Network Rail shall, as soon as reasonably practicable following a request by an Other Party to carry out further consultation in respect of any Proposed Metering Rules Change, carry out that further consultation.

Appeal procedure 9.8 9.9 If an Other Party shall have exercised its veto, another Other Party or the Proposing Party shall be entitled to give a notice of appeal against it. A notice of appeal (notice of appeal) shall: (A) be given to the Office of Rail Regulation and all other Other Parties and the Proposing Party, as applicable, not later than 35 days after the exercise of the veto;

(B)

contain the reasons why the Other Party or the Proposing Party, as applicable, in question considers that the veto should not have effect; and request the Office of Rail Regulation to determine the matter.

(C) 9.10

Without prejudice to paragraph 9.11, the Proposing Party and the Other Parties shall use their respective reasonable endeavours to procure that the Office of Rail Regulation is furnished with sufficient information to dispose of the appeal as soon as reasonably practicable after the date of the notice of appeal. In relation to any such appeal, the Office of Rail Regulation shall, in determining it, have the power: (A) to give directions as to the procedure to be followed in the appeal, including in relation to the making of any written and oral submissions and the extent to which any evidence or other submissions made by one party to the appeal shall be disclosed to the other; to make any interim order as to the conduct or the positions of the parties pending final determination of the appeal; to determine whether the veto shall have effect; and to make such orders as it shall think fit in relation to the proportions of the costs of the appeal which shall be borne by any of the parties.

9.11

(B) (C) (D) 9.12

Where any party shall have given a notice of appeal, the Office of Rail Regulation shall: (A) be entitled to decline to determine the appeal if, having consulted the parties concerned, it shall determine that the appeal should not proceed, including on the grounds that: (1) (2) (3) (B) the matter in question is not of sufficient importance to the industry; the reference to it is frivolous or vexatious; or the conduct of the party making the reference ought properly to preclude its being proceeded with; and

not be liable in damages or otherwise for any act or omission to act on its part (including negligence) in relation to the appeal.

9.13

The determination of the Office of Rail Regulation shall be final and binding on all parties to track access contracts incorporating the EC4T Metering Rules.

ORR Approval 9.14 Network Rail shall, as soon as reasonably practicable following a decision by the Other Parties to approve a Proposed Metering Rules Change (or following a determination of the Office of Rail Regulation that a veto should not have

effect following an appeal pursuant to paragraphs 9.8 to 9.13 above), submit the proposal to the Office of Rail Regulation, together with a written memorandum: (A) (B) explaining the reasons for the proposed change; containing details of the results of the consultation process (including copies of any representations made pursuant to paragraph 9.3(B) above which shall have been neither accepted nor withdrawn); stating the reasons for any dissent from that decision by any Other Party; and stating the date or series of dates upon which it is considered that the proposal is to take effect, the first date being no earlier that 14 days after the date on which the Office of Rail Regulation approves the proposal pursuant to paragraph 9.16.

(C) (D)

9.15

The Proposing Party and the Other Parties shall use their respective reasonable endeavours to provide any further information required in relation to the consideration of a Proposed Metering Rules Change by the Office of Rail Regulation. The Office of Rail Regulation may notify Network Rail as soon as reasonably practicable of its approval or rejection of a Proposed Metering Rules Change submitted to it pursuant to paragraph 9.14 above. No Proposed Metering Rules Change shall have effect unless the Office of Rail Regulation gives notice to Network Rail in writing that it approves the proposal pursuant to paragraph 9.16 above. Network Rail shall, as soon as reasonably practicable following a decision of the Other Parties to reject a Proposed Metering Rules Change, notify the Proposing Party of that decision.

9.16

9.17

9.18

Procedural Irregularities 9.19 If before the effective date or dates of any change (as notified under paragraph 9.32 below) a complaint is made to the Office of Rail Regulation concerning a failure to comply with any part of the procedure relating to the relevant Proposed Metering Rules Change, paragraph 9.20 shall apply. The Office of Rail Regulation shall consider the nature of the complaint and determine either that: (A) (B) the change should become effective on the date notified under paragraph 9.32 below; or the change should not become effective on the date notified under paragraph 9.32 below and shall be treated as a new Proposed Metering Rules Change.

9.20

9.21

A change in respect of which a complaint has been made under paragraph 9.19 above shall not become effective unless and until the Office of Rail Regulation makes a determination under paragraph 9.20(A) above. If a complaint is made to the Office of Rail Regulation concerning a failure to comply with any part of the procedure relating to a Proposed Metering Rules Change after the effective date or dates of any change, such change will remain in full force and effect as though no complaint had been made.

9.22

Modification of the EC4T Metering Rules by the ORR 9.23 The EC4T Metering Rules shall have effect with the modifications specified in any notice given by the Office of Rail Regulation for the purposes of these paragraphs 9.23 to 9.30, (modification notice) provided that the Office of Rail Regulation shall be satisfied as to the need for the modification as provided in paragraph 9.24 below, the procedural requirements of paragraph 9.27 below shall have been satisfied, and the modification shall not have effect until the date provided for in paragraph 9.28 below. A notice given by the Office of Rail Regulation under paragraph 9.23 above shall have effect if it is satisfied on reasonable grounds that either or both of the following conditions has been satisfied: (A) the modification in question is or is likely to be reasonably required in order to promote or achieve the objectives specified in section 4 of the Act; and the interests of any Participating Train Operator would be unfairly prejudiced if the modification in question were not made, and the need to avoid or remedy such unfair prejudice outweighs or is likely to outweigh any prejudice which will or is likely to be sustained by any other relevant person or persons if the modification is made, having due regard to the need to enable relevant persons to plan the future of their businesses with a reasonable degree of assurance.

9.24

(B)

9.25

A modification specified in a modification notice shall not have effect if its effect would, if made, be: (A) to prevent to a material extent any Participating Train Operator or Access Option Holder exercising, or receiving the benefit of, a protected right; or materially to increase any protected obligation of any Participating Train Operator or Access Option Holder

(B)

provided that no person shall be entitled to challenge or otherwise call into question the effectiveness of any such modification unless he (affected operator) shall have given notice to the Office of Rail Regulation not more than 45 days after the date of the modification notice stating that the modification in question would, if made, have on him any such effect and such notice shall be accompanied by such relevant information in support of such statement as it shall be reasonable to expect him to be able to provide.

9.26

Any challenge or other procedure of the kind referred to in paragraph 9.25 shall, unless the affected operator and the Office of Rail Regulation shall otherwise agree, be determined by an arbitrator in accordance with the Access Dispute Resolution Rules within 180 days of the date upon which the affected operator shall have given notice to the Office of Rail Regulation as provided for in paragraph 9.25. The procedural requirements which require to have been followed for the purposes of paragraph 9.23 above are: (A) in its consideration of the matters referred to in paragraph 9.24 above, the Office of Rail Regulation shall have consulted the Secretary of State, Network Rail and the Participating Train Operators together with any other persons which the Office of Rail Regulation shall consider ought properly to be consulted, in relation to the modification which it proposes to make; in the consultations referred to in paragraph 9.27(A) above, the Office of Rail Regulation shall have made available to each person so consulted such drafts of the proposed modification as it shall consider are necessary so as properly to inform such persons of the detail of the proposed modification; the Office of Rail Regulation shall have given each person so consulted the opportunity to make representations in relation to the proposed modification and shall have taken into account all such representations (other than those which are frivolous or trivial) in making its decision on the modification to be made; the Office of Rail Regulation shall have notified each person consulted pursuant to paragraph 9.27(A) above as to its conclusions in relation to the modification in question (including by providing to each such person a copy of the text of the proposed modification) and its reasons for those conclusions; and in effecting the notifications required by paragraph 9.27(D) above, the Office of Rail Regulation shall have treated as confidential any representation (including any submission of written material) which (and to the extent that) the person making the representation shall, by notice in writing to the Office of Rail Regulation or by endorsement on the representation of words indicating the confidential nature of such representation, have specified as confidential information.

9.27

(B)

(C)

(D)

(E)

9.28

A notice under paragraph 9.23 above shall have effect upon such date, or the happening of such event, as shall be specified in the notice, provided that it shall in no circumstances have effect earlier than 180 days after the date upon which it shall have been given. As soon as reasonably practicable after Network Rail shall have received any written material from the Office of Rail Regulation pursuant to paragraph 9.27 above, Network Rail shall send a copy to each of the Participating Train Operators.

9.29

9.30

A notice under paragraph 9.23 shall not have effect in relation to any proposed modification of paragraphs 9.23 to 9.29 (inclusive) or this paragraph 9.30.

Notification to parties 9.31 If the Office of Rail Regulation approves the proposed change in accordance with paragraph 9.16 Network Rail shall ensure that all Participating Train Operators shall be notified of the change and its effective date.

Effective date of Change 9.32 Without prejudice to paragraphs 9.23 to 9.30 above, a notice under paragraph 9.31 shall specify the effective date(s) of the proposed change which shall unless otherwise determined be 14 days from the date of notification made pursuant to paragraph 9.31 above.

Provision of revised texts 9.33 Network Rail shall, as soon as reasonably practicable following issue of a notice under paragraph 9.23 or following approval of a Proposed Metering Rules Change by the Office of Rail Regulation pursuant to paragraph 9.16, supply to all Participating Train Operators a revised version of the EC4T Metering Rules incorporating the change. List of Participating Operators Network Rail shall maintain and keep updated a list of the Participating Train Operators. In addition to any other rights of the Train Operator whether contained in the Relevant Track Access Contract or otherwise, the current list of the Participating Train Operators shall be made available by Network Rail to the Train Operator at all reasonable times. Dispute Resolution The dispute resolution processes set out in clause 13 of the Relevant Track Access Contract shall apply in respect of any dispute arising out of or in relation to these EC4T Metering Rules.

10. 10.1 10.2

11. 11.1

APPENDIX 1: TEMPLATE LOOK UP TABLE Journey Look-Up Table 1. 2. 3. 4. 5. 6. 7. 8. 9. Substitution Value (kWh): Month Relevant Day Year Headcode (Weekdays, Saturdays or Sundays) Specified From To Via Equipment 10. 11. Infill Value (kWh): Regenerative Braking Data

Consumption Regenerative No. of 5 Consumption Data Braking Data minute Data segments

Non-Journey Look-Up Table 1. 2. 3. 4. Infill Value (kWh): Year Location Specified Equipment Consumption Data

APPENDIX 2: EXAMPLE NETWORK RAIL METERING DATA INTERFACE SPECIFICATION This example appendix identifies the issues involved in data transfer between a Train Operator and Network Rail and how they might be handled.

Document Control and Administration 1. Document History

Date Name / Role Description of Changes

Version

2.

Reviewers
Date Name / Role Comment

Version

3.

Document Approval
Date Name / Role Qualifications to Approval

Version

4.
ID

Internal References
Reference / Name Version Date

5.
ID

External References
Reference / Name Version Date

Introduction This specification provides the data requirements and interface approach to: 1. Support the receipt of metered data from Train Operating Companies via the OTM Service. 2. Calculate a journey based bill (NOT ESTA based) The overriding consideration for the Network Rail billing system is: 1. TABS is required to support ALL TOCs and FOCs. 2. TABS is predicated on Journey based billing, historically and because almost ALL operators have no meter capability currently or are likely to for some years to come. For these reasons: 2.1. Journey based billing remains necessary for period end EC4T billing and year end Wash-Up; and to avoid costly disputes. In addition, the solution has to take into account: 3. Mixed train formations (part metered, part non metered) are likely during meter uptake across the fleet for many years to come 4. Shared services The train journey allows us to identify the operator associated with meter reading 5. Standing Locations The train journey allows Network Rail to distinguish Standing location vs. a Train stuck at a signal for 30 minutes 6. Splitting / joining of trains at various locations. Journey details help Network Rail treat appropriately. The OTM Service is expected to support the processes and requirements of UIC 930 Leaflet for EU Cross Energy Settlement, and any additional agreed UK Rail Industry Requirements. Data provisioned from Trains / Train Operator is to expected to comply with Standards BS EN 50463 (currently in draft). It is intended that Network Rail will receive meter data by way of a Web Service. Network Rail may also issue requests for metered data to the OTM Service (as a Web Service), triggered by requests from the Billing system. This is aligned to the UIC 930 Leaflet service capabilities. The document does not address any specific needs of the UK Train Operators (TOCs, FOCs), European infrastructure companies/train operators, and/or 3rd Partys such as ATOC, DFT. The document does not focus on the long term solution. However TOCs and FOCs will be expected to align to the to be agreed Industry solution, at some point in the future either directly or indirectly, by way of OTM Service. The following diagram summarises the context of this document.

Figure 1 Interface Context

1.

Billing - Overview

Network Rail will match metered data to billable EC4T line items (referred to as Fine Journey Legs within the Billing system), in keeping with the existing billing regime the industry requires of Network Rail to adhere to. The Fine Journey Legs are based on an actual Train Journey - further broken down by ESTA, Zone, Time Band (Peak / Off Peak), Night/Day. The Fine Journey Legs have an associated Vehicle ID and are delimited by two Network Locations (Stanox) which have an associated time (at 1 minute resolution). Consumption and Regenerative values will be based on summing up all corresponding metered reading values (indicatively matching on time and headcode). 2. Dependencies 1. The OTM Service fulfils its requirements in terms of data validation, interpolation, aggregation and distribution. E.g. Meter consumption and regenerative values have sensed check by the OTM Service, non readings have been interpolated etc. 2. The Meter ID is correctly associated to the Vehicle ID 3. The Vehicle ID is associated with an Electric Traction Vehicle and therefore will be recognised by the Billing System as capable of being EC4T meter billed. 3. Constraints 1. Incomplete requirements. a) The overall business requirements in support of OTM are being elaborated by Network Rail (from an Engineering and I.T perspective). It is expected that a subset of these relevant to TOCs / FOCs / ATOC etc will need to be discussed and agreed across the Rail Industry b) A number of relevant standards are being defined e.g. BS EN 50463. c) The UIC 930 Leaflet for EU Cross Border Energy Settlement standards a relatively new and subject to interpretation. d) There are a number of significant issues / challenges to understand e.g. Line Loss, Standing Locations.

All the above may influence changes to this and other documents. 4. Assumptions 1. Meter Time is assumed to be synchronised with Railway Time and is in UTC 2. Meter readings are assumed to be for active energy, not reactive energy. Hence, the unit of measurement is always kWh and not kVArh. However, the specification caters for kVArh should this arise in the future. Data Requirements The proposed data requirements are detailed below, and are intended to: 1. Primarily support the billing of Metered Data by Network Rails billing system. 2. Provide for auditability in data provision. These have not been developed with analysis / performance type capabilities in mind. 1. Logical Model

Entities in yellow broadly represent Train sourced data (forwarded via the OTM Service). Entities in green represent OTM Service derived data, based in part of data provided by the meter. Refer next page.

Interface - ID - Received Date-Time - Processed Date- Time - T ype - Name - Request ID - F ile UR L - Success

Provides a n Audit Tra i n fo r d ata pro vi si o ni ng

InvolvedParties

1..*

Provides an Audit T ra i n fo r d ata p ro vi si oni n g

- UIC Ty pe - Provider - Date Out - Date In

1 Product Code --> Regen or Consu mpti on Supply Type --> AC or DC Qual ity Facto r --> Mea sured, Missing, Un certain, Interpolated
Meter Reading - M eter Number - Sample Freq uency - Period From - Period To - Sample Count - GPS Accur acy Sample Date- Time Sample Date- Time - Time Z one Speed Speed - UOM Status - Supply T ype - Product Code - QualityFactor - Value

1..*
Metered Data Time Series Metered Readings

1..*

1
Enhance R eading

1
Vehicle - UK Vehicle Number - EU Vehicle Number - Vehicle Ty pe Location - Latitude - Longitude - Quality Factor

0 ..1

- Time Band - Stabled - Depot

Th e GP S reading (po ssibly interpolated by OTM Servi ce )

OTM Servi ce enhance location data - b ased on GPS re ading and other business rul es

0 ..* In tf - OTM to NR - Logical (Class) System Architect Tue Feb 16, 2010 14:27
OTM Enhance Location

OTM Servi ce enhanced location data - based on GPS reading and other business rul es

ESTA

Stanox

Zone

Figure 2 Logical Data Model

2.

Train

The following two sections list the data to be sourced from the On-Train Metering equipment. The first section correlates to train-meter sourced TMS data, the following section details additional data requirements aligned to the UIC leaflet and/or required by Network Rail to facilitate billing. This data is expected to be forwarded by the OTM Service to Network Rail. Attribute Train Operator Description Train Operator o The Train Operator associated with the Meter ID (and associated Vehicle) o Implied by source of data transmission from Train to UIC-DC Service Format: Text Example: e.g. HF (Virgin Trains) Provisioning: Mandatory, predefined codes mastered by Network Rail A unique meter number which: o can be associated to a specific Traction Vehicle which in turn: o can be associated with a specific chargeable Train Journey (in the TABS Billing system) 3. Speed Unit of measure (UOM): n/a Accuracy: Mastered through the Rolling Stock Library Format: Text Example: No examples available at time of writing Provisioning: Mandatory Validation: (Indicative) The OTM Service would be expected to check that the meter number is valid against the details held in the Rolling Stock Library for this Operator and/or Vehicle Speed of train at time of the associated energy delta. Unit of measure (UOM) = km/h Accuracy: 1 decimal place Format: Numeric >=0 Provisioning: Optional (may be useful for analysis capability and/or to provide enhance data validation capability (should this be required) Validation: (Indicative) The OTM Service might be expected to check that the speed is valid and/or consistent with other factors such as vehicle type and/or track. The Frequency of the data samples for this meter. Unit of measure (UOM): seconds Accuracy: n/a Format: numeric integer [60, 300] Provisioning: Mandatory at 1 minute sample period The sample time to which the energy data applies to. Accuracy: to minutes accuracy Unit of measure (UOM): UTC coordinates (Zulu Time) Format: a UTC format e.g. xsd:dateTime (assuming XML) Provisioning: Network Rail requires meter reading at 1 minute

1.

2.

Meter Number

4.

Sample Frequency

5.

Sample Time

Attribute 6. Location: Longitude and Latitude

7.

Location: Quality Factor

Description intervals. The geographical position of the traction unit at the time of the meter reading. Accuracy: desirable: 1 2 meters (TBD) 1 Datum / Grid: Location data shall be based on the World Geodetic System, revision WGS 84 (per draft EN 50463) Provisioning: To be provided with each sample. 2 Validation: o Latitude >= -180.00000 and <= +180.00000 o Longitude >= -90.00000 and <= +90.00000 The OTM Service will be able to provide Infrastructure specific validation per UIC Leaflet 930 Interpolation: The OTM service is expected to interpolate missing GPS readings e.g. tunnels and set the associated Quality Factor accordingly Format Options: WGS 84 Geographic: Latitude (N/S) / Longitude (E/W) (3 sub formats) Decimal Degrees (DD) e.g. N 54.353180o / W 2.938508 o Decimal Degrees and minutes e.g. N 54o 21,191 / W 2 o 56.310 Decimal Degrees, minutes and seconds e.g. N 54 o 21 11.4 / W 2 o 56 18.6 Format agreed is Decimal Degrees +/-DD / +/- DD e.g. +54.353180 / -2.938508 o Positive values are North, negative are south so N55.82333 becomes +55.82333, o Positive values are East, negative are West so W2.09200 becomes -2.09200. Quality factor associated with GPS Longitude and Latitude values (UIC leaflet 930 defines: measured, estimated, nonexistent) Unit of measure (UOM): n/a Accuracy: n/a Format: text (codes per below) Provisioning: Mandatory UIC Codes 46 - Non existent 56 - Estimated 61 - Uncertain 127 - Measured Energy Delta and AC/DC distinction TBC - AC/DC level of granularity for meter readings IS for data quality and validation purposes. There are sections of track where both AC and DC current is available, and for dual-powered vehicles, Network Rail will need to be able to identify which current they are using to charge correctly in the future for Line Loss (which may have significantly different rates for AC and DC).

1
2

The EN 50463 specifications indicates 250 meters. Note - The UIC leaflet 930 details handling of non-readings..

8.

Attribute Description Energy - Quality factor associated with all subsequent Energy readings per Quality Factor business process model / UIC Leaflet 930. Measured, Nonexistent and Uncertain Unit of measure (UOM): n/a Accuracy: n/a Format: text (codes of M,U,N) Provisioning: Mandatory UIC Codes 46 - Non existent 56 Estimated 61 - Uncertain 127 - Measured Consumption - Active energy value (kWh) representing the AC consumption between AC this sample time and the previous sample time (at 1 minute sample provisioning) Consumption Active energy value (kWh) representing the DC consumption between DC this sample time and the previous sample time (at 1 minute sample provisioning) Regenerative - Active energy value (kWh) representing the AC regenerative / export AC between this sample time and the previous sample time (at 1 minute sample provisioning) Regenerative - Active energy value (kWh) representing the DC regenerative / export DC between this sample time and the previous sample time (at 1 minute sample provisioning) Headcode The Headcode is required to match meter data to TABS journeys. It is understood the Train Driver is required to specify the Headcode prior to Journey Commencement. As such thee attribute is treated as Train Meter data. Multiple Unit ID and Vehicle ID cannot be used as there are data quality issues associated with those within TABS (i.e. upstream systems of TABS e.g. TODS, Paladin, TOPS/TRUS/Gemini/Genius and/or processes not being followed correctly by TOCS and FOCS) Unit of measure (UOM): n/a Accuracy: n/a Format: Text e.g. HD01 Provisioning: Mandatory
Table 1 Train Data Attributes

9. 10. 11. 12. 13.

Notes: 1. Meter index register values are not specifically required by Network Rail. 3. OTM Service

The following lists the data expected to be provided by the OTM Service to Network Rail. This includes the Train data (section 0) above. Attribute Vehicle ID (aka Consumption Description The Traction Unit Vehicle ID currently associated with the Meter Number above. Unit of measure (UOM): n/a

14.

Attribute Point ID)

15. 16.

17.

18.

19.

Description Accuracy: For matching purposes, this ID must be consistent with the Vehicle ID held in the Planned Working Train Timetables and cannot be changed within 24 hours of the Train Journey start (requirement from Logica) Format: free form text e.g. 69109 Provisioning: Mandatory Multiple Unit A number of semi-permanently coupled passenger vehicles with driving ID compartments at either end. The MU has its own identifier e.g. 390004 Vehicle Type Allows for validation capability by OTM Service. Note this is held in the Rolling Stock Library, as can be associated with Meter ID and Vehicle ID Unit of measure (UOM): n/a Accuracy: Per the Rolling Stock Library which should be consistent with values held in the Network Rail Billing system. Example: NZ5/H Format: free form text e.g. 450 Provisioning: Mandatory Period From The periods start date and time associated with the readings provided. Unit of measure (UOM): UTC Accuracy: to Minutes accuracy and MUST be consistent with the least recent time stamp for the associated readings Format: probably xsd:dateTime (XML) Provisioning: Mandatory Period To The periods end date and time associated with the readings provided. Unit of measure (UOM): UTC Accuracy: to Minutes accuracy and MUST be consistent with the most recent time stamp for the associated readings Format: probably xsd:dateTime (XML) (long term solution) Provisioning: Mandatory Number of The number of readings in this message Samples Unit of measure (UOM): n/a Accuracy: matches the number of meter readings provided Format: Numeric Integer, greater than 0 Provisioning: Mandatory e.g. for a 2 hour train journey, with 1 minute samples this would be a value of 120 Request ID The Unique Request ID issued by Network rail to the OTM service for specific metered data. Unit of measure (UOM): n/a Accuracy: Unique, and matches 1 and only 1 request id initially provided by Network Rail. Can never be provided in another message. Format: UUID / GUID (TBC) Provisioning: Mandatory of data is in response to a previous request from Network Rail Sender Details Allows Network Rail to assess provisioning performance. May assist with end-to-end testing and Support resolution. Sender Details The Source of the data in relation to each key service point, can be any - Source of: o The TOC providing the data o The I.T Service providing the UIC - Data Collection role

20.

21.

Attribute 22. 23. 24. 25.

26.

27.

Sender Details Receipt Date Time Sender Details Provisioning Date Time Sender Details Unique Document ID Register The register reading associated with the Energy Delta. To be used for reading audit purposes and possibly as a validation capability. Unit of measure (UOM): n/a Accuracy: n/a Format: TBA Provisioning: Mandatory Standing A location code associated with Standing Location. These will be Location associated to aligned geospatial areas (polygons) defining known Standing Locations, such as depots, platforms, sidings etc. Unit of measure (UOM): codes to be agreed with ALL TOCs/FOCS Accuracy: GPS polygons defined Format: TBD The list of codes for this will need to be defined outside of this document and agreed between Network Rail and Train Operation. It is NOT intended to use free-form text. Provisioning: Optional Location - The ESTA code associated with the meter samples GPS location. ESTA Unit of measure (UOM): n/a Accuracy: Dependent on a number of factors including GPS accuracy, accuracy and currency of ESTA definitions (as polygons defined in terms of GPS), possibly train speed? Format: Codified Text e.g. A Provisioning: Mandatory
Table 2 OTM Service - Data Attributes

Description o The I.T Service providing the UIC - Meter Data Distribution role o The I.T Service providing the UIC - Meter Data Aggregator role The date time that the data was received from the upstream process / system. Of particular relevance where different parties and associated I.T systems may be involved. The date time that the data was provisioned to the next downstream service. Of particular relevance where different parties and associated I.T systems may be involved. A unique number / identifier associated with the provisioning of the data by the I.T Service. To support fault resolution and integration testing

Data Volumes 1. Size and format

The CSV layout would see 29,952 rows per s/s if all 52 train sets were provisioning per day (52 trains X 2 meters X 288 5 minute samples per day). A 30,000 line CSV file of the proposed layout in this document, is 2,813 KB (3 MB) 2. Production

The data volumes below are derived on a broad basis from TABS production since April 2009, for any given period (month)

Period

Average Train Count per Day (28 days per period)

Average Train Hours per day (assuming 3 hours per journey)

Assumed Average Electric Vehicles per Train Journey

Meter samples volume per day (1 meter read per minute)

Meter samples volume per day (5 meter read per minute)

any

3,200

9,600

1,152,000

230,400

Table 3 Data Volumes Production

Messaging Requirements This section is written in the basis of the proposed long term OTM end-to-end solution. It may be refined to align to the capabilities of an off-the-shelf solution e.g ERESS. 1. Overview

Two interfaces will exist between Network Rail, and the OTM Service 1. Meter data push Data is provisioned by the OTM Service, to Network Rail, per provisioning requirements below (timeliness and frequency). 2. Request In a response to a request from Billing, the Journey matcher may issue a corresponding request to the OTM Service for meter data is does not hold. The response is via the meter data push above. Network Rail will not support multiple provisioning approaches. The OTM Service is expected to handle the different data formats (from onboard meter equipment and/or data collection services) and any related provisioning irregularities. Network Rail will not change the data received from the OTM Service. The data is treated as correctly provisioned from both Train and OTM Service 2. Internationalisation

All data will be provisioned: o in English (relevant to Cross Border provisioning), o using Unicode UTF-8 (based on the proposed XML format) 3. Transfer Mechanism

Web Services using SSL (https) will be adopted to support a message centric transfer between Network Rail and external 3rd Parties. Note - The UIC Leaflet 930 provides no guideline regards the transfer of data in this scenario. UTILTS is referenced as an inter OTM Service data format. 4. Timeliness of data

1) In order to provide a bill based on a metered reading (not estimated as is current), the meter data for a Train Journey should be received within 12 hours of Train Journey completion.

a) Data received after this period may result in an initial bill based on estimated, almost certainly if provisioned after 24 hours. It also places additional and unnecessary re-processing loads on the Network Rail billing system. 2) The data should be forwarded by the OTM Service only when it is complete (validated, interpolated, aggregated etc), as defined by this document and by the wider Business Process and related UIC Leaflet 930 requirements. Note - The UIC Leaflet 930 provides no guideline regards provisioning / timeliness of data 5. Frequency of Provision

Metered data should ideally be provided on a continuous basis to Network Rail, in order to avoid the processing overheads of infrequent (daily) bulk transfer. The proposed provisioning format (XML) assumes this to be the case, as XML is not suited to infrequent (e.g. daily) bulk data transfers. Refer next section (Messages) for specifics. Note - The UIC Leaflet 930 indicates at least once per day. 6. Messages

Each message: 1) Will correspond to 1 meter and the associated 1 vehicle. 2) Will be for a consecutive time period not exceeding 30 minutes (for 1 minute accuracy) This is to avoid large XML payloads. 3) Should be sent in time order i.e. least recent to most recent. 4) MUST NOT be inadvertently sent or resent Network Rail has no basis to know that the data was sent in error and therefore will Bill based on any data initially received. 7. Data Interpolation

Data provided to Network Rail, MUST be provided with all sample periods accounted for. By way of example: Samples for each minute (assuming 1 minute accuracy): 2009-12-01 23:01:00, 2009-12-01 23:02:00, 2009-12-01 23:03:00, 2009-12-01 23:04:00 Unacceptable (assuming 1 minute accuracy): 2009-12-01 23:01:00, 2009-12-01 23:04:00 i.e. two readings missing (2009-12-01 23:02:00 and 2009-12-01 23:03:00). The Business Process and/or the UIC 930 Leaflet provide guidance on handling missing data (interpolation / aggregation and/or values + qualify factors)

Data Retention Network Rail will hold the meter data received from the OTM Service, for no longer then 2 years online. Note - TOCs and FOCs can hold Energy data per their own requirements Acknowledgements and Error Handling 1. Receipt of data

1) Network Rails web service will issue a synchronous conformation response, with a unique Acknowledgement ID (typically in the SOAP HTTP response) a) Network Rail must only issue this response when it has successfully extracted ALL the data and persisted to permanent storage. b) Note this does not mean that the downstream processing of the data will occur successfully. It is possible that subsequent issues arise relating to provisioning issues from either the Train Meter or the OTM Service. 2) The sender (OTM Service) must be able to reference the Acknowledgement ID in order to assert delivery of the data to Network Rail. 2. Handling Non Receipt of data

1) There are two broad scenarios the sender will need to accommodate: a) Network Rails web service issues an HTTP response other than OK. This means the message was received but the data could not be accepted understood b) The Network provides an error indication back to the sender. This could be due to a number of reasons: i) Network Rails network or ii) Senders Network iii) ISP It is the responsibility of the Sender to initiate support processes.