IDD Part 1 v27.0



|[pic] |

| |

|NETA Interface Definition and Design: Part 1 |

|Interfaces with BSC Parties and their Agents |

|Synopsis |This document contains the definition and design of all interfaces between the BSC |

| |Service Systems and other Systems. It includes the specification of file formats and|

| |structure of electronic files. Part one only contains details for interfaces which |

| |involve BSC Parties and their Agents. |

|Version |27.0 |

|Issue date |November 2011 |

|Effective date |3 November 2011 |

|Prepared by |ELEXON Design Authority |

Intellectual Property Rights, Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in ELEXON or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make.

All other rights of the copyright owner not expressly dealt with above are reserved.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, ELEXON Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.

Table Of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

1.3 NETA Interface Overview 6

1.4 Summary 8

1.5 Amendment History 9

1.7 References 9

1.8 Abbreviations 9

2 Common Interface Conventions 11

2.1 Interface Mechanisms 11

2.2 Data File Format 12

3 External Interface Summary 37

3.1 Interfaces by BSC Agent 37

3.2 Interfaces by Corresponding Party 44

4 BMRA External Inputs and Outputs 50

4.1 BMRA-I004: (output) Publish Balancing Mechanism Data 50

4.2 BMRA-I005: (output) Publish System Related Data 53

4.3 BMRA-I006: (output) Publish Derived Data 58

4.4 BMRA-I019: (output) Publish Credit Default Notices 62

4.5 BMRA-I010: (output) BMRA Data Exception Reports 62

4.6 BMRA-I015: (input) Receive Market Index Data 63

4.7 BMRA TIBCO Message Publishing - Data Formats 64

4.8 BMRA Data Download Service - Data Formats 163

5 CDCA External Inputs and Outputs 244

5.1 CDCA Flow Overview 244

5.2 CDCA-I001: (input) Aggregation rules 246

5.3 CDCA-I003: (input) Meter technical data 247

5.4 CDCA-I004: (output) Notify New Meter Protocol 249

5.5 CDCA-I005: (input) Load New Meter Protocol 249

5.6 CDCA-I006: (output) Meter Data for Proving Test 250

5.7 CDCA-I007: (output) Proving Test Report/Exceptions 250

5.8 CDCA-I008: (input) Obtain metered data from metering systems 250

5.9 CDCA-I009: (input) Meter Period Data Collected via Site Visit 251

5.10 CDCA-I010: (output) Exception report for missing and invalid meter period data 252

5.11 CDCA-I011: (input) Dial Readings from meter, for MAR 252

5.12 CDCA-I012: (output) Report Raw meter Data 253

5.13 CDCA-I013: (input) Response to Estimated data 254

5.14 CDCA-I014: (output) Estimated Data Report 254

5.15 CDCA-I015: (input) Reporting metering system faults 255

5.16 CDCA-I017: (output) Meter Reading Schedule for MAR 256

5.17 CDCA-I018: (output) MAR Reconciliation Report 256

5.18 CDCA-I019: (output) MAR Remedial Action Report 257

5.19 CDCA-I021: (input) Notification of Metering Equipment Work 257

5.20 CDCA-I022: (input) Distribution Line Loss Factors 257

5.21 CDCA-I023: (output) Missing Line Loss Factors 258

5.22 CDCA-I025: (output) Aggregation Rules Exceptions 258

5.23 CDCA-I026: (output) Aggregated Meter Volume Exceptions 259

5.24 CDCA-I029: (output) Aggregated GSP Group Take Volumes 259

5.25 CDCA-I030: (output) Meter Period Data for Distribution Area 260

5.26 CDCA-I033: File Receipt Acknowledgement 260

5.27 CDCA-I037: (output) Estimated Data Notification 261

5.28 CDCA-I038: (output) Reporting metering system faults 262

5.29 CDCA-I041: (output) Interconnector Aggregation Report 262

5.30 CDCA-I042: (output) BM Unit Aggregation Report 263

