Change Proposal CP1196 (Changes to incorporate Central Management Systems in Unmetered Supplies arrangements), formalised the use of a Central Management System (CMS) in conjunction with an Equivalent Meter (EM). The relevant CMS functional requirements and responsibilities being set out in BSCP520: Unmetered Supplies Registered in SMRS.CP1196 was implemented on 26 February 2008.

BSCP520 includes functional requirements and responsibilities that cover:

CMS data storage;
Provision of data to the MA and Unmetered Supplies Operator (UMSO);
Data validation and exception handling by the MA; and
Application of default data by the MA.

This Test Specification covers the CMS tests that are required to gain approval for use of a CMS, and the test evidence that should be provided to the BSCCo to demonstrate compliance with the requirements and responsibilities as per BSCP520.

1.2 Approval Process

All new CMS are required by BSCP520 to be approved by the Panel or its delegated authority, the Supplier Volume Allocation Group (SVG). The initial expression of an intention to apply for approval of the CMS is made to BSCCo. The applicant will need to appoint a CMS Test Agent (a Meter Administrator) approved by the BSCCo to witness the tests specified in this document and prepare a test evidence report in conjunction with the CMS Test Agent .The approval process is managed by the Unmetered Supply User Group (UMSUG) who will review the test evidence report against the requirements of BSCP520. The UMSUG then makes a recommendation to the SVG regarding approval of the CMS.

This Test Specification aims to provide guidance to applicants by summarising the CMS requirements (specified in BSCP520) in the Requirements Test Checklist (Section 5), along with the associated testing (Section 6) that is necessary in order to demonstrate compliance.

Approval is gained by running the specified tests in the presence of the CMS Test Agent; and the provision of a test evidence report by a CMS Manufacturer (supported by the CMS Test Agent) to the UMSUG and SVG. Once approved, the details of the new CMS will be added to an Approved Central Management System List maintained by BSCCo, and published on the BSC Website.

2. Understanding CMS Terminology

2.1 What is the difference between a Central Management System and a measured Central Management System (mCMS)?

As described in the introduction, Central Management Systems were first approved in 2008. Initially they were used to control lighting apparatus, latterly mCMS was introduced for equipment such as EV charging using measured feedback. In this document all the testing requirements apply equally to lighting CMS and measured mCMS unless specifically stated otherwise.

2.2 What are Unmetered Supplies under the BSC?

An Unmetered Supply (UMS) means a supply of electricity to a particular inventory of equipment in respect of which a Licensed Distribution System Operator (LDSO) has issued an Unmetered Supply Certificate. For example, this equipment could be any electrical equipment that draws a current and is connected to the Distribution Network without a meter recording its energy consumption, e.g. streetlights, traffic signals, zebra crossings, telecoms, etc.

2.3 What is the Unmetered Supplies Operator (UMSO)?

The UMSO is part of the LDSO also known as the Distribution Business or Network Operator (DNO). The UMSO is responsible for looking after all the Unmetered Supplies on its network and agrees with the Customer what equipment is suitable for treatment as an Unmetered Supply. Any equipment connected on an unmetered basis must be included in a detailed inventory supplied to the UMSO from the Customer’s asset database.

2.4 What is a detailed inventory?

As part of the agreement to provide Unmetered Supplies, Customers are required to submit an inventory to the UMSO that lists all of the equipment consuming energy. The format of an inventory can be found in the Operational Information Document published on the BSC Website. When equipment is CMS controlled the detailed inventory is summarised by the UMSO in a control file and supplied to the Meter Administrator to use in the HH energy calculations.

2.5 What is a Meter Administrator (MA)?

A Meter Administrator is a party undertaking a qualified Market Role for the processing of data for Unmetered Supplies. The MA is responsible for providing Half-Hourly (HH) consumption data into Settlement. This is the consumption of a particular Customer in kWh, for each half hour of every day. The Customer’s Supplier will appoint the MA in the industry’s registration system for Settlement purposes.

2.6 What is a CMS Test Agent?

A Meter Administrator approved to carry out the tests detailed in this test specification.

2.7 What are Charge Codes?

A Charge Code is simply a 13 digit number which represents a specific type of UMS equipment. It is used by UMSOs and MAs to look up the power value (known as circuit watts) associated with the equipment and calculate consumption. The percentage figures used in an Event Log are the percentage of the circuit watts allocated to the Charge Code. More information about Charge Codes and Switch Regime can be found on the BSC website (Charge Codes and Switch Regimes) and in the Operational Information Document.

2.8 What is a CMS Controller Charge Code?

A CMS Controller Charge Code is used to report the energy consumed by the CMS Control. Control Charge Codes follow the same approval process as other equipment connected on an unmetered basis and are reported in the customer’s detailed inventory. The Control Charge Code will have a circuit watt rating that reflects the power used by the control.

Some CMS can report the energy used by the control in the event log as a percentage of the Charge Code circuit watts for the controlled equipment. For example a CMS may be controlling a 50 watt lamp with a CMS control that consumes 1 watt continuously. For part of the night the lamp dims to 40 watts. The following percentage power levels will be reported in the Event Log against the CMS Unit Reference;

Night at full power 102.00
Night at dimmed power 82.00
Day (lamp off) 2.00

Where the CMS reports the control power in the Event Log, an application must be made for a Control Charge Code with a circuit watt rating of zero.

