Idd part 1 Interfaces with bsc parties and their Agents




старонка2/82
Дата канвертавання24.04.2016
Памер4.34 Mb.
1   2   3   4   5   6   7   8   9   ...   82

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:

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

  2. 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:

  1. Originating Party

  2. Destination Party

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

  4. Frequency in unit time

  5. Data content at the business level.

  6. Mechanism: Electronic Data File Transfer or Manual

  7. Volume – frequency * mean message size

  8. 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   2   3   4   5   6   7   8   9   ...   82


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка