Page 1
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5) Version: 12.5, Date: 24/10/17
page 1 of 45
BSC Central Services
Participant Guidance Participant Communications Installation Guide
(PCIG)
Customer : ELEXON
Contract number :
Business/project number : 4042.EC.230694
Project Manager : Mark Wood
Reporting to : Paul Buxton
Project/document reference : IF-00000018
Issue : 12.5
Issue date : 24/10/17
Status : Definitive
Distribution : As per distribution list on page 2
Prepared by : Nick Brooks Author Date:
Approved (CGI) : Date:
Approved (CGI) : Date:
Authorised (CGI) : Date:
Accepted (ELEXON) : Role Date:
Page 2
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 2 of 45
Reviewers
Name Role
Distribution List
Name/Role Organisation
UKEST Programme Library CGI
Participant IT Support Participant Organisation
Page 3
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 3 of 45
Detailed contents
1 Introduction ..................................................................................................................................... 5
1.1 Purpose ................................................................................................................................ 5 1.2 Scope ................................................................................................................................... 5 1.3 Summary .............................................................................................................................. 5 1.4 Amendment history .............................................................................................................. 5 1.5 References ........................................................................................................................... 5 1.6 Abbreviations ....................................................................................................................... 7
2 BSC Central Services..................................................................................................................... 9
2.1 Energy Contract Volume Aggregation Agent (ECVAA) ....................................................... 9 2.2 Central Data Collection Agent (CDCA) ................................................................................ 9 2.3 Balancing Mechanism Reporting Agent (BMRA) ................................................................. 9 2.4 Central Registration Agent (CRA) ........................................................................................ 9 2.5 Settlement Administration Agent (SAA) .............................................................................10 2.6 Funds Administration Agent (FAA) ....................................................................................10 2.7 Technical Assurance Agent (TAA) .....................................................................................10 2.8 Supplier Volume Allocation Agent (SVAA) ........................................................................10
3 Electronic Interfaces to BSC Central Services .............................................................................11
3.1 Communications Access to BSC Central Services ............................................................11 3.2 Low Grade Interfaces .........................................................................................................11
3.2.1 BMRS Web Service (BMRA) .........................................................................11 3.2.2 BMRS API .....................................................................................................11 3.2.3 BMRS Data Push Service .............................................................................11 3.2.4 FTP Notification and reporting (ECVAA/SAA/CRA/CDCA) ...........................12 3.2.5 ELEXON Portal ..............................................................................................12 3.2.6 ECVAA Web (ECVAA) ..................................................................................13
3.3 High Grade Interfaces ........................................................................................................13 3.3.1 Tibco (BMRA) ................................................................................................13 3.3.2 FTP Notification and Reporting (ECVAA/SAA/CRA/CDCA) .........................13 3.3.3 ECVAA Web (ECVAA) ..................................................................................13
4 Participant Hardware and Software Infrastructure .......................................................................14
4.1 Hardware Requirements ....................................................................................................14 4.1.1 High Grade WAN Communications (Mandatory for High Grade) .................14 4.1.2 Low Grade Internet Communications (Mandatory for Low Grade) ...............15 4.1.3 Servers to Host Software Infrastructure (Mandatory) ....................................15
4.2 Software Requirements .....................................................................................................16 4.2.1 Trading Software (Mandatory) .......................................................................16 4.2.2 FTP Transfer Software (Mandatory)..............................................................16 4.2.3 XSec Encryption Software (Mandatory) ........................................................16 4.2.4 BMRS Web Clients (Optional) .......................................................................17 4.2.5 ECVAA Web Clients (Optional) .....................................................................17 4.2.6 Tibco Data Transmission Software (Optional – High Grade Only) ...............17 4.2.7 FTP Server Software (Optional – High Grade Only) .....................................18
5 Detailed Operation of Services ....................................................................................................19
5.1 FTP Service Usage ............................................................................................................19 5.1.1 Retrieval ........................................................................................................19 5.1.2 Submission ....................................................................................................22 5.1.3 Receiving via High Grade Push ....................................................................24 5.1.4 Shared S0142 Files .......................................................................................25
5.2 XSec Software ...................................................................................................................25 5.2.1 Application Overview .....................................................................................25 5.2.2 Integration with Other Processes ..................................................................26
Page 4
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 4 of 45
5.3 Tibco Rendezvous Software ..............................................................................................26 5.3.1 Approval of New RVRDs ...............................................................................26 5.3.2 RVRD Unique Naming ..................................................................................26 5.3.3 Offline/Standby Servers ................................................................................26 5.3.4 BMRS Subject Naming ..................................................................................27
6 Participant Disaster Recovery ......................................................................................................28
6.1 High Grade Push/Pull Switching ........................................................................................28 6.2 High Grade Push to a Different Server ..............................................................................28 6.3 High/Low Grade Switching .................................................................................................28 6.4 Resilient High Grade Networking .......................................................................................29
7 Overview of Manual Data Flows ..................................................................................................30
7.1 E-mail Communications .....................................................................................................30 7.2 Fax Communications .........................................................................................................30 7.3 Postal Communications .....................................................................................................31 7.4 Manual Acknowledgement Process ...................................................................................31 7.5 Security ..............................................................................................................................32 7.6 Manual Flows to Participants .............................................................................................32
8 Overview of Electronic Data Flows ..............................................................................................33
8.1 Sequence Numbering ........................................................................................................33 8.2 Sequence Handling ............................................................................................................34 8.3 Acknowledgements ............................................................................................................34 8.4 Handling Negative Acknowledgements .............................................................................35
9 Networking Information ................................................................................................................36
9.1 High Grade .........................................................................................................................36 9.1.1 Information and Site Access ..........................................................................36 9.1.2 Features and Specifications ..........................................................................36 9.1.3 Planning an IP Schema .................................................................................37 9.1.4 Firewall Configuration ....................................................................................37 9.1.5 Provision for BSC Central Services Disaster Recovery ................................38
9.2 Low Grade ..........................................................................................................................38 9.2.1 Firewall Configuration ....................................................................................38 9.2.2 Provision for BSC Central Services Disaster Recovery ................................38
10 Summary Overview – Steps in the Comms Setup Process .........................................................40
11 Service Desk ................................................................................................................................41
Page 5
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 5 of 45
1 Introduction
1.1 Purpose
The purpose of this document is to describe the services provided by BSC Central
Services in relation to the planning, installation and operation of communications,
hardware and software, and the interfaces with Market Participants.
1.2 Scope
Since this is an overview document, it references other more detailed procedures,
documents and instructions. Its scope is to provide a basic understanding of what is
required to interact with BSC Central Services.
1.3 Summary
Participant Communications Installation Guide
Guidance document for new BSC Central Services Participants.
1.4 Amendment history
date issue description author OR no.
29/05/08 10.1 First Draft (based upon 09-
10033301 v10.0) Nick Brooks
N/A
30/05/08 10.2 Incorporating internal review
comments Nick Brooks
N/A
12/06/08 10.3 Incorporating ELEXON
review comments Nick Brooks
N/A
20/06/08 12.0 Made definitive following approval from ELEXON
Bron Roddis N/A
11/12/08 12.1 Isis Changes Nick Brooks N/A
18/08/17 12.2 Updates Nick Brooks N/A
03/10/17 12.3 Made definitive following approval from ELEXON
Lloyd Annobil N/A
11/10/17 12.4 Additional Updates Lloyd Annobil N/A
24/10/17 12.5 Incorporating Appendix and additional ELEXON review
comments
Nick Brooks N/A
1.5 References
tag title doc reference version
[XUG] XSec User Guide 25-17010301 TBC
[TUG] Tibco User Guide 01-100308 TBC
Page 6
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 6 of 45
tag title doc reference version
[CRD] Communications Requirements Document* N/A N/A
[IDD] NETA Interface Definition and Design (IDD) Pt 1 07-550201 latest
*The CRD is an ELEXON document, available via the ELEXON website
Page 7
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 7 of 45
1.6 Abbreviations
ARP Address Resolution Protocol
BGP Border Gateway Protocol
BM Balancing Mechanism
BMRA Balancing Mechanism Reporting Agent
BMRS Balancing Mechanism Reporting Service
BP BSC Party (Participant role code)
BRI Basic Rate Interface (ISDN with two data channels)
BSC Balancing and Settlement Code
CDCA Central Data Collection Agent
CIR Committed Information Rate
CRA Central Registration Agent
CSV Comma Separated Values
DNS Domain Naming System
DPP Daily Profile Production
DR Disaster Recovery
DTI Department of Trade and Industry
ECVAA Energy Contract Volume Aggregation Agent
ECVNA Energy Contract Volume Notification Agent
FAA Funds Administration Agent
FQDN Fully Qualified Domain Name
FTP File Transfer Protocol
HHDA Half Hourly Data Aggregator
HSRP Hot Standby Routing Protocol
IDD Interface Definition and Design
IP Internet Protocol
Page 8
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 8 of 45
ISDN Integrated Services Digital Network
ISP Internet Service Provider
JVM Java Virtual Machine
LAN Local Area Network
NAT Network Address Translation
MDD Market Domain Data
MPLS Multi Protocol Label Switching
NHHDA Non-Half Hourly Data Aggregator
NTP Network Time Protocol
PVC Permanent Virtual Circuit
RSA Rivest Shamir Adleman (algorithms/creators of)
RVD Rendezvous Daemon
RVRD Rendezvous Routing Daemon
SAA Settlement Administration Agent
SO System Operator
SLA Service Level Agreement
SVAA Supplier Volume Aggregation Agent
TAA Technical Assurance Agent
TCP Transmission Control Protocol
UDP User Datagram Protocol
WAN Wide Area Network
Page 9
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 9 of 45
2 BSC Central Services
The services provided by CGI (“the Service Provider”) to support the operation of
the Balancing and Settlement Code (BSC), require market Participants to
communicate electronically with CGI’s systems.
Network communications access to the BSC Central Services is provided through
three networks, the CVA WAN (or “CVA High Grade Service”) and the internet (or
“CVA Low Grade Service”) for CVA Services, and the Electralink DTS network (or
“SVA Network”) for SVA Services.
It should be noted that the focus of this document is on BMRA, ECVAA, CRA, CDCA
and SAA. The FAA and TAA (not shown) involve only manual communications as
specified by the Communications Requirements Document [CRD]. The System
Operator is not addressed here.
2.1 Energy Contract Volume Aggregation Agent (ECVAA)
The role of the ECVAA is to collate and provide to the Settlement Administration
Agent (SAA) all energy contract volume and metered volume reallocation data.
2.2 Central Data Collection Agent (CDCA)
The Central Data Collection Agent (CDCA) collects, validates, processes and
aggregates metered data associated with Metering Systems registered with the
Central Registration Agent (CRA). It does this within the timescales required to
enable settlement to meet the Payment Calendar.
2.3 Balancing Mechanism Reporting Agent (BMRA)
The role of the BMRA is to provide near to real-time reporting of all market
information disseminated by the System Operator (SO) and submitted to the
Balancing Mechanism (BM) from market Participants.
2.4 Central Registration Agent (CRA)
The role of the CRA is to maintain a master register of information relating to the
registration of Participants, trading units and physical plant such as Boundary Points
and interconnectors.
Page 10
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 10 of 45
2.5 Settlement Administration Agent (SAA)
The role of the SAA is to calculate the credit and debit payments resulting both from
trades made in the Balancing Mechanism (BM) and from imbalances between
contracted and actual generation or consumption.
The SAA creates and publishes a Settlement Calendar on an annual basis to ensure
that all Settlement calculations and Settlement Runs are performed in a timely
manner so that payments are made on the intended dates.
2.6 Funds Administration Agent (FAA)
The FAA is responsible for transacting the payments and charges applicable as
determined by the SAA.
2.7 Technical Assurance Agent (TAA)
The TAA is concerned with the technical assurance of all Metering Systems
registered with the CRA. The overriding aim of this service is to support the quality
of meter data that is used in the settlement process. The TAA provides a vital link in
the end to end assurance of settlement data by reviewing the very source of the data,
the Metering System and its associated equipment.
2.8 Supplier Volume Allocation Agent (SVAA)
The SVAA is responsible for producing MDD, DPP and calculating Supplier BM
Units meter volumes using data provided by the Suppliers’ HHDAs and NHHDAs.
Page 11
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 11 of 45
3 Electronic Interfaces to BSC Central Services
3.1 Communications Access to BSC Central Services
The interface with the SVA element of BSC Central Services is via the DTS
network. This is a service provided by Electralink.
There are two methods of electronic communication with the CVA elements of BSC
Central Services, referred to as the High Grade and Low Grade services.
The High Grade service is provided using dedicated communications lines installed
and managed by BSC Central Services. These lines connect the Participant to BSC
Central Services over an MPLS based private WAN.
The Low Grade service is provided via the public internet using connectivity
provided and managed by individual Participants.
Although the primary distinction between the two grades of service is the ability of
the Service Provider to commit to specific levels of performance and reliability, the
guaranteed bandwidth of the High Grade service allows an enhanced method of
BMRS data retrieval to be available.
3.2 Low Grade Interfaces
The interfaces available using the Low Grade Service over the public internet are:
3.2.1 BMRS Web Service (BMRA)
Available at http://www.bmreports.com, the BMRS website allows querying of
current and historic Balancing Mechanism data, which is presented in tables, graphs
and downloadable as CSV files. The data provided is a static snapshot as the data
exists at the time that the query is made.
This is presented over the internet, and no authentication is required to view data, it
is publicly available.
3.2.2 BMRS API
Available at api.bmreports.com, the BMRS API provides a machine to machine
interface allowing XML web service calls to be made to retrieve BMRS data over the
internet.
This service requires authentication using an API key obtained from the ELEXON
Portal.
3.2.3 BMRS Data Push Service
This is an ActiveMQ based data push facility presented over the internet allowing
real-time BMRS events to be subscribed to and received using a variety of protocols
Page 12
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 12 of 45
including STOMP, MQTT ,Openwire and AMQP, offering both durable and non-
durable connection options.
3.2.4 FTP Notification and reporting (ECVAA/SAA/CRA/CDCA)
Available at ftp.bmreports.com, the BSC Central Services FTP service allows
submission of files containing BSC IDD formatted data flows to Central Services.
Files placed on this server are picked up and processed, and responses and reports are
placed on the server for the Participant to periodically poll for and collect.
This service requires login credentials which are supplied during the registration
process.
3.2.5 ELEXON Portal
The ELEXON Portal, accessible over the internet at https://www.elexonportal.co.uk
provides a wide variety of data to the industry including news, documentation, online
forms and utilities as well as access to real-time data from the BSC systems and
archived historic data.
Users self-register for ELEXON Portal accounts, with further privileges for some
functionality requested by the user and granted by ELEXON.
Page 13
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 13 of 45
3.2.6 ECVAA Web (ECVAA)
Available at https://www.ecvaa.com, the ECVAA web service allows an alternative
method for Participants to view their positions and notify to the ECVAA service in a
more interactive way than the standard FTP notification method.
The Sun Java virtual machine is required to use the functionality of this site.
This service has a login authentication process controlled by the Participant
organisation and based on the security architecture used by the main BSC Central
Services FTP service. It requires users to provide a username, password and a
“credentials file” provided by their security administrator permitting them access to
the service.
3.3 High Grade Interfaces
The interfaces available using the High Grade service over the BSC Central Services
private WAN are:
3.3.1 Tibco (BMRA)
This service is only available using the High Grade service, and uses industry
standard Tibco data transmission software to stream a subscription customised feed
of Balancing Mechanism data to the Participant’s site. The Participant can then use
Tibco connectors to pass this data into their own applications.
3.3.2 FTP Notification and Reporting (ECVAA/SAA/CRA/CDCA)
This is the same FTP service as described for the Low Grade service in section 3.2.4,
except that it is accessed via the High Grade network.
3.3.3 ECVAA Web (ECVAA)
This is the same secure web service as described for the Low Grade service in
section 3.2.6, except that it is accessed via the High Grade network.
Page 14
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 14 of 45
4 Participant Hardware and Software Infrastructure
This section outlines the hardware and software requirements for a BSC Central
Services Participant and which parties are responsible for provision and support of
both hardware and software.
4.1 Hardware Requirements
4.1.1 High Grade WAN Communications (Mandatory for High Grade)
If a Participant chooses to use the High Grade service, they place an order for this
service through ELEXON. Before this order is accepted, the Participant then engages
in a technical prevalidation process with the Service Provider. The Service Provider
liaises with the Participant to arrange installation of dedicated communications lines
and a router to connect to the Participant’s network.
The Participant will be responsible for providing technical details related to the
installation throughout the order process, and must allow for reasonable and timely
site access for the Service Provider’s supplier during installation and in the event of
any fault.
The Service Provider is responsible for operation and support of the communications
up to the ethernet port on the provided router. The Participant is responsible for the
network that they connect to the router.
The typical High Grade Service will comprise the following hardware:
A 2Mb MPLS Leased Line
A 20:1 contended, 2Mbps ADSL backup line
A Cisco rack mountable router with a 10/100/1000Mbps ethernet port for
connection to the Participant’s network.
Several other communications options are available, including for ADSL as a
primary line to reduce cost (with compromises in SLA support and contention).
Communications lines options and pricing are available upon request from
ELEXON’s market entry team. CGI can provide advice to participants as to the best
option for a new communications requirement.
The lead-time for installation of these communications lines is 55 working days from
the date that the order is placed following technical prevalidation.
The High Grade communications service is provided using Vodafone infrastructure
and is completely managed through CGI as the Service Provider.
Page 15
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 15 of 45
The Service Provider will discuss networking requirements with the Participant and
will use reasonable endeavours to accommodate any special requirements that the
Participant has, for example:
Custom IP addressing
Network Address Translation
Upgraded communications for bandwidth and/or resilience
Automatic failover if more than one service is ordered.
It is highly recommended that in addition to the inherent security of the network
managed by the Service Provider, the Participant provides a firewall for their High
Grade network connection.
The standard communications described above are suitable for a Participant
registering and using up to three Participant IDs, using one instance of a Tibco server
to retrieve real-time BMRS data and with up to five workstations accessing the
BMRS web service. If a Participant’s needs are higher than this they should consult
the Service Provider to establish whether a more highly specified communications
option is prudent.
4.1.2 Low Grade Internet Communications (Mandatory for Low Grade)
The Participant is responsible for sourcing, ordering and maintaining their own
internet connectivity.
When the Participant provides their internet connectivity, they should consider the
following points:
They should synchronise their systems using a suitable time synchronisation
protocol, and NTP is recommended. The choice of NTP server will depend
upon the requirements and size of the environment to be synchronised. A
recommended server list can be found at
http://ntp.isc.org/bin/view/Servers/WebHome.
They should ensure that they are able to access ftp.bmreports.com using an
FTP client (standard port 21).
They should be able to access http://www.bmreports.com and
https://www.ecvaa.com through a web browser.
It is strongly recommended that the Participant provides a dedicated firewall
platform for their internet connection.
Page 16
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 16 of 45
4.1.3 Servers to Host Software Infrastructure (Mandatory)
All hardware on the Participant site (with the exception of the High Grade router and
associated networking equipment) is provided and maintained by the Participant. The
Service Provider does not provide hardware or support hardware on which the
Service Provider supplied software is installed.
4.2 Software Requirements
4.2.1 Trading Software (Mandatory)
The Participant is responsible for providing software which is able to conform to the
BSC IDD for the generation of, recognition of and response to BSC data flows.
The Service Provider cannot provide recommendations for this software, but is aware
of several vendors who are able to provide suitable software and can provide a list on
request.
4.2.2 FTP Transfer Software (Mandatory)
The Participant is responsible for providing software for the transfer of files via FTP
between themselves and BSC Central Services. Although use of a manual FTP client
is acceptable, it is recommended that an automated solution is employed. Most of the
commercially available trading software incorporates this functionality.
4.2.3 XSec Encryption Software (Mandatory)
All files transferred to and from Central Services by FTP are encrypted/decrypted
using a piece of proprietary software called XSec. It runs on all variants of Windows
supporting the .NET 4.0 framework (including Windows 7, 2008 and 2012). It runs
as a Windows service and has a file based interface - files are placed into input
directories where they are picked up by XSec, processed and placed into output
directories.
XSec provides encryption and signing functionality for all files to be sent to or
received from BSC Central Services and is entirely automated, such that the
successful receipt of a plaintext file from XSec implies that a secure, complete and
validated transfer of data from BSC Central Services has occurred.
The XSec software uses public key encryption/signing technology which requires the
Participant to create private and public keys. The public keys must then be sent to the
Service Provider to be verified and applied to the Central Services encryption
subsystem The Service Provider will provide advice and assistance for this. (see
helpdesk contact information in section 11).
XSec does not provide FTP or trading software functionality.
The Participant is responsible for providing the hardware and software environment
for this software and operating it, but the Service Provider provides support and
assistance in configuring and troubleshooting.
Page 17
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 17 of 45
The XSec software is highly customisable in order to be able to be tailored to the
requirements of each Participant, and the Service Provider will provide advice and
assistance for installation and configuration.
XSec is ordered via ELEXON during registration, and a separate user guide is
supplied with the software.
4.2.4 BMRS Web Clients (Optional)
If the Participant wishes to use the BMRS web service, they are responsible for
providing their own web clients.
4.2.5 ECVAA Web Clients (Optional)
In addition to the technologies required for use of the BMRS web services (Sun
JVM, Internet Explorer 6), to use the ECVAA Web service a user requires a
username, password and a credentials file supplied by their security administrator
(within the Participant organisation). The user connects to the ECVAA Web server
using an SSL enabled Internet Explorer browser and provides their username and
credentials file, followed by randomly selected letters from their password.
The key component here is the credentials file. The Participant security administrator
creates credentials files (using tools available from the Service Provider or by
creating the files manually from specifications available from the Service Provider),
specifying details such as username, password, file validity periods and user rights.
The administrator encrypts these files using the XSec software discussed in section
5.2 (using the same keys employed for encryption of BSC FTP file flows) and
provides the encrypted files to the user.
When the user performs a login, the ECVAA web service confirms that the
credentials file supplied is from a verified source (established by means of
decryption with the Participant’s public keys) and that the credentials being supplied
by the user match those in the credentials file.
It is recommended that a separate installation of XSec on a standalone machine is
used for credentials file encryption, and the Service Provider supplies a targeted
software installation pack for this purpose.
Note: The Service Provider’s staff will never ask the Participant for their ECVAA
web username or password, and users of the system should be advised that they
should not provide these details under any circumstances.
4.2.6 Tibco Data Transmission Software (Optional – High Grade Only)
If the Participant has a High Grade Service and wishes to utilise the BSC Central
Services BMRS Tibco data stream, they are responsible for providing a Tibco RVRD
(server) and as many RVDs (clients) as they require.
Page 18
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 18 of 45
The Tibco software can be sourced through ELEXON (Windows only), purchased
directly from Tibco or the Participant can use any Tibco architecture they may
already have within their organisation, subject to licence agreements
A separate Tibco user guide detailing Tibco setup specific to BSC Central Services is
provided on request by the Service Provider.
The Tibco software has two components known as the RendezVous Daemon (RVD)
and the RendezVous Routing Daemon (RVRD). The server (RVRD) is used to
transfer data between sites, and then redistribute this data to local clients (RVDs).
The Service Provider operates a central RVRD which publishes real-time BMRS
data. The Participant configures their own RVRD which connects to the BSC Central
Services central RVRD and receives this data. The Participant RVRD then relays this
data to local RVDs
RVRD is a cross platform product, but is most commonly run on Windows. The
Service Provider distributes, supports and tests only Windows environments. If the
Participant wishes to use a non Windows Tibco configuration they should therefore
ensure that they provide adequate platform support, and should source their Tibco
software independently of ELEXON.
The Participant must contact the Service Provider before configuring an RVRD to
ensure that the correct configuration is being used to avoid conflicts with other parts
of the Tibco network.
In its default configuration, the RVRD server communicates with its RVD clients by
using a local subnet broadcast, requiring the clients to reside on the same local
network as the server. This is explained more in the networking section 9.
The Service Provider supports the specific application and configuration for Tibco
that is being used for BMRS, and is also able to provide limited support and
assistance for the Tibco product itself, with the ability to refer product defect queries
directly to Tibco. The Service Provider will supply upon request their Tibco User
Guide [TUG].
Note: The Tibco BMRS service only publishes current data. It is not able to be used
for supply of historical data.
Note: Tibco data is also provided as day-behind flat files through the Low Grade
BMRS Web Service. This is known as the Tibco Relay service.
4.2.7 FTP Server Software (Optional – High Grade Only)
When a Participant sends files to BSC Central Services, they place the files on the
BSC Central Services FTP server. When BSC Central Services respond, the default
behaviour is that response files are placed on the BSC Central Services FTP server
for the Participant to periodically poll and collect.
Page 19
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 19 of 45
However, if a Participant is using the High Grade service, they may elect to provide
an FTP server on their own site which BSC Central Services can push files out to
directly as soon as they are generated. This is entirely optional.
Page 20
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 20 of 45
5 Detailed Operation of Services
5.1 FTP Service Usage
As discussed in previous sections, a core part of the services provided by BSC
Central Services involves transfer of files to and from Participants using FTP. The
BSC Central Services FTP service is available both via the High Grade network and
the public internet. Both routes reach the same server, and the same procedure should
be used for both methods of access.
The BSC Central Services FTP servers use standard FTP on port 21, and accept both
active and passive data transfers (passive is recommended to increase the
Participant’s own security, since all network connections are then outbound from the
Participant’s network).
The Participant is provided with an FTP account on the BSC Central Services server
for each BSC Central Services Participant ID that they register. This Participant ID is
the username for the Live FTP service. Passwords are provided by the Service
Provider during the registration process. The examples below use the fictional
account name “user1234”.
When the Participant logs into the BSC Central Services FTP server, they are placed
in a directory off the FTP server root corresponding to their account name which
contains three subdirectories – inbox, outbox and temp. Participants must not create
their own subdirectories or content on the BSC Central Services FTP server and are
not permitted to store files on the server for any purpose other than that described
below.
5.1.1 Retrieval
When BSC Central Services creates files for the Participant, they are placed in the
Participant’s outbox directory on the BSC Central Services FTP server. The
Participant should periodically poll for these files at a rate of no more than once per
60 seconds. The Participant is responsible for retrieving the file in binary mode,
confirming that the transfer was successful and then deleting the file.
Page 21
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 21 of 45
The Participant should pick up their files in a timely manner and not leave files on
the server after collecting them. In reality uncollected files are purged after 12 days,
but the Participant must not rely on files older than 5 days being present on the server
(5 days being the period of time that files are defined to be available. Under some
Disaster Recovery scenarios the full 12 days of backlog may not be populated).
When logging in, the Participant FTP software should make no assumptions about
the content of the FTP login banner, since this may be changed from time to time, or
in response to a disaster.
Once logged in, the user is placed in the /username/ directory directly beneath the
FTP server root. Files generated for the Participant by BSC Central Services will be
placed in the /username/outbox/ directory.
The Participant should carry out the following actions:
Switch to binary data transfer mode using the TYPE I command (usually
implemented in command line clients as bin).
List the files in the outbox directory using the LIST command (usually
implemented in command line clients as ls or dir).
Parse the resulting listing to obtain filenames.
For each file, retrieve using the RETR command (usually implemented in
clients as get), then upon successful validation that the file has been received
delete the file using the DELE command.
If a Participant wishes to use a different method than this, they should contact the
Service Provider who can advise of any potential problems. In particular it is
strongly recommended that the Participant considers the following:
While automated scripting of the FTP process is encouraged, individual file
retrieves/deletes should be carried out on a per file basis, rather than using
batch commands such as mget.
The Participant should carry out some form of basic validation on the
retrieved file before deleting from the server. This may be as simple as
confirming that a 226 code has been received for the transfer, or that the file
retrieved is the same size as the directory listing indicated.
There follows an example FTP transcript of a successful retrieval of two files. In this
example a Unix command line FTP client is being used. Red lines indicate
commands sent from the Participant, and green lines those returned from the server:
ftp> open ftp.bmreports.com
Connected to ftp.bmreports.com.
220 Microsoft FTP Service
Page 22
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 22 of 45
220 ELX-LVW-FTP
ftp> user username password
331 Password required for username.
230 User username logged in.
ftp> bin
200 Type set to I.
ftp> ls outbox
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
file1
file2
226 Transfer complete.
ftp> get outbox/file1
200 PORT command successful.
150 Opening BINARY mode data connection for outbox/file1 (29 bytes).
226 Transfer complete.
29 bytes received in 0.00 secs (0.00 secs, 56.64 Kbytes/s)
ftp> dele outbox/file1
250 DELE command successful.
ftp> get outbox/file2
200 PORT command successful.
150 Opening BINARY mode data connection for outbox/file2 (29 bytes).
226 Transfer complete.
29 bytes received in 0.00 secs (0.00 secs, 56.18 Kbytes/s)
ftp> dele outbox/file2
250 DELE command successful.
ftp> bye
221 Goodbye.
Page 23
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 23 of 45
5.1.2 Submission
When a Participant wishes to submit a file, they must push the file in binary mode to
their temp directory, and then move the file to their inbox directory using a rename
operation. This ensures that there is no possibility of BSC Central Services collecting
a file for processing which has not fully finished file transfer. It is required that
Participants transfer files using this method.
When logging in, the Participant FTP software should make no assumptions about
the content of the FTP login banner, since this may be changed from time to time, or
in response to a disaster.
Once logged in, the user is placed in the /username/ directory directly beneath the
FTP server root. The Participant must submit files to the /username/temp directory,
then rename them to the /username/inbox directory. This is to ensure that files
retrieved from the inbox by BSC Central Services are complete and not still being
transferred.
The Participant should carry out the following actions:
Switch to binary data transfer mode using the TYPE I command (usually
implemented in command line clients as bin)
For each file, upload to the temp directory using the STOR command
(usually implemented in command line clients as put), then move the file to
the inbox directory using the RNFR and RNTO commands (usually
simplified in command line clients using the rename command).
If a Participant wishes to use a different method than this, they should contact the
Service Provider who can advise of any potential problems. In particular it is
strongly recommended that the Participant considers the following:
The Participant should check return codes to confirm that operations have
been successful.
The Participant must transfer and rename files individually. Usage of batch
commands or manipulation of directories to achieve the same effect is not
accepted and Participants using such methods will be asked to stop, since it
can disrupt the automated process used by the Service Provider in processing
files.
Page 24
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 24 of 45
There follows an example FTP transcript of a successful submission of two files. In
this example a Unix command line FTP client is being used. Red lines indicate
commands sent from the Participant, and green lines those returned from the server:
ftp> open ftp.bmreports.com
Connected to ftp.bmreports.com.
220 Microsoft FTP Service
220 ELX-LVW-FTP
ftp> user username password
331 Password required for username.
230 User username logged in.
ftp> bin
200 Type set to I.
ftp> put file1 temp/file1
200 PORT command successful.
150 Opening BINARY mode data connection for temp/file1.
226 Transfer complete.
1 byte sent in 0.00 secs (0.00 secs, 1.95 Kbytes/s)
ftp> rename temp/file1 inbox/file1
350 File exists, ready for destination name
250 RNTO command successful.
ftp> put file2 temp/file2
200 PORT command successful.
150 Opening BINARY mode data connection for temp/file2.
226 Transfer complete.
1 byte sent in 0.00 secs (0.00 secs, 1.76 Kbytes/s)
ftp> rename temp/file2 inbox/file2
350 File exists, ready for destination name
250 RNTO command successful.
ftp> bye
221 Goodbye.
Page 25
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 25 of 45
5.1.3 Receiving via High Grade Push
Participants with a High Grade service may elect to have response and report files
pushed directly to an FTP server on their own site. If this is required the Participant
must provide the Service Provider with the following information during the
registration process:
The IP address of the FTP server which BSC Central Services should push to
The username and password that BSC Central Services should use to login to
the server
The relative or absolute path to the directory which files should be initially
pushed to (the equivalent of the temp directory used on the BSC Central
Services server for file submission)
The relative or absolute path to the directory which files should be renamed
to after initial transfer (the equivalent of the inbox directory used on the BSC
Central Services server for file submission).
If these details are to be changed during operational use, the new details should be
provided to BSC Central Services with at least 48 hours notice.
The method used by Central Services to push files is as follows:
Place the file in the Participant’s outbox on the BSC Central Services FTP
server
Deliver the file directly to the Participant FTP server using the same
push/rename technique required for Participant file transfers.
Delete the file from the BSC Central Services FTP server if the push was
successful.
This allows flexibility for the Participant in the event that their FTP server becomes
unavailable, in which case the files remain on the BSC Central Services server ready
to be collected manually.
Although the FTP push process is convenient, many Participants prefer to poll the
BSC Central Services FTP server themselves since this allows them greater
flexibility to move operations between their own production and disaster recovery
environments without reconfiguration from the Service Provider. If the High Grade
Push process is used it should be noted that the delivery of a file is considered
complete under BSC Central Services’ SLAs at the point that it is placed on the BSC
Central Services FTP server (i.e. if the Participant server is unable to accept the
pushed file, this does not constitute a failure of deemed receipt under the BSC).
Page 26
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 26 of 45
5.1.4 Shared S0142 Files
S0142 data is available to all BSC Parties (i.e. Participants with Participant IDs
holding a BP role). Since this data is not required by all Participants, coupled with
the large size of S0142 data, it is delivered differently than other files. Parties may
access the S0142 area of the BSC Central Services FTP server, which contains a
rolling 7 days worth of compressed data. It is not available via the FTP push method.
The S0142 data is stored in the /S0142/outbox directory on the server, which can be
accessed after initial login using the command cd ../S0142/outbox.
The S0142 files do not have normal recipient details in the header (AAA) record.
Instead, the To Participant ID is set to DOWNLOAD and the To Role Code is set to
PB. The files are read only, so cannot be deleted once copied - they’re needed for
other users. All users see the same directory and the same files. Participants must
keep track of which files they have already downloaded to avoid repeated retrieval of
the same file on successive days.
These files have meaningful names to assist in the identification of required files -
the file name will take the form “YYYYMMDD_RR_YYYYMMDDHHMISS.gz”
where YYYYMMDD is the settlement date, RR is the settlement run type (e.g. II, SF
etc) and YYYYMMDDHHMISS represents the file creation datetime. The file
extension “.gz” indicates the use of the “gzip” compression utility.
The S0142 files stored on the BSC Central Services FTP service are not encrypted.
5.2 XSec Software
The XSec software distributed by the Service Provider is required for all incoming
and outgoing files. Operation and configuration of this software are covered by its
own documentation, but this section provides a brief overview of its features and
usage.
5.2.1 Application Overview
The XSec application uses PGP based public key encryption and signing to secure
the contents of files transferred between Participants and BSC Central Services. It
operates as a Windows service and is compatible and tested with Windows 7 as well
as Windows 2008 and Windows 2012. It uses the .NET framework 4.0.
It uses a file based interface, polling input directories to look for files to
encrypt/decrypt, and placing the processed files into output directories where it is
assumed that other processes will pick them up.
For reliability, processes delivering files to XSec should always place files using
instantaneous move operations to avoid the possibility of part written files being
Page 27
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 27 of 45
processed. XSec contains some protection against this, but in general it should be
ensured that XSec’s input directories are not written into directly.
BSC Central Services allows for this in the FTP push process described above by
initially transferring the file to a temporary directory before renaming to a final
destination. This final destination directory can be an XSec input directory.
5.2.2 Integration with Other Processes
XSec sits between the Participant’s business software and the process which transfers
files to and from BSC Central Services Central Services as per the diagram below:
5.3 Tibco Rendezvous Software
The High Grade Participant’s Tibco RVRD server connects to the BSC Central
Services Central RVRD to send subscriptions and receive real-time BMRS data. This
software is covered by its own documentation which is provided to Participants on
request, but this section covers some high level technical considerations for the
Participant to be aware of in usage of the RVRD.
5.3.1 Approval of New RVRDs
Before configuring or connecting a new Tibco RVRD, the Participant must contact
the Service Provider through the BSC Central Services helpdesk. The Service
Provider will work with the Participant to ensure that this new RVRD will not cause
any problems or conflicts to Participant or BSC Central Services infrastructure, and
will configure access to the BSC Central Services RVRD.
5.3.2 RVRD Unique Naming
If the Participant chooses to use more than one Tibco RVRD, they must ensure that
these RVRDs are configured with unique names on the BSC Central Services Tibco
network. Presence of multiple RVRDs with the same name leads to conflicts which
can cause loss of data and disruption of the RVRD network.
5.3.3 Offline/Standby Servers
The Participant should consult the Service Provider and the Tibco User Guide [TUG]
about offline or standby servers installed with the Tibco software. This is to ensure
that licensing rules are being correctly interpreted and to ensure that no situation can
occur where the standby server might become active at the same time as another
server with the same RVRD name.
Page 28
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 28 of 45
5.3.4 BMRS Subject Naming
The messages distributed via the Tibco application are divided into logical segments
using Tibco subject names. These are dot (.) delimited text strings which split BMRS
data into hierarchical structures.
This can be useful for data analysis if the Participant is using the data for an
application such as a Tibco connector into their own application or database. This
subject naming is covered in detail in the Tibco documentation supplied by the
Service Provider during registration and in the BSC Interface Definition Documents
(IDD) available from ELEXON’s website.
Page 29
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 29 of 45
6 Participant Disaster Recovery
The architecture used by BSC Central Services allows for Participants to provide
resilience to disaster in their own systems. This section explains options that the
Participant may wish to consider when designing their BSC Central Services
infrastructure.
6.1 High Grade Push/Pull Switching
High Grade Participants are permitted at any time to switch between the push and
pull modes of BSC Central Services file delivery by contacting the BSC Central
Services helpdesk and requesting the change. This must be authorised by a BSCP38
Category A authorised signatory for the Participant ID/s in question. In emergencies
this change can be carried out quickly, but Participants should ideally try to provide
at least 48 hours notice.
Requesting a switch from push to pull is not necessary in some DR scenarios such as
a loss or failure of the Participant’s FTP server (since in the event of failure to push
files, these files will be left on the BSC Central Services FTP server ready for pull),
but it is realised that a Participant may wish to carry out a more controlled cutover
under some circumstances, for example where their live FTP server is still active, but
they wish to use their DR site.
Similar authorisation and notice should be provided when the Participant wishes to
resume their original configuration.
6.2 High Grade Push to a Different Server
If a Participant has two sites on the BSC Central Services High Grade network and
uses the FTP push option to have files delivered to their main server, then a move to
their DR site will require the Participant to inform the Service Provider of the
alternate IP address, login and directory structure details of the DR server if they
wish files to be pushed to their DR site.
This is achieved by calling the BSC Central Services helpdesk, and in emergencies
can be carried out at short notice. Authorisation from a BSCP38 Category A
authorised signatory for the Participant ID in question is required.
It is highly recommended if a Participant wishes to use a DR facility that they do not
use FTP push mode. Using pull mode instead provides greater flexibility for moving
to DR without dependence on the Service Provider.
6.3 High/Low Grade Switching
All High Grade Participants are also automatically configured to be able to use the
Low Grade internet based service, and in the event of a complete failure of access to
the High Grade service the Participant may use the Low Grade FTP and web services
as a disaster recovery strategy.
Page 30
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 30 of 45
If the Participant wishes to use this as a disaster recovery strategy, they should ensure
that their networks and firewalls are configured to allow their systems to access both
networks. In most cases all that is required to switch to using the Low Grade service
is a change of target from the High Grade IP addresses to the Low Grade IP Address
(or preferably the Fully Qualified Domain Name for the Low Grade service). No
involvement is required from the Service Provider for this type of switch.
The change from high grade to low grade, or vice versa, does not affect the file
sequence numbers used for file transmissions. If there is any doubt as to which files
have been transferred then the Participant operations staff will need to liaise with the
Service Provider’s staff, via the BSC Central Services helpdesk, to establish the most
recent file received of each type.
6.4 Resilient High Grade Networking
If a Participant wishes to use more than one connection to the High Grade network in
order to provide a disaster recovery position or improve their resilience, the Service
Provider can work with them to find a suitable option.
The BSC Central Services networks team, contactable through the BSC Central
Services helpdesk, can advise on these and other advanced network configurations.
Page 31
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 31 of 45
7 Overview of Manual Data Flows
At times it will be necessary to perform manual communications between the
Participants and BSC Central Services. The following are the types of manual
interface that can be used:
E-mail
Fax
Post.
All manual data flows sent by Participants to the BSC Central Services must have a
unique reference number provided, in an alphanumeric format with a maximum of
ten characters.
Some manual data flows may be sent electronically. However, only those listed in
the flow role tab of the Interface Definition and Design (IDD) spreadsheet are
supported.
7.1 E-mail Communications
Upon receipt of an e-mail, the sender’s details will be checked against the
authorisation register within CRA. If the sender is an authorised party, then the e-
mail will be positively acknowledged. If the authorisation check fails, a negative
acknowledgement will be sent.
Please note, e-mails must contain the manual flow as an attachment and not inputted
as text into the body of the e-mail.
E-mails will be acknowledged using the standard manual acknowledgement process.
See section 7.4.
Following acknowledgement, the e-mail will be forwarded to the relevant team for
processing.
The BSC Central Services e-mail address that Participants must use for BSC Central
Services related manual flows is [email protected]
Note: E-mail is not secure so authentication is limited. For some flows this is not an
appropriate method of communication. Email may only be used for defined manual
flows and ad-hoc communications.
7.2 Fax Communications
Faxed flows must be sent to a dedicated BSC Central Services fax number. This will
interface with the CGI Consortium e-mail system such that the fax is presented as an
attachment to an e-mail.
From this point onwards the process is the same as for the e-mail medium.
Page 32
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 32 of 45
The BSC Central Services fax number that Participants must use for BSC Central
Services related manual flows is 0870 8335601.
7.3 Postal Communications
All post must be addressed to specific BSC Central Services addresses.
Manual communication flows which involve BSCP form submission (with the
exception of forms submitted through the Online Forms service) should be addressed
to:
Central Registration Agent (or CDCA as appropriate)
The BSC Central Services
IMServ Europe Ltd
Scorpio
Rockingham Drive
Linford Wood
Milton Keynes
MK14 6LY
United Kingdom
All manual communications flows not resulting in a BSCP Form submission should
be addressed to the BSC Central Services Help Desk at:
BSC Central Services Helpdesk
CGI
Moor Road
Waterton Industrial Estate
Bridgend
CF31 3LQ
From the point of receipt, the process is the same as for the e-mail media.
7.4 Manual Acknowledgement Process
Each Participant/role combination will have one manual acknowledgement route,
which will be fax or e-mail. When Participant’s initially register with CRA they will
be required to provide an e-mail address and fax number, which will be used for
manual acknowledgements. E-mail will be the preferred method for communicating
manual acknowledgements. However, if an e-mail address is not provided then
acknowledgements will be sent via fax.
All manual acknowledgements, irrespective of the input media sent will be sent to
the address using the standard acknowledgement media (fax or e-mail).
The acknowledgement will be a standard format Word document containing the
following information:
Page 33
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 33 of 45
Flow type
Participant’s sending reference ( as detailed above)
Acknowledgement reference (unique reference generated by BSC Central
Services)
Date/time received.
The date and time of sending of the manual acknowledgement will be recorded.
7.5 Security
The management and handling of all incoming manual information is covered by the
ISO27001 and ISO17799 security accreditation of the organisations processing this
information.
Security is built into this process through:
Restriction of e-mail access to authorised users only for both incoming and
outgoing media
Secure routing of faxes directly to e-mail
Routing of incoming post to authorised users only
Secure routing of acknowledged data to authorised users only
Storage of paper communications in a fire safe.
7.6 Manual Flows to Participants
Each Participant/role combination will have one manual message route, which will
be fax or e-mail. All manual messages will be sent to the address using the standard
message media (fax or e-mail).
The method for communicating manual flows to Participants, is detailed in section
7.4.
Page 34
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 34 of 45
8 Overview of Electronic Data Flows
A common format is used for data files transferred electronically between the BSC
Central Services and the BSC Parties and their Agents. These files use the ASCII
character set. They consist of:
A standard header
A collection of data records using standard format
A standard footer.
The format of these files and individual record arguments are specified in the
Interface Definition and Design (IDD). The IDD is listed in the references section of
this document, and is available at:
http://www.elexon.co.uk/bscrelateddocs/URSIDD/
This section details some of the core information from these documents, along with
important considerations in the generation and processing of the data flows.
8.1 Sequence Numbering
Since the order in which flows are processed can have an important effect on
processing, BSC Central Services uses file sequencing to ensure that all files are
processed in the intended order. All flows to and from BSC Central Services contain
a sequence number in the header record of the file, which wraps around to zero when
it reaches its maximum limit.
A separate sequence series is used for each combination of source Participant ID,
source role code, destination Participant ID and destination role code. So, for
example flows in different directions between a specific BSC Central Services role
code and a specific Participant role code would operate using different sequence
series.
The exception is the case of receipt acknowledgement files, which carry the sequence
number of the file being acknowledged.
Sequence numbering is independent of the method of delivery, so Participants
switching between the High and Low Grade services do not need to reset their
sequence numbers.
There is no automatic process by which the BSC Central Services will alter the value
of any next expected sequence number which it holds (either up or down), apart from
the normal increment when a file is received with a valid header. The only method
by which a BSC Party or Agent can achieve a change in the value of the next
expected sequence number held by a BSC Central Services will be by manual
agreement, via the BSC Central Services Help Desk.
Page 35
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 35 of 45
8.2 Sequence Handling
It is accepted that in some circumstances it may be possible for files generated by
BSC Central Services or by the Participant to be received by the other party out of
sequence order. In this circumstance the receiving party should negatively
acknowledge the file as being out of sequence, but to improve the resilience and
automation of the sequencing system BSC Central Services has a sequence handling
procedure to allow some flexibility for flows submitted in an incorrect order.
The system described is that used by BSC Central Services. It is highly
recommended that Participant software incorporate a similar system.
If a file is received by BSC Central Services with a sequence number greater than
that expected for the given sequence series, it is not automatically negatively
acknowledged. Instead, it is put in a holding queue to wait for the next expected
sequence numbered file to arrive.
If after a specified number of out of sequence files are received, or after a specified
period of time has elapsed (whichever occurs sooner), the next expected sequence
number has not been received then any out of sequence files which have been in the
holding queue are negatively acknowledged as being out of sequence.
The values used by BSC Central Services for this purpose are 99 files (variable upon
request per Participant) or 13 minutes. These values are chosen by BSC Central
Services to comply with the service levels required for acknowledgement of files
submitted by Participants, but are a good suggested starting point for Participants
implementing a similar system.
Factors which would affect the choice of values for a Participant would be the
volume of files transferred during a typical delivery and criticality of alerting their
users should a problem occur.
8.3 Acknowledgements
As discussed above, each flow (other than an acknowledgement itself) sent to or
from BSC Central Services expects a response file to be generated to acknowledge
successful or unsuccessful receipt. The scope of this acknowledgement is to indicate
that the file is in the correct format, that its sequence number is that expected and that
its data integrity can be verified (by means of a checksum in the footer record). An
acknowledgement, sometimes referred to as a “Comms Ack” from BSC Central
Services does not signify that the data within the flow has been accepted. This is
notified via other flows such as ECVAA acceptance feedback reports.
The acknowledgement file format is specified in detail in the BSC Central Services
Interface Definition and Design (IDD) documents. Each file consists of:
A header (AAA) record which among other information contains the name
and sequence of the flow being acknowledged
Page 36
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 36 of 45
An acknowledgement (ADT) record which specifies the type of
acknowledgement being provided, response codes indicating positive or
negative receipt and optional description of errors
A standard footer record containing a checksum for the flow.
8.4 Handling Negative Acknowledgements
The progression of sequence numbers following a negative acknowledgement from
BSC Central Services depends on the nature of the error in the original file (which is
specified in the acknowledgement code of the ADT record).
If a file is rejected because of problems with the HEADER, the sequence
number is not "used" and so the next expected sequence number remains
unchanged. [NACK codes 1,2,3]. A corrected file (with the same sequence
number) should be submitted next.
If a file is rejected because of problems with the BODY or TRAILER (record
count, checksum), the sequence number is used and the next expected
sequence number is incremented. [NACK codes 4,5,6,7] A corrected file
(with a new sequence number) should be submitted next.
Page 37
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 37 of 45
9 Networking Information
This section provides more detailed information to assist network administrators in
the ordering, configuration and usage of the BSC Central Services electronic
interfaces.
9.1 High Grade
After registering interest for a High Grade service with ELEXON, but before placing
an order, the Participant will be contacted by the Service Provider to arrange for
installation of communications lines to the Participant’s site.
9.1.1 Information and Site Access
The information initially required by the Service Provider will include:
The exact termination point (specified down to the room) where the
communications lines and router are to be installed
Site contact details
Site access details, including timescales and any special requirements for
engineers accessing the Participant site
Specification of the lines and router required.
As described earlier in this document, the standard communications product supplied
to the Participant is a 2Mbps Leased Line with a 2Mbps 20:1 contended ADSL
backup, presented through a Cisco 2801 router.
The lead time for installation of this standard circuit is 55 working days, and the
order can only be placed with the communications supplier after technical details
have been confirmed. It is not necessary at this early stage for an IP schema to be
agreed, this can be planned during the order process.
Access to the BSC Central Services High Grade network can only be achieved
through the Service Provider, and the sole supplier used is Vodafone. Tails are
provided primarily by Vodafone and BT, but other tail providers may be used if the
need arises.
9.1.2 Features and Specifications
The standard Cisco 2801 router provided to the Participant is completely managed
through the Service Provider. The Participant cannot manage, login or configure the
router.
The Cisco 2801 router is rack mountable and only has provision for one power
supply (a dual powered router requires an upgrade to a much more costly model).
Page 38
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 38 of 45
The Service Provider supports delivery of service to the Ethernet port on the router
provided, but the Participant is responsible for keeping the router constantly powered
and in an appropriate environmental setting.
The network termination equipment provided for Frame Relay and ISDN lines varies
dependant upon line access speed and site requirements.
9.1.3 Planning an IP Schema
The BSC Central Services High Grade WAN primarily uses the 10.x.x.x RFC1918
private address space, and by default the LAN side of the router provided to the
Participant will be assigned a 24 bit masked (254 usable address) subnet on this
network, the first address of which will be reserved for the Ethernet port of the BSC
Central Services router.
The Service Provider is flexible to the needs of the Participant’s existing
network, and anticipates that it may need to conform to the Participant’s
existing IP schema. In this case a Participant defined IP schema will be used,
and the Service Provider will use Network Address Translation (NAT) on the
router that they provide.
The Service Provider will discuss IP schema selection and design with the
Participant when the High Grade order is placed, or may be contacted before this
point through the BSC Central Services helpdesk.
9.1.4 Firewall Configuration
The High Grade Participant should use the table below when planning the rulebase
for the firewall interfacing with the BSC Central Services router (Note that this is a
complete list of services. Network administrators should consult with those planning
to use the services, which of these are required):
Service Direction BSC Central Services IP Port
FTP Pull Outbound 10.1.1.20 TCP/21
FTP Push Inbound 10.1.1.21 & 10.1.1.22 TCP/21
FTP (Testing) Outbound 10.2.1.21 TCP/21
Tibco BMRS Outbound 10.1.1.31 TCP/7590
Time Sync Outbound 10.1.1.51/10.1.1.52 UDP/123
ECVAA Web Outbound 10.1.1.45 TCP/443
Note: Additional rulebase configuration may be required if the Participant intends to
access the Participant Test Service.
Page 39
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 39 of 45
9.1.5 Provision for BSC Central Services Disaster Recovery
If BSC Central Services invokes their Disaster Recovery plan, no action is required
by the High Grade Participant. If employed, the BSC Central Services Disaster
Recovery site will be address translated and presented to the Participant as if it were
the Live service site. No IP configuration or firewall rulebase changes are required
by the Participant.
9.2 Low Grade
Low Grade Participants provide their own internet connectivity in order to be able to
use the internet based Low Grade service. The following provisions should be made.
9.2.1 Firewall Configuration
The Low Grade Participant should use the table below when planning the rulebase
for the firewall interfacing with the internet (Note that this is a complete list of
services. Network administrators should consult with those planning to use the
services, which of these are required):
Service Direction BSC Central Services
Address
Port
FTP Pull Outbound ftp.bmreports.com TCP/21
FTP (Testing) Outbound ptsftp.bmreports.com TCP/21
Time Sync Outbound Participant’s Discretion UDP/123
BMRS Web Outbound http://www.bmreports.com TCP/80
ECVAA Web Outbound https://www.ecvaa.com TCP/443
ELEXON
Portal
Outbound https://www.elexonportal.co.uk TCP/443
BMRS API Outbound https://api.bmreports.com TCP/443
Note: Additional rulebase configuration may be required if the Participant intends to
access the Participant Test Service.
9.2.2 Provision for BSC Central Services Disaster Recovery
Wherever possible the Low Grade Participant should use the Fully Qualified Domain
Names (FQDNs) in the table above when configuring their software and connecting
to BSC Central Services.
Page 40
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 40 of 45
If BSC Central Services invoke their Disaster Recovery plan, the IP addresses of
these services will change, but the fully qualified names will map to the new IP
addresses.
The table below shows the normal IP address mappings for the fully qualified
domain names above, however the most reliable way of obtaining the correct IP
addresses is performing DNS queries on the FQDNs:
FQDN IP Address
www.bmreports.com 163.164.233.155
ftp.bmreports.com 163.164.233.162
www.ecvaa.com 163.164.233.168
www.elexonportal.co.uk 163.164.233.163
api.bmreports.com 163.164.233.156
Page 41
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 41 of 45
10 Summary Overview – Steps in the Comms Setup Process
This section briefly shows the steps that a Participant should plan for during the
comms setup process. They assume entry of a completely new Participant and do not
directly apply to other circumstances, such as addition of Participant IDs for existing
users.
Page 42
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 42 of 45
11 Service Desk
For further information relating to communications with the BSC Central Systems
please contact the BSC Service Desk on 0870 010 6950 or by email at
[email protected] .
Page 43
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 43 of 45
Appendix A - Schedule of Specified Communication Charges
This schedule sets out the rates of the High Grade Line Monthly Charges, TIBCO Set-up Charge and TIBCO Software Support Charge from 1 April 2017 until 31 March 2018 as determined by the Panel in
accordance with Sections 3.1(d), 3.1(e), 3.3 and 3.4 of Annex D-3 of the Code.
1 High Grade Line charges from 1 April 2017 until 31 March 2018
BSC Parties and non-BSC Parties (“Participants”) may choose from the following High Grade Service i
lines set out in the following table:
Technical Specification HG10 DR10
Primary Line Rental:
10Mb leased Line
2Mb ADSL
Backup Line Rental:
2Mb ADSL Backup
Support:
5 Hour Fix on Primary Line
24 Hour Fix on Primary Line
Primary Line Uncontended
Primary Line is Contended
One-off Costs:
Installation £4,208 £776
Ongoing Annual Costs:
Annual Rental (2017/18): £5,882 £2,440
Annual Support: (2017/18) £1,000 £1,000
Total Rental + Support
(2017/18) £6,882 £3,440
Table 1 – High Grade Line Monthly Charges (2017/18)
1.1 Disaster Recovery (“DR”) options set out in Table 1.1 above indicate that these
configurations shall usually be installed at DR sites and may not be installed without a High
Grade Service line.
1.2 The Code requires Participants to pay the Dataline Monthly Charge for a minimum of 12
months in accordance with Section 3.3(a) (ii) of Annex D-3 of the Code.
1.3 The Dataline Monthly Charge consists of:
i High Grade Service – means the provision of a communications capability between a BSC Service User and the BSC Central Systems using dedicated lines over a private WAN network.
Page 44
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 44 of 45
An Installation charge (which is charged as a one-off lump sum);
An Annual Rental charge (which is charged on an ongoing monthly basis); and
An Annual Support charge (which is also charged on an ongoing monthly basis).
1.4 If requested, ELEXON shall provide users with “non-standard‟ line configurations. These are not included in the standard menu of options shown in Table 1.1 above. Section 6 of Annex
D-3 of the Code allows ELEXON to charge Participants for the exact additional costs incurred from the BSC Central Services Agent to reflect the Installation charges, Annual Rental
charges and Annual Support charges for the non-standard configuration. The Installation charge is charged as a one-off lump sum. Any ongoing rental and support charges shall be
charged monthly whilst the service is used.
1.5 Please note that the standard menu of options in Table 1 does not cover the older suite of standard High Grade Line options which existing Participants may have previously opted for.
From 1 April 2017 only these two standard High Grade Line options can be selected by Participants.
1.1 Application of Indexation from 1 April 2018 until 31 March 2019 onwards
1.2.1 Installation charges and Annual Rental charges are fixed until 31 March 2018.
1.2.2 These charges shall be adjusted for indexation, using the Computer Economics Limited
Index (“CEL”) and the Retail Price Index (“RPI”) measures from 1 April of each year.
Page 45
Participant Guidance - Participant Communications Installation Guide (PCIG)
IF-00000018 / Definitive 12.5 24/10/17
IF-00000018 PARTICIPANT COMMS INSTALLATION GUIDE (PCIG) (V12 5)
page 45 of 45
2 TIBCO Charges
2.1 Options for Participants
2.1.1 Participants may obtain a High Grade Service line and support service from ELEXON without acquiring TIBCO Software Inc (“TIBCO”) Rendezvous software.
2.1.2 If Participants do require a licence to use the TIBCO Rendezvous software, it can be purchased from TIBCO through ELEXON (via the BSC Central Services Agent), however there
is no requirement to procure a licence to use the TIBCO Rendezvous software from ELEXON.
2.2 TIBCO Charging Methodology – TIBCO Set-up Charge
2.2.1 If Participants procure a licence to use the TIBCO Rendezvous software through ELEXON
they shall be charged at the prevailing TIBCO list price for the licence at the time the licence is procured. This will be levied as a one-off charge.
2.3 TIBCO Charging Methodology - TIBCO Software Support Charge
2.3.1 The TIBCO Software Support Charge for each TIBCO Rendezvous software licence procured by a Participant through ELEXON (via the BSC Central Services Agent) is subject to an
annual increase in line with the applicable TIBCO Indexation measure for the 12 month period immediately preceding the anniversary date of the maintenance and shall be charged
monthly.
Need more information?
For more information please contact the BSC Service Desk at [email protected] or call 0870
010 6950.
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.