2.9 What are Switch Regimes?

Switch Regimes are three character alphanumeric codes that allow the operating hours for equipment to be determined. This information together with the power information obtained from the Charge Code allows consumption (kWh) to be calculated. The Switch Regime is a component of the detailed inventory submitted by the Customer to the UMSO. This is then used by the MA in the energy calculations.

The CMS Switch Regimes are;

990 – mCMS - EV charging
998 - CMS Controlled - Continuous Burning – Takes a permanent supply over 24 hours per day, which can be at different power levels.
999 - CMS Controlled - Switched Equipment – Supply is taken overnight, again can be at various power levels.

2.10 What is an Equivalent Meter (EM)?

An EM is the software used by the MA to calculate the Half-Hourly (HH) consumption data for Settlement.

2.11 What is a Sub-Meter?

A Sub-meter is a construct within the EM software that allows inventories of UMS data to be subdivided by customer, region or type of apparatus. For example; a customer that operates across two distribution regions would require a sub-meter identifier (id) for each region. Equally, two customers operating in the same distribution region would each require a sub-meter id to identify to which customer each set of inventory data pertains. A sub-meter could also be used to separate different types of apparatus. For example, a customer could have three sub-meters; one for CMS operated Highway Lighting, another for non-CMS operated Traffic signals, and another for mCMS EV charging Note that the mCMS sub-meter must be traded using a separate MPAN.

Each piece of apparatus (CMS Unit Reference) needs to be assigned Sub-Meter ID (used in the Event Log) and associated with the customer who is responsible for the unmetered supply. Test evidence must be provided explaining how this is achieved within the CMS. If a customer has apparatus in multiple distribution regions then a sub-meter ID is required for each region.

2.12 What is a CMS Unit Reference?

The CMS Unit Reference is a 12-digit alphanumeric field that acts as a unique identifier of the equipment under CMS control and to which the Charge Code and Switch Regime pertains. It is a requirement that the corresponding CMS Unit References are recorded in both the CMS and the Customer’s asset database. This is best achieved by using the Customer’s Asset ID, suitably “padded” to 12-digts if necessary. Using the Asset ID rather than the Control ID allows faulty controls to be replaced, without a change to the CMS Unit Reference and Control File. The Meter Administrator is obliged to issue a monthly exception list detailing CMS Unit References that appear in the customer’s control file that do not appear in the Event Logs output from the CMS. There are restrictions on the characters that can be used in the CMS Unit Reference, for example they cannot start with “H” or “T”. Full details are in BSCP520.

2.13 What is a Control File?

A control file is a list of all the equipment controlled by the CMS, listed by CMS Unit Reference and Charge Code. The UMSO creates the Control File using the detailed inventory supplied by the Customer that lists all the Customer’s unmetered equipment. The Control File is supplied to the MA as part of a data flow that is used by the MA in the energy calculations for the CMS sub-meter

2.14 What is an Event Log?

The Event Log is a file per Sub-Meter produced by the CMS that details the operational switching times and power levels for each unit and is made available to the MA daily. The log shall include the CMS Unit Reference, the time and date at which the load was switched and the power level expressed as a percentage of the full circuit watts of the Charge Code for the equipment. Each entry for a CMS Unit Reference in the Event Log for a day must have a unique time value expressed as HHMMSS. The format of the Event Log is specified in BSCP520.

2.15 What is Event Log Version control?

Each Event Log has a three digit version number in both its header record and file name. Version ‘001’ is the file produced each day and should contain records for each CMS Unit reference associated with the Sub-Meter Id. If any additional information becomes available for units after production of the Version ‘001’ Event Log (e.g. following a communication failure) on a subsequent day then a revised Event Log is required for those CMS Unit References where the data has changed.

The Version number for this Event Log should be incremented by ‘1’ (e.g. ‘002’) every time revised data becomes available.

The revised Event Log only requires events for CMS Unit references where the data has changed but must contain all events for those CMS Unit Reference for the day to which the Event Log pertains.

Each time revised data is obtained for CMS Unit References relating to a sub-meter an updated version of the Event Log is required.

For the avoidance of doubt, this means that a Version ‘002’ may be produced for one CMS Unit Reference for which data has been recovered and then followed by Version ‘003’ for another CMS unit reference if the data is recovered after production of Version ‘002’ (and so on for further updates). All the final versions of an Event Log for that day must be made available to the MA.

2.16 How is percentage power reported in an Event Log?

Equipment approved for connection on an unmetered basis is allocated a Charge Code as described earlier. The percentage power figure reported in an unmetered is the percentage of the circuit watts allocated to the Charge Code for the equipment under control by the CMS. For example a 100 watt lamp dimmed to a 66 watt power requirement, would have a power percentage of 066.00 reported in the Event Log.

An electric vehicle charging point controlled by mCMS has a single Charge Code with a circuit watt rating of 1,000 watts. If a charging point was providing a supply of say 5,000 watts, the power percentage reported in the Event Log would be 500.00.

3 Test Approach, Environment and Data Requirements

The CMS system functional requirements and responsibilities (as per BSCP520) have been mapped to System Requirement Test Checklists (Section 5). These Checklists will be used by the CMS Test Agent to ensure that the applicant has demonstrated compliance with all CMS and MA system requirements listed in BSCP520.

Each test requirement has been given a test reference number, which can be traced back where applicable, to the relevant requirement in BSCP520. Test References have been grouped into Test Groups with a summary of the tests and evidence required for each Test Group given in the Test Group Summary (Section 6).

4 Key Test Scenarios for Central Management Systems

This section contains a high level summary of the key test scenarios included in the Test Group Summary (Section 6). This section does not contain an exhaustive list of all scenarios tested. The applicant is advised to analyse the testing requirements based on all scenarios listed in the Test Group Summary (Section 6).

The key CMS test scenarios shall include, but will not be limited to, the following:

Data security measures;
Synchronisation to Universal Time Clock (UTC);
The recording of Inventory and Equipment control information;
The interface between the CMS and the Customer’s asset database;
The recording of operational switching times and power levels in line with the CMS instructions processed;
Provision of the necessary volume and performance test evidence, to provide assurance that the CMS can meet operational timescales;
The technical details of the measurement device to be used;
The generation and making available of Operational Event Logs in the specified format that when processed by an EM will allocate energy accurately to the half hourly period when it was used; and

Testing in line with the scenarios detailed below (Scenarios in 4.1 below apply to lighting CMS, scenarios in 4.2 apply to mCMS).Test Scenarios for Central Management Systems used to control lighting

4.1 Test Scenarios for Central Management Systems used to control lighting

4.1.1 Scenario 1 – Switch Regime 999

Scenario 1 covers an unmetered supply, (CMS Unit Reference) with a switch regime of 999 for switched operation in the hours of darkness. The test coverage will encompass dimming in half hour increments as specified in the table below. The Unmetered Supply should be switched on and off by the CMS control.

Event	Time On/Off	% Full Power (Circuit Watts)	Duration
1	On by lux level or by programmed event	100%	30 min
2	After 30 min	75%	For 90 min
3	After 90 min	50%	For 60 min
4	After 60 min	75%	For 120 min
5	After 120 min	100%	Till Dawn
6	Off by lux level or by programmed event.	0%	Off

4.1.2 Scenario 2 – Switch Regime 998

Scenario 2 covers an unmetered supply (CMS Unit Reference) with a switch regime of 998 for an unswitched supply (continuous operation). The unmetered supply should be running at full load and the test must demonstrate that the device is already on, even though the full power instruction will have been given (a few days ago) in the past and is being recorded as such.

Event	Time On/Off	% Full Power (Circuit Watts)	Duration
1	Continuous burning	100%	Continuous

Event

Time On/Off

% Full Power

(Circuit Watts)

Duration

Continuous burning

100%

Continuous

In the circumstance that the CMS under test is unable to process the number of events in a 24 hour period, the scenarios will be agreed between the applicant and the CMS Test Agent and explained in the test evidence report

4.1.3 Scenario 3 – Control Failure for Multiple CMS Unit References

The applicant should simulate control failures where the CMS System has not communicated with a number of CMS controls and is unable to record and report the power level for the unmetered equipment being switched by those controls.

The coverage required is:

unmetered supply for a single Settlement Day with a Switch Regime of 999;
unmetered supply for a single Settlement Day with a Switch Regime of 998;
unmetered supply for a range of Settlement Days with a Switch Regime of 999; and
unmetered supply for a range of Settlement Days with a Switch Regime of 998.

The unmetered supply CMS Unit Reference should be recorded on the CMS database and included in an operational event log. The failure may be noted by use of an information flag.

4.1.4 Scenario 4 – Revised Data after Control Failure (following day)

The applicant should demonstrate that data can be revised the next day for a previous control failure (Scenario 4.3). The revised data is reported by issuing an incremental Event Log.

The incremental Event Log should cover:

Previously unknown data; and
Data which has been amended.

Note; The incremental Event Log must be a complete set of data for each control for the day including any previously reported valid data.

4.2 Test Scenarios for measured Central Management Systems

4.2.1 Scenario 1 – On and Off test

To start with the Apparatus should be in an off state, then connected and drawing a steady load for over an hour. It should then be disconnected before midnight, the events should be stored within the mCMS and an Event Log produced that demonstrates the on/off switching times and the percentage power across the duration of the events. The duration between the connection and dis-connection event should be at least one hour.

This test is designed to check that the Event Log will report percentages of power correctly timed to enable accurate energy consumption calculations allocated to the correct half-hour settlement period by the Equivalent Meter.

4.2.2 Scenario 2 – Two Events with Disconnection in Between

This scenario involves two events where the Apparatus is disconnected in between.

The Apparatus should be in an off state to start with, then connected and draw a steady load for at least a half hour. It should then be disconnected and stay off for an hour, before being reconnected and drawing a load for a further half hour. Finally it should be disconnected before midnight. As with the previous test this should result in an Event Log that enables correct energy consumption calculations allocated to the relevant half-hour settlement periods by the Equivalent Meter.

If the Apparatus has a configurable load, a scenario with variable load will be agreed with the CMS Test Agent. The duration of between the connection and dis-connection events should be at least one hour with a minimum of 1 hour between both events.

NB Scenario 2 should be repeated and used as the communications failure model in Scenario 6.

4.2.3 Scenario 3 – No Connection, No Consumption

The Apparatus should not be connected for an entire day. The applicant must demonstrate that when no Apparatus is connected a zero percentage event is produced in the Event Log.

4.2.4 Scenario 4 – Connection, No Consumption