5.31 CDCA-I044: (input) Meter System Proving Validation 263

5.32 CDCA-I045: (input) Meter Data from routine work and Metering Faults 264

5.33 CDCA-I046: (output) Site Visit Inspection Report 264

5.34 CDCA-I047: (output) Correspondence Receipt Acknowledgement 265

5.35 CDCA-I048: (output) Report of Aggregation Rules 265

5.36 CDCA-I051: (output) Report Meter Technical Details 265

5.37 CDCA-I054:(output) Meter Status Report 267

5.38 CDCA-I055: (input) Transfer from SMRS information 269

5.39 CDCA-I057: (input) Transfer to SMRS information 269

5.40 CDCA-I059: (output) Initial Meter Reading Report 270

5.41 CDCA-I060: (input) SVA Party Agent Details 271

6 CRA External Inputs and Outputs 272

6.1 CRA Flow Overview 272

6.2 CRA-I001: (input) BSC Party Registration Data 275

6.3 CRA-I002: (input) Interconnector Administrator Registration Data 276

6.4 CRA-I003: (input) BSC Party Agent Registration Data 277

6.5 CRA-I005: (input) BM Unit Registration Data 278

6.6 CRA-I006: (input) Trading Unit Registration 279

6.7 CRA-I007: (input/output) Boundary Point and System Connection Point Data 280

6.8 CRA-I008: (input) Interconnector Registration Details 280

6.9 CRA-I012: (output) CRA Encryption Key 281

6.10 CRA-I014: (output) Registration Report 281

6.11 CRA-I021: (output) Registered Service List 283

6.12 CRA-I024: (output) Certification and Accreditation Status Report 284

6.13 CRA-I025: Receive Acknowledgement 285

6.14 CRA-I026: Issue Acknowledgement 285

6.15 CRA-I027: (input) GSP Group and GSP Registration 285

6.16 CRA-I031: (input) Metering System Data 286

6.17 CRA-I034: (input) Flexible Reporting Request 287

6.18 CRA-I038: Transfer from SMRS information 288

6.19 CRA-I040: Transfer to SMRS information 288

7 ECVAA External Inputs and Outputs 290

7.1 ECVAA Flow Overview 290

7.2 ECVAA-I002: (input) ECVNAA Data 292

7.3 ECVAA-I003: (input) MVRNAA Data 293

7.4 ECVAA-I004: (input) ECVN 294

7.5 ECVAA-I005: (input) MVRN 295

7.6 ECVAA-I007: (output) ECVNAA Feedback 296

7.7 ECVAA-I008: (output) MVRNAA Feedback 297

7.8 ECVAA-I009: (output) ECVN Feedback (Rejection) 299

7.9 ECVAA-I010: (output) MVRN Feedback (Rejection) 300

7.10 ECVAA-I013: (output) Authorisation Report 301

7.11 ECVAA-I014: (output) Notification Report 301

7.12 ECVAA-I018: Receive Acknowledgement 303

7.13 ECVAA-I019: Issue Acknowledgement 303

7.14 ECVAA-I022: (output) Forward Contract Report 303

7.15 ECVAA-I024: (input) Credit Cover Minimum Eligible Amount Request 306

7.16 ECVAA-I025: (output) Credit Cover Minimum Eligible Amount Report 307

7.17 ECVAA-I028: (output) ECVN Acceptance Feedback 307

7.18 ECVAA-I029: (output) MVRN Acceptance Feedback 311

7.19 Forward Contract Report Start Period Override 315

7.20 ECVAA-I021: (output) Credit Limit Warning 316

7.21 ECVAA-I037: (input) Receive Volume Notification Nullification Request 316

7.22 ECVAA-I038: (output) Issue Volume Notification Nullification Confirmation Report 317

7.23 ECVAA-I039: (output) Issue Nullification Completion Report 318

7.24 Additional Clarification on ECVAA Interfaces 318

7.25 ECVAA-I042: Banning/Unbannimg Individual User Access to the ECVAA Web Service 324

7.26 ECVAA-I043: ECVAA Web Service – BSC Party View ECVNs 324

7.27 ECVAA-I044: ECVAA Web Service – BSC Party View MVRNs 326

7.28 ECVAA-I045: ECVAA Web Service – ECVNA View ECVNs. 328

7.29 ECVAA-I046: ECVAA Web Service – MVRNA View MVRNs. 330

8 SAA External Inputs and Outputs 333

8.1 SAA Flow Overview 333

8.2 SAA-I006: (input) BM Unit Metered Volumes for Interconnector Users 334

8.3 SAA-I012: (input) Dispute Notification 334

8.4 SAA-I014: (output) Settlement Reports 335

8.5 SAA-I016: (output) Settlement Calendar 345

8.6 SAA-I017: (output) SAA Data Exception Report 345

8.7 SAA-I018: (output) Dispute Reports 346

8.8 SAA-I021: Receive Acknowledgement of SAA Messages 346

8.9 SAA-I022: Issue SAA Acknowledgement of Messages 346

8.10 SAA-I030: (input) Receive Market Index Data 347

1 Introduction

1.1 Purpose

1.1.1 Summary

This document is Part 1 of the Interface Definition and Design.

The scope of the document is, for each BSC Service System provided, the definition and design of all interfaces between the BSC Service System and other Systems.

The scope of Part 1 is limited to the definition and design of interfaces between the BSC Service System and the BSC Parties and their Agents.

Note that, subsequent to the introduction of P62, any of the following terms can represent a Licensed Distribution System Operator (LDSO) or any Party which distributes electricity.

• Distribution Business

• Distribution System Operator

• Public Distribution System Operator (and abbreviation PDSO)

• Distribution Company

• Public Electricity Suppliers (PES), as operators of a distribution network

• Distributor, as operator of a distribution network.

1.2 Scope

1.2.1 The Scope of this Document

This document describes the interfaces relevant to five of the seven BSC Service Systems. The interfaces relating to the Funds Administration Agent service are described separately in the FAA Interface Definition and Design. The services within the scope of this document are: BSC

|BMRA |Balancing Mechanism Reporting Agent |

|CDCA |Central Data Collection Agent |

|CRA |Central Registration Agent |

|ECVAA |Energy Contract Volume Aggregation Agent |

|SAA |Settlement Administration Agent |

The remaining five are termed here the Central Services.

1.2.2 Types of Interface

Interfaces between the Central Services and other systems which are not part of the Central Services are termed External and are the main subject of the Interface Definition and Design. These interfaces are of two kinds:

0. Party interfaces – BSC Parties and Agents, including ECVNA, MVRNA, IA, IEA, SMRA and MOA. These interfaces are covered in Part 1 (this document).

1. System interfaces – to other BSC services: FAA, SVAA, the System Operator (SO) and BSCCo Ltd; These interfaces are covered in Part 2 (a separate document).

External interfaces which do not connect to a Central Service, e.g. FAA to Bank, are not included in the Interface Definition and Design.

The interfaces with BSC Parties and Agents will need a wider forum of agreement than the other interfaces, and will be tested in Market Interface Testing (MIT). The Interface Definition and Design is therefore divided into two separate parts for these two interface types. The two parts will be issued independently and will therefore have different version numbers.

1.3 NETA Interface Overview

1.3.1 Introduction

The approach to the interface definition process adopted in this document is a layered top down structure. The highest layer is the business need for the interface to exist. This business transaction is supported by successive lower layers working down via the logical and physical design to the communications protocol and the physical format and media for the data transfer. This is summarised in the table below.

|Layer |Defined in Section |Source/Based on |

|Business Process Definition |1.3.2 |Business Process Model |

|Logical Flow Definition |1.3.3 & 2.2 |Industry practice |

|Physical Message Definition |1.3.4 |Industry practice (with MV90 for meter |

| | |data) |

