Central Management Systems Manufacturers

v 5.0
Effective From Date:
Status:LIVE
Other versions
Download

Central Management Systems - Manufacturers

Guidance Note

This guidance note is to help you as a manufacturer gain approval for your CMS. We explain the technical considerations and steps you need to take to get your CMS approved.

Introducing CMS

Central Management Systems, also known as telemanagement, are the next step in remote dynamic street lighting control. Using a CMS the operator can choose exactly when to switch each individual street light on or off and/or by how much to reduce the lamp power. This allows any number of switching events and/or dimming levels. There are also other benefits such as lamp monitoring etc.

What are the Main Roles and Key Terms You’ll Encounter?

Dynamic Data: This is data which uses the actual switching times of a representative sample of photocells contained in a Photoelectric Control Unit (PECU) array. The data recorded by a CMS is also dynamic data, as the actual events recorded are used in the calculation of consumption.

Currently customers can trade their electricity in two ways, either Non Half Hourly or Half Hourly. The main difference between the two is the use of dynamic data.

Half-Hourly (HH): HH data is the energy consumption of a customer in kWh, for each half hour of every day. In order to trade HH a Meter Administrator must be appointed.

Non-Half-Hourly (NHH): NHH does not use any dynamic data and instead uses an estimated number of annual hours for each switch regime. Customers trading NHH cannot take advantage of dynamic data.

Meter Administrator (MA): is the qualified agent who provides the Half-Hourly consumption data into Settlement through their Equivalent Meter (EM). They manage PECU arrays and process CMS data.

Equivalent Meter (EM): the software used by an MA calculate and then pass the consumption information into Settlement. Suppliers use this information when calculating customers’ energy bills.

CMS Test Agent: is a MA appointed to carry out testing of a CMS in accordance with the relevant test specification.

Customer: any organisation which purchases and operates an unmetered CMS in Great Britain. It maintains a detailed inventory of all its Unmetered Supply (UMS) equipment and provides regular updates to its Unmetered Supplies Operator (UMSO). The customer also appoints an MA.

Unmetered Supplies Operator (UMSO): is a role within the Distribution Business that is responsible for looking after all of the Unmetered Supplies on its Network. It makes new connections and decides what equipment is suitable for use as an Unmetered Supply. The UMSO provides a UMS inventory to the MA.

CMS Manufacturer: the developer/manufacturer (or licensed distributor) of any Central Management System.

Detailed Inventory: is a complete list of all the Unmetered Supplies that a customer is responsible for. The suggested format is defined in the Operational Information Document. It includes the unique CMS Unit Reference which is the key to the events received in the Event Log File.

Overview of Unmetered Supplies Arrangements and CMS

Below is a simplified view of the interactions and data flows between the parties involved in Unmetered Supplies for CMS and non-CMS interactions.

complex image of process

What is the Approval Process?

A CMS needs the following approvals under the Balancing and Settlement Code (BSC) Unmetered Supplies arrangements:

    1. The applicant needs to contact Elexon to express its intention to apply for approval of a new CMS.

    2. The applicant will then need to appoint a CMS Test Agent (a Meter Administrator) approved to witness the tests specified in the CMS Equivalent Meter Test Specification and prepare a test evidence report in conjunction with the CMS Test Agent. The 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.

    1. 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 Unmetered Supply User Group (UMSUG) and Supplier Volume Allocation Group (SVG).

    1. The UMSUG 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. All new CMS are required to be approved by the SVG.

    1. Once approved , the details of the new CMS will be added to an approved CMS list maintained by Elexon and published on the BSC Website.

What Else Should Customers Do?

If a customer trades NHH they must contact their Unmetered Supplies Operator (UMSO) to discuss switching to HH and then appoint a CMS Capable MA.

If a CMS uses mains-borne signalling, the Customer must seek the agreement of the UMSO to use it. BSC approval of a CMS (using mains-borne signalling) does not give the Customer a right to transmit signals over the local electricity Distribution Network.

If you have any questions about this aspect of the approval process, please contact the CMS Coordinator at Elexon. We can then put you in contact with the relevant UMSO.

What is the Event Log?

The CMS records the operational on/off switching times and the power levels for each unit. This should be made available to the MA in an operational event log, typically every day.

The event log includes the CMS Unit Reference, the time and date at which the load was switched, and the power level. The power level is expressed as a percentage of the circuit watts. The Operational Information Document defines this for the relevant Charge Code.

Structure of the CMS Event Log File:

complex image of process

The information flag ‘I’ in the file body can provide further information about the operational event log data , for example, omissions, errors, and so on. The BSC does not currently prescribe values for this information flag, so CMS manufacturers and Mas can agree on and specify its use and structure.

How Should Revisions to Event Data be recorded?

The CMS records significant or material events – any system instruction that results in changes to the power the lamp consumes – for example, on/off, full power/dimmed power, and so on. Minor consumption changes such as an increase from 79.99% to 80.00% should not be recorded as an event. Recording such minor events may result in thousands of events per lamp per day.

The upper limit for updating event data is 4 months. Operationally, we do not expect that data will be updated past 28 days. MAs and CMS operators will agree any updates beyond 28 days.

Any revision to previous data or unreported data shall be reported in a file with an incremental version number. This may occur after repairing a fault or re-establishing communications and must contain all of the events for the affected asset, not just previously unreported events. Alternatively, it will be a complete refresh of the file. The CMS operator and the MA will agree the approach, and how to identify updated information.

What is a Sub Meter ID?

Using a sub meter allows customers to split their inventory. Consider a county which has CMS equipment and non CMS equipment on their inventory. Its Meter Administrator must calculate the load separately because of the different processes involved but will combine the results for the Data Collector and Supplier. The MA sums the total energy of each sub meter onto a single MPAN and the Supplier sends a single invoice to the customer.

The diagram below shows how the Meter Administrator’s Equivalent Meter software will link customers’ CMS and non-CMS inventory.

complex image of process

The MA, UMSO and CMS operator will agree the sub meter ID in the CMS, so it should be a configurable item.

HH data must be assigned to unique MPANs for each Distribution area. This applies even where the same Distribution Business manages two different Distribution areas. If a customer covers two different Distribution areas, they must use separate MPANs for each area. In this instance, the MA cannot aggregate the resulting HH data onto a single MPAN.

What are the Requirements for an Audit Trail?

Under a generic BSC requirement, the CMS must record an audit trail. Party Service Line 100: Generic Non Functional Requirements For Licensed Distribution System Operators and Party Agents requires that the system must hold data for at least 40 months after the Settlement Day.

This consists of:

    • The first 28 months of Settlement data must be able to support a Volume Allocation Run. Practically, this means that the data is available to the Meter Administrator upon request; and

    • The remaining 2 months of Settlement can be supplied within 0 Business Days if requested.

Need more information?

References

We have published the full documents which this guidance summarises and clarifies information on the BSC Website. The BSC takes precedence over this guidance.

For further 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.