The Apparatus should be connected for an entire day but not consuming power. The applicant must demonstrate that when the Apparatus is connected but consuming zero power, that a zero event is produced in the Event Log.

Note; If the CMS reports energy consumed by the control, the percentage power reported in the Event Log must be for the control only.

4.2.5 Scenario 5 – Consumption Over Midnight

In this scenario the Apparatus is connected and consuming power before midnight and continues to consumer power over the midnight boundary into the next day. The applicant must demonstrate that the Apparatus is still connected at midnight and records the correct event data, even though the consumption occurred the previous day. This test will require two Event Logs spanning the two consecutive days.

4.2.6 Scenario 6 – Communications Failure

The applicant must demonstrate that an accurate Event Log is maintained if there is a communications failure during part or all of the day. This test scenario is a repeat of Scenario 2 with a communications failure simulated where the measured mCMS is unable to record and report power levels recorded during the entirety of the second event.

This test is designed to confirm that only the first consumption event (before the communications failure) is included in the initial Event Log. Once communications have been restored, a subsequent Event Log should be produced showing both consumption periods for the test day.

5. Requirements Test Checklist

This section provides a checklist of CMS and MA System requirements. The applicant is expected to comply with these system requirements for approval as a Central Management System.

Where applicable each requirement has been allocated the appropriate BSCP520 reference.

Test references have been grouped into Test Groups with a summary of the tests and evidence required for each Test Group given in the Test Group Summary (Section 6). Note that Test Groups 1-7 & 11-12 apply to Lighting CMS and Test Groups 1-5, 8-10 & 11-12 apply to mCMS.

It should be noted that the Test Group Summary provides a guideline only. It is the CMS Test Agent’s responsibility to perform the appropriate tests in order to demonstrate compliance with all relevant system requirements.

The CMS Test Agent will use the Test Checklist to monitor compliance of each requirement.

5.1 System Requirements

Test Ref	Requirement / Details	Requirement Reference	Comment	Complies
Test Group 1	Configuration Control
Test 1.1	CMS software version	Non-functional
Test 1.2	CMS operating platform and version	Non-functional
Test Group 2	System Security
Test 2.1	Customers	4.6.3.3
Test 2.2	MA	Functional
Test Group 3	Synchronisation to UTC	4.6.3.3 (i)

5.2 Data Input and Storage Requirements

Test Ref	Requirement / Details	Requirement Reference	Comment	Complies
Test Group 4a	Detailed Inventory information
Test 4.1	Add, delete, modify manually or electronically:	Functional
Test 4.1.1	Road Reference	Functional
Test 4.1.2	Town, Parish, District	Functional
Test 4.1.3	Road Name	Functional
Test 4.1.4	Location	Functional
Test 4.1.5	Unit Type	Functional
Test 4.1.6	Unit Identity	Functional
Test 4.1.7	CMS Unit Reference	Functional
Test 4.1.8	Charge Code	Functional
Test 4.1.9	Number of Items	Functional
Test 4.1.10	Switch Regime	Functional
Test 4.1.11	Number of Controls	Functional
Test 4.1.12	Control Charge Code	Functional
Test 4.1.13	Ordinance Survey Grid ref ‘East’ or Latitude	Functional
Test 4.1.14	Ordinance Survey Grid ref ‘North’ or Longitude	Functional
Test 4.1.15	Exit Point	Functional
Test 4.1.16	Distributor	Functional
Test 4.1.17	Sub-meter	Functional
Test 4.2	Audit Trail	Functional
Test Group 4b	Inventory control information
Test 4.3	Add, delete, modify manually or electronically:	Functional
Test 4.3.1	Sub-Meter ID	Functional
Test 4.3.2	Effective From Date	Functional
Test 4.3.3	CMS Unit Reference	Functional
Test 4.3.4	Number of Items	Functional
Test 4.3.5	Switch Regime	Functional
Test 4.3.6	Charge Code	Functional
Test 4.4	Audit Trail	Functional

5.3 Process Requirements