|Data Transfer Protocol |1.3.5 |FTP over TCP/IP |

1.3.2 The Business Process Level

A Business Process can be represented by a ‘transaction’ – a message or sequence of messages that fulfil a business function, for example ‘submit report request’ leads to ‘report sent’ or ‘error message – not available’. Each of these messages can be defined as a logical ‘flow’ to meet the requirement. The flow can classified by its characteristics at the business level:

2. Originating Party

3. Destination Party

4. Initiating event (e.g. user request, another flow, timer expires)

5. Frequency in unit time

6. Data content at the business level.

7. Mechanism: Electronic Data File Transfer or Manual

8. Volume – frequency * mean message size

9. Validation rules.

Flows are given unique identifiers. The same flow can be sent by more than one originator and to more than one party and as a result of different initiating events. These origin/destination/initiation cases are called here different ‘instances’ of the same flow. The same flow can have internal and external instances.

1.3.3 Logical Message Definition

The next step is to define the flow contents at the logical level. This defines what each flow will contain in terms of fields, their attributes and how the fields are grouped within the flow. At the same time, the rules for which fields and groups are optional or mandatory and whether and how often groups can be repeated need to be specified.

To do this, a naming convention and layout standards have been set for those flows so that the information can be presented in a consistent and unambiguous form. The format is based on industry practice, and is similar to that used by the industry to support the Supplier Volume Allocation settlement process.

1.3.4 Physical Message Definition

The Logical Message definition encompasses all the data visible at the user level and is closely aligned to the database design as the flows populate the database and/or are derived from their contents. Physical file formats define, for flows that are transferred electronically, the data representation and control information. Similarly to the logical definition, a naming convention and layout standards have been defined so that the information can be exchanged and validated in a consistent and unambiguous form. The definitions are again based on industry practice.

Details of the physical file format are specified in section 2.2

1.3.5 Data Transfer Protocols

This section only applies to flows which employ the electronic data file transfer mechanism.

Details of the proposed protocols for data transfer are in [COMMS]. For each flow, data transfer will be via FTP over TCP/IP unless specified otherwise.

1.4 Summary

Part 1 of the Interface Definition and Design covers interfaces with BSC Parties and Agents, and is organised as follows:

10. Section 2 describes common interface conventions, in particular defining the approach to interfacing via file transfer.

11. Section 3 gives a summary of the interfaces, organised by BSC agent and by corresponding party.

12. Sections 4 to 7.24.3 define the interfaces to each of the BSC Agents.

Part 2 of this document contains interfaces where the only parties involved are within the Central Volume Allocation system, i.e. interfaces between the following services / systems:

13. BMRA

14. CDCA

15. CRA

16. ECVAA

17. FAA

18. SAA

19. SO

20. SVAA

21. BSCCo Ltd

Note that parts 1 and 2 of the Interface Definition and Design are issued separately and will therefore have different issue numbers.

1.5 Amendment History

|Date |Issue |Details of Change |

|04/11/2010 |26.0 |Document rebadged and amended for November 2010 Release (P243, P244, CP1333) |

|03/11/2011 |27.0 |P253 |

1.7 References

1.7.1 BSC Documents

|[SD] |Draft Service Descriptions for Central Data Collection, Energy Contract Volume Aggregation, Central |

| |Registration, Balancing Mechanism Reporting, Settlement Administration, |

|[BPM] |RETA Business Process Models: |

| |Top Level Processes |

| |Central Registration |

| |Aggregate and Check Contract Volume |

| |Balancing Mechanism Reporting |

| |Central Data Collection and Aggregation |

| |Calculate Settlement Debits and Credits |

| |Indicative Reporting Requirement |

| |Entity Relationship Model |

|[COMMS] |Communications Requirements Document |

1.8 Abbreviations

|BM |Balancing Mechanism |

|BMRA |Balancing Mechanism Reporting Agent |

|BMU |Balancing Mechanism Unit |

|BSC |Balancing and Settlement Code |