Test Ref	Requirement / Details	Requirement Reference	Comment	Complies
Test Group 5	Lighting CMS - Issue Instructions		Where events are driven by CMS programming
Test 5.1	Scenario 1 - Switch Regime 999	4.6.3.3 (b)
Test 5.2	Scenario 2 - Switch Regime 998	4.6.3.3 (b)
Test 5.3	Scenario 3 - Control Failure	4.6.3.3 (b)
Test 5.4	Scenario 4 – Revised Data after control failure (following day)	4.6.3.3 (b) 4.6.3.3 (c)
Test 5.5	Receive Response (optional)	Functional
Test Group 6	Lighting CMS - Record operational switching times and power levels		Where events are driven by CMS programming
Test 6.1	Scenario 1 - Switch Regime 999	4.6.3.3 (b)
Test 6.2	Scenario 2 - Switch Regime 998	4.6.3.3 (b) 4.6.3.3 (c)
Test 6.3	Scenario 3 - Control Failure	4.6.3.3 (b) 4.6.3.3 (c)
Test 6.4	Scenario 4 – Revised Data after control failure (following day)	4.6.3.3 (b) 4.6.3.3 (c)
Test 6.5	Audit Trail	4.6.3.3 (h)
Test Group 7	Lighting CMS - Generate Operational Event Log		Where events are driven by CMS programming
Test 7.1	Scenario 1 - Switch Regime 999	4.6.3.3 (b) 4.6.3.3 (c)
Test 7.2	Scenario 2 - Switch Regime 998	4.6.3.3 (b) 4.6.3.3 (c)
Test 7.3	Scenario 3 - Control Failure	4.6.3.3 (b) 4.6.3.3 (c)
Test 7.4	Scenario 4 – Revised Data after control failure (following day)	4.6.3.3 (b)
Test 7.5	Available daily (Separate CMS and MA System)	4.6.3.3 (b)
Test 7.6	On Request (Integrated CMS and MA System)	4.6.3.3 (c)
Test 7.7	Audit Trail	4.6.3.3 (h)
Test Group 8	mCMS - Event Driven Measurement		Where events are driven by the connection of Apparatus to an exit point
Test 8.1	Scenario 1	4.6.3.3
Test 8.2	Scenario 2	4.6.3.3
Test 8.3	Scenario 3	4.6.3.3
Test 8.4	Scenario 4	4.6.3.3
Test 8.5	Scenario 5	4.6.3.3
Test 8.6	Scenario 6	4.6.3.3
Test Group 9	mCMS - Record operational switching times and power levels		Events and power levels should be available via a user interface to the mCMS
Test 9.1	Record operational switching times for Scenarios 1 to 6	4.6.3.3 (b) 4.6.3.3 (c)
Test 9.2	Audit Trail	4.6.3.3 (h)
Test Group 10	mCMS - Generate Operational Event Log		Generate events for each scenario
Test 10.1	Scenario 1	4.6.3.3
Test 10.2	Scenario 2	4.6.3.3
Test 10.3	Scenario 3	4.6.3.3
Test 10.4	Scenario 4	4.6.3.3
Test 10.5	Scenario 5	4.6.3.3
Test 10.6	Scenario 6	4.6.3.3
Test 10.7	Available daily and on request	4.6.3.3 (b) 4.6.3.3 (c)	Evidence the MA can get the file daily and on request
Test 10.8	Audit Trail	4.6.3.3 (h)
Test Group 11	Volume and Performance
Test 11.1	Compliance with operational timescales	Functional

5.4 Data Output Requirements

Test Ref	Requirement / Details	Requirement Reference	Comment	Complies
Test Group 12	Operational Event Log
Test 12.1	File Format	4.6.3.3 (c)
Test 12.2	Filename	4.6.3.3 (c)
Test 12.3	Header identifier	4.6.3.3 (c)
Test 12.4	Sub-Meter ID	4.6.3.3 (c)
Test 12.5	Date	4.6.3.3 (c)
Test 12.6	Version	4.6.3.3 (c)
Test 12.7	CMS Unit reference	4.6.3.3 (c)
Test 12.8	Time	4.6.3.3 (c)
Test 12.10	Percentage of base power	4.6.3.3 (c)
Test 12.10	Information Flag	4.6.3.3 (c)
Test 12.11	Trailer	4.6.3.3 (c)

6. Test Group Summary

This section provides a guideline to the testing that should be performed and the test evidence that should be secured to demonstrate compliance with the Central Management System requirements as per the Requirements Checklist (Section 5).

Approval as a Central Management System would be demonstrated by the provision of test evidence to the UMSUG and SVG, gained in the process of running the tests specified in this section.

It should be noted that it is the applicant’s responsibility to employ a CMS Test Agent to perform the appropriate tests confirming compliance of all relevant system requirements.

The applicant should secure test evidence in the format specified in Section 7.

Test Group Ref	Test Requirement Overview	Test Evidence Overview
Test Group 1	System Configuration The CMS Test Agent should confirm the software versioning and operating platforms that will be subject to approval.	Evidence that the software and operating platform is subject to version control
Test Group 2	Security The CMS System test agent should confirm the procedures which provide secure access to data. Operators should only be able to access data which is relevant to them. Secure access procedures should be demonstrated for Customers and Meter Administrators	Evidence that data is secure and that only relevant data can be accessed by the appropriate participant.
Test Group 3	Synchronisation to UTC The CMS System test agent should confirm that the CMS System is synchronised to UTC, either by connection to internet time servers or a radio clock, and are accurate to within ± 20 seconds per month.	Evidence that the CMS System is synchronised to UTC within ± 20 seconds per month.
Test Group 4	Inventory control information The CMS System test agent should confirm the processes for addition, modification and deletion of Inventory Control information required for the key test scenarios specified in Section 4, either manually or electronically. The Data subject to testing is: Sub-Meter ID Effective From Data CMS Unit Reference Number of Items Charge Code There is also a detailed inventory test to confirm that it is input, stored and amended correctly with an appropriate audit trail. The methodology for ensuring that there is a process to synchronise the details held in the CMS and the Customer’s detailed inventory (asset database), in particular how CMS Unit References are linked should be described. This must also confirm that where the CMS is operates in more than one Distribution Area, inventory information is assigned to the correct sub-meter ID. The operator of the MA System should demonstrate the recording of the audit trail for the entries made above.	Evidence is required that; The Data is held within the CMS Amendments to the Data should be demonstrated to the CMS Test Agent Details of the methodology for synchronising Data between the CMS and the Customer’s asset database.
Test Group 5 Lighting CMS	CMS Issue Instructions The operator of the CMS System should demonstrate the issuing of operational switching times and power level instructions for CMS Units in the CMS System for the following scenarios: Scenario 1 – Switch Regime 999; Scenario 2 – Switch Regime 998; Scenario 3 – Control Failure (no data for a CMS Unit); Scenario 4 - Revised Data after control failure (following day). Details of the scenarios subject to testing are given in Section 4. If applicable a response should be received indicating that the instruction has been successful or unsuccessful.	Evidence that the instructions were successful, except for the control failure where the necessary business processes or local working instruction were followed showing the operational procedures taken for fault correction to allow for a revised instruction the following day. If applicable, evidence that the response to the instructions is correct.
Test Group 6 Lighting CMS	Record operational switching times and power levels The operator of the CMS System should demonstrate the recording of operational switching times and power levels for CMS Units in the CMS System for the following scenarios: Scenario 1 – Switch Regime 999; Scenario 2 – Switch Regime 998; Scenario 3 – Control Failure (no data for a CMS Unit); Scenario 4 - Revised Data after control failure (following day) Details of the scenarios subject to testing are given in Section 4. The operator of the CMS System should demonstrate the audit trail for the above scenarios.	Evidence that the data recorded is correctly in the CMS Evidence that the audit trail is correct.
Test Group 7 Lighting CMS	Generate Operational Event Log - normal processing and control failure The operator of the CMS System should demonstrate: The sending of a daily operational Event Logs ( with operational switching times and power levels for specified CMS Units to the MA in the specified format for the following scenarios: Scenario 1 – Switch Regime 999; Scenario 2 – Switch Regime 998; Scenario 3 – Control Failure (no data for a CMS Unit); Scenario 4 - Revised Data after control failure (following day) The operator of the CMS system should demonstrate a control failure (no data for a CMS Unit) through use of the correct information flag as per Scenario 3. Operational Event Log – revision to previously reported data The operator of the CMS System should demonstrate that data can be revised by issuing an incremental operational Event Log to the MA in the specified format. (Scenario 3) The incremental Event Log should cover: An incremental update of operational Event Log which includes previously unknown data; An incremental update of operational Event Log which includes data which has been amended. Details of the scenarios subject to testing are given in Section 4 The operator should demonstrate that the operational Event Log has been retained for audit purposes and the audit trail is correct.	Evidence that: The operational Event Logs have been successfully created; The operational Event Log values are correct; The operational Event Logs are sent on a daily basis The operation Event Logs are in the specified file format (See Test Group 12) The operational Event Log headers correctly identify the Event Log version where incremental Event Logs have been created The audit trail is correct and the operational Event Logs have been retained for audit purposes
Test Group 8 mCMS	mCMS Event Driven Measurement The operator of the mCMS should demonstrate event driven measurement of operational switching times and recorded power consumption for mCMS Units in the mCMS for the Scenarios 1 to 6. Details of the scenarios subject to testing are given in Section 4. If applicable a measurement should be produced indicating that there has been connection/disconnection or change in power level.	Evidence that the measurements were successful in the response of an event, except for the control failure where the necessary business processes or local working instruction were followed showing the operational procedures taken for fault correction to allow for revised measurements the following days. If applicable, evidence that the measurement in response to the event is correct.
Test Group 9 mCMS	Record operational switching times and power levels The operator of the mCMS should demonstrate the recording of operational switching times and power levels for mCMS Units in the mCMS for the Scenarios 1 to 6. Details of the scenarios subject to testing are given in Section 4. The operator of the mCMS should demonstrate the audit trail for the above scenarios.	Evidence that the data recorded is correctly in the mCMS; Evidence that the audit trail is correct
Test Group 10 mCMS	Generate Operational Event Log - normal processing and communications failure The operator of the mCMS should demonstrate that the daily operational Event Logs of the operational switching times and power levels for specified mCMS are able to be downloaded by the MA in the specified format for the Scenarios 1 to 6. The operator of the mCMS should demonstrate a communications failure (no data for a mCMS Unit). Operational Event Log – revision to previously reported data The operator of the mCMS should demonstrate that data can be revised by either issuing an incremental operational Event Log in the specified format (Scenario 6). The incremental Event Log should cover: An incremental update of operational Event Log which includes previously unknown data; An incremental update of operational Event Log which includes data which has been amended. Details of the scenarios subject to testing are given in Section 4 The mCMS operator should demonstrate that the operational Event Logs can be produced for the Scenarios above for audit and testing purposes.	Evidence that: The operational Event Logs have been successfully created; The operational Event Log values are correct; The operational Event Logs are sent on a daily basis The operation Event Logs are in the specified file format (See Test Group 12) The operational Event Log headers correctly identify the Event Log version where incremental Event Logs have been created The audit trail is correct and the operational Event Logs have been retained for audit purposes
Test Group 11	Volume and Performance The operator of the CMS System should provide tests evidence of volume and performance tests completed by the applicant as part of their system testing, to the CMS Test Agent so that compliance with operational timescales can be accessed.	Evidence of volume and performance tests provided to the CMS Test Agent.
Test Group 12	Operational Event Log – File format The operator of the CMS System should demonstrate that the operational event logs are in the specified format as per BSCP520 Section 4.5.2.3(c).	Evidence that the operational Event Logs are in the correct format including the Filename, Trailer and the following key data fields: Header identifier Sub-Meter ID Date Version CMS Unit reference Time Percentage of base power Information Flag Each CMS Unit Reference has a different time (HHMMSS) reported for each entry

Test Group Ref

Test Requirement Overview

Test Evidence Overview

Test Group 1

System Configuration

The CMS Test Agent should confirm the software versioning and operating platforms that will be subject to approval.

Evidence that the software and operating platform is subject to version control

Test Group 2

Security

The CMS System test agent should confirm the procedures which provide secure access to data. Operators should only be able to access data which is relevant to them. Secure access procedures should be demonstrated for Customers and Meter Administrators

Evidence that data is secure and that only relevant data can be accessed by the appropriate participant.

Test Group 3

Synchronisation to UTC

The CMS System test agent should confirm that the CMS System is synchronised to UTC, either by connection to internet time servers or a radio clock, and are accurate to within ± 20 seconds per month.

Evidence that the CMS System is synchronised to UTC within ± 20 seconds per month.

Test Group 4

Inventory control information

The CMS System test agent should confirm the processes for addition, modification and deletion of Inventory Control information required for the key test scenarios specified in Section 4, either manually or electronically.

The Data subject to testing is:

Sub-Meter ID
Effective From Data
CMS Unit Reference
Number of Items
Charge Code

There is also a detailed inventory test to confirm that it is input, stored and amended correctly with an appropriate audit trail.

The methodology for ensuring that there is a process to synchronise the details held in the CMS and the Customer’s detailed inventory (asset database), in particular how CMS Unit References are linked should be described.

This must also confirm that where the CMS is operates in more than one Distribution Area, inventory information is assigned to the correct sub-meter ID.

The operator of the MA System should demonstrate the recording of the audit trail for the entries made above.

Evidence is required that;

The Data is held within the CMS
Amendments to the Data should be demonstrated to the CMS Test Agent

Details of the methodology for synchronising Data between the CMS and the Customer’s asset database.

Test Group 5

Lighting CMS

CMS Issue Instructions

The operator of the CMS System should demonstrate the issuing of operational switching times and power level instructions for CMS Units in the CMS System for the following scenarios:

Scenario 1 – Switch Regime 999;
Scenario 2 – Switch Regime 998;
Scenario 3 – Control Failure (no data for a CMS Unit);
Scenario 4 - Revised Data after control failure (following day).

Details of the scenarios subject to testing are given in Section 4.

If applicable a response should be received indicating that the instruction has

been successful or unsuccessful.

Evidence that the instructions were successful, except for the control failure where the necessary business processes or local working instruction were followed showing the operational procedures taken for fault correction to allow for a revised instruction the following day.
If applicable, evidence that the response to the instructions is correct.

Test Group 6 Lighting CMS

Record operational switching times and power levels

The operator of the CMS System should demonstrate the recording of operational switching times and power levels for CMS Units in the CMS System for the following scenarios:

Scenario 1 – Switch Regime 999;
Scenario 2 – Switch Regime 998;
Scenario 3 – Control Failure (no data for a CMS Unit);
Scenario 4 - Revised Data after control failure (following day)

Details of the scenarios subject to testing are given in Section 4.

The operator of the CMS System should demonstrate the audit trail for the above

scenarios.

Evidence that the data recorded is correctly in the CMS
Evidence that the audit trail is correct.

Test Group 7

Lighting CMS

Generate Operational Event Log - normal processing and control failure

The operator of the CMS System should demonstrate:

The sending of a daily operational Event Logs ( with operational switching times and power levels for specified CMS Units to the MA in the specified format for the following scenarios:

Scenario 1 – Switch Regime 999;
Scenario 2 – Switch Regime 998;
Scenario 3 – Control Failure (no data for a CMS Unit);
Scenario 4 - Revised Data after control failure (following day)

The operator of the CMS system should demonstrate a control failure (no data for a CMS Unit) through use of the correct information flag as per Scenario 3.

Operational Event Log – revision to previously reported data

The operator of the CMS System should demonstrate that data can be revised by issuing an incremental operational Event Log to the MA in the specified format. (Scenario 3) The incremental Event Log should cover:

An incremental update of operational Event Log which includes previously unknown data;
An incremental update of operational Event Log which includes data which has been amended.

Details of the scenarios subject to testing are given in Section 4

The operator should demonstrate that the operational Event Log has been retained for audit purposes and the audit trail is correct.

Evidence that:

The operational Event Logs have been successfully created;
The operational Event Log values are correct;
The operational Event Logs are sent on a daily basis
The operation Event Logs are in the specified file format (See Test Group 12)
The operational Event Log headers correctly identify the Event Log version where incremental Event Logs have been created

The audit trail is correct and the operational Event Logs have been retained for audit purposes

Test Group 8

mCMS

mCMS Event Driven Measurement

The operator of the mCMS should demonstrate event driven measurement of operational switching times and recorded power consumption for mCMS Units in the mCMS for the Scenarios 1 to 6.

Details of the scenarios subject to testing are given in Section 4.

If applicable a measurement should be produced indicating that there has been connection/disconnection or change in power level.

Evidence that the measurements were successful in the response of an event, except for the control failure where the necessary business processes or local working instruction were followed showing the operational procedures taken for fault correction to allow for revised measurements the following days.

If applicable, evidence that the measurement in response to the event is correct.

Test Group 9

mCMS

Record operational switching times and power levels

The operator of the mCMS should demonstrate the recording of operational switching times and power levels for mCMS Units in the mCMS for the Scenarios 1 to 6.

Details of the scenarios subject to testing are given in Section 4.

The operator of the mCMS should demonstrate the audit trail for the above scenarios.

Evidence that the data recorded is correctly in the mCMS;
Evidence that the audit trail is correct

Test Group 10

mCMS

Generate Operational Event Log - normal processing and communications failure

The operator of the mCMS should demonstrate that the daily operational Event Logs of the operational switching times and power levels for specified mCMS are able to be downloaded by the MA in the specified format for the Scenarios 1 to 6.

The operator of the mCMS should demonstrate a communications failure (no data for a mCMS Unit).

Operational Event Log – revision to previously reported data

The operator of the mCMS should demonstrate that data can be revised by either issuing an incremental operational Event Log in the specified format (Scenario 6). The incremental Event Log should cover:

An incremental update of operational Event Log which includes previously unknown data;
An incremental update of operational Event Log which includes data

which has been amended.

Details of the scenarios subject to testing are given in Section 4

The mCMS operator should demonstrate that the operational Event Logs can be produced for the Scenarios above for audit and testing purposes.

Evidence that:

The operational Event Logs have been successfully created;
The operational Event Log values are correct;
The operational Event Logs are sent on a daily basis
The operation Event Logs are in the specified file format (See Test Group 12)
The operational Event Log headers correctly identify the Event Log version where incremental Event Logs have been created

The audit trail is correct and the operational Event Logs have been retained for audit purposes

Test Group 11

Volume and Performance

The operator of the CMS System should provide tests evidence of volume and performance tests completed by the applicant as part of their system testing, to the CMS Test Agent so that compliance with operational timescales can be accessed.

Evidence of volume and performance tests provided to the CMS Test Agent.

Test Group 12

Operational Event Log – File format

The operator of the CMS System should demonstrate that the operational event

logs are in the specified format as per BSCP520 Section 4.5.2.3(c).

Evidence that the operational Event Logs are in the correct format including the Filename, Trailer and the following key data fields:

Header identifier
Sub-Meter ID
Date
Version
CMS Unit reference
Time
Percentage of base power
Information Flag

Each CMS Unit Reference has a different time (HHMMSS) reported for each entry

7. Recording Test Results

It is the applicants’ responsibility for recording tests result in the format specified below. Evidence should be secured for each Test Reference listed in the Requirement Test Checklist (Section 5). Evidence guidelines are given for each Test Group in the Test Group Summary (Section 6). The applicant should capture evidence in accordance with these guidelines.

The following convention should be used for labelling evidence where possible:

For example, the reference CMS_Test Group2_250408_1_Test 2.3 should be recorded on the top of each piece of evidence associated with the following test:

Test System: Central Management System

Test Group: 2

Run Date: 25-04-2008

Run Number: 1

Test Ref: 2.3

Test to check the system security of the CMS for the Customer.

Appendix A – Terms used in this Document

Other acronyms and defined terms take the meanings defined in the Balancing and Settlement Code (the Code), Section X.

Acronym/Term	Definition
CMS	Central Management System
EM	Equivalent Meter
HHDC	Half Hourly Data Collector
MA	Meter Administrator
MOA	Meter Operator Agent
UMSO	Unmetered Supplies Operator
SVG	Supplier Volume Allocation Group
UMSUG	Unmetered Supply User Group

Need more information?

For more information please contact the BSC Service Desk or call 0370 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.

CONTENTS

Central Management System Equivalent Meter Test Specification

Purpose

1. Introduction

1.1 Scope

1.2 Approval Process

2. Understanding CMS Terminology

2.1 What is the difference between a Central Management System and a measured Central Management System (mCMS)?

2.2 What are Unmetered Supplies under the BSC?

2.3 What is the Unmetered Supplies Operator (UMSO)?

2.4 What is a detailed inventory?

2.5 What is a Meter Administrator (MA)?

2.6 What is a CMS Test Agent?

2.7 What are Charge Codes?

2.8 What is a CMS Controller Charge Code?

2.9 What are Switch Regimes?

2.10 What is an Equivalent Meter (EM)?

2.11 What is a Sub-Meter?

2.12 What is a CMS Unit Reference?

2.13 What is a Control File?

2.14 What is an Event Log?

2.15 What is Event Log Version control?

2.16 How is percentage power reported in an Event Log?

3 Test Approach, Environment and Data Requirements

4 Key Test Scenarios for Central Management Systems

4.1 Test Scenarios for Central Management Systems used to control lighting

4.1.1 Scenario 1 – Switch Regime 999

4.1.2 Scenario 2 – Switch Regime 998

4.1.3 Scenario 3 – Control Failure for Multiple CMS Unit References

4.1.4 Scenario 4 – Revised Data after Control Failure (following day)

4.2 Test Scenarios for measured Central Management Systems

4.2.1 Scenario 1 – On and Off test

4.2.2 Scenario 2 – Two Events with Disconnection in Between

4.2.3 Scenario 3 – No Connection, No Consumption

4.2.4 Scenario 4 – Connection, No Consumption

4.2.5 Scenario 5 – Consumption Over Midnight

4.2.6 Scenario 6 – Communications Failure

5. Requirements Test Checklist

5.1 System Requirements

5.2 Data Input and Storage Requirements

5.3 Process Requirements

5.4 Data Output Requirements

6. Test Group Summary

7. Recording Test Results

Appendix A – Terms used in this Document

Need more information?