|CALF |Credit Assessment Load Factor |

|CDA |Central Design Authority |

|CDCA |Central Data Collection Agent |

|CRA |Central Registration Agent |

|ECV |Energy Contract Volume |

|ECVAA |Energy Contract Volume Aggregation Agent |

|ECVN |Energy Contract Volume Notification |

|ECVNA |Energy Contract Volume Notification Agent |

|ECVNAA |Energy Contract Volume Notification Agent Authorisation |

|FAA |Funds Administration Agent |

|FPN |Final Physical Notification |

|FTP |File Transfer Protocol |

|GMT |Greenwich Mean Time |

|GSP |Grid Supply Point |

|IA |Interconnector Administrator |

|IEA |Interconnector Error Administrator |

|ISO |International Standards Organisation |

|LAN |Local Area Network |

|MAR |Meter Advance Reconciliation |

|MDP |Maximum Delivery Period |

|MDV |Maximum Delivery Volume |

|MEL |Maximum Export Limit |

|MIDP |Market Index Data Provider |

|MIL |Maximum Import Limit |

|MOA |Meter Operator Agent |

|MPAN |Meter Point Administration Number |

|MVR |Meter Volume Reallocation |

|MVRN |Meter Volume Reallocation Notification |

|MVRNA |Meter Volume Reallocation Notification Agent |

|MVRNAA |Meter Volume Reallocation Notification Agent Authorisation |

|NETA |New Electricity Trading Arrangements |

|NGET |National Grid Electricity Transmission plc |

|PTFF |Pool Transfer File Format |

|QPN |Quiescent (final) Physical Notification |

|RETA |Revised Electricity Trading Arrangements |

|SAA |Settlement Administration Agent |

|SMRA |Supplier Meter Registration Agent |

|SO |System Operator |

|SVAA |Supplier Volumes Allocation Agent |

|TAA |Technical Assurance Agent |

|TCP/IP |Transport Control Protocol/Internet Protocol |

|WAN |Wide Area Network |

2 Common Interface Conventions

2.1 Interface Mechanisms

This section outlines the different interface mechanisms used.

2.1.1 Manual

Some interfaces employ a manual mechanism. This means that the information is delivered by mail, by a telephone call, by email, or by fax from one person to another. (Perhaps in an electronic file attached to an email or written to a floppy disc)

All incoming manual flows are required to have been initiated by an Authorised Signatory. The flow will contain the Authorised Signatory Name and Password plus:

0. for flows submitted by post or fax, the signatory’s signature is required;

1. for those flows which are submitted by email, the sending email address must be that registered for the signatory.

Where applicable, the sender will have read the information from a computer screen or printed it out before sending it. Similarly, where applicable, the recipient enters the information into a computer system, probably via a data entry screen-based interface.

More details of the manual mechanism are given where appropriate for a particular flow.

2.1.2 Electronic Data File Transfer

The majority of non-manual interfaces use electronic file transfer. A data file is created on the source system, and is then copied to a predetermined directory on the destination system. The mechanism for the network copy is described in [COMMS].

A common format is used for data files transferred between the Central Services and the BSC Parties and their Agents. This is specified in Section 2.2.

2.1.3 Meter System Interface

The MV-90 interface is used to interact with meter systems. (This is defined in the CDCA Design Specification Appendix A.)

2.1.4 BMRA Publishing Interface

A TIBCO messaging interface running over IP is used for providing screen-based data for BMRA users.

2.2 Data File Format

A common format is used for data files transferred electronically between the Central Services and the BSC Parties and their Agents.

These files use the ASCII character set. They consist of:

22. Standard header

23. Collection of data records using standard format

24. Standard footer

The file format is similar to the Data Transfer Catalogue file format defined for use in Supplier Volume Allocation. The difference is that the format defined for Central Volume Allocation has the following enhanced features:

0. sequence number added to the header;

1. Party Ids in the header longer than the 4 character Pool Participant Ids;

2. Role Codes in the header longer than the 1 character Pool Participant Role Codes;

3. Message Role (Data/Response) added to the header;

4. free-format message type allowed

The components of the file are specified below:

2.2.1 File Header

The file header will be a record containing the following fields:

|AAA-File Header |

|Field |Field Name |Type |Comments |

|1 |Record Type |Text(3) |= AAA |

|2 |File Type |Text(8) |5 character type plus 3 character version |

|3 |Message Role |char |‘D’ Data or ‘R’ Response |

|4 |Creation Time |datetime |Date/Time file was created. Specified in GMT. |

| | | |(For Response messages this field contains the Creation Time |

| | | |of the message being replied to) |

|5 |From Role Code |Text(2) | |

|6 |From Participant ID |Text(8) | |

|7 |To Role Code |Text(2) | |

|8 |To Participant ID |Text(8) | |

|9 |Sequence Number |integer(9), |A separate Sequence Number is used for each From Role Code / |

| | |rolling over from |From Participant ID / To Role Code / To Participant ID |

| | |999999999 to 0 |combination. |

| | | |NB numbers used must be contiguous so recipients can detect |

| | | |missing files. See section 2.2.8 for more details of the use |

| | | |of Sequence Number. |

| | | |(For Response messages this field contains the Sequence Number|

| | | |of the message being replied to) |

|10 |Test data flag |Text(4) |Indicates whether this file contains test data |

| | | |=OPER or omitted for operational use, other values for test |

| | | |phases |

Either field 6 or field 8 will be the Participant ID of the Central Systems in every case.

The possible values for role code are

|‘BM’ |(BMRA) |

|‘BC’ |(BSCCo Ltd) |

|‘BP’ |(BSC Party) |

|‘CD’ |(CDCA) |

|‘CR’ |(CRA) |

|‘DB’ |(Distribution Business) |

|‘EC’ |(ECVAA) |

|‘EN’ |(ECVNA) |

|‘ER’ |(Energy Regulator) |

|‘FA’ |(FAA) |

|‘IA’ |(Interconnector Administrator) |

|‘MI’ |(Market Index Data Provider) |

|‘MO’ |(Meter Operator Agent) |

|‘MV’ |(MVRNA) |

|‘PA’ |(BSC Party Agent) |

|‘PB’ |(Public - also used for files made available for shared access) |

|‘SA’ |(SAA) |

|‘SG’ |(BSC Service Agent) |

|‘SO’ |(System Operator) |

|‘SV’ |(SVAA) |

This is a subset of the domain ‘Organisation Type’ defined in section 2.2.11.9, containing only those organisation types which send or receive electronic data files. Considering flows to BSC Parties: when a party receives a file because it is a Distribution Business, the To Role Code will be ‘DB’; when it receives a file because it is an Interconnector Administrator, the To Role Code will be ‘IA’; in all other cases, the To Role Code will be ‘BP’.

Message Role is used for handling receipt acknowledgement, and is further described in Section 2.2.7.

2.2.2 File Footer

The file footer will be a record containing the following fields:

|ZZZ-File Footer |

|Field |Field Name |Type |Comments |

|1 |Record Type |text(3) |= ZZZ |

|2 |Record count |integer(10) |Includes header and footer |

|3 |Checksum |integer(10) |Although type is shown as integer(10) the value is actually |

| | | |a 32-bit unsigned value and hence will fit in an “unsigned |

| | | |long” C variable. |

The value of Checksum is defined according to the following sequence:

25. initialise to zero

26. consider each record in turn (including header but excluding trailer)

27. Break each record into four byte (character) sections (excluding the end of line character), padded with nulls if required, and exclusive OR (XOR) them into checksum.

The algorithm for this is illustrated by the following ‘C-like’ pseudo code.

num_chars = strlen (record_buffer)

FOR (i = 0; i < num_chars;)

value = 0

FOR (j = 0; j < 4; i++, j++)

IF i < num_chars

value = ((value ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download